Posts by rheinason

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.

Quote from Nvizeon

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.

Display More

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.

Quote from Nvizeon

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.

On the flip side. text being visible would absolutely ruin us. We do all annotations within the 3D model, and having to hide those would be possible, but super annoying. I'd like the option of rendering text but please don't make it mandatory.

Quote from Bogdan

It might have to do with layers. I notice that the geometry inside the asset (which is a rhino block) will not be assigned to the current layer.

For example.

Place an asset in a new file in Layer 01. Then switch off that layer. Change current layer to Layer 02 and place that asset again. Nothing will show up because the geometry inside is still in Layer 01 which is off.

To fix this situation you can place an asset in another Rhino file and then copy that asset to your working file.

Pascal Goley from the Rhino Discourse made this wonderful script for that issue. This move all objects within blocks that you have selected into a selected layer.

I just spent the best part of two hours re-referencing a load of image files and getting their settings correct (still not a 100% match on brightness on all the textures, so now the renders don't match 100%). Please please please don't make me do that again! It's such a waste of time. This is such a basic feature, it needs to be addressed ASAP. at least some sort of hacky solution.

Quote from Pete Chamberlain

rheinason - we actually have this as part of a feature request regarding the inclusion of a File Path Editor, and I have up-voted that story on your behalf, as I believe it affects other things like IES files, proxies, etc, too.

Is there any status on this? It's still a major pain!

Demian Gutberlet This thread also got marked as resolved... pretty odd!

Agreed, at least let us work in rhino while adjusting settings!

And one more

Quote from Enric

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

Display More

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

Update from Enric:

Quote 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:

1. 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)
2. 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
3. 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

Display More

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

Quote from Simon Weinberger

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.

Pretty sure this is related once again to Enscape's choice of RDK

Quote from Simon Weinberger

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.

Which is a two year old issue. There's been some movement, like this:

Quote from Enric

Hi 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:

1. 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.
2. 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

Display More

Quote from Pete Chamberlain

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.

And we're past Rhino 7 and there's no real update.

As a workaround you can use ExtractPipedCurve, that should show up in Enscape

You can recreate it yourself, add a picture to a layout and then enter enscape, the photo will be visible in enscape.

And how about this? This is still an issue, I can't even put renders I made in Enscape into a layout without it being a problem.

I don't really know why you keep marking this thread as resolved, I don't think it is. And you've been very quiet for very long. Is there still no news on this?

Any news on this? I'm currently using ExtractRenderMesh, but it's still a pain.

Quote from Pete Chamberlain

rheinason - Not sure, that was not mentioned, but I would assume Rhino 7, but I will have to wait now for the developer to return to know more.

Rhino 7 is here. No updates?

Also especially relevant now since Rhino 7 BETA is out.

Sorry to dig up this old topic. But I just wanted to know if it was planned? Vray does pretty well to include both Edge Softening and Displacement from rhino. Our current "hack" is to extract RenderMeshes and then use those within Enscape, it just doesn't seem very intuitive to do it that way, seeing as Enscape should be able to get the Render Meshes from Rhino directly?

Quote from Tupaia

Hello!
Just wanted to ask if there's any progress here.

Still having the problem that I have to explode the VisualArq objects to get correct UVs. That's the workaround for now, but yeah.

Thanks so much!

Yeah I'd like to know as well. This is a major PITA for us.