Posts by Tobias Bauer

    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.

    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.

    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.

    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.

    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.

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

    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.

    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.

    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.

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


    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.

    Hi tarek-t ,

    this feature was already released with Enscape 3.2. When you open the Upload Management in the Enscape toolbar and you hover over an already uploaded panoramas, you can see a 'Replace uploaded panorama in cloud' button. This button triggers the process to replace the current panorama by a new one while the QR code and shared link stay the same.
    However to see this button you need to be logged in to your Enscape Account. For more information have a look at this knowledge base article :…ledgebase/manage_uploads/ . It explains where to log in and what other benefits for managing uploads the account brings.

    Hi Larsonski

    Let me specify Demian's answer a bit. There is no problem in using a floating license with user accounts. The license will NOT be attached to a fixed user, it just defines which user has access to which license. But the license behavior remains the same whether you use user accounts or not. From a license management point of view the user accounts make it easier to distribute your license to your designers. Instead of for example sending around the license key you can simply add the designers to the license or remove them if they don't need to use Enscape anymore. The idea behind this is to get rid of the need to deal with our clunky license id but just add and remove users. Using the accounts won't change the behavior from floating to fixed license !

    What is currently not possible, and I guess this is what Demian meant , is that all the uploads will be in a common place. At the moment we do not have something like 'company uploads'. Every user would have their own individual upload area, where they can manage and share their uploads.

    I hope this makes it a bit more clear.