At this moment, if the button is not pressed, a mesh object is converted to a physic triangular shape. If the user doesn’t want this, he must create a UV layer just to set the collision flag to false on all faces. This is not only a waste of time and memory, it was probably not the intention of the original coder: if you read the tool tip it says “Objects that are evaluated by the engine”. For me it means: objects that have a physic representation.
So my suggestion is to use the ACTOR button for specifiyng that you want a physic representation. If you don’t set the button, the object will automatically be collision free and the bound button will not be displayed.
Of course, to maintain compatibility, the ACTOR button will automatically set when loading older blend.
This change will create one backward compatibility problem: only objects with ACTOR flag set are detected by the Near and Radar sensors. Today, it is possible to define a static physics object that doesn’t have the ACTOR flag and is thus invisible to Near and Radar sensor.
Now my question: is there anybody using this feature? Does this change suits everybody?
I could also add a new “no physic” button, but I would find this really messy compared to a clean no physic -> static mesh -> dynamic -> rigid body progression.
I think this filtering feature on ACTOR for the Near and Radar sensors is something not useful.
I think I like it, but there should be a quick way to change this option for many objects at once. Either by selecting many or some easy coping option. The practical thing about how things are now is that the most common thing to create is (at least for me) static physic objects.
edit: or just make it (or have an option for making it) on by default
the filter feature for the near sensor reduces a lot of lag, if you dont have it then every near sensor casts a ray to every object every frame its active.
As long as current static meshes from current builds are automatically set to actor with static triangle mesh bounds in the newer builds I’m fine with that.
However, you should also make sure you can still turn off collision for faces in the UV options panel, that way current meshes with collision unchecked for faces, (but still detect the ray, radar, and near sensors), still work.
In other words, it’s a must that meshes that detect the ray, radar, and near sensors, but isn’t a barrier the object physically collides with, still work.
I fine the way it is, except the extra free memory will be nice. I have no problem taking the time to turn off the collision faces manually, I have bee doing so for years, thus it is just a common task to me. I never really knew the point of the Actor button, I always thought it was useless…
the filter feature for the near sensor reduces a lot of lag
I doubt that the filter on ACTOR is actually used. Keep in mind that if you specify a property on the Near or Radar sensor, this will exclude the objects that don’t have the property from the collision calculation. So filtering capability is still available through property.
you should also make sure you can still turn off collision for faces in the UV options panel
No problem: if you set the ACTOR button, the mesh will be converted as today, taking into account the collision flag in the UV layer. Nothing of the existing feature will be removed, except the filter on ACTOR.
just make it (or have an option for making it) on by default
Good idea, this way the standard behavior will be like today: default to static mesh.
there should be a quick way to change this option for many objects at once
It’s easy to create a script that will do that, the ACTOR flag can be set by scripting.
This sounds like a great idea to me. My only concern is the same one voiced by Gomer. If changing this will cause the Near and Radar sensors to lag, then I would rather it stayed the way it is right now.
I’ve been using the near sensor with property as soon as it was added. I was looking at one of my games and I do have quite a few objects with actor turned off littering the level… but they don’t affect the game.
I always just assumed that actor had to be on if you wanted the object included in a script or to work with properties etc. So I think your suggestion will be fine.
My main concern is will affect what I say below. (which after re-reading your post a few times… it doesn’t sound like it will be a problem I’ll leave it in if you feel like reading it.)
Anyhow my main problem with the physics right now is this. I make custom shaped collision sensors which are scaled a bit bigger and parented to a dynamic rigid body… I do this by pressing actor and ghost. I leave Dynamic off. I do this because I don’t want the collision mesh being affect by gravity and falling off the rigid body or dynamic object it is parented to.
I like to make it a bit bigger so it can detect a player before he gets to the actual rigid body.
Now this works fine to detect other dynamic rigid bodies… but if another actor/ghost object… intersects with another actor/ghost object, no collisions/intersections are registered. It’s like these static objects can only detect collisions with rigid bodies and not themselves.
Maybe the following isn’t possible?
So I would like to have some kind of clear distinction in the interface for the following: 1.static objects: -that are not affected by gravity. -but can detect collisions/intersections from other static objects (+ghost).
-They can be ghosts or solid.
-can be moved by dloc and drot.
-can detect collisions from dynamic objects (+ghost)
-can detect collisions from dynamic rigid bodies (+ghost)
-can be parented to rigid body/dynamic/ other static objects.
-works with near/radar/ray/collision sensors etc.
2.Dynamic objects: (already there)
-are affected by gravity
-can detect static objects (+ghost)
-can detect other dynamic objects (+ghost)
-can detect rigid body objects (+ghost) -can be moved by dloc and drot and forces/linv etc
3.Rigid bodies: (already there) -are affected by gravity
-can detect static objects (+ghost)
-can detect other dynamic objects (+ghost)
-can detect rigid body objects (+ghost) -can be moved by dloc and drot and forces/linv etc.
From these responses I deduct that people are actually using the ACTOR filter feature without knowing it. There will definately be some performance issue if I remove this facility… so I will leave it in.
Kirado, you have a very understanding of the current situation. Your collision mesh is a static object and Bullet automatically excludes static-static collision, which explains the lack of collision between two collision meshes. What you want to do is impossible today.
However, it would be possible by using the “sensor” collision group in Bullet. At this moment, this group is only used for the Near and Radar sensors. By adding a Sensor option in the dynamic button panel, you could put a mesh object in this group and with some tuning, make it work exactly the way you describe. It would be necessary to add at the same time some refined filtering capability at object level (property, ACTOR, python) to exclude the objects that you don’t want to collide with at the broad collision phase otherwise it will hammer badly the perdormance.
I put this nice idea on my (long) list of todo things. It seems that physics options still requires more thinking before changing anything.
The way default models become collidable triangle meshes for me is a good thing. Generally speaking, when a user creats a non-actor model / mesh, they will want it to be a part of the landscape ( otherwise they select actor etc for it to be a “live” object ).
If a user wants a more specific action ( eg creating the model as non-collision ), then they just press Actor and Ghost buttons ( rather than using the UV face technique ).
Maybe another way of looking at it is this - should untextured faces be allowed flags ( eg collision flag ), not just UV mapped faces. This would give two alternative solutions to the problem ( actor->ghost, or tag face ( UV or not ) with no collision flag )
One final thing - having to tag every newly created model as actor before it becomes geometry might become quite a pita after a while.
I can see your point though - a re-think of the current setup, taking into account what most people are doing ( for good defaults ), and any future enhancements to the GE ( eg potential Soft Body with Bullet ), can only be a good thing to keep it current.
ben, I’m disappointed to hear that you’re abandoning this idea. I think it would be very useful to have this sort of functionality in the Actor button. As it is, the Actor button is sort of useless as far as I can tell. The only time I select the Actor button is when I want to access the Ghost or Dynamic buttons.
mal, Actor >> Ghost is not the same as what ben is suggesting. Ghosts still have physics representations and are still evaluated by the engine for collision detection. Ben was suggesting that non-actors should not have a physics representation and should not be evaluated by the engine.
I agree that people generally want to have collision detection on by default, but wouldn’t it be easy to just having the Actor button turned on by default when a new object is created?
> I agree that people generally want to have collision detection on by default, but
> wouldn’t it be easy to just having the Actor button turned on by default when a
> new object is created?
It might be worth Ben implementing a patch to svn to try this out ( auto-turn on Actor for new meshes, and for previous .blend files created in older Blender versions ).
If it seems to work OK, I can’t see a problem keeping it in there ( as the collision on by default would be sorted out ), and if not, then it can easily be reverted.
blendozo: you didn’t get me right: I have abandonned the idea of using the ACTOR button for selecting if an object should be physicalized or not but I will still implement a top level button to enable physic on the object. When this button is not selected, no physic button will appear. By default this button will be selected.
This is very simple to implement and I’ll add it in SVN soon.
It would be good to hide some of the advanced settings, such as collision margin’ behind a button.
Just for some historic background: the ACTOR came from the previous (Enji) game engine, and SOLID took it over. I never had any intention with that ACTOR button for Bullet, but there might be some functionality behind it, that slipped in. Rather then having separate buttons for ‘dynamic’, ‘rigid body’ and ‘soft body’, shall we combine those 3 into a drop down menu? Dynamic refers to a dynamic rigid body without rotation by the way.
While we are at it, it would be good to start thinking about real-time soft bodies, and add a button for that too. Automatically converting every non-real-time soft body into a real-time soft body might not be desirable.
Last but not least, I already posted on the bf-committers mailinglist, there is some recent introduced issue related to vertex arrays read/write access. This file used to work for Blender 2.47, but it seems broken in latest subversion (80kb): http://bulletphysics.com/ftp/pub/test/blender/RealtimeWater.zip