[Bf-committers] Game Engine / Physics issues

Mal mal at candomultimedia.com
Wed Nov 24 13:34:12 CET 2004


Hi Kester,

>First, a couple of bugs in the .blend: 
>1. The physics tic rate Python method is setPhysicsTicRate, not 
>setPhysicsTicRage.
>
Oops! ;)

>2. None of the meshes set to use polytope are suitable to use polytope, so it 
>is falling back to the previous method. (Check the console)
>
>To use polytope, all the vertices in the polytope (from faces with the 
>collision flag set) must be from the same material.  There is also a limit of 
>65536 vertices.  When the game engine converts a mesh from blender, it sorts 
>the polygons by material to reduce the render state changes required to 
>render.  The big gotcha (and the reason why in this case polytope is not 
>being used) is that triangles and quads create different materials.
>  
>
I can see where that is required for rendering.  For a physical 
simulation, an additional step ( where using the whole mesh is taken 
into consideration for calculating the hull, ignoring different 
materials or the mix of tris and quads ) might be required, otherwise 
any object with more than one material will never be able to be assigned 
a convex hull for speed.

>I still think it is unrealistic - worst case you have 8 intersecting objects 
>with 507 faces = 16451136 face intersection tests to do (based on n^2 
>algorithms - should check this.)
>  
>
The slow-down seems to occur nearly straight away, when there are only 3 
touching objects.  Again, this would have been because polytopes weren't 
used, I'll re-do the scene again.

>ODE support would be really good - the major reason sumo is the main engine is 
>because it is the original blender engine - it's quite difficult to map 
>blender's physics properties to anything but solid.
>  
>
If ODE offered enough advantages over SUMO ( eg it's being maintained, 
and used in commercial applications ), which would be of benefit to the 
future of Blender ( especially if the physics engine might be used for 
simulating scenes for rendering ), it might be worth dropping SUMO and 
taking on ODE, or keeping SUMO ( and auto-selecting it for old scenes ), 
and auto-selecting ODE for new scenes etc.

A physics wrapper would be useful... when I worked at NaN, Blender's 
physical properties were pretty confusing anyways ( and still are a bit 
), a complete re-design of the physical properties might be required 
anyway ( I think the games panel needs a separate options area, where 
you can specify the tickrate for the physics, sound, logic updates etc 
via sliders ).  Having developed quite a lot of physics based content, I 
can help out here with what a typical physics scene designer would be 
looking for.

To end, it's great to see this area of Blender getting some great updates!

Regards...
Mal


More information about the Bf-committers mailing list