OctaneRender™ Standalone 1.14

[RealityFox]

This might sound silly but could you give us a "future" roadmap of what you guys are planning for octane down the road? Like what new features 1.2 might have? And even far into 1.5? Not saying a permanent roadmap but a roadmap subject to change (so people don't feel tricked) this way you can get people to stop asking if you're going to put x, y and z in the next update. And if you guys feel you can't get it done by a certain release version just change the roadmap. I mean a lot of people are asking for features that will probably not be implemented for a few versions so why not give them something to look at while they wait? And people will understand if you need to change the roadmap.

Just suggesting this as Blender does this as well.

[abstrax]

This might sound silly but could you give us a "future" roadmap of what you guys are planning for octane down the road? Like what new features 1.2 might have? And even far into 1.5? Not saying a permanent roadmap but a roadmap subject to change (so people don't feel tricked) this way you can get people to stop asking if you're going to put x, y and z in the next update. And if you guys feel you can't get it done by a certain release version just change the roadmap. I mean a lot of people are asking for features that will probably not be implemented for a few versions so why not give them something to look at while they wait? And people will understand if you need to change the roadmap.

Just suggesting this as Blender does this as well.

No, we are not giving any road maps anymore or make promises about what will be implemented in the future. There are many reason, the three most important ones are:

- This is a commercial project and we don't want to make it too easy for the competition to guess our next steps.
- If we give a road map without a timeline, people will ask when feature A or B will be done. So we would need to give times and everybody who has done software development with R&D knows that it's pretty much impossible to give a reasonable accurate schedule.
- Plans change, features get delayed or we hit a wall and users always take road maps as a matter of fact and a done deal and complain heavily when feature A or B then does not appear.

So, please accept that we are not giving any road maps. We may show a glimpse on some features that we are working on, but we do that usually only, when those features are almost done.

Cheers,
Marcus

[abstrax]

How about displaying only the pin name and making the node name editable in the node graph editor instead?

Since nobody bothered to answered this question. I will ask again: Should we make the node name editable in the node graph editor instead? We could then either not display any node names in the node inspector or only those that are different to the name of the pin they are connected to?

EDIT: Another suggestion from Roeland would be to only show node names (and make them editable), if they are not internal. How about that?

Thanks,
Marcus

[cfrank78]

Since nobody bothered to answered this question. I will ask again: Should we make the node name editable in the node graph editor instead? We could then either not display any node names in the node inspector or only those that are different to the name of the pin they are connected to?

EDIT: Another suggestion from Roeland would be to only show node names (and make them editable), if they are not internal. How about that?

Maybe no one gives the answer, cause it is really uninteressting for most of us. Better implement a better UV mapping and other things that so many users here are begging for YEARS!

UV Mapping is essential for a good workflow and sorry if my words may sound a bit harsh, but it is so frustrating for me to see again and again sutch a great render engine like octane with so many missing BASIC features like ctrl z, basic uv texturing and many more. Who is interrested in sutch node things. Get the basics done please.

If you wanna see how it SHOULD be, please have a look here abstrax: http://www.youtube.com/v/Thg6k0qpJlo

Most render workflow today is using bump maps and normal maps. Render a simple car tire and apply GOODYEAR as a UV Bump Map in Octane. Absolutely horror, compared to, for example, Keyshot.

Octane is in question of algorythms, speed, accuacy, FUN the most promising render engine i found within years, but makes itself sooooooooooooooo cheap because of missing sutch BASIC and so important features. Please, start to focus again on the real important things. Hope the wake up call reaches you coding guys!

Kind regards Chris!

[vinz]

it's kewl that we can edit name directly on panel, the double name display, is really a minor problem to me.
i agree that uvmapping can be greatly improved.

[FrankPooleFloating]

Ouch. That was a little harsh Chris. But I for one understand where you are coming from.
Everyone prolly knows by now that I want/need to be able to make shit invisible to camera -
more than any other single feature. So I guess I am with you - but perhaps in a more gentle
way.

It did not take very long for me to find myself having a lot of time and energy (but not a ton
of money - thanks for that Otoy) invested in Octane. I have changed my pipeline significantly
to work with Octane. But it truly sucks to have to jump through hoops and rely on tricks to
work with Octane in a compositing environment.

I think I said back in February - something to the effect of: "you guys are so f-ing close!!..
don't blow it". I have no doubt you guys have a list somewhere (at least a sticky on a fridge
or something) of these most coveted features we either want big-time or so-very-desperately
need. In my current situation, I can only hope these are coming. I am not even going to make
threats of switching engines... that is not an option, at this point.

Marcus, hopefully you have thick skin. I do not envy your position...

[ROUBAL]

i agree that uvmapping can be greatly improved.

I don't understand where is the problem with UV mapping. If you correctly unwrapped your model in your 3D package, it displays correctly in Octane. I used UV mapping since the beginning in Octane and never noticed any problem.

The only flaw about textures is that procedural textures have their reference in Global space instead of Object. This is a problem for animations, but UV textures are fine.

Could someone explain what is the trouble with UV mapping , please ?

[pixelrush]

Well I gave you feedback. I just don't like the way you have named everything twice everywhere.
Is it not possible to do as I proposed? I can't answer for other people who also didn't like the present arrangement but haven't offered a possible solution.
I don't know why you are being a bit short tempered with us these days.We are still the same enthusiastic community. However people ask for stuff and it just disappears into a to-do void, even simple stuff is never heard of again. You can't blame people for asking about the status of their requests or getting a little frustated. In some cases users are aware of something they asked for hasnt arrived yet because they continually run up against a limitation in their daily work. The net effect is it isn't clear to Otoy customers that you are actually applying yourselves to Octane other than the odd new feature and not doing some other stuff somewhere. People like to make a contribution to development and have a loose expectation that their input matters and something will arrive at some stage. If Otoy don't like interacting with their community we may as well all go home. It wouldn't hurt to keep a list of user requests on the forum and ask users to prioritize the list as they see it. Otoy could then nominate a general time frame for their inclusion like deferred until v2 or possibly in the next test release.
Some of the trouble is that lately Otoy guys have been doing their best to deliver something but when the users see it they don't particularly agree with how it is presented ie the usebility is perceived differently by the user than the coder. I understand this would annoy coders however I think that some of these things could be avoided if you had a small group of users were to check out your general proposal before you get stuck in. Else you employ someone who is into rendering and has UI design skills to assist you. They might also tackle the documentation...
Re the roadmap I think Octane is actually behind their competition in the sense the competition is any other renderer not just gpu based or hybrid. People aren't so much interested in knowing about technology developments as knowing they will have this shader or that composting capability to work with in the near future. Consider this to be a good promotion/advertising strategy as well. If people sight some carrot its good for business and keeps the forums buzzing.
My few cents..

[RealityFox]

This might sound silly but could you give us a "future" roadmap of what you guys are planning for octane down the road? Like what new features 1.2 might have? And even far into 1.5? Not saying a permanent roadmap but a roadmap subject to change (so people don't feel tricked) this way you can get people to stop asking if you're going to put x, y and z in the next update. And if you guys feel you can't get it done by a certain release version just change the roadmap. I mean a lot of people are asking for features that will probably not be implemented for a few versions so why not give them something to look at while they wait? And people will understand if you need to change the roadmap.

Just suggesting this as Blender does this as well.

No, we are not giving any road maps anymore or make promises about what will be implemented in the future. There are many reason, the three most important ones are:

- This is a commercial project and we don't want to make it too easy for the competition to guess our next steps.
- If we give a road map without a timeline, people will ask when feature A or B will be done. So we would need to give times and everybody who has done software development with R&D knows that it's pretty much impossible to give a reasonable accurate schedule.
- Plans change, features get delayed or we hit a wall and users always take road maps as a matter of fact and a done deal and complain heavily when feature A or B then does not appear.

So, please accept that we are not giving any road maps. We may show a glimpse on some features that we are working on, but we do that usually only, when those features are almost done.

Cheers,
Marcus

Understandable understandable. I suppose it explains why Blender does it and most commercial projects do not. Never thought about your competition. Ah welllll, good luck in the future! I demand displacement naow!

[abstrax]

Well I gave you feedback. I just don't like the way you have named everything twice everywhere.
Is it not possible to do as I proposed? I can't answer for other people who also didn't like the present arrangement but haven't offered a possible solution.

Thanks for your input, but your approach is still quite confusing. We have implemented now Roeland idea and it works quite well. I hope you agree when you see it.

I don't know why you are being a bit short tempered with us these days.We are still the same enthusiastic community. However people ask for stuff and it just disappears into a to-do void, even simple stuff is never heard of again. You can't blame people for asking about the status of their requests or getting a little frustated. In some cases users are aware of something they asked for hasnt arrived yet because they continually run up against a limitation in their daily work. The net effect is it isn't clear to Otoy customers that you are actually applying yourselves to Octane other than the odd new feature and not doing some other stuff somewhere. People like to make a contribution to development and have a loose expectation that their input matters and something will arrive at some stage.

User input matters, but in the right place: When we make a new release and people just ask about stuff that is not implemented, then this will be pretty much ignored by us because there is always stuff missing. If people create an appropriate thread and explain why they need feature A or B, give examples whatever, then that is a lot more useful to us than just ranting why feature A or B are not implemented. In a release thread we would like to see positive/negative feedback about the changes, bugs etc. of the release. For example, the UI complaints were related to the release and so we took it seriously and (hopefully) fixed it.

If Otoy don't like interacting with their community we may as well all go home. It wouldn't hurt to keep a list of user requests on the forum and ask users to prioritize the list as they see it. Otoy could then nominate a general time frame for their inclusion like deferred until v2 or possibly in the next test release.

A feature request form is on our to-do list.

Some of the trouble is that lately Otoy guys have been doing their best to deliver something but when the users see it they don't particularly agree with how it is presented ie the usebility is perceived differently by the user than the coder.

Could you give an example?

I understand this would annoy coders however I think that some of these things could be avoided if you had a small group of users were to check out your general proposal before you get stuck in. Else you employ someone who is into rendering and has UI design skills to assist you. They might also tackle the documentation...

We never get annoyed by user feedback about an implementation. The only thing that is frustrating is that people don't accept that there are features that take little development time and features that take much time. Thomas and I have been working on one particular project for almost 6 months and the feature is not released yet, but until things get released it's hidden from you. And then there is maintenance and performance improvement. The performance increase from 1.10. to 1.11 required a lot of work from Roeland. Or getting the SDK working on Mac etc. in the end took almost 3 weeks.

-> If you think that there isn't much going on lately, please rest assured that we are not sleeping. There is actually a lot going on, but as with all bigger software projects, some things take a while until they see the light of day. And believe me, we are as keen to improve Octane as you are and we are very well aware of its current limitations.

Re the roadmap I think Octane is actually behind their competition in the sense the competition is any other renderer not just gpu based or hybrid. People aren't so much interested in knowing about technology developments as knowing they will have this shader or that composting capability to work with in the near future. Consider this to be a good promotion/advertising strategy as well. If people sight some carrot its good for business and keeps the forums buzzing.
My few cents..

Wrong. CPU and GPU renderers may look similar to the outside viewer, but they are not. GPU development is a lot trickier than CPU development. And of course, catching up with CPU renderers that exist already for 10 or more years is hard.