Jump to content

Reactive Rigids for stock (3.6)


Recommended Posts

  • 1 month later...

OK, that's cool... Do I take this to mean you have achieved near-PhysX like reaction of RigidShapes? Because that looks like a PhysX build there :)


Would love to give this a try - I have a PhysX game that is being finnicky and I wanted to maybe rewrite it a bit to use RigidShapes instead, but the stock RigidShape was too clunky and not as smooth as PhysX when I tried originally, that's why we went with PhysX.


But if the same can now be done with only RigidShapes, would love to test that out!


Thanks

Link to post
Share on other sites

Private fork atm. There's been talk of revamping the physics plugins a bit for a saner inheritance setup than the current 'use a plugin for this set of classes and use stock with options for this other set', so not going to push for inclusion there till that's hashed on out.

Link to post
Share on other sites

Of course, that makes sense...


In my other game, I use the PhysX3 advanced plugin that Timmy and Andrew were working on... It's great but yes it had a few mods that had to be made to code outside the physx3 folder so it was not as benign as it could be.


I'm looking for any solution that provides good physics on objects, vehicles and players, but lets me add a lot of them to the scene and have them explode this way and that as I see fit, controlled through script. What we have with the PhysX3 plugin is good, but it still chokes out when I try to really push the amount of objects. I thought maybe your work with the RigidShapes may be something I could try to see if I can replicate the functionality I have, just with better performance and less overhead than the PhysX?


Looks great what you have there :)

Link to post
Share on other sites

The stock physics are actually a good bit slower that PhysX in terms of raw performance.


The stock physics however has the advantage of playing nicely with networking, unlike most 3rd party physics libraries, so that's where the tradeoff comes in.


if you want a sheer number of stuff flying around, looking at Bullet or PhysX is probably the smarter choice(if you're locking up PhysX, how many objects do you have moving around?)

If you want a smaller number of objects but ensure they all play nice with all clients, the stock physics is the choice.

Link to post
Share on other sites

That's kind of what we concluded before, hence why we went with PhysX... I was just holding out hope :)


Regarding our random PhysX-related lockups I mentioned, it was mostly when trying to play networked with other clients. Things got out of synch and things like racing games didn't work well networked. So I guess that's where maybe Rigids could be better?


As you say, it's a trade-off to think about I guess.


Thanks

Link to post
Share on other sites

Ah, yeah, that would make sense.


The issue with 3rd party physics libraries is that in order to get those excellent speeds, they have to handle everything themselves. That's why Torque sets up the physics world, and then passes in all the physics objects to it. That lets the physics sim have all the information in a compact little bubble so it can be as fast as possible.


The tradeoff to that is, for something like interpolation or lag compensation, where the server may need to directly step in and set an object's position again to make everything line up, it doesn't work because the objects are supposed to be handled via the one-way street for the physics stuff.


So yeah, if you're networking around and lag compensation and interpolation are critical(such as a racing game), then looking at the stock physics for those objects may be worth a try.

Link to post
Share on other sites

Paul, you're probably all over this aspect of it but if not, make sure you take a good hard look at whether you really need to network all the physics objects you're trying to network, ie are they all gameplay critical and interactive between different players? Because if there's anything that can be assumed to be only providing eye candy for one client at a time, you can simulate it and render it on that client and remove it from the network bandwidth. You probably already knew that though.

Link to post
Share on other sites

Thanks, yes I had read that before and it makes sense... In some cases I do in fact want the physics effects to be networked, so that one player could crash into a wall which would break into blocks, and those would get in the way of the following player. I tried this in my PhysX game with mixed results, it would work on a low level, but too many moving objects and one client would crap out.


I never actually did figure out how to exclude certain things, is that something that can be done in script when a physics object is loaded? During gameplay I have code that creates new physics shapes in real time, so that you have a tower or wall of TSStatic blocks that convert on-the-fly to physics objects when they are hit with a projectile. Works great, you can build a tsstatic prefab house of blocks and then explode it with a grenade :)


But I would love to know how to control which objects get networked, is that easy enough to do?

Link to post
Share on other sites

By default you're running a physics sim on the server as well as on each client, so if you want objects to run on the client and not get networked you would theoretically just say "simType=0" in the physicsShape datablock. I say "theoretically" because this actually hasn't worked for me, it seems they don't perform at all unless they are simType=2, which is client & server.


For my current ragdoll build, I ended up running my shapes as client+server, but put all my bodyparts on the client, and only put a placeholder physics object on the server - I haven't decided yet what to do with the server side, will probably change that to a player controller or a capsule and use it for collision detection.


Re: your crashing into a wall scenario, though, would it not work just as well to pass the event (driver crashed into wall at location xyz) and then spawn the actual physics blocks separately on each client? The game experience would be the same, the only thing different is each block wouldn't be exactly where it is on everybody else's machine. The lead driver probably won't even see the blocks because he's already speeding away though, so it shouldn't result in any noticeable artifacts.


If the players were actively throwing blocks at each other or something like that, then you would definitely have to network them, but for the case you describe it doesn't sound necessary.

Link to post
Share on other sites

That's a great thought... we actually do have the ability to launch physics blocks at each other with a block firing gun, and that already works networked without much issue, so I would keep the status quo foe that.


However, I see great potential in doing client side only physics for when the vehicles and block walls are involved, as well as other times when I have physics blocks raining from the sky...


Is it really that simple? If the physics blocks are client side, how does the server handle collision and damage detection when a client hits a physics block in those cases?

Link to post
Share on other sites
  • 9 months later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...