General Question Orbiter Collisions

[Pyromaniac605]

I must say that collision detection would add great realism and immersion, but the problem is the actual implementation, if someone were to pull it off properly it would be great, but that doesn't seem likely to happen anytime soon simply because it is very hard to do. (As many have pointed out before me.)

Although it would be nice to hear Martin's opinion on the subject, I'm assuming he must have said something on the subject before. :shrug:

 

[redneck]

Redneck, this is no fight where you have to have a winner and a loser. It is a discussion forum.

It is alright to discuss the demand for collision detection. Just, we didn't discuss it here, we got a thread asking why it isn't already implemented. In any project, this kind of behaviour is doing everything BUT convincing the author to implement it.

Everyone who wants collision detection: come up with ideas how it could be done, ask the author of already established solutions what are the key problems, where are pitfalls, what can be done to fix them, etc. But this here... no, sir, this will just not work.

And one last thing, redneck, before I have to leave this topic for today: you responded like I'd be in charge of Orbiter's roadmap. I can assure you, I am not. I just posted my opinion.

I am not mad at you face nor do I hold YOU or anybody else responsible in any way. You have made your contribution. No one will deny that! No one will deny the fact that Dr. Martin made a great sim. But talk about any improvements such as collision detection and here comes the "Lets save orbiter" calvary. The same old cliche's, same old posts. How about we discuss what we can do to improve orbiter and not what we CAN NOT do. Artlav has a pretty good head start in this area. Why can't a collaborative project continue where he left off?
1: What would it take to get collision detection from a coding POV
2: Are there any addon makers in the orbiter community interested in a collaborative project?
3: Develop from scratch or build on artlavs work? Will he approve of this?
4: Does anybody know any coders outside of orbiter community that we can recruit? what are the requirements? C++, C#,Lua?
5: Logistics,timezones ? does this need to be considered?
6: Repository? Where to dump code
7: Public or closed development?
I could keep going..these are all that come to mind right now at 4:30 am

 

[garyw]

I'm no coder but I can assist with some of these:

2: Are there any addon makers in the orbiter community interested in a collaborative project?

There are existing collaborative projects (SSU) so I think that's a yes but before many developers will commit they'd want to see a solid plan.

3: Develop from scratch or build on artlavs work? Will he approve of this?

Ask him. :lol:

4: Does anybody know any coders outside of orbiter community that we can recruit? what are the requirements? C++, C#,Lua?

C++ and yes. I know quite a few devs. None would give their time for free though.

5: Logistics,timezones ? does this need to be considered?

If you have collaboratative project then yes it does but it shouldn't be your overwhelming concern unless you are planning on having weekly meetings (don't!).

6: Repository? Where to dump code

sourceforge? There are plenty of online code repositories so this shouldn't be an issue.

7: Public or closed development?

Public. If you make it closed how can future devs improve? You'd be guilty of locking something away that you all want.

I'd also suggest trying to get into contact with other devs who said they were going to do this project and seeing if they want in. You never know how far they have gotten.

 

[Face]

I am not mad at you face nor do I hold YOU or anybody else responsible in any way. You have made your contribution. No one will deny that! No one will deny the fact that Dr. Martin made a great sim. But talk about any improvements such as collision detection and here comes the "Lets save orbiter" calvary. The same old cliche's, same old posts. How about we discuss what we can do to improve orbiter and not what we CAN NOT do. Artlav has a pretty good head start in this area. Why can't a collaborative project continue where he left off?

"Lets save orbiter" cavalry is a nice term, I'll remember that :lol: .

Anyway, you laid out a nice list of constructive questions now, so I'd like to give my opinion on them:

1: What would it take to get collision detection from a coding POV

To answer this question, you'd at first have to define what you want from collision detection. I'll now assume it should be the perfect system Artlav stated above...

For such a system to work you will have to work on the mesh level, i.e. check if any mesh intersects with some other, calculate the impuls vectors, calculate the underlying collision model (elastic or plastic), apply the given forces to appropriate objects and optionally apply damage features if plastic model is used.

You can guess that a full-blown system like this will put a huge burden on the engine, most probably leading to slide-show-like frame-rates. Thus, the system should be designed with optimization in mind (yes, I know about premature optimization).

In light of this, you can pick on the different steps to discuss optimization:

1. "check if any mesh intersects with some other" - reduce the number of meshes to be checked, e.g. add another mesh flag where vessel-devs can decide what is rigid, and what is just inner eye-candy. Maybe even reduce the number of triangles within the mesh to be checked... this can go all the way down to simple sphere or box checks.
2. "calculate the impuls vector" - how to take docked superstructures into account, what do with attachments, how to calculate the mass etc.
3. "calculate the collision model" - do we need plastic deformation collisions? Is elastic only really "realistic"?
4. "apply the forces" - transversal only or rotational, too?
5. "damage features" - give out an API for vessel developers to hook in?

I'm pretty sure Artlav thought about this already and can comment much more profound than me about it.

2: Are there any addon makers in the orbiter community interested in a collaborative project?

While I'm interested (it is an interesting programming challenge, after all), I really don't see how I could invest time in yet another project (OMP, AU, COI). Of course that's only me, I can't speak or know of others. In addition, collision detection is something I don't need in my (now rare, but nevertheless existing) Orbiter piloting sessions. So I don't have the demand myself, anyway.

3: Develop from scratch or build on artlavs work? Will he approve of this?

Can't say much on this, as I've never seen Artlav's code.

4: Does anybody know any coders outside of orbiter community that we can recruit? what are the requirements? C++, C#,Lua?

I don't know about coders outside of the community that we can recruit. How is a coder from outside benefitting from being recruited for such a project, anyway? It's not like the Orbiter community can pay 'em...

As for requirements, I'd say C++ needs no discussion, simply because of performance.

5: Logistics,timezones ? does this need to be considered?

ATM, there isn't even a team, so I guess this can be discussed after you(we?) at least know where the project (will it even be a project?) is heading.

6: Repository? Where to dump code

Same as 5.

7: Public or closed development?

Same as 5.

I could keep going..these are all that come to mind right now at 4:30 am

And if collision detection is something you really want to see, this is the best you can do (short of coding it yourself). Constructive comments are certainly always welcome, but just pushing will not make it happen - it only calls the cavalry .

regards,
Face

 

[Artlav]

Ok. Let's state the problem.

First question, what do we want to have?

There is collision detection and there is collision handling.
First determines if two meshes/whatever intersected, second makes the appropriate alterations in the state vectors.

These two tasks go hand to hand, but are quite separate.


Detection
What collides?

Terrain and vessel (orulex-collision, moonland).
Terrain is a heightmap, vessel is points.
+Extremely simple detection.
-Specific to that one task

Vessel and ummu/pilot (Shukra engine).
Vessel is a geometry, ummu is a sphere/OBB
+Not too hard to detect
-Specific to that one task
-Needs defining geometry

Vessel against vessel, high velocity case.
Vessels are bounding boxes or spheres.
+Easy to detect, easy to handle
-Only works when at hight speeds or in other situations where accuracy is not required

Vessel against vessel, generic case.
Mesh against mesh
+No need to alter stuff
+Realistic collisions
-Highest complexity of detection known, beyond capabilities of home PCs
Convex mesh against convex mesh
+Realistic collisions
-Nearly the highest complexity of detection known, existing real-time solutions are large projects by respectable teams
-Needs defining of collision meshes with non-trivial rules
Geometry against geometry.
+Doable level of complexity
-Average accuracy
-Needs definition of said geometry

Handling
The actual response generation to collisions detected.

Can be solved analytically, but that requires a deep integration with the core (variable time step, exact formulas for every perturbation, etc) and well-developed system. Not worth considering.

Situations:

Vessels in space (Meshland 1.9.2, Soyuz collision demo?)
No such thing as resting on or wedging in.
Response with basic newton's laws.
+Easy, needs no special cases, just push away
-Only works in space and with sharply defined collisions

Walking on the ground, single point (Meshland 1.2, Moonland, Orulex-collision).
An object is constantly in contact with another object.
Repulsing will produce shaking.
Time acceleration or low FPS turns the shaking into chaos.
-Needs handling for non-moving objects, at rest with others - freezing. Core support helps a lot (that is what LANDING in Orbiter and Spaceway is - core handled, super stable), or some hard tricks to emulate (attachment points to Orulex planet vessel - Moonland, newer Orulex-collision).
-Needs prior knowledge of next time step length - core integration, can be skipped at cost of some precision.
+Simplistic to implement, makes sufficient illusion of collisions (Meshand 1.2, abuses Orbiter LANDED system by extending touchdown points)

Walking on the ground, multiple points (Meshland 1.9.2).
Same as above, but harder.
-Needs basic constraint solving - sitting on a curved terrain, push one point, another gets in deeper, push that one harder, first gets even deeper, runaway bouncing.
-Needs next time step information
-Needs freezing, absolutely
-Time acceleration provides a challenge - no freezing=every landed vessels jumps into space at 100x.

Walking on another vessel (Shukra engine, Collision SDK, Meshland 1.9.2).
Same as above, only without any easy trick like using LANDED points.
Freezing can be implemented by attachments.
Single-point system of walking a ummu is actually kind of easy.
Multi-point is the next one

Arbitrary collisions between arbitrary vessels
Everything above plus full constraint solver
+Maximum realism

So, what are we going to do and where can we split the tasks?
I have nothing against using my code, except that it's often in a custom variant of pascal language.
Orulex (terrain DRAWING) is pascal-only, and is available (sans link to orbiter) in spaceway repository.
It is also a separated project with collision hooks embedded since forever, so no problems here (except for some interface improvements suggested in one of the related threads).

Meshland, Collision SDK, Shukra engine, MoonLand and Orulex collisions exist in both pascal and C++, and are not too complex to translate in between. Each implements one or two of the special cases presented above. None are doing general cases.

Other parts - interaction points of shukra, control overlay of hius, etc are in C++, and are also quite separate as well.

For collision stuff someone may do the detection, other - the handling.
But in any case it has to be carefully planned first.

So, what do we want to have that we can do?

 

[N_Molson]

:goodposting:

It's the first time I get a fair understanding of the problem, and it seems that some specific Orbiter-core tools are required. Tweaking at each frame for all the vessels in the simulation Touchdownpoints / Attachments, from the little I know from coding... Wow... :blink:

 

[shadowfax]

There is collision detection and there is collision handling.
First determines if two meshes/whatever intersected, second makes the appropriate alterations in the state vectors.

Just to put things in perspective, I'll point out that MS Flight Simulator detects collisions, but does not handle them with the exception of a low -vs belly landing or a water landing. In a regular crash, the screen freezes, it says "CRASH" somewhere, and then gives you the chance to reset or load a new scenario. And that's MSFS. A product that's been developed since the 80's by hundreds if not thousands of people working for a multi-billion dollar software powerhouse.

If I were paying $50 for Orbiter ($80 for the Orbiter Deluxe with the shuttle in it) I'd be annoyed at the lack of collisions and the lack of ability to do cool things on planets. Since I got it for free, I'm more amazed at the level of realism it's managed to achieve with its core code being written by one guy, in his free time.

Sure, I'd love collisions, and a whole bunch of other stuff. But as long as I'm not paying for it, I don't figure I have much reason to be upset at missing a few things when I've already gotten so much for free.