When using Rhino-VisualARQ workflow,What is your choice of renderer?

The collaboration between Enscape and VisualARQ is unlikely, I used to use Lumion, but the price was too high, and the rendering engine was not as good as expected. Although Vray is an optional method, the rendering speed cannot reach the expected effect.
So I’m here to ask you what renderer you are using,THANKS!

What about Rhino Render?

Hi @Zhen_Zixu,

I’m happy to announce that in VisualARQ 2.13 (not yet released) we have improved the compatibility with Enscape, so texture mapping now works correctly.

FYI: As a workaround, VisualARQ now sets the texture coordinates to objects inside VisualARQ custom objects so renders that do not use the advanced Rhino Render Development Kit API (RDK) will work with VisualARQ objects. The cost of this improvement is that identical VisualARQ objects will no longer share geometry if they have a different texture mapping applied.

We’re still testing VisualARQ 2.13, but we hope to publish it very soon.

Enric

5 Likes

I am exited to hear this, so if it will work with Enscape, I guess than it will also work with Octane, right ?
The current behavior is identical, texture maps on VARQ objects look correct in the viewport, but when rendering Octane / Enscape does not recognize any mapping coordinates and uses the default surface mapping.
Exploding the VARQ objects “solves” the issue but is of course a rather terrible workaround.

I don’t quite understand this in all honesty, can you give us an example?

thanks

Andreas

Thanks!
Not only Enscape, but also many other renderers (Like D5 renderer) will encounter the same problem. I think the next update can solve most of the rendering problems.

Great news! Somebody had to make a move - glad you did!

Hi @walther,

VisualARQ custom objects are based on Rhino blocks. When two (or more) VisualARQ objects are identical, VisualARQ tries to create a single block definition shared between all instances. This helps reduce 3DM file size and runtime memory footprint. Imagine a building with several stories with lots of identical windows: instead of having several poly-surfaces and/or extrusions for each window, a single block is created and shared across all windows.

In VisualARQ 2.13, if a window has a custom mapping specified, it will not share the geometry with other windows. That all. This will make file size bigger, but display performance will not be impacted, as blocks generally don’t help with display speed.

Regards,

Enric

1 Like

Hi @Zhen_Zixu,

Yes, I hope this workaround will fix texture-mapping issues in most renderes. I’ve just installed D5 render, but unfortunately my graphics card is an AMD and is not supported on this render.

Regards,

Enric

2 Likes

So a native Rhino material that uses Box Mapping will be rendered correctly when applied to one of the assembly items in a VisualArq entity like a wall.

In other words I can have a VisualArq wall with a brick exterior and a stone veneer interior and using the visualArq styles editor apply a Rhino Brick material that has used the Rhino texture Mapping Box Mapping and that texture on the VisualArq exterior wall will be displayed and “rendered” correctly.

In general we use Box Mapping on Rhino materials so that “ALL” objects that use that “material” will be textured the same.

What Happens to VisualArq objects is that they display in the viewport correctly but render incorrectly.

NOTE: this also happens to Rhino native blocks Enscape uses raytracing and ALL raytracing rendering engines do not support the Rhino native material box mapping.

I beg to differ:

Object with Box mapping applied, made into a block, instanced twice. Rhino 7 Raytraced and Rhino Render do this correctly with raytracing. (left viewport is Raytraced, right viewport is Rendered, then there is the _Render render window using Rhino Render)

As far as I know, there are raytracing engines in Rhino that support WCS mapping materials, like Rhino Render or V-Ray.

Here is a post in the Enscape forums related to WCS mapping:

Enric

1 Like

I don’t want the “OBJECT” to have box mapping I want the “MATERIAL” to use WCS/OCS (BOX STYLE) mapping.

See these images:

  1. Dropbox - 01.png - Simplify your life

and

  1. Dropbox - 02.png - Simplify your life

So here is the scenario I have an architectural project with walls and planters and pavers etc. I want them ALL to use a brick material that represents ACTUAL brick dimensions. I don’t want to apply box mapping to each separate “object” because the box mapping may be different for different size objects and different orientations etc.

What I want is to make (ONE) single Rhino Material that uses WCS/OCS (Box style) mapping and then WHATEVER object in WHATEVER orientation and WHATEVER shape and WHATEVER orientation and Whatever size and regardless if it is a single surface or a group or a block I want them ALL to use the SAME box Mapping of the ONE material so on EVERY object the mapping is the same and the size of the brick texture is the same.

try rendering this file in a raytracing renderer and see if it works for you.

Well, you may be right but not on VisualARQ objects and that’s the point of this discussion.

Your file shows the same in Raytraced and Rendered mode for WCS/OCS Box style.

This works as expected.

(I am not sure why you include mapping channel mapped materials applied to objects in the same file, though).

1 Like

are you using visualARQ? because the triangle-shaped objects are walls and here is what they look like in Raytraced mode on my computer.

I included the same objects with Map Channel 1 because the mapping was being rendered differently in Enscape between “materials” set to mapping channel 1 and “materials” having WCS/OSC Box Style

This is VRAY:

This is Enscape:

Notice how the scaling of the material on the box-mapped objects does not match the scaling in the viewport.

I do not use VisualARQ, nor any of the rendering solutions. I just opened the file with Rhino 7 and switched to Raytraced.

You may want to at least update your Rhino 7 version, the file you shared was created with 7.17, the most current release is at the moment 7.24.

I don’t know what VisualARQ does to the objects to break the material mappings.

1 Like

my Rhino is updated the file was created maybe a year ago and I’v not “saved” it with my current version of Rhino.

VisualARQ is a BIM solution and essentially creates it’s own “SMART” Rhino blocks (Walls, doors, windows, beams, roofs, etc.

These “Smart” blocks contain parametric smart objects that interact with other smart objects IE: a Window will cut a hole in a wall. Two walls will weld together when close enough to each other, etc.

BUT

these “smart” blocks are controlled by the VisualARQ software and materials on surfaces inside these smart blocks is also controlled by VisualARQ to the point that they behave differently than other native Rhino blocks.

What happens when your version of Rhino (sans VisualARQ) opens a Rhino file with (VisualARQ) objects is that these Smart (BIM) objects get converted back to native Rhino Blocks.

​I believe the texture bug between Enscape and VisualARQ for Rhino has been resolved:

​Enscape Version:3.5.0-preview. 11+95987

VisualARQ Version: 2.12.6.16419 - ( 2022/09/01)

See attached image and video files.


1 Like