Posts by Tobias Bauer

REMINDER! If you encounter any issues with Enscape (e.g. crashes, installation problems) or your subscription please reach out to our dedicated support team directly through the Help Center or by using the Support button as detailed HERE! Thank you for your understanding.

    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.

    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.

    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 : https://enscape3d.com/communit…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.

    Nuge let me respond to your two comments in a little more detail

    Joachim


    I am curious about what other sources you use to make these decisions, I would have thought that feedback from your user base is one of the most important as we are the ones using your product in the real world everyday, Small decisions made by your UX team are having major implications to a number of users (Refer to Herbos comments) and this could have been resolved very early in the development process had you involved your user base. Previously you had a trello board which was a great feature but you decided to discontinue that in favour of "upvoting". As i have said many times on this forum as users we have no idea what MIGHT or MIGHT NOT be coming in future releases. Why don't you provide a list of items that have been upvoted with the corresponding number of votes, I am sure that most users would have expected more from a major release (3.0) than a UI update

    I agree with you 100 percent that the feedback from our user base is one of the most important. And trust me, it IS the most important feedback to us, this is why we appreciate all of your feedback and also love talking to you in the forum. But unfortunately, only a fraction of our users is registered in this forum. Therefore, we also reach out to our Resellers and talk to customers directly as well as to long-time partners. We collect all these opinions and take them into account when deciding on what is coming next or how a feature will look like. And if the feedback is clearly that we need to change something, then we do it. Last year, for example, we wanted to put Single Image Rendering and Batch Rendering on one button, with a corresponding dialog. Since the feedback from all sides was clearly negative, we have reversed this as quickly as possible. But as Joachim said, so far we received mixed feedback. We need to have more feedback from more users to make further decisions on a solid basement. Since not all our users are using the preview versions, we will wait after 3.0 is released to get more feedback. But again, this topic IS on our table and we are observing it. But we did not decide to change the current behavior, yet.


    Your question why we don't provide a list with the items that have been upvoted also brings me to your other comment


    Tobias


    Sorry but i take exception to your comment "In addition, we keep a mix between planning ahead and still being able to react to urgent circumstances at relatively short notice". I have been using Enscape for many years and i am yet to encounter any feature that has been reacted to "at relatively short notice". you just have to look at this forum to see how long user have been requesting batch rendering for Panos. if your team had to render 20-30 panos for a project i am sure it would have made it into enscape quite some time ago.


    All of the "feature requests" your users make are based on real world problems/bottlenecks that exist in our businesses everyday, some more problematic that others, as a product manager you should be acutely aware of these issues and be advocating strongly to your developers on our behalf. Let avoid another release cycle where the only change is an updated UI when so much more could have been done to enhance enscape as a usable product.

    I also agree with you that all of the feature request the users make are based on real world problems. But again, the forum represents only a fraction of our users. And even within the forum we receive a lot of different feature request. So, with all the different sources we have, we have several hundreds of feature requests that we consider useful and represent a valid real world problem. And believe me, we are aware of all the issues and also how strong the demand for these features is. But of course, not all users have the same real world problems in their daily work. For example, in the last couple of weeks, I talked to several customers myself. No one, and I am not understating, has mentioned Batch Pano when asked what features should come next. And this is why "reacting to urgent circumstances" does not necessarily mean directly reacting to request in the forum and why we are also not providing a list with upvoted request. Upvotes are a very important factor, that is why we collect them and we take them into account when making decisions, but they are not the only factor when we decide on what is coming next.


    I completely understand that this is very frustrating for the people which have these problems and are waiting for the feature. I assure you, we know that Batch Pano is a feature that have been request since a long time and we are discussing whether we will bring it this year or not. But since there is no decision yet, I can't promise it.

    Tearch  Nuge I completely understand your wish to get more precise feedback on the feature requests and we will definitely try to improve it in the future but unfortunately it is not always easy. As you can imagine, we get a lot of feature requests via different channels not only the forum. And be assured , we collect and document all of them and of course we also note how strong the demand is for individual features. So if we say "Thanks for the upvote" or " It is heard" be assured we document it and are aware of every request.

    For our planning which features will come next, we carefully evaluate all requests. In addition, we keep a mix between planning ahead and still being able to react to urgent circumstances at relatively short notice. For this reason, we can not always say with certainty when exactly a specific feature will come. And that's the reason why we don't make any promises until the features are finally scheduled.


    Regarding the Batch Pano , at the moment I can only tell you it definitely won't come in Enscape 3.1


    I know, this is not the most satisfying answer but I hope it helps you to understand it a little bit and as said we'll try to improve it in the future.


    Thank you very much for all the great feedback !