CRITICAL: Enscape cannot read Texture mapping on VisualARQ objects

Whenever you encounter any issues with Enscape or your subscription please reach out to our dedicated support team directly through the Help Center or by using the Feedback button as detailed here.
    • Official Post

    I will forward this problem once more - it seems likely that this is still caused by a problem inside Rhino 7 as well, or through technical reasons, Enscape simply does not support this kind of texture mapping. I'll let you know if I know more soon.

  • Thank you, Demian!

    It is well possible that Rhino itself needs to expose something in the SDK for this to work. With forwarding you mean the Rhino devs, right?

    Looks like there are 3 parties involved in that one - Enscape, Rhino, VisualArq...

    Best regards

    • Official Post

    Thank you, Demian!

    It is well possible that Rhino itself needs to expose something in the SDK for this to work. With forwarding you mean the Rhino devs, right?

    Looks like there are 3 parties involved in that one - Enscape, Rhino, VisualArq...

    Best regards

    Exactly. :) It seems we'll have to get in contact with McNeel and/or VisualArq, and we may have to look into Enscape as well of course to see what the technical hurdles are.

  • I'm pretty sure it's just because you're using an outdated RDK. See this discussion:

    Micha

    we tried to switch to the API introduced in Rhino 6, which is the preferred way if you ask McNeel. With this implementation we get edge softening works, decals and better material IDs without any code from our side. We really want to make the switch ourselves. Unfortunately there are serious shortcomings regarding live updates when editing blocks. You can see the same problems when using Cycles (switch to Cycles, edit blocks, end editing, see how Cycles renderer gets out of sync). In our opinion it's better to have a synchronous rendering, even if this means to miss out on a few other features. You can try it out for yourself and give feedback. How serious are these sync problems in your opinion? McNeel is aware of the bugs in the API, probably it's not as easy to fix as it might seem. I'm not aware of any ETA for the bugfixes.

    This would allow for some major Photorealism points to be added for pretty much free.

  • Quote from Simon Weinberger

    In our opinion it's better to have a synchronous rendering, even if this means to miss out on a few other features.

    I have to say I completely disagree ! Total live sync is nice, but if it stops us from having essential features, than it should be optional.


    Let the user decide if he wants livesync or advanced features and manual updating !


    Andreas

  • Update from Enric:


  • And one more



    Demian Gutberlet  Pete Chamberlain Do you have any info to add to the issue?

    • Official Post

    Thanks a lot. Everything has been forwarded to our developers. We've received a direct message from Enric himself which I'll add as well of course. I'll be getting back to you with further news asap.

  • Enscape team,

    Please. Live sync doesn't matter when it doesn't correctly show textures and objects. It's not missing out on a few other features. It's missing very important features of Rhino. I completely agree with v-cube. Please let us have these important modeling/rendering features. Even if it doesn't show up in realtime view, it's better to have it in the final render and video.

    I was really shocked to read that Rhino users could use all these essential features with Enscape, but Enscape decided not to support that.


    Quote
    44-6e4e7cb5d03c88124c76ad209a4d6e03849dbcea.png Quote from Simon Weinberger In our opinion it's better to have a synchronous rendering, even if this means to miss out on a few other features.

    I have to say I completely disagree ! Total live sync is nice, but if it stops us from having essential features, than it should be optional.

    Let the user decide if he wants livesync or advanced features and manual updating !

  • Just wanted to Add to the discussion that Twinmotion and Lumion both render the VisuaARQ materials correctly when using the Live Sync and export options from the Lumion and Twinmotion Rhino Plugins.


    Vray, Maxwell, and Thea Render all struggle with the WCS Box Mapped textures in Rhino.

  • Hello!

    Please consider this: Rhino ootb is NOT a software specialized on architecture. It's a general purpose 3d program with the focus set on producibility.

    What makes Rhino an architectural solution is the plugin VisualArq. It's the one and only plugin for this (regardless of all glorious things Grasshopper).

    Enscape is a renderer for architects, right?

    So, you might take VisualArq and it's compatibility with Enscape more seriously, since they have the same target group.

    Whatever the problem is, please take the initiative and approach McNeel and/or Asuni to fix this problem that f*s up a otherwise fantastic workflow.

    Thank you!