[Project] Orbiter Battle Simulation Project Needs Developers!

[Talon1]

This project reminds me of my old "Orbital Cannons". Those designs are long dead and I've decided to make a "Mark 2" version of it.
The Mk. II is a fusion of the old Mk. I cannon:

And the "GN Mega launcher" from Gundam 00:


Thread for it coming after I finish the model.

[Seahawk72s]

Quote by RisingFury; "Vessel to vessel collision detection - Vessels physically react to collisions. Damage is also taken off."


I appreciate what you are saying about orbital velocities but for a ground based effect this would be a good plus. With low velocities you open up the possibility of a push effect with and transfer of object momentum. Cutom tugs,trucks,tractors..? Maybe take the collision damage factor to another level if possible where objects are give a strength\integerity rating, say between 1-10. Where an object of 10 can crush an object of 1 with little or no damage to itself.

Thanks for your work..!

[RisingFury]

Quote:

Originally Posted by Seahawk72s

 Quote by RisingFury; "Vessel to vessel collision detection - Vessels physically react to collisions. Damage is also taken off."


I appreciate what you are saying about orbital velocities but for a ground based effect this would be a good plus. With low velocities you open up the possibility of a push effect with and transfer of object momentum. Cutom tugs,trucks,tractors..? Maybe take the collision damage factor to another level if possible where objects are give a strength\integerity rating, say between 1-10. Where an object of 10 can crush an object of 1 with little or no damage to itself.

Thanks for your work..!

Transfer of linear momentum and damage is ALREADY implemented.

Watch the video:

YouTube - OBSP - Introduction and features

YouTube - OBSP - Introduction and features

The damage model is implemented in a way that the more massive object will take less damage then the less massive ones - the thinking is that if a truck and a car collide, the car takes more damage...

[escapetomsfate]

Quote:

Originally Posted by nidhugg

 Nice

I saw the videos. You use the radius for collision detection. Any plans for mesh-to-mesh collision?

I don't think so. It would be cool, but would hog resources (we're already trying to cut down on that) and would probably take lots of work, so it wouldn't be worth it in the long run. Radius to radius detection is all OBSP really needs, though we might have to come up with a better system to get around problems like docking etc.

[T.Neo]

OBSP is looking for someone who is skilled at texturing and UV unwrapping of 3d models. Meshing skills are also helpful since we are pressed for time and I cannot complete everything alone.

Anyone who is willing and able to dedicate their time and skill can contact me via PM.

Kind regards,
T.Neo

[statickid]

hey this project looks really awesome! I don't know if anybody remembers but it might be fun to search for that old space lasers and warfare thread as it had quite a bit of interesting discussions about space combat. I don't know too much about how you guys are doing all of that, but here's an idea off the top of my head:

could a rudimentary explosion be made by having the explosive mesh's size sphere expand momentarily then having it be destroyed? It wouldn't be the best, but then there could be a primitive blast radius damage to play with running on the current collision detection method.

Another way to look at it would be this: when damage=100% mesh size expands from 2meters to 15meters. since their mesh spheres would be overlapping, it would be like a really bad collision, thus destroying both meshes.

[jedidia]

Quote:

Radius to radius detection is all OBSP really needs,

I think there should at least be a cube option, after all most space vessels are going to be much longer than wide or high. extend that by the possibility of defining several cubes per object, and you'll already have a full fledged colision detection that doesn't really eat up that much resources. Use a .msh file to define those cubes instead of a config file, and you'll give users the posibility to export a perfectly normal collision mesh from the 3d software they create their vessels with. As long as they stay reasonable with the amount of cubes, there shouldn't be much drain on resources. Plus, you pretty much get a damage area feature for free (i.e. you'll know exactly which part has been hit). It's not that hard, and relatively resource friendly.

Indeed, it should even be more efficient: If you use the radius, you have to get the distance from the projectile to the ship. That means a vector substraction AND a trigonometrical calculation for getting the vector length. If you work with cubes, you can simply do three Vector substractions (I think it's three...) without employing trigonometry. You can run a whole lot of substractions in the time you calculate the length of a vector!

[Jaakko]

Awesome project. Good luck for this project here.

[RisingFury]

Quote:

Originally Posted by Jaakko

 Awesome project. Good luck for this project here.

Thanks.

Quote:

Originally Posted by T.Neo

 OBSP is looking for someone who is skilled at texturing and UV unwrapping of 3d models. Meshing skills are also helpful since we are pressed for time and I cannot complete everything alone.

Anyone who is willing and able to dedicate their time and skill can contact me via PM.

Kind regards,
T.Neo

So, any takers?

[nidhugg]

Quote:

Originally Posted by escapetomsfate

 I don't think so. It would be cool, but would hog resources (we're already trying to cut down on that) and would probably take lots of work, so it wouldn't be worth it in the long run. Radius to radius detection is all OBSP really needs, though we might have to come up with a better system to get around problems like docking etc.

If you use radius collision you could do cones or something from each docking port and just exclude the collision if these intersect. When they drift apart you could apply force in a suitable direction to keep the docking in a sort of docking-tunnel. And maybe apply some damage too if it was a bad collision.

What about shifting between radius collision - box collision -mesh collision depending on the proximity somehow (sphere intersection/box intersection and so on)? (and maybe the relative speeds?) Not using a more advanced method if it's not needed.

[Wishbone]

Folks, think you're launching a very huge endeavour, y'need all the luck, and I've got a question: what sensor models do you plan to employ - infrared, telescopes spotting sats and debris (radars are much easier to do in pure space)?

[RisingFury]

Quote:

Originally Posted by Wishbone

 Folks, think you're launching a very huge endeavour, y'need all the luck, and I've got a question: what sensor models do you plan to employ - infrared, telescopes spotting sats and debris (radars are much easier to do in pure space)?

RADAR and IR scanners are an obvious choice. We still don't know what to use for long range though.

[T.Neo]

For long range detection in space, some sort of very sensitive IR or potentially even optical scanner would be useful.

Radar can detect objects pretty far out, but it also isn't a passive sensor...

[Wishbone]

There are also neat radiation detectors aboard US early warning sats...

EDIT: and it may be way to go with optics. One doesn't fire engines that frequently to justify IR sensors (at least ground-based), the other way round (from the top) is hampered though by the clouds and aerosols...

[T.Neo]

Depends. If you have powerful engines, they can be quite bright and thus very detectable. Even with current technology, you could detect the shuttle's RCS thrusters from the asteroid belt.

Though for space-to-surface and surface-to-space surveillance and detection, optical would probably be better, and radar could potentially work as well- there's an atmosphere with all of it's clouds and whatnot to contend with.