OTOY Forums

Hey,

Feature requests litter every every forum outside of General Discussion and it's hard for both users and developers to keep track of them all. It would be great if there were a subforum for Licensed Customers specifically for Feature Requests. By default, every thread would have a poll to allow other users to vote for or against a feature. Each vote would be tied to our user names so that the developers could more accurately gauge demand from the customers (phpBB allows for vote_user_id and vote_user_ip) rather than a small group of users badgering Devs for a feature to be implemented. Duplicate feature requests could be trashed and a customer would be directed to the original thread.

If you look at the RC1 thread, a full third of those posts (including one of my own) are feature requests. The developers would feel less hounded by users and customers would not feel that their requests are getting lost among the other posts if there was a controlled way of putting forth new ideas.

-M

I completely agree.

A feature tracking and bug-tracking system would be really helpful to sort out the mess, but it seems this would make the Octane business look too "opensourcy" (or such was the official position a long time ago)

me too, it's an excellent idea
ciao beppe

+1

def needed
+1

Hi,

unfortunately we can't do a feature poll or public bug tracking system because we don't want to create false expectations. But rest assured, we read every thread and keep track of every requested feature on a priority list. Which ones get implemented, depends on our internal roadmap. Expect to see some highly requested features after the 1.0 release.

If you would like to see a specific feature in Octane, it's best to send an email to [email protected]

Some feature request threads need official acknowledgment (a simple: "yes, it's on the TODO list / no, we don't plan this", will do), to prevent users repeating over and over the same thing, which gets annoying for us to to write and for you to read

yes, it's on the TODO list

Then the user asks every day, when when when...

face

face wrote:

yes, it's on the TODO list

Then the user asks every day, when when when...

face

Face, to a certain extent that already happens. There have been at least a hundred requests, re-requests and re-re-requests for 'Architectural' glass.

The poll voting would haved served two functions:

• 1) Internally, Devs could prioritize the inclusion of some (not all) requests based on demand and feasibility.

• 2) Customers would understand that their usernames have been logged along with their vote and that no further action would be needed.

The forum itself would be heavily moderated to cull both duplicate threads and posts which simply bump a feature request or inquire when a feature will be implemented. A new vote would not bump a thread to the top either.

Any member of the Dev team could also lock a thread with the reason that the request for X feature has been noted but is simply not possible or it's inclusion is so far off in the future as to be unrealistic. New requests for the same feature would be locked with a link to the original post.

RayTracey has already expressed the feelings of the Dev Team though I hope they will reconsider it one day.

One thing we could do is provide a request form without a poll. There you could enter your feature requests and a priority. We could then derive the demand from it, but wouldn't tell you what it is. The main reason, why we don't think it's a good idea to have a public poll is, because there is not only the question of demand, but also the question how complex it is to implement a feature. Highly complex features may sit a long time at the top of the popularity list, because they are hard to implement. This would then suggest that we are not taking these requests seriously.

Take motion blur for example: It's not that you just change 3 lines code and then you are done. No, you have to change the acceleration structure, the acceleration structure traversal, you need animation support in the geometry data, you potentially need animation support in the nodes, you need a file format with animation support, you need animation support in the user interface. That's not a small thing you just hack in over a weekend. Changing the acceleration structure may cause slow-downs even if you are not using motion blur (just have a look at all the crying when beta 3.00 came out and scenes without instances suddenly rendered 10% slower). Changes in the file formats have long range consequences and must be well thought through (otherwise you end up with a mess like the current OBJ/MTL situation). Currently the UI is not designed for animation at all - it's not even designed for handling complex scenes with many objects...

So having a public poll just creates wrong expectations and assumptions and we really want to avoid this. But yes, you are right that it's probably time to get rid of feature requests in the forum by providing some form, where people can enter their requests. You don't know how frustrating it is to see a release thread mutating into a feature request thread after the third post. It's not that we are not reading every post here including the feature requests... And replying to every feature request with a timeline or an explanation why we won't implement it, is not possible for obvious reasons.

You can be sure, that if we think we need more feedback about a particular feature we will ask in the forum. And yes we try to be as close to the customers (you guys and gals ) as possible and it will stay like that. The forum can be very helpful for the development, because it gives nearly instantaneous feedback, but it should be clear that this is not an open source project with an open development. I hope this explains our situation a bit more.

Happy rendering,
Marcus

PS: One more thing: If you want to motivate us and give more weight to your requests, show us some renderings every now and then. There is nothing more motivating than seeing a recently implemented feature actually being used