• News

• Industries

• Learning & Support

• Community

• Marketplace

# How to make a texture to always face the camera?

Hi to all. First of all, I don’t know if I’m making a stupid question, but I can’t find any way to achieve it. How can I set a material to always face the camera? I’m trying to import a 3d model of a tree and, for the leaves, the material needs to be a 2d texture with an alpha channel, applied on to planes that have to face the camera. Here are two pictures that describe my problem.

As you can see, from a frontal point of view it looks good, but seen from the side, it looks flat. How can I make it to turn in order to always face the camera?

Check out my tutorial here!

Thanks, but this method doesn’t work for this case.

As you see, the leaves consists on a lot of planes. I don’t think that working with a hundred billboards per tree is the most efficient way to do it. I need to have the texture mapped onto the tree, not as a single plane, and I need it to react to the material properties (normal maps, roughness, …etc.) so this method doesn’t work for me, but thanks for the tutorial. Do you know any way to achieve the same effect but as a mapped material instead of a separate actor?

Take a look at World Position Offset in the Material Editor.

After a lot of effort and failed attempts, finally it works. For everyone who’s got the same problem, here’s a nice solution, under the Foliage Material section (https://docs.unrealengine.com/latest/INT/Resources/Showcases/Stylized/Materials/index.html). But even now, it’s not exactly what I’m looking for:p When I apply it to the tree, It looks really weird because all the leaves pivot like a single object around it’s center. What I exactly need is to have every face of the material to face the camera.

When I move the camera, the whole object turns to face it but, as you can see, every face of this cube still has it’s original orientation, these faces are not facing the camera. Do you know what can I change in a way that every face of the object turns to the camera, not only the object as itself?

I don’t fully understand what you mean, you want the faces to face the camera but don’t want the leaf planes to rotate? There isn’t really any other way of achieving it

Or, do you mean that they are only rotating around one axis (the up/down Z Axis?) If that’s what you mean, take a look at the examples in the Math_Hall in content examples. Near the end in the Vector Math section, there are two examples of rotating planes to face the camera, using slightly different systems.

Don’t forget that WPO only updates on the GPU side, and that information doesn’t pass to the CPU. What that means is that sometimes your leaf planes will be out-of-bounds, so you’ll have to manually increase the objects bounds to prevent any dodgy popping or clipping when the trees are at the edge of the screen.

Check out the math hall content example. There is are 2 styles of camera facing math examples show near the very end. I have used both of those techniques to do speedtree style camera facing sprites. You can also transform the normal map properly so the sprites light correctly as they rotate.

To do it inside of a single tree mesh you just need some way to store the center position of each leaf poly. Several ways to do that. You could store their local space position using the pivot painter script, or you could do that manually by doing a uv planar map set to 1 scale centered at 0,0,0 and then collapse the charts to a point(by scaling them by local center). You would need one map top down and another from a side axis to store the Z location too(uv is only 2 components we need 3). Then a local to world transform on that UV position can be used determine the world space positions in the material, by first subtracting worldposition and then adding your new centers.

Or you could just scale the polls down so they are verrrrrrrry small, almost invisible. Then you can just project out wards from that tiny position. The downside to the last technique is that your polls will not really cast much static shadows. Light mass does not see vertex shaders. The other methods let you build your ploys to any size and have them facing a convenient direction for lighting.

Hi Ryan,

I would love to know how you would calculate the normals and use a normalmap with this technique.
With my material I subtract the world position from the camera position and normalize that and then I add the normal map and plug that in the normals of the material that has the tangent space normals off.
This doesn’t seem to work. What would be the correct way to do this?
Here is a screenshot of my material and from the result:

The correct way is with a transform. I’m not completely sure the method you are using between the function and the custom UVs but sometimes just a view->world or a view->tangent->world transform. and there there are times when you need to do your own custom transform based on your own vectors. And then there are times when everything is right except for one viewing angle and you pull your hair out until you magically try flipping the Z or something…

If it really is just a simple UV projection, try doing the view->tangent transform. if you leave the “Tangent Space Normal” option as true in the material then it will automatically do the tangent-> world part. I think you need to multiply by 1,-1,-1 before the view-> tangent transform. check out the “Sprite” function or “ImposterUVs” for two completely different ways of solving this.

Thanks, going from view>tangent space and multiplying the normal map by -1 1 -1 works!
The only problem is now that when you rotate the camera the shading changes slightly. Only when you look at the particles directly the lighting looks how it should, but when you rotate the view away from the particles the light direction on the particles slightly changes.
The sprite and the imposter functions have the same problem.
I tried to rotate the normalmap from 0 0 1 to the particle position - camera position vector, but that didn’t give the desired result. I having trouble getting my head around this whole vector math stuff.

Is it the normal changing or the shadow casting? If your normals are based on a perfect sphere then they should look absolutely identical to a real sphere from all angles. If not then you still have some unsolved issue with the transform somewhere.

The other thing that can cause issues is that the sprite may face a different direction than perpendicular to the camera in the shadow pass, which is why you see kind of thin slivers of shadows when viewing at 90 degrees to the light. That one is fixable but takes quite a bit of workaround, unless you just use view direction for the spite WPO offsets, which get corrected in code during shadow pass automatically.

The problem is still there without the shadow.
I have some screenshots to demonstrate the problem.
I just rotate the view without translating the camera.

I think I know what is going on there. It might not be the orientation that gives the inaccuracy, but the distance from the center of the screen.

Transforming this way is using only the camera forward direction, not the CameraVector which actually varies across the screen. In the past I fixed this manually for important shaders where it really matters to make it correct. You need to perform the transform manually by calculating cameravector as camerapos - worldpos (you need to add in the offsets) and then derive the other 2 vectors using the material function Create Third Orthogonal Vector. Then use the function matrix 3x3 transform.

I agonized over a similar issue a bit over a week ago.

It really should not be necessary to do steps like that to get this right. A transform should be all that is necessary. No rotations needed here. I know you aren’t believing me but I have set it up many times and matched it against real spheres just like the above image. There are lots of little things that can go wrong and confuse you with these methods so it is important to keep things simple.

Indistinguishable from the real spheres:

4 are sprites:

Transform:

Make sure tangent space normal is DISABLED for this method as it works differently than the sprite function.

I think something went wrong with the attachments

The face to camera from materials cause me problems with the cast shadows.

That is becuase camera position isn’t changed in the shadow pass. If you need it to face the light you should use the view transform method or use the Camera Forward, left and up vectors for the transform since those do get updated in the shadow pass.

It is possible to fix other kinds of transforms but that requires performing a dot product with the camera forward vector and your known light vector, and checking if they are within a certain threshold and then changing the transform of the shader. note that it will also cause a change when the camera is actually close to the light ray but it shouldn’t be a big deal with a small threshold. Note that the above method is pretty tricky to set up. I only just came up with it a few weeks ago and hasn’t been very tested.