Been using the vertex interpolator node a lot recently at work to optimise down shaders (mainly UV-based stuff which doesn’t need to run in the frag/pixel shader). But we noticed 2 things that happen; it breaks baking our lighting unless we use a LightMassReplace switch (should this not automatically be integrated into the VertexInterpolator node if it causes issues?), and it sometimes causes compile errors (stuff to do with the TEXCOORD buffers, assuming this basically automates the custom UVs for passing data from vert to frag/pixel shaders) but only on certain machines (even though they’re using modern hardware, GPU is just an Nvidia 1070).
Anyone else have any issues with the node or anything else they’ve noticed?
Also should say we’re using 4.16.
When a material is used for Lightmass all vertex-dependent information is ignored. I guess that’s because the surfaces are processed in a completely different way that doesn’t involve vertex shaders. About the texcoord registers, there is a limit to them (16 float4 registers, I think) and they are also used by the main and lightmap UV, so you need to keep that in mind and not go overboard with the vertex interpolators.
Agreed, it should really do the light mass replace thing itself (i.e. Light mass ignores the node). I wasted a lot of time trying to figure out why my bakes were all dark.
Also, I can’t recall the exact usage, but sometimes I’ve noticed I have to use a component mask to force a single channel output from the node, when I’ve only passed a single channel into it. Just a small annoyance.
This is not the case. Custom UV’s work just right for lightmass. For some reason vertex interpolator nodes have some kind of bug that cause them to be ignored for lightmass. So just change vertex interpolators to customized uvs and everything is OK.
@Spoondog I’ve had the same issues with it outputting vectors with scalars sometimes - again can’t nail down an exact cause for it. And that makes sense actually I guess @Manoel.Neto. We managed to fix the issue on the specific machine I believe as the DDC folder on that machine was corrupted.
Sometimes custom UVs can even make a more readable material tbh, and easier to keep track of. But sometimes the interpolator node is cleaner. I use both. The light mass thing is indeed a pain though.
Vertex interpolators can also make pseudo chains if you have feature level switches. I did have to stop using them in any more complex material because of htat.
I think bug is related to this bug. Somehow vertex interpolator can’t handle scalar -> vector3 conversion. Lightmass bug somehow mess vector3 as scalar.
Interesting stuff, thanks guys! And yeah it basically is just automating the custom UV process though, which is useful when you’re utilising shader functions and can’t guaruantuee which UV slots you’re already using so it’s pretty handy to allow the compiler to handle that.
Hi everyone, thanks for raising this issue. The interpolator code was blocked out for Lightmass as a default value and never filled in, so I’ll look at getting the correct data returned for 4.21 if Lightmass is capable of consuming the it correctly. The change should be as simple as actually calling the real functions on the translator though as some of you noted, Lightmass doesn’t support everything so you’ll still need to be careful what you do and don’t pass through. Interpolator nodes should be the equivalent of using CustomUVs though and give the same support.
The interpolator node was intended to be a workflow improvement to shift away from CustomUVs, offering auto-packing and an inline method to handle your data so ideally it’s interchangeable, you can even use them side-by-side if you wish. There are still some edge cases but the intention is that you can use each as freely as the other.
@Kalle_H, the scalar/vector bugs are because the interpolator node uses a strict type rather than loose (Float1 vs Float) which the enforced up-cast on final output interprets slightly differently. It was initially done that way for correctness but in practice can cause more unknowns than it solves. There’s an issue ticket in to address it so hopefully the behavior will be more intuitive in the future.
If you have an example of the issue you mentioned with switches I’d be interested in seeing the problem, I don’t believe that’s one we have logged.
Problem is quite hard to naildown. It’s happened on quite big uber material that support uv scalings and POM. For mobile POM is disabled and all uv scaling code is at vertex shader. This causes compiler to think that pixel shader information is feeded to vertex interpolator even tought this is not case when Feature level switch is evaluated. I try to make minimal test case.
This is simplest way to show the bug. This may seems quite stupid material but in more complex materials this kind of stuff happens.
Minimal test project can be downloaded here CircularDepency.zip - Google Drive
@Kalle_H Technically that’s correctly is it not because you are interpolating Vertex -> Pixel, and then trying to interpolate that again but technically by that point it’s already in the pixel shader so you can’t interpolate again?
Thanks @Kalle_H, I reproduced the example issue and made a ticket so it doesn’t get lost. The the ES3.1 interpolator pre-compiles its input even though it’s not actually used as the current flow is a two-stage process, only after input translation does the node usage get considered.
@Calvinatorr, Kalle_H should be correct as feature level switches only read the input of the active feature level. So the ES3.1 path should only hit the second interpolator and SM5 should only hit the first interpolator. In the example posted there’s an SM5 error that the second interpolator is connected to the first, which shouldn’t be happening.
