Any news on this? I'm currently using ExtractRenderMesh, but it's still a pain.
CRITICAL: Enscape cannot read Texture mapping on VisualARQ objects
- rheinason
- Thread is Unresolved
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.
-
-
Running into this issue as well on RHino 7 and VisualArQ trying to render with Enscape.
-
Hello!
Well, Rhino 7.3 is here, and the bug still persists. What can be done?
Thanks!
-
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
-
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:
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:
Let me try to explain why the texture mapping is not working on Enscape or in ExtractRenderMesh command:
VisualARQ objects are Rhino block instances with some added features, like custom representation, etc. So, for each wall, there is a block definition that contains the wall geometry (usually extrusions and/or poly-surfaces). In order to improve performance and reduce memory footprint, similar VisualARQ objects will share the same block definition. That means that we cannot store the texture mapping in the render meshes that lie inside the geometry, as it could be different between instances, so we store this information in the wall itself.
Rhino has different ways to provide meshes to render plugins:
- the standard Rhino SDK (C++/RhinoCommon) that can only access the same render meshes that are shown on viewport by native Rhino objects (not custom objects like VisualARQ)
- a new SDK introduced in Rhino 5: the Render Development Kit or RDK (C++/RhinoCommon) . Using this SDK, plugin like VisualARQ can provide render plugin with different meshes for rendering, with some features not possible without it:
- More detailed meshes than in viewport
- Custom texture mapping
- Per mesh material
- And finally it seems that McNeel introduced a new Render SDK (RhinoCommon), I think it is named Render Engine Integration. This new SDK is specifically for real-time renders like Enscape. And it seems Enscape is using this new SDK. I was in contact with Enscape developers some time ago, and they told me that they were waiting for McNeel to fix a bug in
ChangeQueue
, and they expect to have this bug fixed in Rhino 7.
The ExtractRenderMeshes command is an old Rhino command that is just using the first SDK, so it’s normal that the texture mapping is lost. Also, if you use this command on a VisualARQ door with different materials for the frame and the leaf, my bet is that the extracted meshes will have the same material.
I expected that Enscape worked fine on Rhino 7 with VisualARQ, but it seems it doesn’t work fine yet, so I’ll try to contact them again, and see if we can do something on our end, or we should help McNeel fix something on Rhino.
Regards,
Enric
-
And one more
Hi @walther and @rheinason,
I’ve now tried to debug the issue with Enscape and our objects, and I came to the conclusion that this is an Enscape issue. Enscape is using the plain C++ SDK (for both Rhino 6 and Rhino 7), which doesn’t allow them to get our custom meshes or per-mesh material.
I’m close to fix the issues between VisualARQ and Rhino Raytrace displaymode, which uses the new RDK. But unfortunatelly, Enscape is nou using this SDK.
I’ll try to contact an Enscape developer to see if I can help them in order to fix this issue, or if we can make anything so VisualARQ and Enscape can work fine together. Last time they told me there was a bug in the RDK
ChangeQueue
, but I cannot see any problem. If you can, please, contact them also an ask them to fix this issue.Thanks,
Enric
Demian Gutberlet Pete Chamberlain Do you have any info to add to the issue?
-
I really hope that things will start moving from now on.
-
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.
QuoteI 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.
-
Any news on this? This is still a daily annoyance.
-
Hello!
Just struggling with this annoying bug again. Could you please give it a push at last?
Thank you!
-
yes, any progress?
-
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!
-
Guys, this problem still exist
-
We will keep nagging you until you fix this.