Tokamak + Irrlicht (code release 0.5 !!!)

[buhatkj]

what i have managed to find on that subject, of whether to use just a sort of dead reckoning between the client and server says that it is not preferred, but in most cases unavoidable. of course the server always has the last say, but in most games it is judged that the little bit of jitter when the server "corrects" the player's position is considered acceptable as long as it is getting those correcting updates as frequently as possible. naturally you cant sync the position every frame and expect to have a playable game...so of course we do it on a timer. the real question is HOW OFTEN?

the bottom line is, if you are lagged, no matter how well written its is, any real-time game is gonna suck hard.

for fmorg what im trying to do is make the actual network messages as succinct as possible to hopefully minimize the lag, and to run ALL movement on timers, do nothing based on framerate.
several ideas have occured to me as to how i can help keep the game expeirence thae same for all, no matter how different their lag is.
not all of these may be good ideas:

-sort the message queue BY the lag, so the more lagged people sort of get preference in processing, since they have less preference in receiving time

-when client send a state change req, and server sends back the OK, account for the lag when setting the timeForWay in the animator to move them(on the client)...the idea being that they both hopefully arrive at the same time

of course, the more fast-paced i make the game, the more noticable the lag becomes, no matter what i do, since i can't seem to come up with any way to account for the fact that network messages just take time...

also the obvious way (to me anyway) to track lag is to timestamp all messages from the source and then check what time they arrived and subtract. is there a better way?

i think on a fast enough LAN i could prolly get away without really handling lag at all, but i would like it to work over the internet too, who knows, i guess i will just see what i can do with it
-Ted

[keless]

as we've started hijacking this thread with networking talk, I started a new one for that: http://irrlicht.sourceforge.net/phpBB2/ ... =6942#6942

my original question was just to ask PP if he thought I could use Tok to do intermediate physics on both ends at the same time, and be able to completely update the client's physics scene when it gets world updates. Is this possible? Efficient?

[keless]

Well, I think this is my last post in this thread cause you are not listening to me
[...]
2. I have a lot of programming experience (starting from ASM) so I can tell you that EVEN IF YOU HAVE 5000(!) animating nodes it means NOTHING!
[...]
So don't tell me that it can eat you perfomance...
[...]
Sorry, if you find I'm a little rough... I'm not - I'm just a little upset...

Im certainly not offended, and I hope you dont feel that way either. I do however continue to politely disagree with you about #2. Here is why:

While you are correct that having a bunch of little animators for each node processing each frame 'isnt that much,' its just not good practice. Why have an OMEGA(n) system running when you can have minimal calculations running at maximum efficiency at only little-o(n)? Furthermore, in actual implementation PP has shown that doing it your way drops the framerate drastically. Doing it his way gives 50FPS more!

[Guest]

[quote]
for each node processing each frame 'isnt that much,'
[...]
Furthermore, in actual implementation PP has shown that doing it your way drops the framerate drastically. Doing it his way gives 50FPS more![/qoute]

My polite answer

1. it's not 'isn't that much' - it's actually nothing. And it makes your code structured when you make all movements (actually even more generical - any animation) linked to the particular node that it affects.

2. Where has he shown this? If you take a look at Tokamak sources then you will see that I've made almost the same as PP did. (You can specify one sim for all nodes)... I just don't understand why do you want to put all eggs in one basket?
So the only point is to make one sim for all node but update node positions in their animators.

so I think that everyone still has his own opinion and there is nothing to discuss anymore

P.S.: anyway it will be useful to make an experiment (to prove your point of view )

[powerpop]

Guest:

I think you are right, I have not actually proved that you get faster frame rate doing things with one timer rather than in scenenode animators. The animator that held the tokamak simulator was called every frame and updated itself every frame - instead it could have looked the time and only updated itself when the elapsed time passed 15 milliseconds - that would make it more even with my timer based classes. But then there is still the problem of each scenenode updating its position and rotation - there would have to be some way for these individual animator objects to know that the physics sim was updated and then update their position/rotation based on those 15 millisecond clicks. Its possible to do. But then I think that having a central time manager will make the game logic much easier to balance and network sharing of data much easier to synchronize. If you distribute all the updates inside scenenodes its going to be hard to manage tradeoffs as lag and cpu differences between machines (in a network play scenario) become more important.

so yes, you are right, i can see a way to implement physics in scenenode animators - one attached to the node and one dummy node that handles the simulator updating

** did i read your post correct that you said one sim per scenenode - that didnt make any sense to me because tokomak requires a central simulator that models a group of objects that interact - you cant make one sim per object, it cant simulate that - neither can ODE or other physics engines **

keless:
tokamak over a network - i have that exact question - because tokamak does not like it at all if you mess with the rotation/position on the fly - but i read some postings in network code forums about integrating havok with network play and some techniques for doing it - i have to explore more of that because my game app is network based completely, there is no standalone!

[powerpop]

I added a list to the simmanager which handles the init and update of all pnode (physics nodes) - so now you just create the rigid body, add it to the manager and call init and updateSimulation - you no longer have to interate through your list of rigidbodies - i am going to do some more mods and additions - then release a tutorial and sample code - zip at the same url as before

[Guest]

Powerpop:
In the code I was sending to you there is a line in function animateNode()

Code: Select all

// save your fps :)
if (timeMs - Start < Refresh)
  return;

this means that you DON"T update node's position each frame but only ONCE PER REFRESH time. (Set Refresh to 15 ms...)

Keless:
Anyway, I'm giving up
The point is that I'm making a 3D interface for a program (not making a game) - so we have a little different requirements for timing.

Anyway, I think it would be useful to incorporate abstarct IPhysicsSceneManager intereface and support it in CSceneManager directly in 0.5 (e.g. like it is done with mesh loaders where you can use some predefined or create your own one and use it through the addExternalMeshLoader function).
Then functions like addAnimatedMeshSceneNode can be modified a little so they will have parameters such as "node_phycics_shape" and "node_mass". So the user won't be requested to add this node to some lists or anything else. Refresh time you can set up in simulator. If you don't want to apply physics to the mesh you can set zero mass or shape as EPS_NONE (EPS = enumeration_physics_shape).

[buhatkj]

powerpop:
have been watching this thread and checking your code out every so often. very impressive! looks like it should be possible to integrate into an existing project well, just create the simmanager, add some nodes to it, and call the updater. i like, i like. i definitely look forward to your tutorial, so i will know how to properly set up my workspace and stuff.
good work!
-Ted

[Boogle]

Hey powerpop, just checked your TokamakSceneNode code and found that you are using some code I made to make the body's inertia tensor (at least it looks like mine). You should know that it contains a bug I never got around to fixing On the cylinder scene node, once you have determined which direction the cylinder is facing, you have to rotate the geometry to match that.. The default is vertical (along y), so along x and along z must be rotated accordingly.

[powerpop]

ah yes, i did nab some code from your scenenode - i didnt know if it was yours or from the tokamak demos (still don't ??) - i also want to go back and rearrange it because i want to add a few types - thanks for your example to get me going - and feel free to nab other snippets back, like the euler angle code

[powerpop]

b:

thanks - i have been updating the code - i am adding a list to the simmanager so it will hold onto the objects for you - i am also working on a larger game framework - feel free to PM me if you are trying to use to the physics and have specific questions

[buhatkj]

so a tokamak rigid body is a simple un-animated object, right? that makes sense, but why is the other class called tokamakstatic body, when it contains a neAnimatedBody* body;??
i dunno if i understand the distinction properly there...i would think that the one that had a neRigidBody* body; would be considered "static" and the other would be something like tokamakAnimatedBody. just a clarity issue.
also do you plan to add a similar list to the sim manager to manage the animated bodies also? or is that not possible with tokamak?
tokamak has decent enough docs for the parameters of the actual classes, but i didnt see any description of WHAT these thing are or what they are meant to do. i suppose i am spoiled by the excellent documentation in Irrlicht
perhaps its in the demos, will have to see....
-Ted

[powerpop]

that is one quirk of tokamak - an animated body is a body that doesnt move (go figure!) - and a rigid body is one that moves - an body that has animation (like a MD2 mesh) is treated as a rigid body - i think the term rigid body comes from the fact that the mesh of the object does not deform on impact - this kind of softbody physics is not included in tokamak (cloth for instance or jello) - when i made my objects i renamed the animatedbody as StaticBody to hopefully make that piece a little clearer - maybe i will call rigidbody a MovableBody or something?

i will add a list for StaticBodys to the sim

and i have yet to add breakage of objects

[Robomaniac]

Is there currently ragdoll physics in Irrlicht Tokomak? If not, you might want to check this out. Its from the Ogre binding of tokomak. They used hinge joints to make it.

http://www.ogre3d.org/phpBB2/viewtopic. ... &start=100

just below the picture i think.

[powerpop]

thanks - i have been communicating with the guy who did the ogre tokamak code - he even sent me a copy - it looks great - ragdoll, i know what it does but how is it useful in a game (when a player gets shot he/she tumbles?) - one of those things that seems like you can do it but what effect does it supply?