OctaneRender™ 2019.1 XB1

[Notiusweb]

2 - gLTF

+ 1 for gLTF 2.0 support. We have been waiting a loooooong time for this. Now that we have Universal materiel how about at least a gLTF 2.0 export feature - maybe where procedural materials, if used, are automatically baked into standard metal roughness work flow output? This would be realy useful BTW for the Blender plugin, which already has a very good gLTF export feature. But I always have to convert my Octane nodes to Cycles Principled BSDF nodes first.

I am enthusiastic abou glTF. I’ve been studying it for two years. But glTF work flow is the domain of the DCC program. If a person is building glTF they don’t use Octane materials, nor any third party renderer. They use native file formats and tune material channels appropriately. You use what is supported for native export, and that only!

Wait, if a glTF scene is exported native out of Octane then it will be using Octane materials, right?

[FrankPooleFloating]

Not sure what he is referring to. All I know is that exporting from Painter as glTF2 and importing into Blender is perfect (for Cycles at least).. no need to change a thing! It is just ready to go right out of the gate with Principled BSDF metal rough that is damn close to Octane Universal node setup, from what I could tell. I just wish Octane had an option to convert Principled BSDF on the fly into Octane Universal, or better yet, able to use and render PrBSDF. Alas, I have all but given up begging and pleading for glTF support from Otoy. I think it has been well over a year now, and it doesn't seem to be any more of a priority now for Marcus and Jules then it was back then...

[coilbook]

We do need dirt like on the picture from a previous post. Please add it.

[pegot]

I am enthusiastic abou glTF. I’ve been studying it for two years. But glTF work flow is the domain of the DCC program. If a person is building glTF they don’t use Octane materials, nor any third party renderer. They use native file formats and tune material channels appropriately. You use what is supported for native export, and that only!

I’d have to disagree with you. While I have a Substance subscription, there are different work flows where other tools can simply be more convenient, and the strict “true material channel” orthodoxy you speak of may not be necessary (not sure exactly what you mean here by the way – while Substance has tools to ensure materials are within PBR standards, the export process to compiled textures for gLTF would be the same whether one was using Substance Painter or Octane). Why go through the additional step of another application and export process when you might just have an object that uses a few internal procedural textures?

Even if I exclusively used Substance Painter for texturing my animated gLTF files, I’d still have to convert material node setups between Octane Universal and Blender Principled BSDF. So any procedural textures in Octane I used are going to have to be baked anyway and piped into Cycles and then output to gLTF. How wonderful if I could just do that all directly from Octane!

[Notiusweb]

I am enthusiastic abou glTF. I’ve been studying it for two years. But glTF work flow is the domain of the DCC program. If a person is building glTF they don’t use Octane materials, nor any third party renderer. They use native file formats and tune material channels appropriately. You use what is supported for native export, and that only!

I’d have to disagree with you. While I have a Substance subscription, there are different work flows where other tools can simply be more convenient, and the strict “true material channel” orthodoxy you speak of may not be necessary (not sure exactly what you mean here by the way – while Substance has tools to ensure materials are within PBR standards, the export process to compiled textures for gLTF would be the same whether one was using Substance Painter or Octane). Why go through the additional step of another application and export process when you might just have an object that uses a few internal procedural textures?

Even if I exclusively used Substance Painter for texturing my animated gLTF files, I’d still have to convert material node setups between Octane Universal and Blender Principled BSDF. So any procedural textures in Octane I used are going to have to be baked anyway and piped into Cycles and then output to gLTF. How wonderful if I could just do that all directly from Octane!

Between the primitives, LUA, Material Library, Vectron, and Spectron, you could probably natively create a whole entire scene in Octane outright, even with animation, without ever using another application.

[Iceman9]

I am enthusiastic abou glTF. I’ve been studying it for two years. But glTF work flow is the domain of the DCC program. If a person is building glTF they don’t use Octane materials, nor any third party renderer. They use native file formats and tune material channels appropriately. You use what is supported for native export, and that only!

I’d have to disagree with you. While I have a Substance subscription, there are different work flows where other tools can simply be more convenient, and the strict “true material channel” orthodoxy you speak of may not be necessary (not sure exactly what you mean here by the way – while Substance has tools to ensure materials are within PBR standards, the export process to compiled textures for gLTF would be the same whether one was using Substance Painter or Octane). Why go through the additional step of another application and export process when you might just have an object that uses a few internal procedural textures?

Even if I exclusively used Substance Painter for texturing my animated gLTF files, I’d still have to convert material node setups between Octane Universal and Blender Principled BSDF. So any procedural textures in Octane I used are going to have to be baked anyway and piped into Cycles and then output to gLTF. How wonderful if I could just do that all directly from Octane!

Between the primitives, LUA, Material Library, Vectron, and Spectron, you could probably natively create a whole entire scene in Octane outright, even with animation, without ever using another application.

No.

Vectron and Spectron aren't going to show up or work in glTF...V & S don't even employ standard polygon meshes at all...nor can you bake them into real geo, as I understand. If you could bake them they'd be too massive to be useful and would lose their dynamic nature. Same with the other new OSL Octane primitives--they aren't geo meshes. They are volumetric.

You don't seem to appreciate the Khronos spec, nor what glTF is designed to do. I don't think the Khronos spec supports VDB's nor even *true* displacement in materials.

And look....Octane is building a rendering solution for 3d apps and games... not their own DCC. It would be a horrible mistake for Otoy to try to make Octane Standalone a content creation tool. From a technical standpoint and from a strategic/business perspective that makes no sense.

glTF is designed for light-weight, quick-load 3d objects that work in the browser, in MS Office docs, VR...and hopefully soon just about any context where a .jpg would work. glTF is not the place for quixotic high-compute technology.

[Goldorak]

I forgot to include every possible slide/feature in the 2019 video, but anime kernel is coming, it wasn’t intentially left out.

We are also on the gltf working group, and helping them with PBR next. Also we have been working on a gltf 2 node exporter that accounts for our heaviest scenes and all types of octane scatter:

[Goldorak]

Also directional dirt is in development, but we plan to make it 1) optimized for RTX and 2) controllable with OSL and 3) fast. Same thing with curvature maps. Don’t know what exact release these will be in, so we didn’t make a slide for them at GTC.

[Notiusweb]

Anime Kernel! Yes!
Anime Kernel is the best feature of 2019, as voted by me and myself. And I agree with them.

Iceman touches on a very interesting point, because Otoy outdoes its competitor base with something no other rendering tools take any initiative to do-
Otoy expands the user's creativity toolset in truly innovative ways, its own app.

I think if Octane Render had some of its own 'fake' GI, like realtime PBR engines have (glow channel, fake emitters, fake-AO, glares, bokehs, fake-rays, fake lighting by billboards), it would enhance its rendering power.
I wouldn't say it needs it per say, but it wouldn't be noticed by the average consumer that a glow wasn't truly spectrally accurate if it is put on top of other real accurate lighting elements.
As it is, Octane works really to hard to maintain accurate lighting, and then we smack Post Processing and Color correction on top of it, to make the consumer like it more.
So why not open up the whole zany world of fake GI effects!!!

[Iceman9]

Notius, I enjoy your posts and your out-of-the-box thinking but we diverge a bit in how we view this thing will grow and in practical next steps...both for Otoy and for Khronos Groupls glTF.

GlTF will have two flavors:
-The simpler, lighter more ubiquitous vanilla version that all parties agree to
-The variants where companies add their special sauce “on top”of consortium-approved glTF...that will be context-constrained

The vanilla glTF will just work...soon in any browser and in tons of apps. Then there will be apps, games or experiences that build on top of glTF and require extra downloads or only work contingent upon the presence of other code.

My comments above are in reference to the simpler, universal glTF.

As for Otoy...It’s my conviction that Otoy will need to guard against feature-creep. They have plenty of work to get stable bug-free operability in their current suite...esp. with Unity and UnReal...and esp. with the advent of RTX. And features like Anime are far more important and useful than Vectron in a browser.