Bringing down the house: Structural Demolition

Ok so I havent got round to contact the proffesionals listed below yet but I will be getting round to that soon I'm sure (actually not really 100% sure, finals in 2 weeks!). Anyway, heres another thing to think about.

At the very beginning of stated that the problem with video game software and structural analysis is that one was almost exclusively concerned with visuals (and minor physics I guess, like gravity) and the other was completely mathematically based with no visual aspect (deformations that are certainly too small to see). But when do we need to witness deformation and failure? Ok sure, like in Red Faction we can go around blowing stuff up and yes, it looks fantastic, but there is a realistic counterpart here. Say... the demolitions industry and the simulation software they run?

Well turns out a company used none other than Blender to do just that. So this is my a side project that I'm hoping might be able to give some more insight into how this works and how Blender can be applied. Will post again soon hopefully.

It`s not what you know, it`s who you know

So after a couple of midterms at the UofA im back at looking into this, I have a fresh approach to kick-start things. It seems I`ve been looking to contact the wrong people, or more specifically, ive been taking the wrong route to those I actually need to speak to. As far as computer whiz`s go, physics programmers probably come pretty high up the list, and it just happens to co-incide with the fact that most have managed to whip up a website of sorts (a blog mostly) detailing there steps as professionals and individual developments they make in their programming. They also have an email address (cha-ching!) which goes directly to them, and avoids those admin people who take one look at "university thesis" and immediately associate it any non-commercial enquiry which generally recieves the same bullshit response. So here's a list of people im constructing that may be able to help me. I only wish I had more of a programming background as some of their research papers are deep. Like Mariana trench deep...

Erin Catto - http://www.gphysics.com/ - erincatto@gphysics.com

David Baraff - http://www.cs.cmu.edu/~baraff/ - deb@pixar.com

Chris Hecker - http://chrishecker.com/Homepage - checker@d6.com

So I'll hopefully get round to contacting these people soon, and will post information on what they think about my proposal and any professional thoughts they may be able to contribute. I'll also add more people as I go, and eventually this post should be filled with a plethora of useful information that I can piece together to lead me in the next direction with my research. Fingers crossed!

This just in: Spelling and Grammer not important in video game industry

Interesting reply from one of the founders of the Newton Game Dynamics engine mentioned in the previous post. Quite simply, he rules his engine out of being anywhere near capable of any type of analysis. Perhaps I should have mentioned this is merely an investigation and that commercially testing his software is not planned. Oh well, will look into those names mentioned to see how they relate to what i am looking for.

"Dear Julio,

My name's Jaryd Carolin and I study Civil Engineering and Architecture at the University of New South Wales, Australia. I am currently completing a thesis based on the feasibility of structural engineering analysis in video games. This more leans towards the 'serious games' side of things and perhaps that a editing tool could be used for both architectural visualization and engineering applications. I read about your engine off the Leadwerks site, and I'm extremely excited about the fact your engine is one of few (if not the only?) based on accuracy (as this would of course be important in mathematically analyzing structures). I was wondering if you had any information about how feasible this could be? Specifically in terms of coding capabilities (I'm only an engineer and not too savvy on the ways of C++ and Python, etc.), future direction (is something like this a goal of physics engines, perhaps more specifically for greater realism in failure/destruction?) and industry demand also.

Any information you could provide is greatly appreciated, and keep up the good work with the beta

Regards,
Jaryd Carolin"

"I am not really a fan of mixing stuff peopel do for veideo game with stuff people do to where teh life of other peopel are could be a risk.

Newton is a Library designed for video Game, so althought teh equation are teh same use and Newtoniona Mechanic I do no have to abode for thier correctness.

Accademia physics is a different field and it is suggested to must higher standards that phusics for Video Game.

Please do not consider Newton for Graduation Thesis Material.
There are oteh sources of of information you cna go to, like teh work of Brian Mirtich and David Baraff and Chris Hecker
I am a Mechnical Engeneer and I hold a master of applied math, but to learn the how to now I studied those papers.

Please do no take this as bad, I jsut do not want to misalead you"

A Shortlist of Potential Engines

After clicking through almost every link of the Wikipedia page "List of Game Engines" (http://en.wikipedia.org/wiki/List_of_game_engines) I've narrowed it down to this short list of new and developing engines:

• PhysX (Nvidias all purpose gaming engine, used in countless games including the recently released Batman: Arkham Asylum game [http://developer.nvidia.com/object/physx.html])
• Havok (or specifically Havok Destruction [http://www.havok.com/index.php?page=havok-destruction])
• Crytek CryEngine 2 (and its editor Sandbox 2). Also CryEngine 3, recently released details show promise [http://www.crytek.com/technology/cryengine-3/specifications/]
• GeoMod 2.0 (Volitions Red Faction: Guerrilla engine which I've already taken a look at. Hopefully more info will be made available in the coming months as they develop new games using it)
  
• id tech 5 (currently under development [http://en.wikipedia.org/wiki/Id_tech_5])
• DX Studio (its physics are handled by PhysX, but it specifies its applications to also include that of architectural visualization [http://www.dxstudio.com/wiki.aspx?n=Applications%20Summary])
• Trinigy Vision Game Engine (also lists itself as software suitable for "serious games" including "architectural walkthroughs". Also has interchangeable middleware for third party software [http://www.trinigy.net/index.php?id=52])
• Itlit RelentENGINE (new engine, where "All Objects React based on Force Exerted and Environmental Resistance", definitely shows potential for structural engineering applications [http://www.itlit.co.za/tech/])
• DICE Frostbite FPS Engine (http://www.dice.se/)
  
• Leadwerks Engine. Perhaps the most interesting of all, working off an accuracy based purely Newtonian physics engine, Newton Game Dynamics (developer not confident/willing to look into structural application due to risks and inaccuracy). Already showing stunning visuals and definetely something to be looked at closer (http://www.leadwerks.com/index.html) and (http://newtondynamics.com/forum/newton.php)

Turning Failure Simulation into Success

So after sending an email to Volition (the makers of Red Faction: Guerrilla) I got a response that went somewhere along the lines of "details of how this engine work precisely are not available to the public". Understandable as it is an extremely modern piece of software and companies our out to protect their technologies, it is all commercial after all. Still and unfortunate development however. Nonetheless I was directed to a couple of interviews related to the information I was inquiring about, so here are some relevant snippets (Digital Foundry is a techonology website, Dave Baranec was a senior programmer for the game)

"Digital Foundry: In what way do you tinker with the mathematical precision of the physics to make a more crowd-pleasing effect? Is pure realism in itself a bit too boring for a video game?

Dave Baranec: One of my favourite phrases about game development is "we're not making simulations, we're making games". This is often used to chide a young programmer who is trying to get too fancy or complex with a new piece of code. A corollary is "perception is everything". Now, RFG is definitely violating this law a bit – to get a simulation that looks and feels as realistic as ours does, you have to go in and do some real simulation-y work. There's just no way around it. But as with many things in game development, our physical model is a very rough approximation of reality. Civil engineers use something called matrix finite-element analysis to examine the true forces acting on a complex structure. It's very formal, expensive, but ultimately unnecessary for a game. So, we came up with some approximations that don't look much like the real thing under the hood. What was important was to get a bunch of eye-pleasing objects flying around and crashing into each other in believable ways. Better to have a game than a mathematically correct simulation that takes 30 minutes to render a frame."

[Found at http://www.eurogamer.net/articles/digitalfoundry-red-faction-tech-part-two-interview]

"Digital Foundry: I suppose the real question here is just how much further can you push the GeoMod technology? Do you have any tentative plans for how you intend to push the technology in any potential sequel? Perhaps explosions that impact the terrain as well as structures?

Dave Baranec: In terms of an improved feature set, anything is possible. The original Geo Mod engine was a boolean solid operation engine, which made it ideal for terrain modification. While this is a distinct piece of functionality from Geo Mod 2.0, there's nothing inherently stopping them from being rolled together into one world. What I find really exciting is that the tech is trivially expandable as hardware improves. The core system is capable of doing much more than you see in RFG. What limits us currently is how much rigid body simulation modern hardware can do. In that sense, the engine is very much a mean nasty dog that we have to keep leashed (for now)."

[Found at http://www.eurogamer.net/articles/digitalfoundry-red-faction-tech-part-two-interview?page=2]

Now to break this down a bit. This statement from Baranec;

"Civil engineers use something called matrix finite-element analysis to examine the true forces acting on a complex structure. It's very formal, expensive, but ultimately unnecessary for a game"

; is perhaps of most interest. He makes a completely valid point here, games are designed to be completely visual experiences. There must be some point where we cannot visually realise the difference between GeoMod 2.0's approximations and real life structural behaviour. Any complexity beyond this is pointless.

This is still in the mindset that games engines and made for games alone. With the advent of such engines as professional modeling tools, we should see a shift in this thought. Also it's hard to say how long this transformation could take, considering the large population of the gaming community compared with that of firms willing to use this technology on projects. We can imagine two separate technologies developing, one for the game and one for the professional (each with a markedly different price tag). This is something that should be avoided. The price of the model creation tools for an engine is typically the cost of the primary game that utilises that engine ($100AU, much like how UnrealEd is packaged with Unreal Tournament and Sandbox II is packaged with Crysis) and it should remain like that as it is one of the softwares biggest draw cards. Prices can be lower because the purchasing community is larger, and splitting these communities would surely be detrimental to both.

Baranec also stated;

"What limits us currently is how much rigid body simulation modern hardware can do"

So what is "modern hardware"? Well typically we can assume its what the company considers an ordinary gaming PC's specifications. The computers that run structural software in engineering firms are likely to be faster and better equipped than this. As engineers we don't require the 'visual' aspect of structural analysis (or more poignantly, we don't need to witness a structures complete and utter destruction) but merely need numbers on the screen that indicate to us its stability and areas of weakness. If run separately to a full visual profile of the software could we expect "modern hardware" to handle it?

Red Faction: Guerrilla

This was taken from an interview with James Hague (Design Director of Red Faction: Guerrilla, which was released Jun-Sep 09) by a CVG employee (full interview available at http://www.computerandvideogames.com/article.php?id=198478)

"Surely you've had to send your environmental artists back to school to understand how to build structures that work? It sounds like a completely different school of training to what was previously asked of them...

Hague: They've been through the school of hard knocks. Early on, it was a regular occurrence for buildings to get put in the game and collapse on their own, because the load-bearing columns couldn't handle the stress placed on them. Eventually the artists became self-taught structural engineers, though we've had some catastrophic bridge collapses that should make everyone glad we're not a civil engineering firm."

Another interview tells us that the team used a physics engine known as GeoMod for this purpose, but used Havok for the collisions and particles (http://www.totalvideogames.com/Red-Faction-Guerrilla/feature-12500.html)

So is seems like early adjustments of this idea of structural engineering in physics engines is already causing havoc for design artists. Could the video game industry open up to structural engineers as the worlds they build further increase in complexity? It's interesting to hear this sort of statement as it indicates that level of realism we're now attaining.

On another note, Havok Destruction (released circa April 2009)  seems to be taking a similar approach. Although the game designers work on these sort of realistic physics of buildings just so that there destruction is more realistic, it will definitely help us as we consider buildings that we'd prefer to stay in tact. From the Destruction product guide (http://www.havok.com/uploads/Havok_Destruction_Brief_10Aug09.pdf):

"[Havok Destruction] Incorporates tools specifically targeting simple and multi-material props, destructible buildings, deformable objects and believable structures [resulting in an] unprecedented level of realism for structural mechanics, graphical effects and game-level design"

Constraints and... Clarity? An Exercise in Tangentiality

Where do we start with this idea? What do we need to have in order to make it work?

I thought about this for a while and, as the abstractness of this project may suggest, there seems to exist several technical constraints to my approach. The first and foremost is this; the game editor I use must allow solids to exist as individual dimensioned objects. A games engine applies its set laws of physics to each individual object, so if we have any intent to analyse a structure on a beam-by-beam basis, the structure must then exist not as a mesh import but instead as a sum of its smaller, analysable parts. Secondly, the physics engine must already have a concept of “force”, with the ability to apply point loads (or similar) as a minimum.

It gets more complicated from here. In game physics terms, what do we classify an ordinary beam. Is it a rigid body? Or is it a soft body exhibiting very high stiffness? The rigid body approach assumes no deformation, but that isn’t to say we can’t calculate it from the data we have. The only real advantage of the soft body approach is visual deformation that we can see in game. But really that’s not entirely necessary. We’re engineers, the maths will tell us the same thing. There is rarely intent to cause major visible deformation so there’s no outstanding reason to consider the soft body for this purpose alone.

Realising Purpose and Reason...

It is here that in lies the main concern with physics game engines in general. They are simply not concerned with what we can’t see. Considering I just eliminated the need for a component of the engine that is concerned with what we can see, it almost seems that the two ideas of visual realism and structural analysis are at odds with each other. To think more positively however, the co-existence of these two ideas in one piece of software leans towards a more well-rounded package, each covering the others deficiencies. If games are trying to replicate reality, it is about time it considered what goes on behind the scenes. There is a lot more to reality than what we can see.

It’s here that we can see how a software package like this would be useful to the engineer and architect. The development of an underlying physics system concerned with engineering behaviour along with the amazing visuals that are drawing nearer and nearer to actual vision definitely brings us closer to encompassing a truly “real” experience. You might say however that programs such as the Autodesk Revit suite already contain individual software which functions like this, and that this is a particularly foolish endeavour considering the years of development already put into them. Maybe, maybe not...

To me as an engineer/architect, it comes down to this. We design and construct buildings for their placement in the real world. If we intend to model such buildings then we need a piece (or pieces) of software that best represent this. That is they are the best representation of reality and everything that encompasses it. This by itself means nothing though. I have merely assured that the building can exist in the real world, nothing more, nothing less. It is the EXPERIENCE of this reality that sets apart these two different streams of software development. Games, especially those designed in first person, are designed to be LIVED. You are an integral part of the environment, you witness your surroundings the way you would in real life. A building does not exist as some series of still photos from high angles. Nor is it a fly through or wireframe. The real experience involves interactivity with the architecture, exploration of its detail, moving through its human traffic and identifying area access and flow of people (through AI). If we can experience a building like this before it is built, take into all the possible considerations of its operation, then we can be sure that we have produced a building that is at its maximum efficiency with minimal flaws. This results in not only much greater client satisfaction, but architecture perfectly attuned to its defined purpose. Revit can create this reality, but it cannot create its experience.