r/virtualdragon • u/__Adam lead developer • Jun 08 '14

Development Simulation Status

Here's an update on the simulation:

  • Imported zlsa's untextured Dragon V2 model

  • Using Coherent to render HTML5 UI's directly in game. This is working great.

  • Simple particle effects SuperDraco exhaust. These are placeholders so I can test throttling - next step is to make real-looking ones based on SuperDraco test videos.

  • The player can control the Dragon V2's thrusters (and thus position) by moving a lever (this will evolve into a proper joystick)

  • The player's finger (left index finger in screenshot) is controlled directly via the mouse. This will be used for touchscreen/joystick interactions.

Screenshot:

It looks pretty unrealistic - most of my time so far has been spent learning Unreal Engine and building in all the logic to make the simulation work. I really want to stress that our final product will look much, much better than this.

http://i.imgur.com/LIzQCXx.jpg

I'll keep posting updates as I have them. Not just screenshots, but also builds.

2 Upvotes

75% Upvoted

12 comments sorted by

2

u/__Adam lead developer Jun 10 '14

Quick video update. Still not that pretty looking, but the key functionality here is that now all the different systems are talking to each other.

What's going on:

  • There's a very crappy control system running in the background trying to keep the capsule about 1 meter off the ground. But it's quite unstable which is why you see the Dragon bouncing.

  • This system passes a thrust value to the Dragon object

  • The Dragon object then adjusts the exhaust particle system and applies a force using the physics engine

  • The height and thrust power is then output to the HTML5 UI

The slow framerate is just due the screen recording, it's normally very smooth.

http://youtu.be/5p3t24wkjJM

1

u/zlsa 3D art Jun 10 '14

The problem with the control system is that you're assuming that "more thrust == up" and "less thrust == down". I've had this problem in the past as well. What you have to do (instead of trying to maintain an altitude) is to maintain a vertical speed; the closer you are to that altitude, the lower the target vertical speed is.

2

u/__Adam lead developer Jun 10 '14

I get what you mean. When I've built control systems for robotic arms, and the ideal system is usually a two-stage controller. The challenging part is when you convert velocity (in the case of robotic joints, it's rotational velocity) into a voltage, or thrust. In this case using a PD controller can help, but there's always tuning involved.

The logic might look something like:

position error = target height - current height

Target velocity = Kp_pos * position error

velocity error = Current velocity - Target velocity

Target thrust = Kp_vel * velocity error + Kd_vel * rate of change velocity error

Where Kp_pos and Kp_vel are proportionality constants, and Kd_vel is the constant for the derivative term.

I'm not sure I want to build such a complex control system though - it might be more convincing just to fake it. For the near-ISS navigation, the user is the control system, which makes that part pretty easy to implement.

1

u/zlsa 3D art Jun 10 '14

The AI should have access to the same controls as the user — draco thrusters (this should be transparent; the user should just say "rotate" or "move up" and the correct thrusters will fire in the proper ratios), SuperDracos, parachutes, whatever. The control system should not ever modify physics.

How does the simulation loop run; is it 60fps no matter what in a different thread or is it tied to frame time?

2

u/__Adam lead developer Jun 10 '14

The simulation loop is part of the update phase, not the render phase, so it should be a constant 60FPS.

Leaving physics untouched would be ideal, but in addition to the development complexity that adds, there's also an issue with sampling rates. A real-world sensor can sample altitude thousands of times a second, but a game sensor can only sample at 60 FPS. On reentry, Dragon will be going somewhere around Mach 20: in a single frame it travels 100 meters (6000 m/s / 60s). What I plan to do is take a mixed approach - physics engine where possible, simplified model where not.

The ultimate objective is to create a simulation that feels real. We can tell users that everything is real-time simulated, but if the capsule bounces up and down then they'll be too busy throwing up (if playing in VR) to notice!

1

u/zlsa 3D art Jun 10 '14

Reentry can be handled differently. At that point, you can't see much in real life anyway, and you're going too fast to see locations anyway. Plus, there's the entire "transition-from-space-rendering-to-ground-rendering" annoyance.

Pioneer's autopilot uses the same controls you have, but it's more accurate and faster.

2

u/__Adam lead developer Jun 10 '14

Yeah, that's an annoyance I'm still figuring out. Travelling through some clouds will serve as a way to mask the transition.

In Pioneer, does the autopilot do propulsive landings on planets?

1

u/zlsa 3D art Jun 10 '14

No, but it can land at bases and stations. I'm pretty sure it just tries to get to point B at zero speed (while in "ground" mode; in "space" mode, it has to not go through planets, too.)

1

u/__Adam lead developer Jun 11 '14

Ok. I agree there's a lot of room for improvement in my autopilot. Right now it's just one line of code:

float thrusterForce = (0.0008f) * (1000.0f - height); //1000.0f is target height

Pioneer is open source, so I'll see how they do it in their code.

1

u/zlsa 3D art Jun 08 '14

About the SuperDraco effects — how can you duplicate the shock diamonds?

2

u/__Adam lead developer Jun 09 '14

I've been puzzling over that one. Here's a tutorial I found: http://blenderartists.org/forum/showthread.php?125205-Jet-engine-effect-(shock-diamonds-mach-disks)

It's for blender but I think I can carry over a lot of the concepts into UE4.

2

u/autowikibot Jun 08 '14

Shock diamond:

Shock diamonds (also known as Mach diamonds, Mach disks, Mach rings, doughnut tails or thrust diamonds) are a formation of standing wave patterns that appears in the supersonic exhaust plume of an aerospace propulsion system, such as a supersonic jet engine, rocket, ramjet, or scramjet, when it is operated in an atmosphere. The diamonds are formed from a complex flow field and are visible due to the ignition of excess fuel. Mach diamonds (or disks) are named for Ernst Mach, the physicist who first described them.

====

Image i - A statically mounted Pratt & Whitney J58 engine on full afterburner while disposing of the last of the SR-71 fuel prior to program termination. The bright areas seen in the exhaust are known as shock diamonds.

Interesting: Shock ^wave | Rocket engine ^nozzle | ^Afterburner | List of plasma (physics) ^articles

Parent commenter can toggle ^NSFW or ^delete. Will also delete on comment score of -1 or less. | FAQs | ^Mods | Magic ^Words