OTOY Forums

As time progresses and plugin development marches on it becomes clearer that there are serious fundamental issues with Octane’s core and underlying data structures.

This appears to result in major limitations that seriously impact Octane’s use in a professional setting, and put it at major feature disparity with competing engines.

In the hopes of improving Octane and having these addressed I’ve outlined the major pain points below.

All of these are issues that are not found in other render Engines (redshift, vray, arnold)

1. Handling of instance data

* Use of instance attributes requiring Octane to write data to an image file(????) thus limiting the amount of instances that can have attributes to the amount of pixels in the image 


* Reservation of already limited UV sets for writing of instance data

* Very small number of concurrent instance attributes supported (no other engine has this limitation)


* No nested instancing

2. Shaders/materials

* Hugely limited amount of exposed inputs on shader nodes - every other engine (Arnold, Redshift, Vray) exposes nearly every input on every shader node to be driven by a texture


* No shader level primitive attribute support - this means hacky workarounds to get shader switches working and removes the ability for advanced shader parameter control with User Data


* Gradient interpolation limitations - no other engine has this much restriction on gradient interpolation 


* No additive materials


* No adaptive Vertex displacement


* No proper rest attribute support

3. UVs

* hugely limiting amount of allowed UV sets on a mesh (1-2?) no other engine has this limitation 


4. Lights

* Arbitrary limits on the amount of linked lights


5. ORBX

This is probably the worst implementation of a proxy format out of any modern render engine and the fact it hasn’t been updated much in the 10 years I’ve used octane is astonishing.

* Writes all geometry in scene to a single alembic file (this is insane) creating huge I/O performance bottlenecks that drastically increase with frame count


* Will not use already cached alembics and instead re-writes the whole scene 


* Use of a single Alembic file means we’re not able to take advantage of the many different Alembic features (like transform hierarchies versus deformation for instances) resulting in massive file sizes


* Does not use frame sequences meaning if an export crashes you have to run the entire process again


* No option to export/update selected objects


* No option to export USD instead of alembic

* No time offsetting


* No previews

Other

* No support for multi-step deformation blur

* No alembic render time procedural


All of the aforementioned is so much more important than fancy new features that inevitably release with a bunch of huge caveats that massively limit their use in production. ( no light linking for caustics, analytic lights breaking in certain conditions to name a few)

New tech is cool but at this point Octane is starting to feel more like a rendering research project than a tool for work.

Most of these gripes have been mentioned for years.

Please can we focus on getting the fundamentals right.

I will continue to update this post with corrections and additions if I’ve missed anything - if anyone thinks I’ve missed anything let me know.

I second this entire post.

I +1 the entire section on ORBX. Honestly if I see one more feature announcement without addressing how unfit for purpose ORBX is as a file format I'm going to lose it.

+1 Absolutly right. Octane is amazing in terms of technology and innovations but it lack some core tools and features necessary for professional workflows.
I'll be happy to give more feedback and suggstions for the OTOY team especially for the Houdini plugin.

+ 1 - also would love to see more quality of life updates like a similar implementation of RS proxies and automatic attribute extraction etc.

Houdini users, and there is many, need a working Rest Position workflow. As it is in Beta, it is not a solution at all. It does not work with Bumb or Displacement, which is crucial for our work, and many fellow Houdini users I spoke with over the last days testing the Beta feel exactly the same.
We really want to use Octane for production, but the missing rest position workflow does not allow it in Houdini.
Please please please make this a priority.

Houdini is all about animated meshes with changing topology and point count.
It's the meaning of "organic".
We especially need to have Triplanar working to get good looking, stable procedural shading results - for deforming geometry of all kinds.

It's not a Nice To Have.

Rest Position is a Make Or Break for being able to use Octane in production with Houdini.
I am just writing this, because it might not be clear maybe.
And thanks so much for listening.

Agree 100%. Personally, I could care less about many of these big speculative features that are announced once a year (and seemingly stay in beta/development forever), and I would much rather have smaller incremental changes that are less sexy, but make Octane a more production focused tool.

One thing I've noticed in looking through some of the different Octane forums and the Facebook page, is that people will often ask for fixes or various features, and the devs will answer why any change is not possible because there is some limitation in Octane Core, or some other reason, pointing the finger to someone else. It makes me wonder if there is anyone in charge and actually overseeing the bigger picture for Octane's development.

A real roadmap would be a helpful. The Redshift devs, for example, keep a Trello board which is updated regularly - and I think that works quite well in communicating what they are actively working on in each release.

I love Octane - it looks great, it doesn't have a bunch of fussy settings to deal with, and its speed really makes it a joy to use. But I think it should strive to stay competitve with other production focused renderers.

1. Handling of instance data

* Use of instance attributes requiring Octane to write data to an image file(????) thus limiting the amount of instances that can have attributes to the amount of pixels in the image 


I think you can think of it as a buffer of attributes in GPU memory, it just happens to be stored on disk in image format and represented as an image node in the graph. It has to be loaded to the GPU at some point, it will always look like a buffer of some sort. If it wasn't an image it would still be some sort of array.

With a large enough resolution you can have hundreds of millions of data points, probably more than the engine can handle as instances in the first place so I'm not sure the storage format is really such a problem.

* Reservation of already limited UV sets for writing of instance data

Not sure what you mean, I think this is a DCC specific implementation detail (C4D?). It's not one in core.

* Very small number of concurrent instance attributes supported (no other engine has this limitation)


Not sure what you mean. As you noted they are stored in images, you can have as many as needed and pipe them into a shader network.

* No nested instancing

Nested instancing is supported. I suspect you are talking about a specific plugin implementation.

jobigoud wrote:
I think you can think of it as a buffer of attributes in GPU memory, it just happens to be stored on disk in image format and represented as an image node in the graph. It has to be loaded to the GPU at some point, it will always look like a buffer of some sort. If it wasn't an image it would still be some sort of array.

Ok so how would one read instance attributes in Standalone? The only way is to export the scene via plugin to ORBX. That is not ideal because of all the issues that ORBX brings.
There needs to be a way to read attributes from instances the same way we can read Float and Color Attributes from vertices. Using instances and manipulating data that is stored in instances is how most of us build complex scenes in Houdini. Exporting an alembic with all that data and NOT being able to use it inside Standalone is probably the main reason for not using RNDR.

What frustrates me the most is how awful displacements are handled in this software. It's almost comically bad.

I came over from MODO, and while the shady tree certainly had its issues, the ability to simply stack displacements made it so, so much more powerful for creating randomness and abstraction within a texture (perfect for food, for instance).

In MODO, I can create a texture using multiple displacements, and the final result might be 100k polys. In order to achieve the same level of crispness and detail in Octane, I have to use the vertex displacement mixer, and once I've dialled in the detail by increasing the subdivisions, my mesh has jumped from 100k polys to 3 million. It's just ridiculous. It's not a limitation of technology, it's just awful code.

I don't understand where Octane's hatred of texture displacements comes from, but it's limitations are a constant source of stress and frustration to my workflow.