Um, it's the GG physics settings in the FPE I need explaining! And more importantly which ones are actually implemented as a lot of them seem to not do anything.

For example, in my simple ball imported from a 3ds file, the importer created a 'physics shape' portion in the FPE file but also set the 'colision mode' to 1 which is polygon collision, a more sensible collision mode would be 2 which is supposedly 'sphere' but that doesn't appear to do anything (not implemented? PMs list says 'legacy').

If I knew what the settings should be, and what the 'physics' shape bit actually does (or is supposed to do) than I can dig through the code to see if I can improve matters somewhat.

The other thing I'm not clear about is does GG take any collision information from the models themselves? I know there are various model formats that can include such information but don't know if any of GG simply ignores it or attempts to use it.

The code is quite hard to decipher due to the 'real' model format that is loaded being the 'dbo' format so I suppose it depends a lot on what is stored in that format really.

@AmenMoses

I can tell you what GG should be doing using Bullet.
First Polygon collision shapes are for static objects only.
In Bullet it is called the bvhTriangleMeshShape, If you give this shape to
a dynamic rigid body it will cause a huge slow down and very bizarre behavior.
Second Bullet recommends not using the default primitive shapes( box, sphere,)
as these are actually slower than a convex hull collision shape for dynamic rigid bodies.
I know this sounds contrary to other physics engines but they designed it this way for better game
engine collisions. These are 2 major things GG is doing wrong.

As far as telling you what GG is trying to do it is pointless as I refuse to look back at the convoluted
mess the was the GG interface with Bullet. It had so many errors as you are discovering.
In my copy of the code I have already deleted all of that code so can no longer look thru it.
FYI: If you try to add code to the Bullet interface just remember what I said above Bullet itself has
been butchered so do not expect good results. Maybe Lee can help you.

Well so far just added pushing/pulling/throwing which seem to work reasonably well, hinges are ok-ish except that the collision shapes appear to be a lot bigger than they should be so if two dynamic objects are too close or the hinged object is too close to a static object I'm getting reactions between them that aren't pretty.

I've just started looking at how the shapes are being created from the model/fpe files but as you say it's rather messy and it doesn't help that there is a lot of 'X10' code and 'reloaded' code which appears to either be commented out or deactivated (i.e. reads things from file but doesn't do anything with it) mixed in with the 'real' code so it's not clear in many places which paths are important.

It's a lot like making sense of a Jigsaw puzzle with no picture and all the edge pieces missing.

@Stab : Thanks for the feedback on the current state of the physics system, I don't envy anyone's journey through the code! If you have time, can you elaborate on the two broken items you mentioned:

1. You mention giving 'bvhTriangleMeshShape' to a dynamic body which quite rightly causes a massive slowdown. Are you recommending that we use btConvexHullShape for any dynamic entities that are set to polygon collision?

2. "Primitive shapes slower than a convex hull collision shape" - Are you recommending that I generate meshes for box, sphere and cylinder shapes, using this data to create a btConvexHullShape object instead of using objects such as btBoxShape? The purpose being to speed up performance?

I can't throw away the entire physics engine just now as everyone is keenly awaiting the release of the DirectX 11 and PBR final release, but once that is out and stabilized, I think we can get a lot more aggressive on the code. In the meantime, I am just getting a solid handle on what is broken with the physics, and separately, what can be done to improve performance in the interim.

@AmenMoses : A lot of the commented out code was left in as the older ODE based physics could do more (had more DBP functions) than the newer Bullet implementation, and it was felt they would be needed putting back in at some point. I feel that time has probably passed and we can start cleaning up the code and removing all traces of the old ODE influence, which should make navigating what remains much easier. Can you also point me to the code that "reads things from file but doesn't do anything with it", as I can either comment it out for later deletion or find out why it's not connected up.
Thanks!

I've not really experienced too much issues with the physics engine yet. Only if the player is cornered between static entities the FPS drops by 40 frames per second. Also Just unsure of how flying objects and moving ground objects can retain physics while moving. Other than that I have had zero issues with physics as is. Though, this is just me. I'm sure there is room for improvements and enhancements.

Ok, so I keep hearing about this 'slowdown' but cannot really repeat it myself.

Here is a video showing what I get when 'colliding' with static entities:



Any drop in FPS appears to be dependent on the entity which indicates to me that it is nothing to do with the Physics part of the engine and more to do with the rendering. (I have noticed a marked drop when inside buildings but again it depends on the entities involved)

@AmenMoses : The physics does not run on its own thread so does not benefit from n-core acceleration, and as such it runs on the same core as the main game loop, and so the more intense physics work will steal cycles from the CPU that runs your main loop. The best way to trick the physics into taking a holiday inside its own loops is to create an EBE building with individual 1x1 cubes sprayed everywhere within a 300x300 area, randomly, on all three axis, then end the editing and do test game on the structure. The small polygons that make up the cubes (when interacting with the player capsule) all conspire to slow your FPS down.

Modern games take the view that the player capsule is not the size of a small cube and is in fact quite a large blob. Thanks to this, you can make your scenery's collision geometry much lower resolution when it comes to the polygons you use. Right now GameGuru uses the same geometry as the stuff that is visible, but by adding Convex Hull Meshes generated with respect to the typical size of colliding objects, you can reduce the work the physics engine has to do massively. You won't catch much harm if you make your world using entity box collision objects, but the moment you introduce polygon level collision some users will soon experience slow down as they get closer to those small polygon soups.

Here is an example of the FPS drain in action with all 3 snap modes:



I haven't tested this but by the sounds of it, all I really need to avoid this issue is to place invisible collision walls around the fences and other complex geometry. In the interim.

@Lee


Using the 'bvhTriangleMeshShape' in Bullet for dynamic rigid bodies is forbidden, it is for static only.
This is the fastest shape for static bodies. Bullet will allow you to make this mistake so it is up to you not too.
All the other collision shapes can be either static or dynamic but btConvexHullShape is the fastest for dynamic.



If you have a object that is a box(wooden crate) just create a btConvexHullShape from the mesh data of the object.
It will still be box shaped(convex) but handled as a convex hull by the solver which is faster than btBoxShape.

@LEE @AmenMoses @Teabone

Let me try to clear up the confusion. In the video below I have 2 fences that are using the 'bvhTriangleMeshShape'
what you call polygon collision if you could see the collision shape it would just look like the wireframe of the object.
The terrain is also using the 'bvhTriangleMeshShape' . With my current implementation of a Kinematic character controller
I am not getting the slow down as you can see in the video. In the PP2 version of GG the slow down is occurring when ever the character controller is in contact with 2 static objects regardless of snap mode or angle. For example if the 2 pieces of fence are in a strait line and the character controller is in contact with both of them. Try it and you will see it happens.
What I can tell you is that the problem is in the character controller. I can not tell you how to fix the bug in the character controller as it is a incorrect implementation as it does not inherit the class but uses it directly and has part of the Bullet core code deleted.

Warning: This video shows my version of GG

Are you able to apply a convex hull collision to a model with your version Stab?
I wonder if you want to try the saw blade.
It has the small polygon soup for the shape of the sawtooth so that would make a good test model.

EEEEEKKKK every time I see that fence I cringe I have done a new version here https://forum.game-guru.com/thread/217932?page=8#msg2597154

different variations with matching gates. the original Fence I did about 12 months ago I have learned a lot since then

In my version all dynamic objects are currently only using a convex hull collision shape.
I do not need to try the saw blade as the number or size of triangles in the model does not matter.
All convex hull collision shapes end up with less than 100 vertices if done correctly.
What does matter in the case of the saw blade is the size, as bullet has a minimum size of objects.
In GG the minimum size of objects is about 3.5 units. The saw blade probably is too small on its width
which may cause tunneling. This can be handled in code by scaling the collision shape on an axis to meet
the minimum size which would not be noticed by the user.

This video I made for DBPro but it gives you a better idea as you can see the collision shapes.

Ahh, that is the answer to the question why there is so much space between the chains after dropping them on one another.



Thanks for your reply and the video Stab.

Yes, but when attached via hinges or joints the collision between linked objects is turned off so even if the links themselves are visually quite small the complete chain should still move quite well. I wouldn't try to make a player wieldable weapon with it though (what is it with all the blood thirstiness around here? ).

What I had in mind is more atmospheric enhancement, hanging chains that move out of your way as you stumble around in creepy castle type thing.

I think for the time being we should stick to simple box collision objects for any physics demo stuff, at least until the Physics rework occurs.

That is sort of why i made the chain.

But then fwith a warehouse environment in mind.

This is where I am at present:



Basically the script hooks up the boxes then after 10 seconds the constraint holding the top box in place is removed. I haven't added the functions to set limits on the joint constraints yet (have them on single hinges though), that's next on my todo list.