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.
Posts
Post a Comment