Announcement

Collapse
No announcement yet.

Render to texture issues

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Render to texture issues

    Hi there,

    Apologies if I've missed something but I reported multiple problems with render to texture quite a while ago to support (#455453, update 07/02/2019 raised on new ticket 761-538-581), and have not heard of, or been able to test fixes on any 3.x release, win7-10, 3ds 2015. And these look to still be an issue with 4/next too?

    Would greatly appreciate if someone could take a look and let me know what's going on. And again, apologies in advance if I missed a response, or am doing this wrong, but these seem to be legitimate issues.



    Issue 1: Normal requires re-saving [Think the upshot was this is an issue with max and out of the remit of v-ray... so feel free to dismiss?]

    Gamma is applied to normal map output from render to texture when saving, however, it does actually appear to render correctly in frame buffer, the problem is this then gets saved with gamma applied incorrectly?

    Also gamma override in the normal map file output seems to be ignored/reset, and is impossible to set en masse for when adding the normal element to multiple baking objects and multiple outputs.

    Output saved (wrong) -> workaround re-saved in post (correct)





    In addition, none of the normal map options in the projection mapping options from…
    3ds>Rendering>Render To Texture / Projection Mapping [section] Options… [button]
    … appear to apply to render element, possibly by design? [Swapping green/red directions etc.]

    Workaround: Easiest to resave composited normal maps after getting them out from 3ds. However, possible confusion/duplication if normals are derived/re-produced in different manners due to other workaround issues (see below).

    Desired fix: Do not apply gamma to normal map output tick box option. (Like color mapping.) Lesser issue but further normal settings from option button linking to the VRayNormalBump render output.




    Issue 2: Opacity map issues [Believe was reported to dev - to the best of my knowledge remains unresolved?]


    Opacity map not recognised as expected in render to texture.

    Examples:
    Scene geometry, walls and a bent planes for a tree cut-outs:





    Scene mapped with materials and rendered via camera with complete and normal bump render elements:






    Render to texture results for a wall bake, whereby trees are projected onto rear wall - renders opacity map alpha through tree and also wall – shows just environment on transparent sections not the wall? In addition ‘stacking’ is impossible. Front most opacity appears to alpha through any subsequent masks.



    Workaround: Have attempted use refraction for complete map + mask overlays for glossiness and reflections. Introduces another problem (see 3 below) light artefacts on intersecting refractive/non-refractive materials. No solution other than to render masks and composite with another pass that excludes normal pass from the baking projection.

    Desired fix: all output types to obey/recognise opacity map when present.
    Last edited by Gro; 07-02-2019, 04:37 AM. Reason: updated support ticket 761-538-581

  • #2
    Issue 3: Refraction artefacts [Believe was reported to dev - to the best of my knowledge remains unresolved?]

    As mentioned above, here you can see tree planes artefacts at intersection with back wall and with each other along non refractive parts, but not on refracting portions. None of the same artefacts appear to be replicated in regular renders, even orthographic. Perhaps intensity of artefacts perhaps also appears to be slightly based on angle of intersection, result is perhaps somehow that refraction get’s applied to intersecting surface, showing what’s behind?

    Example, (enlarged crop of the rear wall render to texture above); red highlight showing of tree plane intersection with wall, Blue highlight showing intersection with another non refractive part of a tree [you can see further artefacts with wall as well to the right], and then, on the far right, a regular render from orthographic front view that has no apparent artefacts.




    Workaround: None known other than manual fixes and trying to avoid such cases.

    Desired fix: Removal of artefacts from render to texture.





    Issue 4: Poor normal results [Unsure of progress - to the best of my knowledge remains unresolved?]

    Baking to normal map seems to apply geometry normals from baker object in an over-exaggerated? Smoothing can help, but on particularly low resolution geometry there seems to be an issue with the interpolation on how this relationship works?

    Example outputs, v-ray (harsh face edges; bad), scanline (smoother face edges; better), and xnormal (averaged normal):


    Workaround: Process normals using scanline, convert over normal if useful. However, scanline has issues with intersecting geometry and lack of filtering, although best advised to render larger and scale down in that case. Can also export baker and cage to another application to bake if needed. Though issues with normal mapping detail from materials may need resolving with compositing. Can also result in differences if using tracing instead of cage.

    Desired fix: Fix so that v-ray normals can be rendered cleanly with normal detail maps out of max to best fit pipeline and minimise any interventions/manual or duplication of passes/materials into scanline. Options required for how normal maps are interpolated between baker and source objects?





    Issue 5: Render to texture will not render backside. [Unsure of progress - to the best of my knowledge remains unresolved?]

    A standard camera render will render backside of polygon if the vraymtl has ‘Double-sided’ option ticked and/or render>common [tab]>Options [section] Force 2-sided is ticked.
    However, even with both ticked, render to texture renders the object as if it is single sided. In this case 2 of the cushions had their normals flipped and despite rendering from a camera fine and having double sided material and force 2-sided tick, the render to texture process still renders the inside of the pillow (/sofa intersection):



    Workaround: All geometry must be checked for back-facing objects. Inconvenient on quick/test modelling especially involving xforms or mirror duplications on smaller objects/elements.

    Desired fix: Fix so that render to texture can obey either ‘double sided’ material, or ‘force 2 sided’ render option, and/or both, as per regular camera render.



    Simple test scene:

    Please see 'Test_Vray_Issues.zip' attached




    For issues 4 and 5 please follow steps to help reproduce:

    i) Unhide and select the ‘Baker_Shape’ object in 00_Bakers.
    ii) Rendering>Render To texture>render (button)
    iii) A complete map and a bump normal should be rendered out to c:\Work\Out, as well as the frame buffer test_day.000.vrimg.

    All baker settings should already be set in scene:





    Many thanks to anyone looking into this, and again apologies if I have missed anything!
    Attached Files
    Last edited by Gro; 07-02-2019, 04:39 AM.

    Comment


    • #3
      Hello!

      Thank you for the detailed descriptions about all the issues!
      Unfortunately many of these are already logged in our bug tracking system but we haven't fixed them yet. I'm sorry about this. We've been busy with some other urgent issues.
      Issue 2 (Opacity map), Issue 3 (Refraction artifacts), Issue 4 (Normals from low poly) - these all have been already logged but they are still not developed.
      Issue 5 (Backside of double-sided materials baking) - I just logged this issue for you, thank you for reporting it!
      About Issue 1 (Projection baking options) - I also logged a feature request to support them.

      I can only hlep a bit with Issue 1 (Normals gamma).
      What you observe is not really gamma applied in the saved output although the colors appear similar. When rendering Normals the values for the pixels are calculated in a range that is from -1 to +1 to decribe the components of the normal vector. This range is displayed in V-Ray VFB and you can check the values with the Pixel information tool after rendering. When saving the output from VFB or from the separate channels output option this range is shrinked to (0;1). The data in the saved output result image is still valid but it should be handled accordingly in post production. It is transformed in a manner that the negative values are saved as positive in (0;0.5), and all the positive (0;1) are saved in (0.5;1). And so the saved image looks brighter, almost like with sRGB or 2.2 gamma instead of 1.0 . We have a logged open issue about this too.
      There is just one option that enables you to save signed normal vector values and it's by using the V-Ray raw image file output option in the Render Setup >>V-Ray >> Frame buffer. When using the Render to Texure, the baked Normal texture will be saved in its original signed range as a layer in the raw exr output file specified there.

      Unfortunately this is all I can do. I have updated all logged issues and I hope they will be moved up in the To Do list.
      Thank you for the patience!

      Best regards,
      Margarita




      Last edited by Margarita.Stoeva; 08-02-2019, 06:31 AM.
      Margarita Stoeva | chaos.com
      Chaos QA (V-Ray for 3ds Max)

      Comment


      • #4
        Please check if issue 2 is fixed in the upcoming Update 2 for V-Ray Next. Just a note - the scene you sent is very small and there are some artifacts just because of that. Also there is a plane with refractive material - mind that when you are using refraction, the geometry must always have volume.
        If it was that easy, it would have already been done

        Peter Matanov
        Chaos

        Comment

        Working...
        X