Posts Tagged ‘system’

I previously discussed replaying user input and in this article I’ll cover a related feature: recording and replaying rigid body motion.

The basics are quite simple: dump transformations of a physics driven actor to a file and then convert that data into a matinee, like before. However simply replaying the motion track with a mover has an inherent problem: impact and slide effects, defined in physical materials, won’t happen because no actual collisions occur. All the special effects (impact dust puff, damage decals, sparks, etc) would need to be placed and timed manually. That would be a bad workflow.

Fortunately the solution is rather straightforward: let’s constrain a KActor to a mover: the mover replays the given motion data while tries to keep the physics driven actor on the same path. The guidance is gentle since it doesn’t work against the physics engine, only corrects small inconsistencies so the result is the same every time.

In the following video I actually used an invisible mover to replay matinee data and placed a constraint on the map to link it to the KActor but later on that won’t be necessary: our own physics driven actor (GVKActor) will spawn its own constraint and in there will adjust the LinearPositionDrive and AngularPositionDrive settings.

Anyway here is the proof of concept map:

However there is something wrong: on hitting the wall the balls sometimes don’t produce the dust puff impact effect. The source of the problem is the fixed rate motion data was sampled: although transformations were recorded 60 times a second, roughly half of the collisions still happened between measurements.

The dashed line indicates the original path of an object while the orange curve is the matinee data reconstructed from the samples. The collision happened while we were not looking so we’re left with a flat part keeping the object away from the surface it originally hit.

I came up with two ideas I yet to implement. The first one is pretty obvious: let the physics actor report its status every time its RigidBodyCollision event occurs. However past experiences show that it’s not a 100% reliable, I’ll have to see if it’s good enough.

The second potential solution is trying to guess the time and place of the collision based on the data we have.

First we generate velocity vectors from the samples then we scan for a potential collision: we know that physics driven actors generally move in a smooth, gradual fashion so the difference between two samples will be small unless a collision happened. For example A and B vectors are kinda different but not much. After comparing B to C/D we can be pretty sure that a collision happened there.

The next step is extrapolating two new velocity vectors, and extension of B and D in the example, and finding their intersection (or mid-point where they are closest to each other). That point is our guess which might not be exactly precise but a lot better than what we had before.

I’ll implement these solutions after I’m done with one of the earliest, yet still unfinished prototypes I have in the pipeline. Stay tuned.

I’ve just finished the first iteration of the performance recording and replay mechanics in Gavit: now user actions can be captured and turned into a matinee using an external application.

Let’s say there is a fire truck which is a “machine” in Gavit. The truck has two main, controllable features: the body which can be driven around and the water cannon which can be aimed and fired. These translate to “machine components” inside the machines: each component monitors one particular input (like x360 left stick or the mouse). In this case the vehicle itself could react to the left stick while the water cannon to the right one.

And now let’s assume that I’m not very good at driving and aiming at the same time as I can only really pay attention to one thing at a time. Also, as will be the case in the short video bellow, I might have lot more entities to control than input devices and/or fingers. To work around these limitations multi-pass performance recording and replaying is used:

In each machine component one can define where the component should get the raw input data from: live input devices or matinee. Regardless of the source, the input can be recorded into a JSON file. (Recording can be disabled per component or in the parent machine.)

So the workflow for our fire truck would look like this:

- Enable live input for truck body, disable input for water cannon.
- Start the game and drive around.
- Convert the produced recording into matinee data which can be pasted back to the map.
- Link the fire truck machine to the matinee.
- Enable matinee input for the truck body, enable live control for the water cannon.
- Start the game, aim and put out fires while the truck is driving around on autopilot following the recorded route.
- Convert the recorded clip into matinee data and replace the old one.
- Enable matinee input for the cannon too.
- Move on to other things knowing that the fire truck will replay your performance from then on.

To stress test the system I set up a machine with 16 components (colored balls), each of them controlled by the left x360 stick. I started the game several times, each time controlling only one ball. When I was happy with the result then I converted the recorded performance into matinee data, put the ball on autopilot and focused on the next one.

Finding a way for the last two balls through the crowd was rather difficult. I had to restart the map a dozen times, it felt like an action puzzle game.

The recording rate is a machine property and was set to 60 Hz in this case which produced 500K/s clip files. For interpactors and kactors transformation data is also saved and converted into movement tracks in matinee.

I spent the majority of my time working on and with our effect container, the GVEffect class.

GVEffects are abstract entities containing any number of basic building blocks called EffectTypes. We have particle system and decal effect types working, light and sound will be implemented later. A typical setup would look something like this:

[GVEffect: FlashyExplosion]

[0][Particle system: Base explosion]
[1][Particle system: Black smoke]
[2][Particle system: Burning ground]
[3][Decal: Scorch mark]
[4][Light: Explosion flash]
[5][Sound: Explosion sound]

By combining different bits and pieces a wide range of different visuals can be created without the need for authoring new assets. (Of course having a decent library is recommended.) In the example above the black billowing smoke could be replaced quickly with a gray smoke puff sort to experiment with the visuals.

There are many additional parameters for defining the behavior of effect types like start delay or life time. Position, rotation and scale can also be set and randomized for each item.

GVEffects are always embedded in other entities which will create them at runtime when it’s appropriate. For example a pawn might have a GVEffect set up for spawning to make it look like the character was teleported onto the map.

Another example is physics material based interactions (which I implemented last week). What this means is that when two objects are in contact, the right effects are created depending on the interacting materials. For instance if a stone ball hits a reinforced glass surface the following effects will be created:

• Puff of stone dust (particle effect)
• Crack on the stone ball (decal)
• Splinters of chipped off glass (particle effect)
• Cobweb like cracks on the glass (decal)

Each material has its own set of effects for the different types of interactions: impacts, sliding, foot steps for light/medium/heavy characters, bullet/pellet/energy weapon hits, etc. The effects can be dynamically adjusted based on properties of the interaction. For example the force of an impact sets a certain parameter (called “Amount”) in the related particle systems and decal materials. What those assets actually do with that information is up to the author: a decal could change size or opacity, particle systems could vary particle number, size, speed, even turn off emitters entirely for smaller impacts.

While I had no trouble with impact effects, slide detection turned out to be a huge problem. Apparently I have no direct access to contact points in the physics scene which makes it rather difficult to find out which actors are in contact. I did manage to get the necessary data but the workaround is hacky, slow and not very reliable. I might revisit it in the future but it seems that I can not do better without access to lower level functions.

To distract myself from Gavit, I took on a side project: MCEditor. It will be a proper configuration utility for the Razer Hydra controller which to this day lacks that kind of a software. (Razer has a lot to learn from Logitech in this regard…) The programming is handled by a fellow Hydra owner while I’m responsible for the UI. We’re using C# and WPF and this is how it looks at the moment:

This is the second major iteration of the layout. I really enjoy that the challenges are so different from the ones I usually deal with, it’s somehow refreshing. So much so that I intend to start another side project when this one is done.

Next week I’ll work on motion replay for rigid bodies and try to finish my earlier pinball prototype.

During the past two weeks I spent the majority of my time programming. One of the features I got working (at least on a basic level) was matinee based digital input replay, which means that matinee can now mimic user input for both analog axes and digital buttons in order to drive GVMachines. This replay of captured user performance is a fundamental feature of Gavit’s machinima support.

Read the rest of this entry »