CRITICAL: Enscape cannot read Texture mapping on VisualARQ objects

  • We will keep nagging you until you fix this.

    Oh yes.

    Enscape team already admitted it was feasible but just not with live sync. Who in the right mind cares about live sync if the actual material, UV, separate material on each surface on one polysurface object, etc, doesn’t work. The final result is much more important. The preview render can be examined with Rhino Render view.


    No need to fix, just bring it back please at least.

  • They don't care about us



    Correct! We even got it in writing:


  • Looks like you went into ignore mode here... that's pretty uncool, especially since the VisualArq and Rhino devs are happy to help with this issue.


    Again: how come that an architectural renderer (Enscape) ignores the most important Rhino plugin for architecture?

  • Looks like you went into ignore mode here... that's pretty uncool, especially since the VisualArq and Rhino devs are happy to help with this issue.


    Again: how come that an architectural renderer (Enscape) ignores the most important Rhino plugin for architecture?

    Agreed! The VisualARQ people have gone above and beyond and still crickets from Enscape. I understand that Rhino is the underdog here, but come on! Your own developers have even outlined the solution.

  • Hi There!

    Joining the forum afresh in the hope to revive this thread.

    Suffering hard for this issue, which completely kills what would be a very nice workflow between rhino, visualarq and enscape. Enscape unusable as such.


    To all other users, have you guys found any solution other than copying all VA objects and exploding them?

  • Hi There!

    Joining the forum afresh in the hope to revive this thread.

    Suffering hard for this issue, which completely kills what would be a very nice workflow between rhino, visualarq and enscape. Enscape unusable as such.


    To all other users, have you guys found any solution other than copying all VA objects and exploding them?

    Extracting, exploding always, while screaming inside.

    You can't even place different texture on difference surface of polysurface. It always has to be extracted, making unnecessarily so many different objects. Enscape really needs to respect what Rhino is, can do, please.

  • Our support team has compiled a detailed list when it comes to the ongoing requests and additional support for some of Rhino's specific functionalities which have been discussed extensively here in this Forum - It's with our developers now, and it will take some further time to review, but you will be the first to know when there is any news I can share.

  • Until this has been fixed by the Enscape development team I have a workaround that seems to work pretty good:


    First follow the WCS mapping option here: How can I apply texture mapping to VisualARQ objects? - VisualARQ

    Make sure you have the texture mapping set to surface on the object.

    Now it the the texture mapping should look ok in the Rhino workspace but still to small (or too big) in Enscape. What I found is to change the material type from for example Custom to Enscape. Now you might have to adjust the size in the Enscape material editor by clicking on the texture under Albedo and adjusting the height and width until it looks ok in both Rhino and Enscape. If you have walls with very different sizes there will be a problem with the texture size due to the surface mapping. In that case make a copy of the material and adjust the texture size in Enscape material editor again, and also make a copy of the wall type and change the material under attributes to the copied material. A bit complicated I know, but until it has been fixed by Enscape I havent found any other way to do it.


    One thing I found though is that some VisualArq objects, for example a certain wall with windows or with a boolean subtraction can have the texture in the wrong direction, this is probably a VisualArq error and I will ask them about it. But for now the easiest way to fix an object that has this error is to use the "extractrendermesh" command to get a mesh copy of the object where the texture can be adjusted the normal way (box mapping and adjust the size of the box).


    Hope this helps some of you.

  • Thanks JonasCarlsson

    You're right that does seem to be able to apply the texture map into enscape. Though I am seeing an issue that adjusting the size of the object, for instance making a wall longer or taller, affects the scale of the textures since it isn't unilaterally applied as a WCS. As multiple objects get adjusted, the textures get more and more off.

    But it seems to be a potentially better solution than 'blockedit' each object and apply a box mapping, which is tedious and undone after every update to the visualarq object.


    Until enscape actually fixes this bug, I'm just basically using the white model most of the time, and vray for textured renders (the CPU render can read WCS without any issues).

  • Hello again! We are still running into that problem.


    Can we talk directly to your developers here? Ask what the status is? In the McNeel forum, this was always possible, like forever.

    I always frown about this attitude that the 'devs' have to be shielded from lowly users by friendly moderators. Here and in other places.

    Thank you!