Hi there. This is part of an ongoing issue with Enscape where they're using an outdated RDK. A way of getting around that is running ExtractRenderMesh that will create a mesh object that includes the displacement. You might have to play around with the Mesh Options to get a smooth result.
Posts by rheinason
-
-
To tell you the truth. we know we have a couple of gaps in our Enscape support for Rhino functionality wise. And so far we have not run a dedicated analysis internally and therefore have not been able to define the development requirements for our Developers yet. Again, this will probably not make you happy but all I can say for now that it's still something we're looking into it and I'm sorry that it's been taking so long. You can be assured that this isn't something we simply have forgotten, but it's not the top of our priorities either, for now.
That is the current state with its details.
Hi, You've had a couple of months, have you looked into it enough yet? No update? I can't understand how this isn't pretty high up on your priorities! This is basic functionality that you simply wont support. Any new functionality gets cheapened by your lack of supporting already built in Rhino functionality. It seems like 95% of all of your rhino issues would go away by switching over. VisualARQ support, Lands Support, Pipe Modifier, Edge Softening Modifiers, all the other geometric modifiers, all of these issues would be resolved.
-
Are you sure this isn't related to this? :
Display MoreHi everyone.
This is Enric Marquès, one of the lead developers of VisualARQ.
VisualARQ seems to have problems with real-time renders, like Enscape, Octane, V-Ray Interactive, and even Rhino Raytraced display mode. AFAIK, there are two issues:
- Wrong materials: VisualARQ objects contains several meshes, with different UV mappings and materials. Rhino SDK allows plug-ins to query the object meshes, with its correct UV texture coordinates applied, but materials for each mesh cannot be queried, so all meshes will be rendered using the object render material. Then, Rhino provides another SDK, called RDK (Render Development Kit), to query not only the meshes (with their UV mapping) but also the materials for each mesh. I guess that some of the real-time renders do not use RDK.
- Wrong texture coordinates: The second reason is that VisualARQ objects are Rhino blocks (with asteroids). If a plug-in sees a VisualARQ object as a simple block, it will just render the objects that are inside the block. As VisualARQ objects share geometry between several instances (for example, two columns with the same profile, will use the same block definition), objects inside the block do not have correct UV texture coordinates. Only the meshes provided but the VisualARQ object (the column) have correct UV mapping. Renders should get meshes for the VisualARQ object using RDK, and if RDK is providing meshes for the block, then do not try to render the block contents.
If you explode all VisualARQ objects before updating the model in Enscape, it should be rendered correctly.
I've already talked to Enscape regarding this issue. They told me there is a bug in Rhino that is the reason of the issues between VisualARQ and Enscape. It seems McNeel will fix this issue in Rhino 7.
We're open to make changes in VisualARQ if those changes will fix the issues between Enscape and VisualARQ.
Regards,
Enric
-
Just wanted to make sure this topic wasn't getting dusty, this is still a vital feature that is missing!
-
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.
-
They don't care about us
Correct! We even got it in writing:
Display Morerheinason , I know that my response is not really satisfying, and so I also just had another talk with our product management team:
To tell you the truth. we know we have a couple of gaps in our Enscape support for Rhino functionality wise. And so far we have not run a dedicated analysis internally and therefore have not been able to define the development requirements for our Developers yet. Again, this will probably not make you happy but all I can say for now that it's still something we're looking into it and I'm sorry that it's been taking so long. You can be assured that this isn't something we simply have forgotten, but it's not the top of our priorities either, for now.
That is the current state with its details.
-
This would be excellent. Especially considering Substance is getting better and better support within Rhino:
-
when it was looked into a while ago it was not really something easy to resolve straight away due to technical reasons
And so it was removed from the to do list?
As for now I'm sure you read what our Developers stated in the corresponding thread about that
The developers have been very silent for well over a year as far as I can tell? see:
rheinason - just to update you, as the developer, even though on leave, answered my request for an update.
He said that McNeal won't fix the issue that we reported until the next major Rhino release. So in this regard we are waiting on McNeal. The developer will follow this up once they are back from leave, and we will then update you again as to the status. Thanks for your patience.
Cause this promise of an update is nowhere to be seen? The VisualARQ team have offered their hand more than once to help.
-
I'll get back to you as soon as I have any further news - our developers will be looking into this! If there is anything else in the meantime let me know of course please.
Have they looked into this? It's been two years. And as far as the cause goes, I bet it has something to do with not using the proper RDK... again.
It's seriously disheartening when all of the issues that I've reported haven't had any progress in two years or more.
-
Demian Gutberlet This one's been marked as resolved too. Has there been any discussion on this?
-
Any news on this? Honestly I don't understand why you're not updating to the correct RDK, Rhino 7 has been out for quite some time. Sometimes it really feels like Rhino users are an afterthought, Enscape doesn't leverage a bunch of features that makes Rhino uniquely well suited for rendering. This topic is over 2 years old. If you're still worried about the live updating feature then implement a listener for events that break the live update and then refresh those objects or all the objects, or just put a warning on screen that the geometry is out of date.
-
Yes or separate maps for Normal/Bump and Displacement, as they deal with different levels of detail.
-
It would be great to have a way to mix different materials within Enscape, like other 3D packages and their mix RGB or similar with just a black and white map. Doing the mixing in photoshop is time consuming and not very artist friendly.
-
When placing assets they require a Base Surface, but sometimes (especially when dealing with terrains) the geometry is mesh based, it would be great if it would be possible to place assets on meshes as well.
-
+1 here as well.
-
Add my vote for this as well.
-
Any news on this? This is still a daily annoyance.
-
I'd love to have the ability to change the focal length as I'm walking a project, changing it in a dialogue is a bit cumbersome.
-
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 NvizeonExternal 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.
-
Display More
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.
