WiP Shooter

Share with us how are you using the powerrrr of the force

Moderator: Alain

WiP Shooter

Postby Marc » Mon Jan 31, 2005 2:27 am

Hi !

I'ld like to show you my progress on combining Newton with Ogre and my NetworkingLib:

Image

If you want to try it, you can download it from http://rochel.s83.deinprovider.de/wip/wip.7z


Known Issues:

Problems I'm aware of:

- Probably the system gets out of sync if tried in
Multiplayer mode. This is hard for me to try right now
because I have only 1 pc where Ogre an Newton run
correctly on.

- Gun 1 needs some tweaking, especially sometimes some
cubes don't react if you try to pull them. Moving a
bit around and trying it again makes it work.

Problems related to Ogre:

- Some cubes are flickering. I have no idea of the reason why.

- When switching the guns, their models stay fixed at
the position where you switched them in world space.
I don't know why. I define an overlay for each gun
and show and hide them according to the selected gun,
but instead of hiding the gun attached to the overlay,
it seems like it just disconnects the model from the
overlay somehow.

- Dynamical creation of Particle Systems are pretty slow,
at least the way I do it. If you take the second gun and
shoot, the framerate drops drastically on impact of the
projectile, exactly when a new Particle System gets
created. If I don't creat a Particle System then,
there is no slowdown.
Right now, my code to create a Particle System dynamically
looks like this and the first line is the one that takes
much time:

psys = ParticleSystemManager::getSingleton().createSystem(s, "Particles/Explosion");
vis = visualization->mSceneMgr->getRootSceneNode()->createChildSceneNode();
vis->attachObject(psys);


Problems related to Newton:

- The cubes sink into each other when you try to stack them.
I probably have to tweak the properties of the bodies
somehow.


If you have some tipps how to deal with these problems I'ld like to here about it.
If someone has some nicer models than I have and is willing to contribute them,
that'ld be cool :)

-
Marc
User avatar
Marc
 
Posts: 281
Joined: Sun Mar 14, 2004 4:07 pm
Location: Germany

Postby Julio Jerez » Mon Jan 31, 2005 2:46 am

I do not know what kind of compression file is that, I could not unpack it
You say the boxes sink into each other, what units system are you using?
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Postby Marc » Mon Jan 31, 2005 3:09 am

That's 7zip. I already thought that it may produce some confusion, but since my bandwith is limited at the moment, I choosed to use it anyway. You can get it here http://www.7-zip.org/

Yes the boxes sink into each other. I use 1 unit=1 meter. So the boxes on the screenshot have 0.5 m edges. As gravity I use 2*9.8. Just 9.8 looked like gravity was not strong enough. When I just use 9.8, the boxes do not sink into each other. The boxes have a mass of 0.25 and these tensor values are all 0.25. I use a fixed timestep of 0.016.
User avatar
Marc
 
Posts: 281
Joined: Sun Mar 14, 2004 4:07 pm
Location: Germany

Postby Julio Jerez » Mon Jan 31, 2005 3:40 am

That should work correctly, it should work even if gravity is higher than that. I still do not undertand why you are getting these erros, it does not make sense to me.
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Postby Marc » Mon Jan 31, 2005 5:03 am

Did you try it and saw it for yourself? Perhaps it is correct the way it is and I'm just assuming it should be better but it shouldn't.

By the way in that binary, I don't define a material graph and also didn't change the parameters of the default material.
User avatar
Marc
 
Posts: 281
Joined: Sun Mar 14, 2004 4:07 pm
Location: Germany

Postby Marc » Mon Jan 31, 2005 6:32 am

Since you wondered about my sinking cubes, I investigated this a bit.
I guess I know now the reason why this happens. Let me start a little bit in front of the actual problem.

For my networking I need a deterministic behaviour of my gamestate. That is having a state S0 and some input I0, calling the process function, I always get some state S1. When I was starting to include Newton physics in the state definition, I tried the following:

1. Setting up some state S0
2. Process(including NewtonUpdate) a few times until I get a State S1
3. Process n times until I get a State S2

What I needed was the ability to do the following:

1. Setting up State S1
2. Process n times until I get the State S2

Therefore I had to save somehow State S1 from the previous running. I tried to save the bodymatrix, velocity and omega, but I didn't seem to be enough because I never got S2 when I tried to rebuild S1. Probably these 3 things are not information to save a state of Newton's simulation. (By the way I disabled the autofreezing for all bodies.)

But then I found yome workaround to this problem, I guess you already imagine the worst ... ;)
Before every call to NewtonUpdate, I remove all bodies and recreate them. Then, bodymatrix, velocity and omega seem to be sufficient to rebuild a state of Newton. I also figured out that I don't have to rebuild the static geometry e.g. my static treecollision building the map.

Now I tried to remove the rebuilding before every frame and the boxes don't sink into each other any more. I guess the additional information I'm not able to get via Newton's api, also the information I discard by rebuilding the scene every iteration, is exactly the information that is needed to stack the boxes correctly. I wasn't aware of that and didn't thought of that possibility until you wondered about that a few posts ago.

If this is all right, then I'ld like to make a feature request to Newton: I'ld like to be able to serialize Newton's state (perhaps without the serialization of treecollisions) so that I can rebuild a state and call NewtonUpdate with the same parameters and I get the same results. Perhaps adding some NewtonBodyGet/SetMagicData() function or, if it is not possible on a per body level, just some NewtonWorld(Un)Serialize(). It wouldn't make trouble if this serialization gets large, it doesn't get sent over the network. The only thing I need it for is to be able to go back a few milliseconds if I need to (depends on the method my Networkinglib works).

I know depending on the inner workings of Newton this might be complicated.
But I think being able to save and restore states is a key feature in synchronizing physics over networks.
User avatar
Marc
 
Posts: 281
Joined: Sun Mar 14, 2004 4:07 pm
Location: Germany

Postby Marc » Sat Feb 05, 2005 11:05 am

I finally managed to keep the boxes from sinking into one another:

Image

I discretized my time even further and only rebuild the Newton scene every 8th frame. This seems to be sufficient to keep stability.
User avatar
Marc
 
Posts: 281
Joined: Sun Mar 14, 2004 4:07 pm
Location: Germany


Return to User Gallery

Who is online

Users browsing this forum: No registered users and 21 guests

cron