Collision detection vessel - vessel

kuddel

Donator
Donator
Joined
Apr 1, 2008
Messages
2,064
Reaction score
507
Points
113
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",
or this git
(The NCC-1701 vessel however is a hard one! ...With shields up however...piece of cake :D )​
 
Last edited:

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,877
Reaction score
2,870
Points
188
Website
github.com
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

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
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

Addon Developer
Addon Developer
Donator
Joined
Mar 5, 2010
Messages
9,271
Reaction score
3,244
Points
203
Location
Toulouse
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

Move slow and try not to break too much.
Orbiter Contributor
Addon Developer
Tutorial Publisher
Donator
Joined
Mar 21, 2008
Messages
2,687
Reaction score
1,337
Points
128
Location
Saco, ME
Website
mwhume.space
Preferred Pronouns
he/him
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

Move slow and try not to break too much.
Orbiter Contributor
Addon Developer
Tutorial Publisher
Donator
Joined
Mar 21, 2008
Messages
2,687
Reaction score
1,337
Points
128
Location
Saco, ME
Website
mwhume.space
Preferred Pronouns
he/him

4throck

Enthusiast !
Joined
Jun 19, 2008
Messages
3,502
Reaction score
1,008
Points
153
Location
Lisbon
Website
orbiterspaceport.blogspot.com
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

Addon Developer
Addon Developer
Joined
Apr 18, 2009
Messages
212
Reaction score
40
Points
43
Location
Kolkata,West Bengal
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

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,877
Reaction score
2,870
Points
188
Website
github.com
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?
 
Top