Collision detection vessel - vessel

[kuddel]

I agree about "it might get too many points soon". There are some convex hull aproximation algorythms out there[1] that might help to make a good hull out of far less points.
A factor (lets say from 0.0 to 1.0) might need to be provided to give the best result with the fewest points.
That aproach however would need a tool (GraphicsClient) to visualize that hull, in order to see what parameter works best.
That "less-than-perfect" hull would then be calculated at runtime once at startup, or -even better- at compile-time by another tool...

...and here we go again towards the "uh, that sounds complicated" part

[1] e.g. "gift wrapping",

"A SIMPLE AND EFFICIENT APPROACH FOR 3D MESH APPROXIMATE CONVEX DECOMPOSITION"​

or this git​

(The NCC-1701 vessel however is a hard one! ...With shields up however...piece of cake )​

 

[GLS]

That "less-than-perfect" hull would then be calculated at runtime once at startup, or -even better- at compile-time by another tool...

I'm sorry to be looking at this from a Space Shuttle point of view, but how would the Payload Bay Doors be handled? Or the arm?

 

[DaveS]

I'm sorry to be looking at this from a Space Shuttle point of view, but how would the Payload Bay Doors be handled? Or the arm?

The bounding boxes would have to be tied to the animation sequences.

 

[N_Molson]

Yes, all the addon devs would have to do is to provide "collision meshes". Those could be parented as child to the "visual" meshes and inherit from their transformations. That should work.

 

[n72.75]

Yes, all the addon devs would have to do is to provide "collision meshes". Those could be parented as child to the "visual" meshes and inherit from their transformations. That should work.

I like this approach.

 

[n72.75]

This topic came up in a discord discussion recently (SFS), and I thought I'd share this old blog post from 2006 http://djvader.blogspot.com/2006/11/bumping-into-things.html?m=1

Iirc there was a video demonstrating it but I can't find it now.

 

[4throck]

Yes, all the addon devs would have to do is to provide "collision meshes". Those could be parented as child to the "visual" meshes and inherit from their transformations. That should work.

I guess one would need to keep the same number of groups for consistency, but yes, it should work.

 

[Abloheet]

Can the collisions be handled on a seperate thread of the cpu? I guess, by default, it would be calculated by the main thread, which is also commanding the gpu, calculating MFD updates, running vessel code.... Orbiter needs to go multi threaded. It has already started to with orbiter 2016, loading terrain on a seperate thread, now the goal will be slowly shift out tasks from the main thread to other threads, leaving it only for commanding the gpu mostly, while we are on DX 9. When we get to vulkan, then every thread should be able to communicate with the gpu

 

[GLS]

Can the collisions be handled on a seperate thread of the cpu? I guess, by default, it would be calculated by the main thread, which is also commanding the gpu, calculating MFD updates, running vessel code.... Orbiter needs to go multi threaded. It has already started to with orbiter 2016, loading terrain on a seperate thread, now the goal will be slowly shift out tasks from the main thread to other threads, leaving it only for commanding the gpu mostly, while we are on DX 9. When we get to vulkan, then every thread should be able to communicate with the gpu

I don't want to send this thread off topic, but it might be somewhat "easy" to split the current thread into 2: one handles the physics, and the other handles the graphics and would request the "state of things" to draw them in the screen. This would allow the physics side to run at a much faster rate, and it would probably help the fps a bit (depends on the physics-to-graphics ratio).
But there are some questions though:
What should be time step length in the physics thread? Fixed, or full CPU load, or related to the graphics thread rate?
Would it be noticeable in the physics thread when the graphics thread executed? And if so, how bad would that "oscillation" be?

 

[Sword7]

Yeah. I did not see any collision detection in that orbiter code for vessel collisions but only collision detection against surface in AddSurfaceForces function call in Vessel class. That needs to be implemented.