Building a Rotator from scratch

Please note that I didn't figure out how to make this at all. I had no idea how to make a rotator. I had to look at the Custom Rotator material function to figure out how to do this.

I just noticed that the TexCoord and pivot point are in the wrong places. (they should be swapped) This obviously wouldn't make a difference if it's rotating around the center but it won't offset back to the right place for any other pivot point.

Racing game: Missing features

I've had these for a long time now but never bothered to screenshot them. I was going to wait until I had a proper UI for them but I may not have time to put that together anymore.
Maybe I never noticed it before but we now have a HUD assignment in programming class, one requirement is a speedometer.
The speedometer is straightforward. I didn't try to make the output accurate to real world scale but instead based it roughly on the top speed of a Wiesmann GT MF5.

At first I had the Wrong Way code set up with a Next Checkpoint variable that was driven by a list of checkpoints I had put in order. This worked perfectly but required manual labor for anyone wanting to use the code. I attempted to make it procedural by swapping the A>B and A<B and measuring from the last checkpoint you touch, but because of the way Touch and Gate work, the WRONG WAY message always appears briefly when switching to the next checkpoint. I did figure out several ways to fix the problem but it really should just work like this.

This still isn't good enough because it doesn't take into account which way you're supposed to go, only whether or not you're moving away from the last checkpoint you touched. Since all checkpoints already need to be facing the direction the player is supposed to go, I figured I could compare their Yaws and any time opposite values within a certain threshold were returned, it would allow WRONG WAY to be drawn. I briefly tested getting the Rotation and the Rotation Vector but neither seemed to be outputting the local object rotation and since switching back to the Next Checkpoint method would solve the problem anyway, I didn't bother experimenting further.

Electrical Arc progress

Dylan and I worked on the Beam more in class yesterday. Now, not only does the beam target random locations in the air but a thicker beam contacts random locations on the ground. To make this work with prefabs (and also because his level has an organically shaped ground) we had to use a Trace for finding contact points then reset the target location back under the level (Z offset is now a fixed, negative number rather than a random float like before).
The Nodes for the other beam have been removed to make it screenshot nicer.

Oops, pretend that Toggle is hooked up to the emitter.
(I edited out walking away because it didn't toggle off. That explains why.)

Building a Panner from scratch

I recently learned about plugging textures into the UVs of other textures to distort them and that got me thinking about how the panner and rotator nodes work. The panner was simple enough, it's just constantly adding a value that's offset by the ramps in either channel of the TexCoord node. The 2 vector constant acts as the Speed X and Y for the panner. The only trick is that Time outputs a scalar value and needs to be appended to itself to be multiplied with the 2 vector constant.
At first this may seem useless beyond understanding the node (like many of my previous breakdowns) but it actually has applications. I helped Dylan improve his electricity particle by using this panner with a noise texture for the speed instead of a 2 vector constant.

I'm still working on the rotator node and luckily there's a material  function called Custom Rotator that I think will help me figure it out. I just don't have time right now. (Plugging Time into the rotation angle gets a constant rotation, I just need to figure out how the math inside the function works.)

More Progress on Electrical Arc

These are some very rough, quick proof of concepts Dylan and I made after class today. While looking through the vector parameters for the emitter we discovered a Random Vector variable, as seen in this screenshot, and used it to produce the first result.

Unfortunately it's not possible to make the beam particle update in local space, so these random variables will not work in prefabs because they reference points in world space.

With no point of reference it may be hard to tell but the triggered beam is switching location with a random offset. Dylan wanted to animate the beams in Matinee and I suggested using the following Kismet code to change the location procedurally. This code could be combined with the previous one that targets the player to set up a nice effect, but it seems like a heavy solution for the desired effect. Perhaps there is a way to do most of the work in the emitter but we couldn't figure it out today.

Building Fresnel from scratch

I wanted to see how the Fresnel node works so I attempted to build it in the material editor.
According to a comment in the .uc file for the function it's, "pow(1 - max(Normal dot Camera,0),Exponent)" with a default exponent of 3.
So it turns out that Fresnel is 1- the dot product of a camera vector and a normal (top).
Well that was easy… So in reality my goal was to build a dot product in the material editor.
Luckily there's a way to get the dot product without a bunch of fancy trigonometry: X1*X2 + Y1*Y2 + Z1*Z2

Switch params were just for testing the results.

Deriving the B channel on a normal map

I found this function in the VectorOps that I'd never noticed before. It's really cool. My plan for normal maps this semester was to just use the R and G channels and append 1 into that. (top row) With this function (middle row) I can still pack my textures but I will also be able to get an accurate B channel. Obviously appending 1 would be cheaper but it'll be interesting to see if there's a noticeable difference in appearance that's worth the cost. Bottom row shows how the function works. √(1-(xx+yy))

GA222 Blog: Character Turnaround

I wanted my character to be curvy like the car so I made him fat. The car is pretty expensive and since the rich are often portrayed as fat, that seemed to fit nicely. The car is white with black and red accents so I made his color scheme compliment that.

I didn't really plan on making a German character but others seemed invested in the idea of him being German so I came up with this lame, cross-language pun for his name.

UDK and Photoshop filters

I thought it'd be interesting to try replicating two photoshop filters in UDK (before I found out they were already in the material functions) but the exercise was still fun and taught me the math behind these two filters. I think understanding how they work is useful so I wanted to lay it out here.

Screen:
This one was simple enough and my solution looked exactly like the material function in UDK.
The math for Screen is:
1-(1-a)(1-b)

Overlay:
I never got the result I wanted for this one and now that I've seen the UDK solution I know it's because I was trying to do it without splitting the channels. The reason is that If only takes float values (UDK even tells you this but I didn't connect the dots) so you have to break the images into their separate channels and append them back together after running each one through an If.
The math for Overlay is:
2ab,                     if a < .5
1-2(1-a)(1-b),    otherwise
(Sorry the notation doesn't look pretty. I couldn't get MathJax working the way I wanted)

I'm not sure why they're running the base through a subtract and a clamp (set to 50). I couldn't test it with these textures though because the result is the same as 2ab. I'll try to figure that out some other time.