DisableNewton

[Paul Thomas]

For some of us who want to use a different physics library than Newton. I don't care if blahA is better than blahB, it would great to have the ability to disable Newton (most likely after the Graphics call). One of the obvious reasons is because of the automatic phy file creation.

[TylerH]

I second this.

[TylerH]

If this unlikely/hard to do, it would be cool to know.

 

Just curious if we could get a verdict on how plausible this is, just out of curiosity?

[Josh]

I don't see much point in this because the attempts at implementing other physics libraries have not gone very far.

[Paul Thomas]

I have plans to use PhysX. Almost finished an up-to-date library for blitz and was thinking about how LE would react to it. First thing I remembered was the automatic phy file creation.

 

Once I begin using PhysX with LE I'll post up progress. I remember Masterxilo already implementing PhysX but I don't know how far he went with it.

 

I figured it would be easy to add a disablenewton method but I could imagine that it's more complex than I'm thinking. But I also think expanding the engine to cater to multiple physics libraries couldn't be a bad thing either.

 

I'll bring the subject up again once I get more progress going. Tyler, didn't you have plans to use Havoc? Can't remember.

[TylerH]

Yep, havok.

[Gardowyr]

I think Masterxilo's PhysX implementation looks like it's working very well - what makes you think it's not usable yet, Joshua?

[Josh]

The most I have seen is some boxes falling. I have not seen:

 

-Selective collision system.

-Interpolated physics with constant update speed.

-Joints

-Vehicles

-Terrain

-Character controllers

-Any of the features that motivate people to look at PhysX in the first place.

 

So the most I have seen is some experimental stuff that doesn't have nearly the same feature set as our current implementation. I'm not sure what the motivation is to pursue these alternatives.

[Masterxilo]

-Interpolated physics with constant update speed.

This is just a matter of passing AppSpeed() to the update function.

 

-Selective collision system.

-Joints

http://forum.leadwerks.com/download/file.php?id=969&mode=view

^^ those are held together by a distance joint. One can click on other oil-drums to make that thing "attract" these too.

In the testing environment I have, I can drag bodies around with the same technique.

(Is the clicking/selecting what you mean with "Selective collision system"?)

 

Every joint in PhysX can be created with ease.

 

-Terrain

 

-Character controllers

-Vehicles

Didn't have a look at these, but it would be as easy to do as it is in physx when using it with any other engine.

 

-Any of the features that motivate people to look at PhysX in the first place.

If these are things that deform meshes (cloth, soft bodies) or create graphical effects (fluids) then it's more difficult

beacause to either make them available (fluids) or make them work fast (mesh deformation), one would need better access to the rendering.

 

Everything else that just controls entity matrices is easily possible.

 

---

For example my system works this way: It attaches an le pivot entity to physx bodies. You can then parent any entity you want to that.

You can use the rest of physx sdk as usual.

 

---

Really, it's just a matter of using the physx sdk, there's no magic in there. Everything that works in physx will work in LE when using physx.

 

If anyone wanted to use PhysX, there's nothing stopping him. It's just a waste of resources to have a second physics engine running at the same time.

 

---

So the most I have seen is some experimental stuff that doesn't have nearly the same feature set as our current implementation.

If that means, you think that other physic engines aren't as good/complete as newton then that statement is ok.

If you're saying that it's not possible to use other physic engines to their full extent, then you're wrong.

[Canardia]

LE should use an physics abstraction layer, which allows people to write their own implementation of physx, havoc, ode, bullet, etc.... Newton should be a default example.

[L B]

When Josh said he didn't see any of these features, he probably meant "Not in LE."

[Niosop]

The vids Masterxilo posted were using LE for rendering and PhysX for physics I believe.

[Masterxilo]

^^ yeah, I wouldn't have posted just some stuff simulated using physx if it wouldn't use le for rendering.

 

When Josh said he didn't see any of these features, he probably meant "Not in LE."

I know.

And then I said that this is no argument since everything possible in the physics engine is possible in le.

[Josh]

LE should use an physics abstraction layer, which allows people to write their own implementation of physx, havoc, ode, bullet, etc.... Newton should be a default example.

That's not feasible because each physics library is so different. PhysX does not support heightfield data. A terrain has to be made out of a mesh, and editing the terrain in real-time like we do is not possible.

 

So what is everything considered "disabling physics"? Generation of the .phy files? What about raycasts? They use the physics system. Should they be disabled? What should happen if the user calls a raycast command when physics are disabled?

[Niosop]

I'm pretty sure PhysX does support heightfields.

seems to indicate it and Unity uses PhysX with their terrain system. Although there might be differences in the implementation that make using it w/ LE's system unfeasible.

 

A flag to LoadModel that would allow you to bypass .phy file generation would be nice.

 

As for disabling raycasts, yes, you'd have to. If a person is advanced enough to be swapping out the default physics implementation then they should be advanced enough to add in their own raycast system using their selected library.

 

An abstraction layer could expose the code to the raycast/collision/all other physics related stuff. By default they'd call Newton functions but if someone wanted to replace the Newton stuff with PhysX/Havok/Bullet/ODE/etc code then the function names wouldn't have to change and existing scripts would continue working.

[Josh]

I meant a heightfield where there is just a pointer to the height data that can be changed at any time. PhysX heightfields can't be dynamically updated:

http://developer.nvi...?showtopic=3548

[TylerH]

Josh: You act like users to dumb, and you are the only smart person.

 

I think people would know not to use raycast commands if they disabled physics...

 

 

And I don't like PhysX. Havok heightfields can be updated dynamically and even deformed using collision dynamically, you seem to be basing all your hate against other physics engines only on PhysX. PhysX is pretty eye candy, so you shouldn't base your opinions/decisions solely on it.

 

Havok has been used in every game from A to Z atleast twice. I mean, all we are asking for is the ability to turn of Newton, shouldn't be that hard, nor does it require all this hypothetical non-sense and fan-hate.

[DaDonik]

Josh has just asked us the question what exactly we want

DisableNewton (true);

to do. Like he pointed out, disabling Newton would affect some

parts of the engine.

From my point of view he is in no way acting as if we are dumb

Maybe you should read in between the lines, Tyler

 

 

My 50 Cents to physX in LE:

I'm neither a hate, nor a fanboy of any physics engine. I just see,

that this "DisableNewton ()" command would cost Josh another

week in which he can't fix bugs or add any documentation or new stuff.

Masterxilo already implemented physX and shows us it works. IMO there

i no need for a DisableNewton () command , anyone using physX will

have a little overhead, but it will work.

 

When your game is nearly finished and you need every bit of performance

for the release, than pay him a few bucks to disable newton for you.

That way everyone is happy and Josh can go on, careing for the more

important things

[Josh]

Half-Life 2 is the only Havok game I know I have played, and when you push objects in the game, the movement is extremely jittery. Maybe it has gotten better in recent years.

 

There's been a pretty good case made by people wanting to use other physics libraries. I don't think I can support other libraries officially, because it is very hard to get all the functionality we have working with every physics lib, but I don't see a problem with other people implementing their own. I'll begin to design things with this in mind, and figure out exactly what it would entail to completely disable Newton.

[Marcus]

Half-Life 2 is the only Havok game I know I have played...

 

You need to play more games then.

 

Havok Made Games

 

I highly doubt any other physics engine comes close to the amount of published (and high profile) games.

[TheoLogic]

Havok is like Josh says pretty rough... It's used in 3ds Max, and I must say 3rd party libraries using PhysX do the job way better.

I must agree it would be nice to see PhysX in Lwe.

[omid3098]

you can see how many games made with each one of them.

[Marcus]

It is possible that the underlying engine isn't modularized like it should be. This is the same thing that happened with Torque.

[TylerH]

Thanks Josh, good to know that you will give it some thought and research time

[Paul Thomas]

Didn't know there was more posts in this thread, apparently my Droid decided to wipe out threads I haven't read when using quickly to skim through everything and then they're reverted when I get back on the PC.

 

Thanks for considering this feature request, Josh. Expanding the engine to allow multiple physics libraries is a plus in my opinion. Officially supporting just Newton is actually ideal. Leave it up to each licensee to determine what route they want to take and with the ability to disable Newton the option is completely there to make that decision.

 

Newton is definitely a nice physics library, I'm not against Newton, I just have my eye/mind on some of the features PhysX provides, or even Havok. All three are great libraries and I just thought it was a good feature request to ask a way to disable Newton so that there's an option to use different physics libraries.