Opinions Please - Physics solution

#1

Quote:1. RigidShape - works but rigid object dont interact with other rigid objects, only scene objects and terrain.

This should be fixable in the engine. If you look at the function that resolves collisions between two Rigid objects (which could belong to vehicles or RigidShapes) you will see that there used to be code that applied impulses to both, but that is commented out in favour of code that applies an impulse only to the object that identified the collision. There's some nasty bugs in the commented-out version of course, but you should be able to approximate something that will apply the inverse impulse to the 2nd object.

#2 Have you tried PhysX yet? That's what I would go with, plus there's a resource for it.

#3 Yer PhysX looks like the one - I looked for the RigidShape collision checking and there doesn't appear to be any rigid to rigid checking - not in RigidShape anyway. I put in some console prints in there and it appears to work but I can't determine where the rigid to rigid should occur and why it's not happening.

RigidShape leverage the the Rigid code? Because I put a console print statement in there as well and it never goes in there.

I couldn't find the commented out code of which you spoke Sam.

#4

Quote:1. RigidShape - works but rigid object dont interact with other rigid objects, only scene objects and terrain.
2. ODEScript - objects fall through terrain.

Both of these are similar issues - collisions simply not happening. In the first case, it's likely that the collision mask for rigid shapes simply doesn't include other rigid shapes in it. I described what might be a cause of the second one in the other thread.

Gary (-;

#5 So are you making large dif's out of multiple small dif objects or multiple small .dts objects?

Sounds like a very interesting concept! Can I borrow that idea?

Tony

#6 Andy you could always try Havok. :)

#7 Andy, look into physX or Havok.
Hey Bill, wouldn't the havok engine have to go through the same process as the physX engine in regards to implementing the physics engine into all types of shapes, terrains, players and whatnot? If so, then wouldn't the physX engine be alot farther along in the merge process? (even though I think the last person working on it stopped) I haven't looked into the havok yet but you'd think the process would be the same. Either way, GG should pick one and stick it right in there for the next release. LIGHTBULB, Hey, just thought of something, why don't you, GG, pick a physics engine throw it in TGE/A and release ASAP :-) wink wink nudge nudge. Btw, has anyone actually tried throwing the havok engine in yet?

#8 I am still reviewing the Havok SDK and I think it "might" have an advantage over PhysX in regards to multiplayer.

I think for legal reasons either one would have to remain apart from TGE/A but could be officially maintained as a resource add-on by GG.

As it stands right now PhysX does appear to be the better option.

#9 @Infinitum3D - I was planning on using DIF - but the performance is horrible when I start firing at them or flying past them. So I will be using DTS's in 4 stages of destruction, and every hit releases a DTS object that looks like part of the building - plus lots of little bits. I need them to tumble down to the ground and roll around realistically.

@Bill - I'll check out Havok - but it's not for commercial use is it?

I'm probably going to go with PhysX in TGEA 1.7 to use polysoup as well - throw out all the difs and just use DTS's because I have to release at the end of June.

#10 @Andy - The Havok EULA seems to indicate a small 1 time fee depending on if you sell your product for more than $10, I think (I don't have the SDK with me at work right now). If I read it correctly Intel is picking up the tab for the developer. Anyone else read it that way?

Also have you tried the debris object. It's not exactly what you need but a good compromise.

#11 No, there is no fee. If you're selling your game for $10 or more you have to get a distribution license, which is free, it's basically them verifying that you've compiled in the required logos. Intel is picking up the tab for everything.

#12 @Bill - yeah I should probably use the debris object for now - it's just an effect anyway - but I do want the player to enjoy blowing up buildings with their miniscule weapons, so that when the aliens start blowing up buildings they will see just how much damage alien tech can really do.

@Scott - thanks for researching it. I will look more thoroughly into it soon.

Thanks guys! Thanks for all the responses.

#13 Just thought I'd chime in:

I've been toying with the recently released Havok SDK in what little spare time I have. Another benefit it has over PhysX is the integration at the asset level. You can integrate Havok properties within your models (Maya, Max, etc), export that, and load it into the game. This could mean a little less coding, or a different coding approach compared to PhysX.

There are base level libraries that ship with Havok as well. For instance, there is a ragdoll library. In PhysX, you must build the ragdoll from the ground up...joint by joint, limb by limb. I've done this, and it is a pain in the ass.

That's just my 2 pennies.

#14 Havok > PhysX.

Why do I think so? Well, from what I remember, PhysX has a terribly restrictive license, whereas Havok's seems to be the exact opposite. And as Michael said, there are certain things that PhysX lacks that almost everyone would like.

#15 Actually the physx license no longer sucks.

IANAL, but one of the big reasons for me disliking physx before was the licensing, but that's no longer the case. I emailed nvidia about it recently, and they sent me an updated EULA for it, and said that if you try to run the installer, that's the one that's presented. I presume he meant on windows, since the linux versions [that I looked at] still contain ageia licensing stuff.


And IMHO Havok !> PhysX, since freely available physx runs on more platforms than freely available Havok. Physics engines are no use if they don't actually work on the platforms you're developing for.

Gary (-;

#16 GG has stated flatly that they are not going to integrate any commercial Physics solution into any "official" release of their engine. What they are looking to do is make Torque much easier to integrate into any physics solution that you choose. This is another one of those situations where if GG tries to do something and please everyone they'll end up pleasing no one. There is no way to design a physics solution that will be satisfactory for all possible games.

The best opportunity here is for someone to create a company to sell an professionally supported extension to the Torque products to support one of the aforementioned physics engines. This will work as long as people realize that it will take a significant amount of time and effort to create and maintain, therefore it is something that you will need to pay for.

#17 PhysX and Havoc are used widely in major engines so to me both seem like they'd be saweeet, PhysX == Havoc in most cases. I have to disagree with with ya on that one Mark, It's this reason alone that makes me look on the net for an engine that has this ready to go, Unity3d, NeoAxis, XNA, etc. We are seriously having a tough time trying to decide if we should stick with GG for the next project or start fresh with an engine that has, what I think, today's industry standards. If it weren't for the AFX system, which I think is now the engines biggest and most important component, we would have looked else where long ago. I don't want to monkey around trying to pick which physics system to use and then spend hours, days or even months trying to merge it into the engine crossing my fingers and hoping for the best, that's wasted developing time. Because PhysX and Havoc are major ball players, I'm guessing most developers would be happy just to have one of them in and ready, I know I would. If people complain, then that's up to them to make the necessary changes. All in all, now that both PhysX and Havoc are ready to rip, I'd say analyze both systems and decide which one would benefit the engines the most and let'r rip. Don't fall behind.

#18 DALO you took the words right out of my mouth! i mean hell if having one physics engine built in as standard is good enough for unreal etc then its good enough for us. Physics is physics at the end of the day, GG just pick one and put it in, its the only main thing lacking in tgea and the only main thing making me keep an eye on other engines; and statments like "GG has stated flatly that they are not going to integrate any commercial Physics solution into any "official" release of their engine" makes me doubt torques future. when people come looking for an engine they are not going to pick the one missing a main standard feature! - new commers have started to ask the "has physics?" questions on the forum already!

as said above, come on guys! dont fall behind!.

#19 While it would be great for GG to integrate a commercial physics solution into TGE/A I don't believe it is that easy legally.
But as the torque community has shown in the past as, with ODE and PhysX , Havok will be integrated in some form. It is just a matter of time.
Most have our favorite resource or code snippet we add to our projects that aren't officially GG supported but consider useful or needed for a given situation. I think Havok will be no different.

If we wanted it sooner rather than later we could always offer some sort of community bounty to get it done.

#20

Quote:If people complain, then that's up to them to make the necessary changes.

If there's one thing I've seen consistently among (especially new) users, is that they do not understand that concept. Physics is a very difficult thing to make generic and useful for all purposes.

How do you balance the needs of someone making an RPG that doesn't care about physics ("I don't even have a JUMP button!") with the next guy who's making a Flight Simulator ("The thrust to weight ratios in this engine suck!").

To top it all off, there probably are some big legal hurdles to get over when integrating one of these commercial physics solutions into Torque. While the licenses may be nice and skippy for us as individual users, they are probably much more onerous for an engine developer.

Now, all that being said, I certainly wouldn't mind if GG were to suddenly announce that it is integrating Havok or PhysX support, but I'm just not expecting or demanding it.