Anyone out there have a Tokamak integration object and example that works?
I have tried Boogles CTokamakSceneNode but its missing quite a bit - the rotation is also not updated.
Also, I wonder if making a scenenode is the right thing to do - it might be better to just have a game object include a node and then a physics node but to keep them separate - otherwise it seems to get complicated
The physics node will setup the tokamak info based on a scenenode's information and has an update routine (the game object would have an update routine that would pass through)
If noone has done this then I will start this ...
Tokamak integration
Boogle kindly sent me a copy of his tokamak app and objects - his approach is to create a tokamak scenenode which knows about the visual object it manages - but both the tokamak scenenode and the regular one need to be attached (separately) to the scenemanager tree - while it works i am wondering if there is a better approach - here is my private message to boogle which outlines the approach i am going to try ...
thank you boogle for sharing the code - this is how we move irrlicht ahead quickly!
----
boogle
i got your code compiled on my machine and it works!
but looking at the design i dont think its the best way to go - it means having separate nodes just for physics sitting off the rootnode - it also means that if someone changes the position of an object that will not be automatically reflected in the tokamak node(s) - also, having to make an id for each new tokamak node is a pain
one thought i had was that we could make a PhysicsSceneNode that holds onto a scenenode underneath - and only the PhysicsSceneNode gets added to the tree and it manages all the rotation, scale and geom information - it also should have a new physicsupdate method that can be called by an outside simulation timer - that way the scenenode is not updating transform info every frame which it doesnt need to do
thats one option - the open question i have there is if its even possible in irrlicht to make a scenenode not attached to anything
another option is to make the physics an animator - this works in the downward direction (physics changes effecting the object) but it doesnt work the other way (someone changing the objects position and the physics object needs to be moved as well) - but what might work here is that the physics animator has two new calls, preupdate and update - the preupdate makes sure the geom matches the object its attached to and is called before the simulator is pushed ahead - after the simulator is updated then the update is called on the physics object - the best case here would be in scenenode had a flad that said "something changed in my data since the last render" and if tokamak had the same flag on a geom - then we dont have to do the full updating in both directions each cycle
make sense? i am going to try to build the animator approach - thanks for sharing your code with me - i'll contribute back what i do as well
thank you boogle for sharing the code - this is how we move irrlicht ahead quickly!
----
boogle
i got your code compiled on my machine and it works!
but looking at the design i dont think its the best way to go - it means having separate nodes just for physics sitting off the rootnode - it also means that if someone changes the position of an object that will not be automatically reflected in the tokamak node(s) - also, having to make an id for each new tokamak node is a pain
one thought i had was that we could make a PhysicsSceneNode that holds onto a scenenode underneath - and only the PhysicsSceneNode gets added to the tree and it manages all the rotation, scale and geom information - it also should have a new physicsupdate method that can be called by an outside simulation timer - that way the scenenode is not updating transform info every frame which it doesnt need to do
thats one option - the open question i have there is if its even possible in irrlicht to make a scenenode not attached to anything
another option is to make the physics an animator - this works in the downward direction (physics changes effecting the object) but it doesnt work the other way (someone changing the objects position and the physics object needs to be moved as well) - but what might work here is that the physics animator has two new calls, preupdate and update - the preupdate makes sure the geom matches the object its attached to and is called before the simulator is pushed ahead - after the simulator is updated then the update is called on the physics object - the best case here would be in scenenode had a flad that said "something changed in my data since the last render" and if tokamak had the same flag on a geom - then we dont have to do the full updating in both directions each cycle
make sense? i am going to try to build the animator approach - thanks for sharing your code with me - i'll contribute back what i do as well
Interesting design problem - so i am calling the tokamak object an Animator but its not really - its not something that will be called every frame and its not even something that would be called on a timer - there is a central object that i will make that will handle the update to the simulator and then update each object using the animators
hmmm, also ran into the idea that it would be nice if scenenode had a userdata entry (like tokamak objects do) - in this way i could attach the physics animators to the scenenodes without having to make meta object as a container
hmmm, also ran into the idea that it would be nice if scenenode had a userdata entry (like tokamak objects do) - in this way i could attach the physics animators to the scenenodes without having to make meta object as a container
I dont see why it would need to 'not be attached to anything'one thought i had was that we could make a PhysicsSceneNode that holds onto a scenenode underneath - and only the PhysicsSceneNode gets added to the tree and it manages all the rotation, scale and geom information - it also should have a new physicsupdate method that can be called by an outside simulation timer - that way the scenenode is not updating transform info every frame which it doesnt need to do
thats one option - the open question i have there is if its even possible in irrlicht to make a scenenode not attached to anything
I suppose you're worrying about being able to call the update function on them in a manner similar to normal IScene nodes? You basically need to keep a 2nd scene graph (one just for physics). When you create a new physicsSceneNode, it attaches to the smgr as well as the physicsSceneGraph (or physicsMgr, or something). Then you can simply call physMgr->update(currTime);
I much prefer the PhysicsSceneNode idea to the PhysicsAnimator idea (though, whatever works..
)a screen cap is worth 0x100000 DWORDS
looking more closely at Boogles tokamak scene node i see that its not really separate - the physics node is on top and it contains the other scene node(s) it controls under it - the problem there is that if you want to change the position of underlying scene node you have to do it through the physics node - if the position underneath of the scene node changes the physics node will not have a clue (like if there is another animator messing with it)
hmmm...
keless, i think i agree with you - i think the physics have to stay out of the scene graph completely and have their own - there is a simulator and it holds onto the list of physics nodes in the scene
i forget how open inventor did this - i think they might have gone the other direction - i think they might have made the physics nodes as children of the node it controlled - thats another approach
it seems like there are categories of modifiers for scenenodes:
- individual time oriented (one animator modifies one scenenode)
- central timer oriented (a central timer/simulator updates and tells each animator to update)
- every frame (wants to be called every frame)
and there are two things an animator might want to do:
- effect the data inside the scenenode
- be told when data inside the scenenode is modified
in the case of physics this animator wants to do two things at the same time, it wants a central timer to tell it when to update AND it wants to know, at the point it does update, whether something has changed with the scenenode that matters
---
it seems like you have to go one direction or the other:
Direction #1 - Make a special Tokamak enabled SceneNode for each SceneNode type (so there is a one to one relationship)
Direction #2 - Make a tokamak animator that is attached to each object and your game object needs to manage the physics objects separately
the way that Boogle is going doesnt work long term - the physics node mess up the scenegraph and it will get VERY complicated (sorry Boogle, i think you code is great but there has to be a better way to integrate seamlessly with irrlicht)
hmmm...
keless, i think i agree with you - i think the physics have to stay out of the scene graph completely and have their own - there is a simulator and it holds onto the list of physics nodes in the scene
i forget how open inventor did this - i think they might have gone the other direction - i think they might have made the physics nodes as children of the node it controlled - thats another approach
it seems like there are categories of modifiers for scenenodes:
- individual time oriented (one animator modifies one scenenode)
- central timer oriented (a central timer/simulator updates and tells each animator to update)
- every frame (wants to be called every frame)
and there are two things an animator might want to do:
- effect the data inside the scenenode
- be told when data inside the scenenode is modified
in the case of physics this animator wants to do two things at the same time, it wants a central timer to tell it when to update AND it wants to know, at the point it does update, whether something has changed with the scenenode that matters
---
it seems like you have to go one direction or the other:
Direction #1 - Make a special Tokamak enabled SceneNode for each SceneNode type (so there is a one to one relationship)
Direction #2 - Make a tokamak animator that is attached to each object and your game object needs to manage the physics objects separately
the way that Boogle is going doesnt work long term - the physics node mess up the scenegraph and it will get VERY complicated (sorry Boogle, i think you code is great but there has to be a better way to integrate seamlessly with irrlicht)
I just thought of one major problem with marrying physics and graphics--
it wont work for Client-Server models. The server needs to keep track of everything in Physics format, and simply pass this on to the client, who will then draw it.
If we require the server to keep a graphical scene node, we'll likely be adding extra and definately unneccesary work to it.
the client will still need to have both phsyics and graphics (it does physics while interpolating objects between Server updates), so this might still work for the client-- but we'd need to have a version which is only physics for the server, but which generally comes up with the same results (so that when the client does get a Server update, it shouldnt find that is own physics were far off from that of the server's)
it wont work for Client-Server models. The server needs to keep track of everything in Physics format, and simply pass this on to the client, who will then draw it.
If we require the server to keep a graphical scene node, we'll likely be adding extra and definately unneccesary work to it.
the client will still need to have both phsyics and graphics (it does physics while interpolating objects between Server updates), so this might still work for the client-- but we'd need to have a version which is only physics for the server, but which generally comes up with the same results (so that when the client does get a Server update, it shouldnt find that is own physics were far off from that of the server's)
a screen cap is worth 0x100000 DWORDS