Hi, I guess this might be more of an enhancement request. The type of objects I work with are imported (originally CAD nurbs). Many times for convenience I use cubic projection on the texture tag instead of UVW to ensure the texture looks reasonably OK with the correct scaling of the tiles. The problem is, Arnold doesn't seem to like any projection other than UVW.
In the material I have an image>bump2d>normal node of a standard surface. With cubic projection the result looks strange (checker marks and overall shading looks off):
However, if I right-click the texture tag>Generate UVW coordinates and ensure the projection of the tag is set to UVW Mapping, the result looks correct:
I guess I could remind myself to always generate new UVW coordinates for these types of materials, but is it possible for Arnold to correctly use projections other than UVW in C4D? Perhaps internally generate UVW coordinates so that the user doesn't have to create them him/herself?
Thanks.
The bump shader uses some surface derivatives which are not updated when a non-uvw projection is used. I'll take a look if I can fix this in the shader. Otherwise internally generating the UVW coordinates might be a good idea.
Actually I'm not able to reproduce the issue. Can you send me a scene please? Also what's your C4DtoA version and os?
Hi Peter, attached is the C4D R20 scene. Replace zip with rar (rar did better compression to get under 2 mb).
There are 3 different tests, with a total of 6 renderings to make. In general, the cubic projection shows darker color, with strange shading breaks. Displacement shows odd lines in the middle.
C4DtoA: 2.4.1.2 R20
OS: Windows 10
Thanks, I could fix the issue using your scene. It will be available in the next release.
I just added the workaround to automatically generate the UVs from the texture tag. Will be available in the next release.
Peter, the cubic projection bump on the new version 2.4.2 looks perfect. However, cubic projection displacement is still an issue, although looks better than before. As I understand, the Generate UV's and Texture tag in the Export tab in the Arnold tag must be set.
This is with uvw projection:
And this is cubic projection with the new Generate UV's export method:
The marked areas show a different/darker shading compared with the uvw projection.
Hmm I did not notice that, but indeed I can see the difference. This displacement is tricky... : ) I'll take another look.
Yep, my bad. I forgot to disable the texture tag, so besides the generated UVs it also executes the cubic projection. Will be fixed in the next bugfix release, which I hope will be out soon.
Here's a fix for the displacement. Please let me know if you still see any differences.
https://safeshare.solidangle.com/index.php/s/24O1jmF90J1Cbkz password: UX9g72I installed the fix, did some tests, both bump and displacement, with different projection types, modified those projections, and everything looks perfect. Thank you so much.
However, I noticed that now, using the old method of right click>generating UV coordinates, the result is worse (for displacement). But I don't think this will have any adverse effect on any existing workflow, as from now on I will always toggle the UV checkbox and set the texture tag in the Export tab.
Lastly, I wonder if the UV checkbox and texture field in the Export tab can be eliminated, and have Arnold automatically generate UVs for all texture tags on the object (without needing an Arnold parameters tag). I don't see a situation where the user would rather not have automatically generated UVs, even in cases where it doesn't make a difference (e.g. a texture that contains no pattern). If the texture tag is already set to uvw, then of course no UVs would need be generated, but when using any "custom" projection (cubic etc), automatically generating UVs would always provide a better result, as far as I can see.
The old method (right click>generating UV coordinates) should produce exactly the same result as before. And it should match the auto generation.
I would keep the options for now. Doing it automatically needs more testing (performance, etc.). In theory it should work, yet maybe there are some use-cases, where it's not beneficial (I don't have any in my mind though).
I had several reports that bump mapping looks different in 2.4.2, so I'm afraid I have to revert the changes in the upcoming 2.4.2.1 release until I find a proper solution which works in all cases. You can still use the workaround of generating the UVs from the tag.