What you want to see in the Next release of Orbiter
- Thread starter Kaito
- Start date
RisingFury
OBSP developer
Well, still a cool thing 
There are many subjects in this post regarding a better Orbiter. High on my list is a realistic collision detection. I really do not like to fly trough the ISS without anything happen to my ship or the ISS. The DGIV explode in pieces when hit the earth or burned up in the atmosphere. Maybe that can be programmed into the code of the next version of Orbiter?
RisingFury
OBSP developer
That can be implemented without actually putting it into Orbiter.
RisingFury
OBSP developer
It can definitely be turned "on and off". I suppose it'd need it's own config system like DGIV has for engines, fuel, LOX,...
Kaito
Orbiquiz Coordinator
- Joined
- Jul 24, 2008
- Messages
- 857
- Reaction score
- 0
- Points
- 0
hm...heres an idea for the Collision detector:
For the "default" ships (the ones that come with orbiter), have a pre-defined set of area's that are collision areas. For NEW ships, i think i know a way it can detect when its colliding and when its not:
Have this program analyze the entire mesh of a ship. Then, it creates its own, separate "shell" around it, conforming to the individual plane changes. So, in effect, it would create an invisible mesh around the mesh. When two points, two planes, or point and plane intersect, the program would create a new point at the intersection and fetch the Mass of the ships, velocity, direction, and all of the elements that would effect such a thing. When all of those have been calculated against each other, it would then use that point it created as a reference to apply changes in angle, speed, etc.
I know the "calculate against each other" is the big problem, but its a start
For the "default" ships (the ones that come with orbiter), have a pre-defined set of area's that are collision areas. For NEW ships, i think i know a way it can detect when its colliding and when its not:
Have this program analyze the entire mesh of a ship. Then, it creates its own, separate "shell" around it, conforming to the individual plane changes. So, in effect, it would create an invisible mesh around the mesh. When two points, two planes, or point and plane intersect, the program would create a new point at the intersection and fetch the Mass of the ships, velocity, direction, and all of the elements that would effect such a thing. When all of those have been calculated against each other, it would then use that point it created as a reference to apply changes in angle, speed, etc.
I know the "calculate against each other" is the big problem, but its a start
RisingFury
OBSP developer
Actually, the meshes are used in most cases.
The most difficult part here is that you have very fast moving objects.
Imagine two ships in LEO traveling in opposite direction, directly at each other. Every ship has a velocity of nearly 8 km/s ---> I'll just say 8 for simplicity. Which means their relative velocity is 16 km/s.
Now, the difficult bit is that you can only check the collision state "for that frame". Imagine having 100 frames per second. That means that you get 1 frame per 1/100 of a second. And because of the high relative velocity, the ships come 160 m closer in every frame. That means that in most cases they'd pass right through each other. I'll try to graphically demonstrate it:
SX means ship (S1, S2).
Every "-" means 10 meters
* means where the collision would occur in real world.
This is the first frame:
S1----------*----------S2
S1 is traveling left, S2 is traveling right. They each have 100 meters to the collision point. Each of them is traveling at 80 m per frame (relative velocity of 160 m / frame).
At this point, we check the collision and we notice that... the ships aren't colliding.
Then comes the next frame:
--------S1--*--S2--------
Each ship has traveled 80 frames, but still no collision, so we let the next go.
----S2----*----S1----
OMG! What happened?
Well, this IS the next frame, but the ships went through each other without collision. That's because we didn't check the collision between frames, we only checked it "right on" the frame.
The thing is, this is the "efficient" way of doing collision detection, but it doesn't work for fast moving objects. If we want to check collision for fast moving objects, we'd have to check if there was a collision from the previous frame to the next... but that would probably take even more CPU.
That's probably the reason why collision detection in Orbiter is as simplistic as it is. It's easy to check the whole path of three points against a plane, but it's not easy to check 1000's of planes against each other.
Realistically speaking, any implementation of a collision system would only work effectively under small relative velocities.
To save more CPU, we could also turn it off while the distance between two ships is more then Ship1's Size * K + Ship 2's Size * K where K is a number between 1 to 10.
The most difficult part here is that you have very fast moving objects.
Imagine two ships in LEO traveling in opposite direction, directly at each other. Every ship has a velocity of nearly 8 km/s ---> I'll just say 8 for simplicity. Which means their relative velocity is 16 km/s.
Now, the difficult bit is that you can only check the collision state "for that frame". Imagine having 100 frames per second. That means that you get 1 frame per 1/100 of a second. And because of the high relative velocity, the ships come 160 m closer in every frame. That means that in most cases they'd pass right through each other. I'll try to graphically demonstrate it:
SX means ship (S1, S2).
Every "-" means 10 meters
* means where the collision would occur in real world.
This is the first frame:
S1----------*----------S2
S1 is traveling left, S2 is traveling right. They each have 100 meters to the collision point. Each of them is traveling at 80 m per frame (relative velocity of 160 m / frame).
At this point, we check the collision and we notice that... the ships aren't colliding.
Then comes the next frame:
--------S1--*--S2--------
Each ship has traveled 80 frames, but still no collision, so we let the next go.
----S2----*----S1----
OMG! What happened?
Well, this IS the next frame, but the ships went through each other without collision. That's because we didn't check the collision between frames, we only checked it "right on" the frame.
The thing is, this is the "efficient" way of doing collision detection, but it doesn't work for fast moving objects. If we want to check collision for fast moving objects, we'd have to check if there was a collision from the previous frame to the next... but that would probably take even more CPU.
That's probably the reason why collision detection in Orbiter is as simplistic as it is. It's easy to check the whole path of three points against a plane, but it's not easy to check 1000's of planes against each other.
Realistically speaking, any implementation of a collision system would only work effectively under small relative velocities.
To save more CPU, we could also turn it off while the distance between two ships is more then Ship1's Size * K + Ship 2's Size * K where K is a number between 1 to 10.
Artlav
Aperiodic traveller
- Joined
- Jan 7, 2008
- Messages
- 5,814
- Reaction score
- 869
- Points
- 203
- Location
- Earth
- Website
- orbides.org
- Preferred Pronouns
- she/her
Why and why?
Why not do projection-ahead collision detection scheme, that is - calculate the nearest expected collision point using sphere approximations, adjust SimDT accordingly, do a step, calculate the accurate collision system, do small steps until all collisions are done, continue with large orbital steps.
Even in the typical collision detection by "watching the results and fixing for collisions" you described is less efficient than possible, checking every mesh point for collision every step.
You better use some optimizing structures and delta projection algorithm, which incidentally removes the fast moving objects problem.
In any case, doing it in an add-on is nearly impossible with any acceptable accuracy, you need some physics core control and data to do it properly.
RisingFury
OBSP developer
Yea, that's one of the algorithms I read about, and I think it would the best option, given that it can predict the point of collision or the point where the ships are at their closest points.
The DLL would have to add some extra physics, I'm sure of that... but unless it's impossible to change stuff like acceleration, velocity and location,... from outside the class, I think it's still possible.
I mean, me and a lot of other peeps sure would like to have this implemented. Worth researching
@woo: I thought MeshLand only adds planetary meshes and collision.
RisingFury
OBSP developer
Errr... I don't know about that.
You mean... collision with planets?
If you mean that, that's not really "true" collision detection. When you make a ship, you have to define 3 points of contact - where the gear or the bottom of the ship is. Those three points are used to do collision detection with the planet.
It's not really a "mesh" collision detection.
You mean... collision with planets?
If you mean that, that's not really "true" collision detection. When you make a ship, you have to define 3 points of contact - where the gear or the bottom of the ship is. Those three points are used to do collision detection with the planet.
It's not really a "mesh" collision detection.
Artlav
Aperiodic traveller
- Joined
- Jan 7, 2008
- Messages
- 5,814
- Reaction score
- 869
- Points
- 203
- Location
- Earth
- Website
- orbides.org
- Preferred Pronouns
- she/her
It have both, but neither is perfect.
Here is what it could do at it's best:
Vessel-Vessel:
http://orbides.1gb.ru/orbf/Visosad-2-VV-c.avi (25Mb, DivX 3)
Same, full length:
http://orbides.1gb.ru/orbf/Visosad-2-VV.avi (44Mb, DivX 3)
Planet collisions at 10x:
http://orbides.1gb.ru/orbf/visosad-2-10x.avi (20Mb, DivX 5)
Perfect, can you can give me the name for it?
It's possible to change positions and velocities, but no way to change the time step ahead of schedule. I tried making an integrator and getting from previous step to the next on it when needed, but it is basically replacing the orbiter innermost core with a module, and degrades accuracy a lot.
Might be possible in an addon, but way better to do in the core.
Mission_CDR
New member
- Joined
- Mar 28, 2008
- Messages
- 164
- Reaction score
- 0
- Points
- 0
Is there anyway to make repeating scenary for different parts of the world like in FS9? Would it also be possible to make random objects such as buildings, trees,etc.?
Kaito
Orbiquiz Coordinator
- Joined
- Jul 24, 2008
- Messages
- 857
- Reaction score
- 0
- Points
- 0
Yes: make meshes, and place them where you want
RisingFury
OBSP developer
Nope.
I've been through too many in the past year, mostly just searching on Google and saw people come up with different possibilities...
You obviously have may more experience in OrbiterSDK then I do. After all, I've only been playing around with it for the past week or so.
My impression is that one would be able to implement a collision model that would work when docking and in collisions with large bodies like buildings, but it would fail in high relative velocity collisions and you'd still be able to run it on a decent computer. With decent, I think something like my computer - which isn't all that decent anymore I guess - AMD Athlon 3000, 1 GB RAM, GeForce 6600 GT.
Oh and judging by the videos, my idea has already been implemented. Sure, maybe it isn't perfect, but it's still very cool.
Enjo
Mostly harmless
- Joined
- Nov 25, 2007
- Messages
- 1,667
- Reaction score
- 19
- Points
- 38
- Location
- Germany
- Website
- www.enderspace.de
- Preferred Pronouns
- Can't you smell my T levels?
I'd like to see visible orbits in Planetarium Mode, like in Celestia. This should explain many things.
tblaxland
O-F Administrator
I agree, it would greatly increase the educational value. The main problem I can see is that Orbiter only knows where you have been (still of value though). Addons like Jarmonik's IFP will provide better visualisation for trajectory prediction.
