So About OSL...

[jayroth]

As we all know, 3.0x was a long time coming (and stabilizing). I am very happy to have it, and the C4D implementation by aoktar is wonderful overall. Sadly, however, many of the features that we need are often met with the answer, "we'll do that with OSL." I can appreciate that, and I hold the OSL specification in high regard. I think the reason for basing a shader model on this is sound. That said, it has been a very long time now that we have been waiting for OSL to appear. There are many here who need features that are allocated only for OSL solutions. So you can understand our desire to have a timeframe that is legitimate for OSL implementation.

Perhaps Octane is a victim of it's own success. Perhaps efforts are focused elsewhere at present, but those of us with years of investment in Octane (I go back to the initial version offered for 3DS max way back when) and I admit that I will be buying into other solutions coming down the pike for Cinema, specifically Cycles and Redshift. I'm really not too happy about that, but given the pace of Octane development, and along with the missing features and missed deadlines, it would be foolish for me to ignore these other offerings. They are likely to have other issues, of course, and I can imagine that Octane will still be my primary for some time to come, but if these promised features take too long to present themselves, I can imagine that Octane will find itself relegated to a secondary role. I'm not trying to start anything here, and the fact that many of us are likely to add these other products to our arsenals should not come as any surprise at this point, but it is disappointing that this might actually happen.

Hopefully some action will occur that would allow us to rethink getting these other products, though I doubt it at this point. Competitors are nipping at your heels, folks...

[aggiechase37]

I'm in full agreement with this post. I need a render engine that can do everything. Maybe that's selfish, but for those of us without unlimited budgets or spending the money of some bottomless corporate entity, it's a tough pill to swallow to have to cobble together a variety of render engines. Cycles 4d is right now saying they're going to have full X particles support, and that's what I need.

Octane needs to get with the program. Perhaps cycles comes in half baked, or with missing promised features, but my prediction is if cycles delivers the goods, octane's and their unending "we need to have osl to do that" excuse for too many feature requests will have a limited future.

[itsallgoode9]

I'm have the same concern too. I've been a Maya user for 15 years...I have seen firsthand how far a program can lag behind its competitors when devs can always say "yeah, that feature can be done using Mel or Python or OSL" . It's great if you have a dedicated tools programmer but otherwise, you're at the mercy of hoping somebody else in the community happens to care about the issue you have.

[aggiechase37]

So nobody at Otoy wants to respond about this? I'm guessing OSL is just something that we're simply not getting and that's it.

[Goldorak]

OSL is happening in 3.1. We are roughly 75% of the way there. Yes, It's taken us months of additional testing to get OSL stable. Is it worth the wait? Without a doubt.

We did a toon shader test today using the (totally separate) OctaneImager codebase. This was quickly re-written entirely in an OSL node... and it just worked. We could add to LiveDB to share with all users, anyone could. This is powerful stuff which can drive years of new features from one seed we are planting now. Just like the plug-in SDK led to a massive ecosystem of 22 integrations beyond what Octane Standalone could ever do in isolation.

That being said, OSL is a very ambitious feature. That's fine. So was AMD CUDA cross compiler, we cracked that, and so was fast OOC textures in V2 which worked and shipped at the tail end of 2.2.

The stability w/ OSL has to be rock solid and really QA'd heavily, and there are no shortcuts - we are running a live GPU compiler system in the heart of Octane, parsing arbitrary (potentially super powerful) shaders/custom code designed for CPU renderers, while keeping performance identical (or better) with all our current kernels.

Not sure if this answers your question? Perhaps more salient to our 3.x roadmap is that 3.1 features which wrap sooner than OSL, and several look like they might, will go out in 3.0.x releases immediately. This way there is no dependency on OSL to get these updates in users' hands.

[calus]

OSL is happening in 3.1. We are roughly 75% of the way there. Yes, It's taken us months of additional testing to get OSL stable. Is it worth the wait? Without a doubt.

We did a toon shader test today using the (totally separate) OctaneImager codebase. This was quickly re-written entirely in an OSL node... and it just worked. We could add to LiveDB to share with all users, anyone could. This is powerful stuff which can drive years of new features from one seed we are planting now. Just like the plug-in SDK led to a massive ecosystem of 22 integrations beyond what Octane Standalone could ever do in isolation.

That being said, OSL is a very ambitious feature. That's fine. So was AMD CUDA cross compiler, we cracked that, and so was fast OOC textures in V2 which worked and shipped at the tail end of 2.2.

The stability w/ OSL has to be rock solid and really QA'd heavily, and there are no shortcuts - we are running a live GPU compiler system in the heart of Octane, parsing arbitrary (potentially super powerful) shaders/custom code designed for CPU renderers, while keeping performance identical (or better) with all our current kernels.

Not sure if this answers your question? Perhaps more salient to our 3.x roadmap is that 3.1 features which wrap sooner than OSL, and several look like they might, will go out in 3.0.x releases immediately. This way there is no dependency on OSL to get these updates in users' hands.

This is very exciting and I can see why osl/3.1 will open unlimited possibilities for Octane extension on the shading side, joining the team of production renderer supporting programmable shaders.

About exciting future is there some plans about extending Octane on the geometry side, the same way OSL will extend octane on the shading side ? (and supported by DCC plugins)
For the moment Octane is limited to triangle , basic hair and basic sphere primitive.
I think Octane would benefit greatly from procedural render time geometry primitive, something like renderman DSO.
(One immediate benefit would be to overcome the current tedious and RAM hungry hair/fur workflow.)

[Goldorak]

Vector displacement maps, or something along those lines, is something we've been looking into for longer term roadmap.

[calus]

Aff, so nothing about procedural geometry

A typical use would be for example to only provide to Octane "guide" curves data plus parameters for producing millions of fur geometrie at render time,
or for vegetation be able to build L-system geometry on top of minimal data.
I guess it's somewhat already possible in standalone through LUA script, and module API,
but the point would be to to support in DCC application, procedural geometry from third party plugin.

[Goldorak]

Imagine OSL driven vector displacement mapping over current primitives. It would open the door to any kind of procedural geometry you'd want. At least baking to this from OSL at runtime could be a first step.

[calus]

Oh I see, right !

One simple polygon, vector displaced, can replace almost any shape of primitive ....

Ok, this is exciting