Cool/weird cubemap shader effects?

Swizzle

I was discussing this with some people at work and we were trying to determine how the sword effects in this Guild Wars 2 video were achieved:

[ame="http://www.youtube.com/watch?v=_J_spuKY3oQ"]Guild Wars 2 Legendary Greatsword Twilight - YouTube[/ame]

It's pretty obvious that they're projecting a cubemap on the mesh and effects, but the cubemap isn't affected by things like surface normals since there's no distortion happening. I'm not entirely certain how they did that, but I've my suspicions that it's some sort of weird camera projection trick. I could even see it being a crazy post-process effect that gets masked by the geo and particles, but that seems kind of unlikely.

Anyway, I'd like to be able to replicate something close to this in UDK.

Thoughts, ideas, solutions?

r4ptur3

The sword blade is jet black -- does the red/blue image receive lighting information? Is it possible to make an unlit material with a cube map fed right into emissive? The sword will always have an image mapped on it (even in the shade) but it looks like that'd do the trick.

Swizzle

From what I've seen both in videos and in the game, the sword doesn't have receive any lighting information. I can't say whether the cubemap is fed directly into the emissive or not, but that seems like a somewhat logical thing to do.

Here's an animation from me rotating a character with the sword in the weapon preview window in the game:



There's only distortion around the edges where there's also some animated effects happening. As you can see, the cubemap is pretty much unaffected along the center of the blade. It doesn't react to the surface normals in the way you'd usually expect a cubemap to.

sprunghunt

if you use the camera vector as the UV input for the cubemap you should be able to get it to stay locked to the screen like that.

Drew++

Yep sprunghunt is correct! But invert it before hand


Alternatively: It also seems to be fairly flat, possibly even entirely planar so a basic normal would work.


If you have a normal map on your model, maybe try this old school way to do reflection vector, before we had reflect().

You can then plug your normal map into the "Normal" Slot and do the rest of your model textures like normal. Just mask out the custom reflection, from the rest of the model.

Minato

Drew, can you elaborate a bit on the camera inverse?...

Drew++

Minato wrote: »

Drew, can you elaborate a bit on the camera inverse?...

The cubemap would simply show upside down without it

lpcstr

Drew++ wrote: »

...

Why on earth are you normalizing a constant which is already explicitly unit length?

Swizzle

Awesome! Those work perfectly, Drew.

Drew++

lpcstr wrote: »

Why on earth are you normalizing a constant which is already explicitly unit length?

lol, I had some other stuff plugged into it before, used it as a multiplier to flip a channel, and I ended up never removing it cause I'm lazy like that.

sprunghunt

Drew++ wrote: »

Yep sprunghunt is correct! But invert it before hand

you could use a 'oneminus' node here instead of the multiply and constant.

I guess it's essentially the same thing - but much neater for the OCD shader makers among us

Farfarer

sprunghunt wrote: »

you could use a 'oneminus' node here instead of the multiply and constant.

I guess it's essentially the same thing - but much neater for the OCD shader makers among us

Not really.

Say vector.x is -0.03

OneMinus gives;
1 - -0.03 = 1.03

Multiply by -1 gives;
-0.03 * -1 = 0.03

The second one is correct :P

Drew++

Farfarer wrote: »

Not really.

Say vector.x is -0.03

OneMinus gives;
1 - -0.03 = 1.03

Multiply by -1 gives;
-0.03 * -1 = 0.03

The second one is correct :P

You are correct! Alternatively you could always do ( 0.0 - x ) instead of ( x * -1.0 )