Posts by rheinason

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.

    Firstly I don't appreciate your condecension, one of us should be a grown up here and I was hoping it wouldn't have to be me but rather the spokesperson olf the very sucessful software package. I don't mean any personal offense to any of you, but your handling of this issue has been incredibly bad.


    I don't know where you got the certainty that we need to implement UV mapping. Maybe you are referring to enric's post. But as said in my post before our developers assessed this topic. Their conclusion is that we need to support WCS mapping. And we rely on the many years of technical expertise of our developers.


    I've got the certainty that you need to support UV mapping because WCS is just another way of mapping textures onto objects. Supporting UV mapping is the way all other render engines solve this issue, just ask your colleagues at V-Ray. WCS mapping, while nice, is a whole other can of worms that would require quite a bit of work, both from your developers and also your users. WCS mapping means that all mapping happens at the Material Level (World Coordinate System) instead of Object based, going solely for this route would be detrimental in multiple ways. One example where WCS would not work is a if you were showing a L shaped floor, the pattern on the floor would not align with one side of the L, this would require cutting the object into two, duplicating the material and changing the WCS mapping of the duplicated material, and now you have two materials that are exactly the same but if you change the properties of one(say you want to adjust the intensity of a bump map) you'll need to adjust the same values on the other material. It could also lead to unsightly stretched textures on elements at an angle, there's also the whole business of furniture which really needs UV level adjustment and custom mapping abilities. Just look at the top renders this week and you'll see that all of them require UV level adjustments.


    Furthermore, there is indeed an Rhino RDK as well as an Rhino API ( that is what Simon was referring to).In fact, they are two somewhat different things. That's why the right terminology is important here. The RDK is not sufficient for the functionality of Enscape. The API had shortcomings in the past as mentioned by Simon which is why we have not implemented the new one so far. But we have the issue on our radar.
    So even if somebody said UV mapping and the RDK are the solution, there is usually more than one solution to a problem.

    API? I don't see how using an API would make sense in this context? I'd recommend reading this thread for the insight the VisualARQ team have provided. And regarding multiple solutions, of course there are always multiple solutions, but when one(the one you're using) is the old legacy solution made so that functionality doesn't break in new versions of Rhino and one recommended by the Rhino Developer Docs, I think the choice is pretty easy. Especially when it would solve most of the issues users are having with Rhino.


    And yes of course, time is also ONE factor for the prioritization. But as said before, being requested for a long time does not automatically make it highest priority. For example, another long open requested feature is a Dark Mode for Enscape. Just because the Dark Mode request is older than other feature requests does not make it higher priority.

    Time is one factor and I gave you another, which is that this has been very heavily debated, and will continue to be debated.

    I really dislike how you're mixing up new features with basic functionality that isn't supported. One is a feature request and the other is, as you call it, a bug. Those also get priority most of the time, why not this one.

    The bug mentions scaling issues for textures. But before the work on the bug wasn't completed, I unfortunately can't tell more.

    This is why I lack confidence in you guys, it's been years and you still haven't even explored the problem.

    For this particular issue we need to support WCS mapping (not UV mapping. This was unfortunately a typo).

    Actually you don't, that's an additional request from Nvizeon(which probably should be it's own topic). For the VisualARQ you need to support UV mapping, for which you'll probably need to adopt the "new" RDK, with this you'd also get features such as geometry based displacement, edge softening, decals and a bunch of other really cool Rhino features. Adopting the newer RDK is by far the best thing you could do for Rhino users.

    You are right, being large and technically challenging is not an excuse to not do it. But on the other hand being an issue for a long time is also not a reason to automatically prioritize it over other requests.

    Time should be a pretty important factor to consider when doing any sort of prioritization, no? You could also compare the activity of this thread to the most "replied" threads in the Sketchup and Revit sections. This thread is pretty similar with the other two sections. So on the spectrum of feature requests on this forum, this has to rank quite highly? I understand that prioritizing features is very difficult, I just can't see how this isn't even on the roadmap yet, and I'm really tired of this handwaving.


    Rhino:

    Sketchup:

    Revit:



    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.


    There's also this Doozy of a reply from years past:

    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.


    But as Demian mentioned we have a dedicated bug we plan to fix for 3.4 in order to achieve some improvements in the meantime.

    Could you go into any detail about what that bug fix will do? Any improvement is of course welcome.


    What does full mean and has there been any support added in the most recent update? I can't find anything that has changed? Your developers have also previously mentioned the benefits of switching to the new RDK, is that the relatively large and technically challenging problem? I'd really recommend you give the V-Ray team a call about their Rhino support. And I think the excuse of being a large and technically challenging problem is not applicable when you've been made aware of a glaring issue 2½ years ago, that's basically a lifetime in software years.

    Umh... It seems to me that the new version has completely broken support for Rhino!


    The issue appears to be that that objects blocks where their material properties are based on layer are completely broken.



    So while the timber flooring is based on a "Per Object" setting the windows and doors have their materials based on a "Per Layer" basis. This is a MASSIVE issue and one that needs a hotfix ASAP.


    Also, VisualARQ texture mapping is still broken.


    Demian Gutberlet  Pete Chamberlain @ANYBODY!

    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.

    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.

    Hi Tearch and Ritz


    Our developers have taken a look at the texture issue.


    It looks like these objects don't have UV coordinates which is why we don't display the attached textures.

    Are you sure this isn't related to this? :

    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:


    rheinason , 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:

    External Content youtu.be
    Content embedded from external sources will not be displayed without your consent.
    Through the activation of external content, you agree that personal data may be transferred to third party platforms. We have provided more information on this in our privacy policy.

    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.

    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.

    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.