About a year ago I wrote an article about the early days of the pinball table, now after several mothballed months it’s done and here is how it works.
A GVMachineController actor is on the map and a kismet node makes sure that the player takes control of it when the level loads. After that, all input is processed by the machine which then adjusts linked actors (changes position, rotation, etc). For example here is how the right flippers are set up:
This pinball-air hockey mashup was the very first prototype I created using Gavit. I worked on it every now and then, pimped the effects, tested Gavit’s new features and so on, until it was worth of a video:
The technical details are discussed in this “behind the scenes” article.
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.
In this article I’ll discuss the key features of the Fire material showcase video.
When I started working on the material I had the following goals in mind:
Fulfilling these core requirements was simple enough after some experimentation and I ended up spending most of the time on optimizing and making the controlling parameters easy to handle.
This latest video shows a fire material I made:
The base mechanic works for both meshes and particles, can be used for fires of different scales (from candle flame to forest fire) and the material’s complexity can be adjusted. More details are in the “behind the scenes” article.
Here is one of the assets I made for the latest Gavit sub-project:
It will be used to showcase my fire material.
I needed a flexible way to create borders around things so I implemented nine-slice scaling as a material function:
 |
 |
It takes decal projection width and height as parameters so the texture doesn’t stretch at the corners. Another parameter defines border thickness which is the absolute size of the border slices:
 |
 |
And of course the user can also define the location of the 4 cuts which create the 9 slices.
Generating the proper texture coordinates costs 24 instructions but it could be simplified by sacrificing some of the flexibility (like forcing symmetric cut positions).
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:
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.
I’ve been working with vehicles for two weeks now, covering both programming and asset authoring aspects of the task.
On the code side I had to implement proper handbrake functionality which to my surprise was missing, added a few usability tweaks and laid the foundation of a modular car system where one will be able to assemble a car from different parts.
I learned a few lessons while dealing with the less than neat codebase. These are the most screwed up ones:
- SVehicle.MaxSpeed doesn’t necessarily define the actual max speed of a vehicle. One should also set Pawn.AirSpeed high enough too.
- The stock handbrake system does not prevent the wheels from rolling for some reason. It only changes slip values on the tires so actually locking the wheels needs an extra function where you apply throttle based on the local velocity vector.
When I had my vehicle class working I started modeling the car which will be the hero of the next prototype video.
I’m a fan of classic muscle car designs so the vehicle was based on a Plymouth Barracuda but got the undercarriage of a Ford Mustang, tail lights from a Dodge Charger and the hood of an Oldsmobile. (Coincidentally all of them were from 1970.)
I used the Pixar SDS implementation of modo 501 so the high poly mesh is reasonably clean.
 |
 |
The SDS cage was the base for the low poly mesh which sped up the modeling process.
This time around I used modo (instead of Max) for object baking all surface properties: diffuse color, reflection amount and normals. The baking was performed on “exploded” versions of the objects (via a morph map) to prevent baking artifacts on surfaces close to each other:
As you can see not the whole car was baked only one half plus one extra polygon row on the other side of the mirror axis so normals are properly aligned near the cut.
There were extra textures, “mask maps” baked too where the red channel defines the area of the painted body while green indicates decals:
The decal texture is actually a distance field which is used by the in-game shader to produce a sharp decal mask:
Both the body paint’s and the decal’s color can be defined in a material instance along with the thickness of the decals (plus the usual surface properties).
The textures have a 2K native resolution but only the diffuse map is presented that way at the end: the specular map is fine on LOD 1 while both the normal and the mask maps are stored as uncompressed normal textures so they are automatically loaded at half resolution.
The uncompressed normal map not just looks smoother but also fixes the seams along the car’s forward axis where it was mirrored.
The following weeks I’ll tune the cars and add a few special effects like break lights, wheel smoke and damage.
