pegot wrote:I’m not taking your comments as criticism at all.
Those parts were not directed at you.
pegot wrote:As for gLTF 2.0 support, that has been promised (in Standalone at least) for some time now.
That sounds great. But it's probable that even if it is added to SA it wont be included in OctBlend (at least not immediately), since they're (slightly) different implementations.
pegot wrote:But for Octane Blender to remain competitive I think a big effort should be made (or continue to be made) ensuring as many features as possible work with major Blender Addons.
I'm not disagreeing with you, but I don't think it's easy:
Until (I doubt it will ever happen) there's a unifying standard on how material setups should work and that's adopted by all (major) software's/rendering engines, I don't see many ("good") options to accomplish this (as a programmer):
- Each rendering engine supports the default material/node system of the host application (in this case Cycles): This would be pain in many ways. Firstly it would be confusing for the user (Well, if you stick to one host app it's fine). If you use Octane in Blender it works in one way, you go to C4D and it works in another way, and in the Stand alone it's different again. The manuals and tutorials would be specific to each host application. It would also greatly limit the ability to have unique features in each render engine
- Each (major) add-on supports several render engines. This is an impossible task for the add-on developers (I don't even think there's add-ons that support other "heavily Blender connected" render engines [like Lux]). Now, one could argue that the render engine firms could add those features to the add-ons, or maybe sponsor the devs to do it. But that's hard (and maybe expensive [Octane works in 16 host apps, each with unique add-ons]), and which add-ons "deserves" that treatment!?
- The host apps gets an "intermediate API" which both Add-ons and render engines hook into. Add-ons could then be "render engine agnostic", almost like glTF, but on another "level". This is perhaps the best option, but would require some reworkings of the host apps.
- An add-on that converts one setup to another. This might happen (half-)automatic (like triggered by certain actions) or run by a user (menu/button). This is the "easiest" option, it could be written by the render engine devs, or user contributed, without redefining other, pre-existing, systems. But it does add some steps to the workflow, but hopefully it could be done so it's as smooth as possible.
pegot wrote:No, not for my use case. I am always going to need high quality renders with the more specialized material features that Cycles or Octane supports. But I also need to bring these models into PowerPoint as live 3d objects in a more economical and flexible way than a rendered animation provides.
Your use case is absolutely valid, but it's also one of many. My point about commonly used properties etc was that it's described as an format that supposed to reduce (or even remove [almost "Plug-n-play"]) any extra work to bring material from one software package to another. But (IMHO) it doesn't really live up to that.
pegot wrote:The conversion back and forth between Octane and Cycles PBR Principled shaders is a real drag. The ability to use the same node setups in Cycles and then instantly output that to my gLTF file destined for PowerPoint is priceless. And this is not just a conversion done once. [...] But it is a hassle and quickly leads to the two sets growing further and further out of sync when changes are continually made to one or the other. So for my particular workflow, Octane having the ability to export to gLTF 2.0 would go a long way in solving this.
I completely understand your pain, and I think an exporter Octane -> glTF exporter (in Blender) would be great! As for the ability to use the same node setups, see my previous point.