Shareing resources between instances

Shareing resources between instances

rbabiak's picture

Hi in our game we want to have a single server host manysmall user rooms. There will be hundreds of copys of the same basic room collision, then seperate placed colidables in each room.

This could lead to many GB of havok assets in memory if every room had it's own copy of the rigid body that makes up the room walls. Each room will be in a seperate hkpWorld instance, and we will be ticking each room in order on the server. so in each instance the room will be at the exact same location in all worlds.

Is there a way to make havok share a given rigid body between many worlds?

thanks

- Rob

6 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.
sean.thurston's picture

Hi Rob,

Networking is a tricky thing with physical simulations. Havok isn't really set up to share rigid bodies across multiple world. Rigid bodies can only belong to one world. There is a chance you could maybe share shape data, but I don't think that would get you too much in terms of savings.

Maybe there is a different way to approach this problem besides multiple world instances.

Let me know if you can give any more information.

Thanks,
Sean

Developer Support Engineer Havok www.havok.com
rbabiak's picture
Quoting - sean.thurston

Hi Rob,

Networking is a tricky thing with physical simulations. Havok isn't really set up to share rigid bodies across multiple world. Rigid bodies can only belong to one world. There is a chance you could maybe share shape data, but I don't think that would get you too much in terms of savings.

Maybe there is a different way to approach this problem besides multiple world instances.

Let me know if you can give any more information.

Thanks,
Sean

Thanks

We tried a experiment and things sort of worked untill shutdown. then KA-BOOM....

It would be nice if we could share rigid bodys for just the things that never move, like the ground.

The multiple instances is already a fixed game design, the shared memory would lett us run the servers closer to the full capacity, as it is we will have many duplicates of the same data. BTW we are not doing physics symulation for moving objects in the world. Just as a hi performance collision model. The movement of the players and other assets will be under strict game play controll.

On the client we will use physics to move fluf and other wow things that don't interact with gameplay but look nice.

Any other ideas?

havokchris's picture

Hi Rob,

Sharing rigid body (hkpRigidBody) instances is pretty much a no-no. Sounds like you found that out the hard way. The overhead for rigid bodies is relatively small though (~512 bytes, give or take), so unless you have a ton of "throw away" rigid bodies, the memory usage shouldn't be too bad.

On the other hand, sharing shape (hkpShape) instances is perfectly acceptable. This is probably where a lot of your memory is going, especially for triangle meshes and bounding volume (MOPP) data. Simple shapes like boxes and spheres are very small and probably not worth the bookkeeping overhead, but other shapes like convex hulls or list shapes probably are.

It might get a bit tricky handling all the reference counting, especially if you're loading bodies from packfiles. If that's the case, post some callstacks and/or assert messages and we can try to get to the bottom of them...

-Chris

rbabiak's picture
Quoting - rbabiak

Thanks

We tried a experiment and things sort of worked untill shutdown. then KA-BOOM....

It would be nice if we could share rigid bodys for just the things that never move, like the ground.

The multiple instances is already a fixed game design, the shared memory would lett us run the servers closer to the full capacity, as it is we will have many duplicates of the same data. BTW we are not doing physics symulation for moving objects in the world. Just as a hi performance collision model. The movement of the players and other assets will be under strict game play controll.

On the client we will use physics to move fluf and other wow things that don't interact with gameplay but look nice.

Any other ideas?

Actually looking at the rigid body class, it looks like the clone does this for you. I can load the rigidbody from a package and the clone it. According to the comments it will copy all non static data of the rigid body.

this should do what we want as it will share the shape data between the instances.

havokchris's picture
Best Reply
Quoting - rbabiak

Actually looking at the rigid body class, it looks like the clone does this for you. I can load the rigidbody from a package and the clone it. According to the comments it will copy all non static data of the rigid body.

this should do what we want as it will share the shape data between the instances.

Yep, that should do the trick. Just be careful if you do things like disable child shapes within an hkpListShape, since this will affect all bodies that share the shape.

-Chris

Login to leave a comment.