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.

    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.

    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.

    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.

    And one more



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

    Update from Enric:


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

    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


    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:


    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

    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?