Discussion of GE Physics Panel suggested changes

Hi folks,

I’d appreciate some feedback on this potential change to the Blender GE Physics panel.

The theory behind it is that a user could pressed Dynamic on a model, and should expect the model to fall, collide and rotate as expected. If they did want a more specific behaviour ( eg no rotating ), then they could set this, but the default behaviour would be “real life”.

I’ve attached an image with more info - let me know what you think!

I’m going to start coding a patch for this so that people can try it out, but of course I’m not expecting to commit it unless it is actually going to be better than the current setup, and has majority approval.

Best regards…
Mal

There has already been a suggestion on IRC …
Remove the No options ( No Rotating and No Sleeping ) and have positive options ( Allow Rotate and Allow Sleep ), which would be on by default ( thanks to ZanQdo )

Mal

I think this would be a good addition. I remember wondering why the defaults were weird…

Hi Mal… the thing to remember is that the terms should conform to standard 3d graphics terms… not specifically terms to make it easier for people new to 3d graphics… so if the terms do not correspond to a physics engine then you will confuse the crap out of people with 3d experience who are trying to use the game engine… (these will be the largest group of people using it)

In the same way when an traditional 2d artist learns the names of the medium and tools at their disposal… only then do they learn how to use those tools and mediums.

Basically the concepts of a how a physics engine works would need to be taught first to students before it gets compared to real life… because it’s not real life… just a rough approximation of collisions… so if they don’t understand that, then they won’t be able to manipulate it to get more artistic and realistic simulations. E.G. if you undertand that the rigid body produces collisions you can create a particle system that emits sparks and dust where the car collides with a crash barrier…

Also coming from using other applications the terms are correct and correspond to what they should be… so it will make it incredibly hard for experienced people to use if you dumb it down for beginners… the beginners will one day become experienced… then use another 3d app and get confused with the non-physics engine terms and be frustrated because they learnt the incorrect term to refer to rigid body convex hull?

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…

–>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…

also the reason why it is like this is because when intermediate users use it, they need to custom set-up their scene quickly… it’s a usefull convention to follow.

my problem with the Dynamics button is that if I hit dynamic it becomes sort of like a rigid body and is affected by gravity… when what I want is a cube that is a ghost and can register collisions between other static objects as well as other dynamic rigid bodies…and NOT be affected by gravity… so I want an object that just sits there and can only be moved by dloc and drot but can still detect collisions between absolutely everything.

-bounds should definitely always be an option because again not all objects need to have bounds on… so that would be destroying functionality that a new user doesn’t realise they might need at a later stage…

so is the game engine meant to be easy for new users or is it supposed to have all the tool and functions you need to make a good game…??

I suggest doing this… ask the students again when they have some experience… and have completed some complicated games… what they think then. It’s only when you have to use the tools over and over do you appreciate how they are setup.

So I think you should be take into account the opinions of new users,intermediate users, and expert users… (which your are kinda doing by posting here:yes:)

my last point is this… games will always involve programming and there are concepts in programming that just can’t be compared to anything at all… so how would you describe a state machine so a n00b could use it? It’s an impossible task… better to just accept that a lot has to be learnt before being able to jump in and start making games… (doesn’t mean it can’t be fun for students etc) First crawling then walking then running… then sprinting…

I would focus on making more tools for the game engine. .eg. having objects following paths, having a static object collisions, spawning particles where objects collide, LOD systems,cloth, bullets uprgade etc… but I did like you idea of making xyz fields colour correspond… and pls… no modal menu’s. unless it’s the utter last resort :wink:

There has already been a suggestion on IRC …
Remove the No options ( No Rotating and No Sleeping ) and have positive options ( Allow Rotate and Allow Sleep ), which would be on by default ( thanks to ZanQdo )
huh… by default your objects should go to sleep… and what do you mean by no rotating… that doesn’t mean anything? 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…:frowning:

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…

Thanks for your feedback toonist and kirado.

toonist wrote…
> 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.

Kirado wrote…
> 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…:frowning:

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.

Mal

Yeh exactly. The names of those things relate to real world rules (mainly in maths, physics etc etc) because these are the things we are wanting to simulate. The more science and engineering i study, the more i see these names coming up.

I think making a button called ‘no rotating’ is a bit primitive…

I realize it would be easier to understand for a lot of people, but i just dont think its appropriet. It all makes sence when youve been using it for a long time, theres just a small learning ‘bump’ to get over initially.

Generally I think this is great. Making the default behaviour as close to what you would expect to happen, will help a lot in debugging erratic objects.

That said, I really think the “Rigid Body” term should remain - certainly in the tooltip say something like “allow rotation”. As important as it is to make things easier for new people, they also need to learn what they’re dealing with if they expect to get anywhere.

Nice to see this stuff being looked at though!

you could just use ode

Kirado and AD-Edge,

I totally agree with naming, but…

Can you tell me what your understanding of a a Dynamic object and a Rigid Body is, and the difference between them?

In my understanding, they are both the same thing ( an object that will fall and tumble during the physical simulation ). So why have both buttons if they mean the same thing?

If they both do indeed mean the same thing, but one of the buttons really carrys out a different bit of functionality, then the button should be renamed to reflect this.

Mal

Well Dynamic object means that it is an object that is affected by the universe forces (gravity, other object pushing it) while Rigid body means that now we care about it’s shape and the interaction this shape has with the environment and the influences the universe can have with the object affecting parts of it’s shape.

You could say that Dynamic objetc is a simpler version of Rigid Body, because of the same is easier to calculate; making reference to physics that we study on school or college, Dynamic object would be the same as studying physics with punctual objects, while Rigid body would be the study using center of mass and torque.

Now you could say that in Dynamic object we can set the collition to Convex Hull too, but even doing so it doesn’t mean that if I apply a force to an edge of it, something different will happens compared to apply the force in the middle of the object. But in rigid body we care about the shape of the objetc, so if I apply force to the edge, and the center of mass is also calculated, then naturally the objetc will lose its balance and start rotating, instead to be pushed.

Im doing a course in Aerospace Engineering, and 2 of the first year subjects are Statics (ie forces/moments on objects that dont move) and Dynamics (forces/moments on objects that do move. (Moments are a kind of rotational force, around a specific axis)

We have done a bits with Rigid Body objects, but you just have to imagine that dynamic objects can move around etc, while for a dynamic object with rigid body can be rotated as well as moving around. Cloud_GL explained it much better than i ever could.

Its kinda the opposite to what i first thought though, youd expect something thats rigid as being stiff, and not able to rotate. Thats not the case however.

I do find it strange that an objects defult properties are sphere bounds though. Its probubly because Convex came after sphere (since spheres been around since the sumo days) and so no ones thought of changing it.

I like the changes you proposed in the OP, maybe the bounds should still be togglable but default ON.

CryEngine 2’s physics settings are much more organic sounding/seeming than blender’s.

@kirado - blender’s current state system/physics buttons etc. have a much higher learning curve than CryEngine2’s logic,phyics set up. To continue on the path that blender GE is taking would be purposefully making things more complicated for n00bs than they have to be.

The reason I say that is because there seems to be a mistaken exptectation fo complexity within the blender GE when things could REAALLY be MUCH simpler than they are.

Perhaps not a hardcore programming enthusiast’s cup of tea, but for the other 98% of the population, it’s really time for some changes such as what Mal is suggesting.

That said. FLOWGRAPHS. I was able to do in a matter of hours, with CryEngine2, as a complete novice, what it would take an expert an entire day to do inside of blender GE. If the Apricot team was using flowgraphs they could have doubled or tripled or quadripled the content of the gameplay systems that they have right now. :wink: Srsly. I wouldn’t lie about that.

and not to miss the point of this post, physics is also very simplified in the modern engines. Basically, you have these choices. You make a physics proxy OR you don’t. If you make a physics proxy for your mesh, then the physics proxy, WHATEVER THE SHAPE and VOLUME, will be physicallized while the mesh will not. If you do not make a physics proxy, then the mesh itself will be physicallized. To me that is just a more straightforward, less confusing concept for a beginner to grasp and it also allows you to retain baisic 3d concepts without having to paste the terms all over the UI, which like I said, can be daunting for a beginner. Why have someone learn these terms when it isn’t really necessary? Either you make a proxy, or you don’t. Case closed.

Now as far as Mr. CanDo is concerned I say “goe’own’hed’wif’yo’baad’sef

Besides that I feel like the enter game interface needs to be rearanged. I mean let’s use the viewport more plz! Let’s embed these options into the viewport. Maybe if you mouseover an object then it’s physical options will be displayed right above it’s head (toggled off and on) or something like that.

well, i want the anisotropic friction back XD mal, pause the mouse a couple of seconds over the buttons, the tooltips are really clear

however, the options should be rearranged in a better way

edit: here is a lame proposal

http://s2.subirimagenes.com/imagen/880717pantallazo9.png

I agree with everything in the first two posts, except I think objects should sleep by default.

edit: here is a new version, a bit better, but still lame

http://s2.subirimagenes.com/privadas/117845pantallazo9.png

what do you think?

I made a mockup too!

http://img148.imageshack.us/img148/6590/uimockuppb7.th.png

I’d make the rigid body on by default and you can do whatever for bounds, but make it disableable

I think we should be able to use anisortopic friction, aparently it still works but it’s not in the ui anymore?
I’d just put it between the main thing and the bounds, and in the same layout as the bounds settings like were Use Bounds is have Use Anisotropic Friction and where the menu is have 3 number inputs for the x,y and z of it

I think some kind of friction would be a good addition. While the bullet physics engine is capable of complex things like convex hull polytype collisions, it seems to lack sometimes when providing realistic friction. For example, some objects do not roll realisticly. If you try making a UV sphere with spherical bounds, rigid body etc. and add force actuators to it, you can speed up in one direction, then add force going in the opposite direction, yet there is no roll. I’ve found I can get it to the point where I’ve been able to make a ball is move at quite a speed in one direction without rolling, which is quite visually displeasing. As soon as the force is released from an object, world forces like friction and rolling should take priority.
Hope that makes sense.

I think some people are overlooking really what Mal wants to do. The default settings will be different, but that won’t prevent you from doing whatever you want to do. Hes not taking anything out, just changing what buttons are already pressed. I for one agree with it, some of my friends use blender to fool around witht the pyhics and all that. They always eend up thinking the engine is bad becasue of the waythe objts behave initially.