CRITICAL: Enscape cannot read Texture mapping on VisualARQ objects

    Allow me to clear a few things up and my apologies for adding to the confusion with previous replies:


    Right away, we've indeed filed a dedicated bug for the behavior detailed by Nvizeon "Enscape does not recognize the mapping of the material that has WCS box mapping." which we're looking into resolving as quickly as possible.


    Our developers also state, that when it comes to full VisualARQ support though the main problem here is that we'd require working support for UV mapping in that regard, which is a feature that's going to be relatively large and technically challenging to tackle for a variety of reasons.


    In that regard, I can only discuss this once more with product management to see if this is a topic we can/will look into in the near future.


    Again, I am sorry if previous replies from me/us were misleading/confusing but I will keep you posted once I have any updates.


    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.

    Guys,

    this is getting ridiculous.

    How hard can in be to read those bloody UVs from a model (even if it's in a block) and translate it into your own mesh data structure?

    This is not even happening in realtime, but when the scene gets translated up front.

    Enscape basically supports UVs, right? Otherwise there wouldn't be any texture mapping at all. UVs exist since the dawn of 3d rendering.

    So, what exactly is the 'technically challenging' problem of getting those UVs over from one mesh (Rhino's) into the other (Enscape's)?

    Even if there's world space mapping involved - that's nothing more than taking the coords of a mesh vertex, doing some simple modulo calculation.

    2,5 years! What's wrong with you?


    Your top priority should be to make your users happy, all of them. VisualArq is THE ONE AND ONLY decent plugin that retrofits Rhino to standard architectural industry workflows. The outcome of that should be compatible with a renderer with a focus on architecture, right?


    Somebody talk some sense into your product management, please.

    I do understand you frustration with this topic. However, it is unfortunately also not as easy as you imagine.

    Quote

    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.

    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.


    As Tupaia said it is our priority to make all of our users happy. But this also means making tough decisions. Always when we decide for a topic and against another we are very well aware that people will be disappointed. And again I completely understand your frustration that this topic was not tackled until now. But for every release we consider several factors to determine the priority. Amongst others we have to take into account how many users are affected by a feature,what is the actual benefit, how strongly is it requested (and since this is an ongoing topic in the forum. The forum is just one of several sources for user and customer feedback).We also have to take company goals into account as well as the available capacity of our development teams. Especially the latter means that we have to weigh features against each other. For this particular issue we need to support WCS mapping (not UV mapping. This was unfortunately a typo). Our development teams assessed it and came to the conclusion that it's "relatively large and technically challenging". So we have to weight the effort and benefit of this feature with the hundreds of other feature requests we have.

    I could copy this text into almost every feature request thread of this forum because almost everyone perceives their feature request or problem as the most important and wants it to be implemented immediately. Be assured we are aware of all the feature request , especially those that have been open for a long time. Unfortunately, is it not always as easy as it might look from the outside.


    For this particular issue I unfortunately can tell you that we presumably will not implement WCS mapping in 3.4 or 3.5. 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. In fact, WCS mapping for Rhino is on the short list for the beginning of next year. But as shown, the final selection depends on a variety of factors, which is why we can't promise anything at the moment.

    Quote from Tobias Bauer

    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.

    Quote from Tobias Bauer

    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:



    Quote from enric

    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:

    Quote from Simon Weinberger

    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.


    Quote from Tobias Bauer

    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.

    I unfortunately have to repeat myself , it is not always as easy as it might look from the outside.

    Quote from rheinason

    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.

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


    This brings me to the next point that cannot be seen from the outside. And that is dependencies. Almost every feature has some dependencies. Whether it is technical dependencies, dependencies between teams, roadmap items or even between different companies, as in the Space Mouse example you gave. These dependencies can make simple-looking features much more time-consuming and complicated to implement than originally thought. And this is not meant as an excuse but this is again a factor which is considered when planning upcoming releases.

    Quote from rheinason

    Time should be a pretty important factor to consider when doing any sort of prioritization, no?

    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.

    My goal was to give you some insight into the road mapping process and to display why it is not as easy as often times assumed. We know that with every decision some users are happy and others are frustrated. And we appreciate you passionately arguing on the forum why your features should come next. It's just important that it always happens respectfully. And that's why I wanted to share these insights, so that even if someone is frustrated, it's hopefully easier for them to also understand our side of the coin.

    I know understanding still does not fix the problems you have. I can only repeat myself, we are aware of the Rhino issues and they are considered in the release planning.

    Quote from rheinason

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

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

    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.


    Quote from Tobias Bauer

    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.


    Quote from Tobias Bauer

    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.


    Quote from Tobias Bauer

    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.

    Quote from Tobias Bauer

    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.

    Quote from rheinason

    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 didn't mean it in any condescending way. But if I have something formulated badly, so that it came across condescension, then my apologies, that was not my intention.

    Regarding the mapping and API, as I said, this is the solution identified by our developers but I am happy to pass on your suggestions and the link to the MCNeel forum. Thank you for the input.

    Quote from rheinason

    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 agree, it is also a topic that is much discussed.But I was trying to illustrate that the selection process takes place based on a variety of factors and not solely on time and number of requests.

    Quote from rheinason

    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.

    I understand your point of view, but we classified this topic as a feature request. Therefore, this topic unfortunately has to go through the usual selection process.


    But as I said, I am happy to pass on your input and if our developers come to a new assessment, this classification might also change.

    Quote from rheinason

    For the VisualARQ you need to support UV mapping,

    This is very much so! The most annoying shortcoming of Enscape in my book (and not only mine obviously) is: if you apply ANY mapping to a VisualArq object, it will be just ignored by Enscape. Finding workarounds is time consuming, and takes the parametric/automatic approach out of the workflow.

    Exactly this is already working in VRay, by the way. I tested it recently just because of this.


    Having world space mapping too, would be welcome, but if it's difficult, do it later, as long as the 'normal' mapping methods work! Planar, box, cylindrical, ...


    Quote from Tobias Bauer

    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.

    Did you approach the McNeel devs about this?


    Like it or not, we will keep you hammering about this until you really take the initiative and do everything you can on your side to get this fixed!

    Thank you!

    Most of the API shortcomings we had in the past should be resolved. The support of the new API is a topic we have on the radar and ideally want to address in one of the next releases. But currently it is not planned for this year.

    Quote from Tupaia

    Like it or not, we will keep you hammering about this until you really take the initiative and do everything you can on your side to get this fixed!

    As said, we appreciate and consider everybody's input on the forum and also that you 'keep hammering' us with these topics. My intention was just to give you a better insight into why some issues are not being addressed as quickly as you might have hoped.

    jdtotto


    I don't work for Enscape, so don't attack the messenger. Enscape as of 6 days ago has reiterated that they aren't going to fix any issues when it comes to VisualARQ. So to answer your question "Is there still not a solution for this?" No there is no solution, your best bet is to find another rendering software.

    Quote from Tearch

    jdtotto


    I don't work for Enscape, so don't attack the messenger. Enscape as of 6 days ago has reiterated that they aren't going to fix any issues when it comes to VisualARQ. So to answer your question "Is there still not a solution for this?" No there is no solution, your best bet is to find another rendering software.

    Not an attack. Just stating the facts :)