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.
