textureMapping inVisualArQ wrong in Enscape render

  • Hey ehn.sa , we have an existing active thread about this behavior here:

    CRITICAL: Enscape cannot read Texture mapping on VisualARQ objects


    It's still an ongoing discussion in the development team - I'll reply in the thread linked above in case I have any more news soon.

  • We are having the same issue. It's related to WCS Box Mapping but also the way VisualARQ does texture mapping. One wall that Intersects another wall will create multiple UV mapping which is NOT AT ALL good.

    It's only related to WCS Box Mapping if the materials you're using have box mapping. And it's not related to the way VisualARQ does texture mapping, but rather that Enscape are using the wrong RDK.

  • It's only related to WCS Box Mapping if the materials you're using have box mapping. And it's not related to the way VisualARQ does texture mapping, but rather that Enscape are using the wrong RDK.

    If you take enscape out of the equation there are still issues with the way VisualARQ objects are texture mapped. Particularly when two walls intersect. With Mapping Channel 1 the orientation and the size of the texture changes on each side to the wall at the intersection. With Box Mapping this is not the case.


    As you can see in the attached images Before the file is rendered in Enscape the texture mapping glitch is present.


    Box Mapping is effectively hiding or compensating for the way the VisualARQ objects are mapped. You can see in the Enscape rendering that the box mapped textures get super enlarged...but it also reveals that even on the box-mapped VisualARQ walls the wall that is intersected has two different orientations of the material in Enscape.


    So as I see it VisualARQ is not mapping textures properly on walls as they intersect each other


    AND


    Enscape is not reading the box mapped textures correctly.


    Both of these are true and both contribute to undesired results.


    I've attached the Rhino FIle for anyone who wants to verify the issue I am seeing.

  • I see what you mean, but if you apply a box texture map onto those VisualARQ objects it renders correctly within Rhino:


    I can also see how Raytraced does not work on either of the models, so there is some issue within VisualARQ as well.

  • VisualARQ only accepts one mapping value per object, so I just applied a box map to the wall objects themselves. Definitely agree about WCS Box Mapping! It would save many a nightmare. It would also allow us to use different mapping for the various objects, as you mention, that's not possible and requires you to adjust the UV repeat within the material settings.


    Quote from Nvizeon

    External Programs like Lumion render VisualARQ objects correctly I suspect because the transfer process makes extracted render meshes of the visualARQ elements.

    As far as I've understood from the VisualARQ guys it's because Lumion and others use the updated API. The one that the Enscape team chose not to use because it wasn't as live editable.

  • VisualARQ only accepts one mapping value per object, so I just applied a box map to the wall objects themselves. Definitely agree about WCS Box Mapping! It would save many a nightmare. It would also allow us to use different mapping for the various objects, as you mention, that's not possible and requires you to adjust the UV repeat within the material settings.


    As far as I've understood from the VisualARQ guys it's because Lumion and others use the updated API. The one that the Enscape team chose not to use because it wasn't as live editable.

    I rebuked Enscape team's decision before on this matter, and I will do it again. Please let us have this useful and necessary features of Rhino. We users rather have it in the final version even if it doesn't show up in live view.

  • I rebuked Enscape team's decision before on this matter, and I will do it again. Please let us have this useful and necessary features of Rhino. We users rather have it in the final version even if it doesn't show up in live view.

    Enscape team, could you please elaborate on that problem again? So, it's either the live preview is correctly mapped, or the final rendering?

    That's a super annoying contradiction, because of course both need to work.

    I for my part practically always need the final renderings to be correct.

    Thanks!