Hardware Can Orbiter use PhysX?

Eccentrus

Geekernaut
Joined
Jun 26, 2009
Messages
859
Reaction score
27
Points
28
Location
Jakarta or Bandung
You see, most of the new NV cards is packed with a PhysX chip alongside with its GPU, it will be good if Orbiter can utilize it to calculate the physics, oh well, if this is off forum, I don't know where else to put this question.
 
The physics calculations are done by the Orbiter core, which is not open-source, so the community would not be able to add this.

Moreover, PhysX does not do physics calculations on the large scale needed for Orbiter--it's good for calculating local phenomena, but it would not correctly calculate, say, orbits.
 
I think though, you can use the API for doing orbit calculations. the problem will be though, that you use the PhysX for calculations, for which it is not made. Calculating only a small number of objects with complex relations is not it's task and might be even slower than using the CPU.

Multicore support would be more effective today, but I can understand if martins does not use it now - debugging multithreaded programs is always one level of magnitude harder.
 
It's not really a chip - it's a wrapper to implement the PhysX API through CUDA, and uses the same processor used for graphics - which is made up of many "stream processors", which are very specialized and mostly geared toward vector operations, which they are quite fast at. (A modern nVidia GPU can completely outclass a top of the line x86/64 CPU at things like Folding@Home).

Vector processing is useful for physics - but I'm not sure they are precise enough for Orbiters usage.

In any case, from my experience profiling other apps that have similar physics to orbiter, little time is actually spent in the physics calculations. The physics load of a modern FPS game is much higher than that of orbiter - many, many more objects, collision, etc., and they generally do well enough without needing PhysX hardware.
 
So then, is this just because orbiter usually conducts calculations of huge, very huge objects, and only a few ones of them actually, but if we're making a very realistic universe for Orbiter, such as thousands of satellites orbiting Earth and other planets, then it would eventually can be used?
 
The PhysX card is more effectively used for stuff like particle effects when cars are crashing and bullets hitting the wall. (If we simplify things...)

It doesn't bring any advantage when calculating orbits of objects.
 
maybe we could use it for collision detection when there is a viable implementation?
 
The PhysX card is more effectively used for stuff like particle effects when cars are crashing and bullets hitting the wall. (If we simplify things...)

It doesn't bring any advantage when calculating orbits of objects.

Then How about a Deltaglider crashing into the ISS, it would be spectacular if we can simulate the realistic effects on Orbiter.
 
Then How about a Deltaglider crashing into the ISS, it would be spectacular if we can simulate the realistic effects on Orbiter.

For what? We know that we have screwed up when the relative velocity is bigger than 1 m/s
 
maybe we could use it for collision detection when there is a viable implementation?


The thing is that such collision detection would probably have to be implemented through the Orbiter core and not through a DLL. And it doesn't seem like anything like that will happen any time soon.

I agree the multi-core implementation would produce the largest improvements, next to DX9.
 
There isn't much point, as Orbiter isn't physics intensive at all. There is a lot of calculations, but i believe they are mostly operated and executed on the FPU.
 
Then How about a Deltaglider crashing into the ISS, it would be spectacular if we can simulate the realistic effects on Orbiter.

My experience at school is that kids get bored when they crash and it bounces on the surface, and then they start to try to learn to fly instead of creating spectacular fireworks.
 
My experience at school is that kids get bored when they crash and it bounces on the surface, and then they start to try to learn to fly instead of creating spectacular fireworks.
QFT

Crashing gets anybody fustrated. It made me read the whole apollo 11 manual.
 
QFT

Crashing gets anybody fustrated. It made me read the whole apollo 11 manual.

And blowing up (or at least breaking up) would be even more frustrating than bouncing off the ground or docking target, thus, that much more motivating (and immersive). ;)
 
maybe we could use it for collision detection when there is a viable implementation?

Putting the collision detection in is one thing. Once it would be in, the load of it would be practically neglectable, since there are rarely more than 2 objects involved in the check. This would hardly need the GPU to help out with.

p.s: Artlav actually did a basic collision detection for the D.G. and the I.S.S. once (something he added to meshland). I think he would have come up with a way to make it better by now if he wouldn't be caught up in so many other projects. Once the OGLA-client is up and running, I'm sure it won't take long until we get collision detection (of course, how long OGLA will still take is a nother matter. But I'm sure we'll have it by tuseday.)
 
That collision detection was not limited to the DG and ISS. Those were simply the config files he provided.
There were some big problems though. Once we have a working collision detection I will continue the Furry Dicez :)
 
actually did a basic collision detection for the D.G. and the I.S.S. once (something he added to meshland).
The collision detection system was supposed to be universal, which is pretty much impossible in the add-on context. That's the main problem - it's the core stuff, not something add-on doable.
It can be done as special-case system, like on Shukra and in NASSP, but no general solution yet.

At it's best, that was Visosad capabilities:
Vessel-vessel:
 
So then, is this just because orbiter usually conducts calculations of huge, very huge objects, and only a few ones of them actually, but if we're making a very realistic universe for Orbiter, such as thousands of satellites orbiting Earth and other planets, then it would eventually can be used?

Well, it doesn't really have anything to do with the size of the objects. That's just a number, and the size of that number doesn't have much to do with how quickly it can be processed.

GPU's do a good job of taking a huge batch of data and performing the same operation on each data element. CPU's generally do single elements (or a few elements at a time for multicore) quickly and with alot of flexibility.
 
While the topic is open, knowing this is totally a 'what if' situation, wouldn't integrating a PhysX setup also serve to make aeronautic and possibly aquatic situations more realistic? Consider a scenario where a Sealaunch [tm] rocket must be transferred in rough seas or having partial effects of hypersonic flight and reentry generated procedurally instead of through set animations. Even more intriguing: modeling a realistic version of the proposed space elevator, which not only relies on orbital dynamics, but also oceanic / atmospheric conditions.

*Making Spell-check cry since 1982*
 
While the topic is open, knowing this is totally a 'what if' situation, wouldn't integrating a PhysX setup also serve to make aeronautic and possibly aquatic situations more realistic? Consider a scenario where a Sealaunch [tm] rocket must be transferred in rough seas or having partial effects of hypersonic flight and reentry generated procedurally instead of through set animations. Even more intriguing: modeling a realistic version of the proposed space elevator, which not only relies on orbital dynamics, but also oceanic / atmospheric conditions.

*Making Spell-check cry since 1982*
Again--PhysX is designed to be used on small scales, and it gives entirely too much detail for the purposes of a very large-scale simulator even if it could be used for such things. Orbiter would be far better off with a custom-designed "water" model which was "good enough."
 
Back
Top