Download

World Position Offset wierdness on LOD meshes?

Getting some weird issues with World Position Offset and my mesh, wonder if anybodies seen this before?

Basically I’m just trying to collapse a mesh so it’s almost flat, to prevent having loads of overdraw when a translucent material is completely faded out. It seems to work for some of the polygons on the mesh, but not all of them. What’s odd is, it seems strangely linked to the lowest LOD mesh. Here’s the shader math for that, plugged into WPO (the planes of the mesh are UV-mapped from top to bottom, nothing special).

WPO.PNG

It works fine with LOD2, but with LOD1 and the Base LOD, only the planes that exist in the same place as those in LOD3 are being manipulated. As you can see below, the LOD’s share some of the same polygons as the hi res meshes, they’re just less dense. I’m using Shader Complexity view in the engine as it shows the outline better:

f13561ef2bb41faa87fbbb57a4fe2e837acd506e.jpeg48f1ba42c7c6d8da48dfcd26b051a456d7396a78.jpeg
Any clues as to why this isn’t working correctly? Would I be better off painting vertex colours for each LOD instead? They all use the same UV’s. To clarify, the furthest LOD is working fine, it’s the closer two that aren’t.

Hm, this is an odd effect. Honestly it could be linked to several things. Have you tried not relying on the (G) channel (driven by a textureCoord.), but rather building this in world>local space? Driving it off of mesh uv’s might be the issue. If you build both equations in world coordinates and it is still occurring, it could be related to export settings and or some mesh issue (perhaps a quick stl check might yield something)? I would honestly try to rebuild the equation before doing anything else though.

Edit: I am sure you have thought of this - but instead of adding more complexity to the shader in order to drive the mesh bounds lower (thereby reducing overdraw), have you thought about simply forcing the render distance to be set just beyond LOD2? This way as the rain got to a certain pixel size, the mesh would literally stop rendering. Even though you are crushing the mesh, it is still being calculated and rendered. The performance might be better to some degree, but it doesn’t “remove” it. Unless there is something you are doing that I am un-aware of, in which case - my apologies :stuck_out_tongue:

-Jeremy-

Hey Jeremy,

As for Part 2: I do indeed do that already, There is one additional LOD layer that’s just a single tiny little triangle.

I haven’t tried without the TexCoord yet but I think that’s the next step, I’ll give your idea with the local/world space math a test and see where I get, shouldn’t be too difficult to implement that. I’ll give Vertex Colours a go as well, though I don’t really want all those meshes in the scene with vert colours taking up valuable resources too (even though it’s probably insignificant).

Just thinking aloud here now… I could do the WPO math by taking the World-Position of each Vertex, subtracting Actor/Object Position, then getting all vertices within a threshold in the Z-axis. Shall try that. Vertex Shaders are fun :stuck_out_tongue:

Basically when i use WPO the edges in between mesh faces disappear. Which makes me wonder what the point of WPO’s is. Looking through some of the doc’s i see BumpOffset is used togetehr with height values.

So, what would be the best solution to facilitate those height maps, through bump offseting nodes or is there a way to integrate them with WPO?