Gaming Car simulation and Orbiter

[ar81]

I found TORCS and Racer.

I wonder what orbinauts may think about adding features for ground vehicles. I would like to race on the mountains and crater on the moon or perhaps Mars, some day. Do some stunts with rocket powered cars.

 

[T.Neo]

I wonder what orbinauts may think about adding features for ground vehicles.

Well, there is this: http://orbiter.dansteph.com/forum/re...=17793&t=17793

I would like to race on the mountains and crater on the moon or perhaps Mars, some day.

Unfortunately we do not have stable mesh-mesh collision detection.

 

[ar81]

Well, there is this: http://orbiter.dansteph.com/forum/re...=17793&t=17793

It says "Error 404. File not found"

 

[Andy44]

Dan Steph's project has apparently been in the works for a long time, and the previews of it seemed to show something quite extensive.

Earlier I was requesting a sort of "vehicle.dll" for ground vehicles, similar to spacecraft3 or multistage2, that would be a generic wheeled or tracked module with adjustable parameters via .ini file. If I knew what I was doing I would program it myself. I have so many ideas for surface vehicles, not to mention the obvious historical examples currently resting or operating on the surface of Luna and Mars.

If I ever get the time to learn dll-making this would be worth doing, but if you wait for me don't hold your breath.

 

[T.Neo]

It says "Error 404. File not found"

Dan Steph's website is down at the moment.

 

[dansteph]

The site is up and the the correct url is this one (preview video)
http://orbiter.dansteph.com/forum/read.php?f=1&i=20873&t=17793

Cheers

Dan

 

[Ark]

Unfortunately we do not have stable mesh-mesh collision detection.

That whole orulex/meshland system is IMO the coolest thing to ever hit Orbiter, it's really too bad the whole thing just doesn't work right.

 

[cjp]

I created Ultimate Stunts. Maybe not the best racing simulator, but at least I'm not a newbie in making racing simulators.

How important is this feature? I don't have much time, but maybe this isn't much work. The most difficult part is collision detection. I see three options:

• Only 'default Orbiter' collision detection, with the flat ground surface. Sounds like a nice weekend project for me (if someone else can do basic stuff like mesh modeling and making 'cockpit' art).
• Collision detection with Orulex-like 3D ground. I need an API with the right capabilities for this (specifically, I need to be able to get the ground height and slope for arbitrary positions).
• Full-featured collision detection with buildings, other vehicles etc.. As far as I can see now, this is way too much work for me.

---------- Post added at 11:06 PM ---------- Previous post was at 11:00 PM ----------

That whole orulex/meshland system is IMO the coolest thing to ever hit Orbiter, it's really too bad the whole thing just doesn't work right.

Making stable collision response simulation is very difficult. In Ultimate Stunts, I discovered it to be very effective to 'cheat' a bit in the physics by explicitly programming the desired effects instead of trying to achieve then through physics modeling. I think this can also be done in Orbiter, especially when you have one particular type of situation in mind, like driving a car.

 

[DaveS]

I created Ultimate Stunts. Maybe not the best racing simulator, but at least I'm not a newbie in making racing simulators.

How important is this feature? I don't have much time, but maybe this isn't much work. The most difficult part is collision detection. I see three options:

• Only 'default Orbiter' collision detection, with the flat ground surface. Sounds like a nice weekend project for me (if someone else can do basic stuff like mesh modeling and making 'cockpit' art).
• Collision detection with Orulex-like 3D ground. I need an API with the right capabilities for this (specifically, I need to be able to get the ground height and slope for arbitrary positions).
• Full-featured collision detection with buildings, other vehicles etc.. As far as I can see now, this is way too much work for me.

---------- Post added at 11:06 PM ---------- Previous post was at 11:00 PM ----------


Making stable collision response simulation is very difficult. In Ultimate Stunts, I discovered it to be very effective to 'cheat' a bit in the physics by explicitly programming the desired effects instead of trying to achieve then through physics modeling. I think this can also be done in Orbiter, especially when you have one particular type of situation in mind, like driving a car.

Well, it would be useful to quickly create the ground support equipment vehicles at KSC: http://www-pao.ksc.nasa.gov/nasafact/transportersold.htm

Would love to test it for you along with making the meshes/textures.

 

[cjp]

Well, it would be useful to quickly create the ground support equipment vehicles at KSC: http://www-pao.ksc.nasa.gov/nasafact/transportersold.htm

For the crawler and similar vehicles there are some other issues:

• It needs to be able to drive on the slope towards the launch pad. This requires more advanced collision detection than the default 'flat ground' model in Orbiter.
• You probably want it to have a fully functioning STS on top of it, so it needs to use some kind of multistage architecture. Things like that exist in add-ons, but I've never worked with them before. In fact, I only know names, but I don't know what I should use. CVEL? Multistage.dll? Something else?

For the very first version, I'll keep it very simple:

• I'll make the DLL, artwork will be provided by others
• The first version of the DLL will not support:
  • any collision detection other than with the 'flat ground'.
  • multiple stages (like the STS on the crawler)
  • virtual cockpits, instrument panels etc.
  • animations of any kind
  • Orbiter Sound(*)
• However, it will support:
  • Traction on the wheels, instead of rockets/jets
  • Steering with the wheels
  • Simulation of the wheel suspension system
  • Some very simple tire skid physics model
• Configurable settings include:
  • Positions of the wheels (first version only supports 4 wheels)
  • Per-wheel settings (like suspension)
  • Engine performance (first version only supports single-gear)
  • Meshes, mass, moments of inertia and all the other usual stuff

Does this sound like a nice start?

(*) The combination shouldn't crash, but it won't do any extra racing-specific sounds (engine noise, skidding etc.)

 

[DaveS]

For the crawler and similar vehicles there are some other issues:

• You probably want it to have a fully functioning STS on top of it, so it needs to use some kind of multistage architecture. Things like that exist in add-ons, but I've never worked with them before. In fact, I only know names, but I don't know what I should use. CVEL? Multistage.dll? Something else?

Better up: Orbiter's own default attachment system. Native support already from the beginning, no need for a special payload system. Is well used by other add-ons like Kulch's add-ons, the shuttle add-ons, Spacecraft3.dll etc.

So the payloads can be totally separate add-ons simply attached to the "transporter vessel". For SSU this would be the MLP attached to the "transporter vessel", while the Shuttle stack vessel is attached to the MLP.

 

[cjp]

Better up: Orbiter's own default attachment system. Native support already from the beginning, no need for a special payload system. Is well used by other add-ons like Kulch's add-ons, the shuttle add-ons, Spacecraft3.dll etc.

So the payloads can be totally separate add-ons simply attached to the "transporter vessel". For SSU this would be the MLP attached to the "transporter vessel", while the Shuttle stack vessel is attached to the MLP.

How much programming is involved in this? I mean, the least thing I need to do is to add a jettison key, right? Is there anything more that needs to be done?

 

[DaveS]

How much programming is involved in this? I mean, the least thing I need to do is to add a jettison key, right? Is there anything more that needs to be done?

Not that I know of. The key can be the same for attach/detach. All that you need to do is add code that checks if an compatible attachment point is within a certain range limit(up to you!) and then attach it.

The compatibility is determined by a 8-character ID string at the end of each attachment point line.

More info can be found in the Orbiter SDK Reference Guide, page 77.

 

[ar81]

It would be interesting to have some drifting capability for vehicles.

 

[cjp]

It would be interesting to have some drifting capability for vehicles.

Drifting is easy to make, it's harder to make drifting that 'feels' right. Your picture makes me think you also want a smoke effect. Another thing that probably won't make it in the first version. You know, adding features is the best way to make sure it won't be finished...

 

[ar81]

In order to make it unfinished, how about not only to make smoke, but also to simulate lateral bouncing, damage, overdrive, slick tires, and virtual 3D cockpit... ?? :lol:

It is a great effort BTW.
:speakcool:

 

[Andy44]

I couldn't care less about drifting. The vehicles I wish to simulate on the lunar or martian surface won't be the kind of thing Vin Diesel uses in his movies, unless he's playing Riddick again.

 

[DaveS]

I couldn't care less about drifting. The vehicles I wish to simulate on the lunar or martian surface won't be the kind of thing Vin Diesel uses in his movies, unless he's playing Riddick again.

Exactly same thing here.

The vehicles I intend to simulate are heavy duty ground support equipment machines which can't go over 16 km/ and can go as slow as 0.0224 km/h. And each weighing in at over 45 mT empty and being no smaller than 4 m.

So all I want to see this add-on is a realistic physics model for ground vehicles and custom engine sound support. That is all.

 

[cjp]

I made a first start for creating 'car.dll' for Orbiter.

I first wanted to model the car in 'landed' state, but it turns out that Orbiter tends to kill all rotations in this state.

So, now I made a car that 'hovers' on top of its suspension springs. It seems to work nicely, especially for Ar81's racing needs, but unfortunately the system tends to become unstable at large time accelerations, which is of course unacceptable for simulating crawler-like vehicles.

So, I created a system that automatically switches between two modes of simulation, depending on the simulation timestep. Now I still need to implement the 'large timestep' simulation mode.

BTW, I found something that could be an Orbiter bug: when I created a 1400kg vehicle, landed at KSC, with no forces acting on it (no explicit AddForce, no thrusters, wings etc.), and I set the friction coefficients to 0.0, then the vehicle accelerated with about 0.03 m/s^2. I guess this effect was never noticed before, because it tends to be hidden by using larger friction coefficients.

 

[blane]

BTW, I found something that could be an Orbiter bug: when I created a 1400kg vehicle, landed at KSC, with no forces acting on it (no explicit AddForce, no thrusters, wings etc.), and I set the friction coefficients to 0.0, then the vehicle accelerated with about 0.03 m/s^2. I guess this effect was never noticed before, because it tends to be hidden by using larger friction coefficients.

I am not into Orbiter coding but coming from the physics side: If you place a vehicle with frictionless wheels on the ground, I would *expect* it to accelerate. Unless of course there is absolutely no wind (Okay, there isn't in Orbiter) and the surface is absolutely flat and even -- which isn't the case in reality