Stevodoran
Donator
hi lads and lassies i was just wondering is their an addon which makes ships not go throught eachother and may even crash off each other
Request Ships dont go throught eachother
- Thread starter Stevodoran
- Start date
diogom
Well-known member
- Joined
- Aug 2, 2010
- Messages
- 1,564
- Reaction score
- 927
- Points
- 128
- Website
- github.com
- Preferred Pronouns
- he/him
I saw a Orbiter video on Youtube. There were two soyuz (the old ones) near each other and when they collided they didn't go through eachother. It's Soyuz 4/5 collision test I think. The person that posted the video sais that the addon is made by him, and that it was almost complete, but the video is from 3 or 4 years ago.
Stevodoran
Donator
looks very good i wonder if it will ever be finished
Izack
Non sequitur
[ame="http://www.youtube.com/watch?v=1gZN-5hl428"]YouTube- Visosad 070426 vessel-vessel collision detection demo[/ame]
http://orbides.1gb.ru/csdk.php
Leave it to Artlav to come up with something amazing and leave only a glimpse of it.
http://orbides.1gb.ru/csdk.php
Leave it to Artlav to come up with something amazing and leave only a glimpse of it.
Moach
Crazy dude with a rocket
you know, such an addon may not be too hard at all to pull off.... as long as you don't expect it to catch colisions between fast movers, i.e. two objects orbiting in different directions....
if you switch detection on based on a relative-velocity target (like the ISS)... then handling collisions is no task out of this world (well it is, literally... but you get the point) :hmm:
biggest problem however, is how do create the collision mesh for vessels.... for the stock ones (DG, Shuttle-A), this could be pre-included in the module - but what of addons?
an SDK would be needed, just like for OrbiterSound - so that developers could attach a physics-mesh to their vessels :huh:
any addons created without such consideration (aka, most of them) would continue to fall through others.....
unless some clever vessel-class association scheme could be used as a fallback in such cases
so it's not really impossible... but it's a little impractical, in terms of compatibility.... and in the end, for all purposes of Orbiter as a simulator - the actual need for such thing is questionable, which i believe is the main reason this hasn't been taken much further
if you switch detection on based on a relative-velocity target (like the ISS)... then handling collisions is no task out of this world (well it is, literally... but you get the point) :hmm:
biggest problem however, is how do create the collision mesh for vessels.... for the stock ones (DG, Shuttle-A), this could be pre-included in the module - but what of addons?
an SDK would be needed, just like for OrbiterSound - so that developers could attach a physics-mesh to their vessels :huh:
any addons created without such consideration (aka, most of them) would continue to fall through others.....
unless some clever vessel-class association scheme could be used as a fallback in such cases
so it's not really impossible... but it's a little impractical, in terms of compatibility.... and in the end, for all purposes of Orbiter as a simulator - the actual need for such thing is questionable, which i believe is the main reason this hasn't been taken much further
HAL9001
super-ninja-orbinaut
ooooh if it would be possible to use the "picture"-meshes for the collisions...
Usquanigo
New member
Couldn't you come at it from the other angle? Look for a way to deal with high velocity, and let the slow stuff take care of itself?
Anything at all would be better than nothing, but as I was reading your post, I got to thinking of 2 satellites colliding. Depending on the addon, it could either shatter (ideal), or simply bounce off like a billiard ball into some screwed up orbit and probably end up re-entering.
Would be interesting simply to see happen, but also give more incentive for traking and better placing items into orbit, as well as actually putting satellites up there in the first place.
Moach
Crazy dude with a rocket
if two satellites were to collide in their orbits there would be very little of them left to tell the story.....
still.... there's a LOT of space in space (i think that's why they call it that)... so the odds of something like that (in orbiter) are from dim to null
so one can assume it to be not worth it to busy our restless CPU's with such considerations....
however, doing so, would not be impossible either.... but with the scale of the velocities involved, to do so accurately would be quite a feat of enginuity :blink:
it would require an initial collision-likelyness check, probably based on orbital elements...
then for object pairs which are found to have any chance of a near-pass, we can increase precision by emplying progressively finer tests, like raycasts on increasingly lower ranges until w're close enough to say - these two have crashed...
the good part here, is that no reaction would be needed.... at such speeds, even a slight brush would make the two plain disintegrate... it really doesn't matter how solid are the parts that make contact -remember that a few years ago, a small business jet's winglet ripped the whole wing of a 737 on a Trans-Amazonian middair sending the boeing to it's doom
... - even so, their relative speeds were a puny fraction of those in an orbital collision
still... it's quite an imposition on the CPU, having all those checks, narrowing down and all... for close-by collisions (relative-speed based) this would be a needless overhead - which is why such cases must be handled so differently
also, since it doesn't matter at what point of the vessels a high-velocity impact occurs, the detection algorithms are considerably distinct from those employed on near-object cases, which would have to take polygon meshes into account
so, as you can see... the slow stufff really wouldn't take care of itself just by having the fast stuff sorted out, unfortunately
there are many possibilities for vessel-vessel collisions.... and still most of them are so rare and so hard to detect that i can understand why they have been ignored so far
it WOULD be cool, tho:hmm:
still.... there's a LOT of space in space (i think that's why they call it that)... so the odds of something like that (in orbiter) are from dim to null
so one can assume it to be not worth it to busy our restless CPU's with such considerations....
however, doing so, would not be impossible either.... but with the scale of the velocities involved, to do so accurately would be quite a feat of enginuity :blink:
it would require an initial collision-likelyness check, probably based on orbital elements...
then for object pairs which are found to have any chance of a near-pass, we can increase precision by emplying progressively finer tests, like raycasts on increasingly lower ranges until w're close enough to say - these two have crashed...
the good part here, is that no reaction would be needed.... at such speeds, even a slight brush would make the two plain disintegrate... it really doesn't matter how solid are the parts that make contact -remember that a few years ago, a small business jet's winglet ripped the whole wing of a 737 on a Trans-Amazonian middair sending the boeing to it's doom
... - even so, their relative speeds were a puny fraction of those in an orbital collisionstill... it's quite an imposition on the CPU, having all those checks, narrowing down and all... for close-by collisions (relative-speed based) this would be a needless overhead - which is why such cases must be handled so differently
also, since it doesn't matter at what point of the vessels a high-velocity impact occurs, the detection algorithms are considerably distinct from those employed on near-object cases, which would have to take polygon meshes into account
so, as you can see... the slow stufff really wouldn't take care of itself just by having the fast stuff sorted out, unfortunately
there are many possibilities for vessel-vessel collisions.... and still most of them are so rare and so hard to detect that i can understand why they have been ignored so far
it WOULD be cool, tho:hmm:
HAL9001
super-ninja-orbinaut
yes, dgiv, ummu ... should by destroyed ad that collisions too, if it's fast enough. even like there would be the earth surface.
Usquanigo
New member
I never said it would be realistic for a satellite to collide and remain intact. However, it's not realistic for certain vessels to be impervious to over-zealous re-entry either, but they are. This is orbiter. lol
Besides, baby steps. Collisions first. Damage can be left up to the add-on makers and in time it'll come 'round.
I gotta wonder if it's really all that much of a drain on the CPU though. Look at something like online FPS's. They have bullets and "energy" beams flying fast and furious from mutlitudes of players all over the map (physically and virtually) and they handle both collision of everything (clipping) and weapon hits, and then do damage on top of everything.
And if that's "slow", well, bullets aren't. But we can move to IL2 - again, online, much higher speed, deals with collision of planes with all objects, but also flack and bullet hits. Plus eye candy, AI (in COOPs or offline), detailed damage modeling, detailed flight physics, and even sim-pilot modeling, all with up to 64 players from around the world in real time.
Then you have LOMAC, now you're taking all of that, adding intense systems modeling (RADAR, ECM, ECCM, MFDs, warning systems, AWACS, missile guidance, etc), and dealing with mach 3 to mach 4 missile collisions (and of course bullets as well), all in real time, all with large numbers of players online, plus even AI (IIRC, at least for certain things).
So it would seem to me that they aren't doing it in a way that puts a huge overhead on the CPU as most of that is needed for everything else (flight physics first and foremost, then systems modeling, then damage modeling, then graphics, then sound, then AI, etc....).
But I've never made anything like that, so I can't really say, I'm just speculating. :shrug:
Besides, baby steps. Collisions first. Damage can be left up to the add-on makers and in time it'll come 'round.
I gotta wonder if it's really all that much of a drain on the CPU though. Look at something like online FPS's. They have bullets and "energy" beams flying fast and furious from mutlitudes of players all over the map (physically and virtually) and they handle both collision of everything (clipping) and weapon hits, and then do damage on top of everything.
And if that's "slow", well, bullets aren't. But we can move to IL2 - again, online, much higher speed, deals with collision of planes with all objects, but also flack and bullet hits. Plus eye candy, AI (in COOPs or offline), detailed damage modeling, detailed flight physics, and even sim-pilot modeling, all with up to 64 players from around the world in real time.
Then you have LOMAC, now you're taking all of that, adding intense systems modeling (RADAR, ECM, ECCM, MFDs, warning systems, AWACS, missile guidance, etc), and dealing with mach 3 to mach 4 missile collisions (and of course bullets as well), all in real time, all with large numbers of players online, plus even AI (IIRC, at least for certain things).
So it would seem to me that they aren't doing it in a way that puts a huge overhead on the CPU as most of that is needed for everything else (flight physics first and foremost, then systems modeling, then damage modeling, then graphics, then sound, then AI, etc....).
But I've never made anything like that, so I can't really say, I'm just speculating. :shrug:
Istochnikov
Costa Rica Space Systems' CEO
Igel have done something like a collision engine on his [ame="http://www.orbithangar.com/searchid.php?ID=2711"]Laika Lunar Lander[/ame], More info here 
Last edited:
River Crab
SpaceX Cheer Captain
I've heard of some people who played Orbiter with "ongoing scenarios", that is, they always saved their one scenario, and when they wanted to do a mission, they spawned the vessels and took off.
If there's (a lot of) debris added to the mix, an interesting Kessler syndrome might develop...
Anyway, the best way I can see to program the collisions is how it's done in Touhou. OK, only 2 forum members will get that, but, basically, the program doesn't check for collisions unless objects are within a certain range at a certain velocity relative to the player's hitbox. That's the reason why Touhou can allow so many bullets- they don't really exist to your player unless there is a probability of a collision. That's also why Danmakufu is so slow- it doesn't have the collision engine that the real games have.
Of course, space debris is magnitudes less frequent than bullets in Touhou (you don't know the least of it), so that should put more of an emphasis on velocity. The harder part, is factoring gravity into the mix. And time acceleration could be dangerous-it might be better to disable collisions at anything past a certain level of time accel.
Also...what is Artlav trying to do with that video!?
Stop messing with meeee!!!
If there's (a lot of) debris added to the mix, an interesting Kessler syndrome might develop...
Anyway, the best way I can see to program the collisions is how it's done in Touhou. OK, only 2 forum members will get that, but, basically, the program doesn't check for collisions unless objects are within a certain range at a certain velocity relative to the player's hitbox. That's the reason why Touhou can allow so many bullets- they don't really exist to your player unless there is a probability of a collision. That's also why Danmakufu is so slow- it doesn't have the collision engine that the real games have.
Of course, space debris is magnitudes less frequent than bullets in Touhou (you don't know the least of it), so that should put more of an emphasis on velocity. The harder part, is factoring gravity into the mix. And time acceleration could be dangerous-it might be better to disable collisions at anything past a certain level of time accel.
Also...what is Artlav trying to do with that video!?
Stop messing with meeee!!!
Usquanigo
New member
Well, that IS the music in the DeBeers commercials.... sooo... maybe we don't WANNA know! :leaving:
:lol:
Izack
Non sequitur
That explains the 'Schrodinger's Hitbox' effect I've gotten in IN...:hmm:
On-topic...I'm trying out that Laika lander now. I downloaded it a long time ago but never got around to it...
Artlav
Aperiodic traveller
- Joined
- Jan 7, 2008
- Messages
- 5,813
- Reaction score
- 869
- Points
- 203
- Location
- Earth
- Website
- orbides.org
- Preferred Pronouns
- she/her
Amazement is relative.Leave it to Artlav to come up with something amazing and leave only a glimpse of it.
To show what i was making at the time.
-The centrifuge is useless and boring.
-Shooting boxes evolved into [ame="http://www.orbithangar.com/searchid.php?ID=4411"]Asteroids! the game[/ame]
-ISS collisions make newbies cry.
-The flying carrier evolved into [ame="http://www.orbithangar.com/searchid.php?ID=3488"]Shukra_Venus_Station_080813[/ame]
Hm?
What was that about?
Usquanigo
New member
'twas a joke. The DeBeers corporation, which controls the world-wide diamond trade and artificially inflates the prices, occasionally has these commercials with silhouettes dancing around and whatever, and the male gives the female a diamond, could be ear-ring, or engagement ring, or necklace or whatever. In the background of some of them, which of course I can't find on YouTube now, they played a different version of the music that you used in the video.
Similar threads
