Bad English video, my mind was in another place , sorry



Added Convex Hull collision shapes to GameGuru.
In your .fpe use: "collisionmode = 9" To use a convex hull shape for collision.

This is way faster for the physics engine to process so its perfect for objects where you dont need a perfect collision mesh but still need collision. Like if you have 100 rocks on your level changing the rock to use convex hull will really speed up the physics engine.

BUG FIX: If you have fps drops due to collision on your level, you can use convex hull on the models to remove the fps drop.

GitHub:
https://github.com/TheGameCreators/GameGuruRepo/pull/584/commits/6229dea0742ce115df5d9f4511bd850bdb1108eb

Fantastic addition Preben, thank you .should speed up a lot of people’s levels

Dave

Nice work Preben, thank you. Will try this when I get the chance.

Awesome Preben

Reliquia....

Great Preben!
thank you mate.

Wonder if collision has something to do with soldiers shooting thru the walls?
Player takes convex hull, box, cyl as collision shape, but does the soldiers does the same?
In another words does the soldier takes a wall with let's say box as collision shape, as an object with collision than should avoid.
It is not natural soldier shooting/walking trhu the walls.

Fantastic stuff and a welcome addition for optimisation ..
Thanks Preben ..

nice job!
do you know if there is a limit to the number of points? i.e. if you combined a bunch of objects into 1 mesh how well would it be able to handle that?
also just curious - why does the chair make a ramp shape but the fence and altar don't when the only real difference is the rotation of the object? (if you lay the chair on its side it would technically be the same as the fence) - not that it matters, convex is a great addition, i'm just wondering if you know the reason behind it? i'm assuming it's because the logic works/calculates from top - down?

@smallg I think the fence is two separate models

Dave

Thanks Preben. I have just the level to test this on. Will report back outcome

Cheers.

Dave is right the model does not look as bad as it does in the video, it is 2 pieces placed together but not lined up correctly

also I don't think there was a FPS drop at the chair so the chair does not really need 9 I think 1 would suffice

@Preben thank you so much for the Convex settings I have just added it to FPE Creator

If the object is box shaped use box collision ( collision mode=0 ), if it is spherical or cylindrical then use those collision shapes ( 2 & 3 ) all of these are way faster than convex hull! (for cylindrical shapes the models Y axis must be the centre, i.e. like the barrels)

GG does have the facility to have objects built up from multiple physics shapes but I'm not sure how well that is implemented, so for example 'L' shaped objects could use two box collision shapes. (I think this is only implemented for static entities, extending this for use with dynamic entities would be a huge improvement!)

probably, i was thinking preben had welded the models to showcase the convex calculations... otherwise a box collision shape would be just as effective)

Have to be careful with AI im guessing or you could have them unexpectedly running up ramps ... although …. Run and jumping a chair could look cool

Outstanding. Thank you.

If your able to use box/cylinder/sphere collision you should it is faster , convex hull is faster then using the mesh for collision (or polygon collision) , so it should be used on objects that dont fit any of the predefined shapes, but where you still need some precision in the collision.

Here are some objects that would fit perfect for convex hull:



smallg: the limit is 100 points , i kind of tried to explain how the shape would be but ...
Put your model inside a bag and suck out all the air, and the bag will now kind of be your convex shape (simple explained) , thats also why the chair got that shape (with a ramp).

3com: "Wonder if collision has something to do with soldiers shooting thru the walls?" , dont think its the collision shapes , its properly the ray that are cast from the AI to the player that are inside the collision shape when cast, but thats another problem

@ Preben
Thanks for the explanation.
So another question:
If I've let's say a wall broken into several fragments after animation (physics, gravity and so on), does each fragment has collision?
or it lose the collision shape when the wall break into several chunks?

@Preben did you try convex with terrain collision? I saw some comments in the code about this - wasn’t sure if you were inviting people to test this (with some code tweaks) or you had already done so?

Cheers.

I didnt belive the physics slowed down the engine when the physics isnt really used? Good job anyway! One problem in the engine that I think is serious is that AI characters never follows the player if the player jump up on a box or a carhood, etc. There shourld be a commando something like "FollowPlrOnEntity" even if its high to climb for the AI, how bout a climb animation?(If it isnt already there)...

that's not really how the A* pathing works in GG because we only get 1 walkable plane by default - the terrain, it won't take into account navigating on objects unless you specify they are ok for it.
you would need to mark the objects as walkable - i.e. floor zones (or forcesimpleobstacle = 3 if it still works) and make sure there's a way for the AI to get up to that height - i.e. stairs or ramp or resetting the AI position after an animation (like a jump).

"and make sure there's a way for the AI to get up to that height"

Yeah, but thats a part of the problem, if You put a ramp in front of a carhood (For example) then the player get collision problems. Would be better if You courld just mark the entity as "AiCanClimb"...

3com: animated objects is handled different.
cybernescence: Yes did test it on the terrain and its not really useful

Cool. Could have done with that years ago Had several problems over the years where you can't have collision in a cylindrical lift for example.

Thanks Preben.

I believe that an entity always remains the same, and always in the same position, even if it is an animated entity.
I believe that the animation is executed and the object moves a few meters but in reality the object is still in the same initial position, without experiencing any change, the object that we are seeing a few meters beyond, really does not exist, is an instance of the model original, if this is so, the fragments of the object do not really exist and therefore cannot have collision, the collision of the object is still in the original object, and I am not talking about characters, only objects.
Perhaps we could know through the X file, how many chunks the object will be divided into, convert these chunks into static and assign them collision convex hull; although this may be a very crazy idea.
Or I may be totally wrong.

This sounds great Preben. So... this will work or not for dynamic entities?
When will this likely be available?

Anyhow, I'm going to give it a go ASAP because dynamic entities hate to represent
their true shape selves-- not really sure why, but my guess is that it has again to do
with trying to make cheap work of the low memory capabilities of 32 bit GG and
subsequent frame rates? Well, if this actually does represent "true clipping" on
moving, dynamic entities--- we have just made "one giant leap" for GG kind.

Not really anything to do with memory capabilities, it's more to do with number crunching.

The Bullet physics engine can handle any collision shape but the simpler the shape the better the performance, the simplest shape is a box, calculating collisions between boxes is mathematically pretty simple which is why you so often see demos with thousands of boxes to show off a BE implementation.

Spheres are also mathematically pretty simple, cylinders are slightly more complex as are cones.

Arbitrary mesh shapes are very complex and computationally very expensive so where possible the best approach is to break down a complex model into simpler shapes, GG can do this but IIRC it isn't implemented for dynamic entities.

Convex hulls are a compromise whereby a closest fit approach is used to reduce a complex mesh into a simpler less computationally expensive shape, in a lot of cases the resulting shape will match the visible shape well enough for most purposes.

For dynamic entities GG currently only allows box, sphere and cylinder collision shapes. If I read the OP correctly Preben has added another option, i.e. convex hulls.

Cone shape could also be added relatively simply and with a bit more work I reckon that multiple physics shapes could be added for dynamic entities. But arbitrary mesh collision for dynamic entities are never going to be a good idea!

When I first started playing around with GG there was a way of making a dynamic entity have mesh collision and in my first stab at the moonlander demo I did used the lunar lander model with mesh collision (and nothing else on the level!), I got single figure FPS when moving it around dynamically!

The simplest answer is to choose dynamic entities for your game very carefully to make sure they fit one of the simpler collision shapes.

@Preben :

Looking at the changes you have made it appears that the Convex Hull shape can only be used for static entities, are you planning on changing M-Physics::physics_setupobject routine to allow use for dynamic entities as well?