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.
