Thanks for your feedback toonist and kirado.
> I think this would be a good addition. I remember wondering why the defaults were weird…
Part of the reason was that, historically Blender GE only supported spherical rigid bodies ( Sumo ). When Bullet was introduced years ago, support for lots more physical features were bolted on.
I def agree with the weird initial setup ( for new users, and personally as a more experieced GE user ), which is why I’m hoping to offer an alternative patch. Again, I’m happy enough to make the changes to try it out, even if it doesn’t get accepted down the line.
> so things need to be named for what they are eg. a convex hull is a convex hull… a rigid body is a rigid body… collisions bounds are collisions bounds…
Convex Hull could be kept of course, but polytope? I’ve used different physics engines as a coder, including Havok. and Convex Hull is used but not Polytope. The additional ( Shrinkwrap ) info is really just to highlight to the user the difference between Concave and Convex ( even after all these years, I still have to think for a brief second about the difference between the two ).
> also the bounds should be set to the least CPU intensive collision types possible… it’s > like this for all 3d physics engine… you start low then work you way up because not
> all PC’s are the same…
Agreed, to a point. Selecting a Convex Hull bounding volume gives great speed, but also visual correctness ( add in a ball or a crate, and they will collide correctly, and also be fast - a lot faster than Concave Hull ( / Original Mesh ).
However, if you currently set the default box to be Dynamic, it becomes a sphere - something that doesn’t make sense for any level of user.
Basically there is no way for Blender to know what high level bounds optimisation ( ie box / sphere ) that you want to place on a model, so it’s best to choose one that will always work, and that works optimally. Then, if the user REALLY wants to highly optimise a ball, they can select sphere ( default ), or a crate ( cube - not default ), or a barrel ( cylinder - also not default ).
> I would focus on making more tools for the game engine.
I wish I had time to do some of that - at the moment though, my workload means that I can only commit time to fix the type of UI related things that I’ve submitted to svn so far.
> huh… by default your objects should go to sleep…
That would still be the default option.
> and what do you mean by no rotating… that doesn’t mean anything?
That’s the default now - when you press Dynamic ( the model doesn’t rotate )…
> Not rotating how?.. you see an object can rotate and not move… calling it that is more > confusing… because then what does the Rot mean in the movement actuator…?? a
> rigid body has gravity and collisions and is moved via Newtonian forces… but a rotating > object… does what? Erwin called those things names with good reason…
Again, if someone presses Dynamic at the moment, they have the exact same issues that you just described above.
> edit… I really don’t want to have to go from now on and turn all of my objects so they
> do infact got to sleep… rather than have them sitting there wasting CPU cycles
> calculating collisions…
As mentioned above, sleeping would still be on by default.
The change would be rotating, which would be on by default ( it is currently off by default, until you then press Rigid Body ).
For most users ( and also it is the standard in eg Havok phsyics ), Dynamic = Rigid Body. Stopping rotation ( currently the default ) is like adding an additional constraint, and some people would require this ( eg having a capsule for your player collision in a character game / FPS, which can slide and jump around, but never rotates / falls over ), but for the most part, a dynamic object should fall over ( like dropping any object onto the floor ).
It’s good to hear different ideas like this, to all feed into the patch, and whether or not it gets committed.