I’ve created a Vray material of a procedural brick with a triplanar mapping.
Altough the wall seems to be rendered correctly, the beam on top does not follow the triplanar (both in interactive and normal render).
I’ve tried to change beam type but it seems it follows its own logic when it comes to UVs.
Any idea how to fix it or is it an already known bug?
I’m using the Beta version for Rhino 8.
ps. by exploding the beam the mapping is corrected but of course that should be my last option
I can reproduce the Interactive Render bug using a native Rhino blocks with a non-uniform scale (1D scaling). This is how VisualARQ creates the beams, sharing the same block for all beams with the same profile section, and then using a 1D scaling depending on the beam length. This way VisualARQ models are smaller in disk and memory.
Here is a model with a Rhino block with the same issue: WALL+BLOCK.3dm (350.9 KB)
I’ve been thinking about this issue. Although I think this can be fixed in V-Ray, I can see that the problem is not entirely a V-Ray problem. I can reproduce the issue using Rhino render, if you use a simple textured Rhino material, and then render the document on a Rhino without VisualARQ. In Rhino you can fix this issue using WCS mapping.
Anyway, I will add an option in VisualARQ to not use scaled blocks on VisualARQ objects. This option will make files with lots of beam a little heavier, but will fix any render issue on interactive renders, non-WCS materials, etc.
I will try to implement it before VisualARQ 3 release.
