OctaneRender™ Standalone 3.08 RC 1

[funk]

There is still some weird issue (values clipping / saturation ?) with environment HDRI with high dynamic range
( https://hdrihaven.com/hdri/?h=flower_road )

Compare-308.jpg

Moreover, the result differs in 3.08 RC1 version

The "halos" around the cube are an issue in the PMC kernel we are currently trying to fix.

Unfortunately, the archive didn't contain the HDR image you are using. Could you send it to me please? Thanks.

Hey Abstrax, you can get it from the link in his post (which you also quoted): https://hdrihaven.com/hdri/?h=flower_road

[abstrax]

Hey Abstrax, you can get it from the link in his post (which you also quoted): https://hdrihaven.com/hdri/?h=flower_road

Sorry, I obviously can't read ... Thanks for the link.

[andw]

The "halos" around the cube are an issue in the PMC kernel we are currently trying to fix.
Unfortunately, the archive didn't contain the HDR image you are using. Could you send it to me please? Thanks.

The link was given already, I think it's not necessary to attach 300Mb file to my message I used the image with maximum resolution, but lesser resolutions presumably will work same way.
Yes, the edges of cube looks weird, but I'm more worried about resulting color of cube surface - it is far away from clear white (as it was in 3.07 and 3.08 TEST 6)

[funk]

I'm just testing out toon lights. The power pin doesnt seem to be doing anything, even though the tooltip states its a multiplier.

EDIT: Actually it seems to work but you cant use the slider. You have to type in very small values like 0.001. Is this intentional behavior?
EDIT 2: Sorry, it looks like you need a toon ramp plugged in to see the affect toon light power on diffuse

Also, is there any way to disable shadows from being cast, like we can with emission?

[Notiusweb]

Yes. We are all on this same page - and have been already heading in this direction.

3.08 is an important first step, due to the introduction of the metalic material and related workflows (sheen was in fact the last properly missing from the checklist of standard PBR inputs, and why we needed it to go out with RC1). Plug-ins like can use 3.08 RC1 material features to support the properties needed to expose such an uber material in the host app (as Ahmet has done for C4D), and we do plan to work on getting this better supported in the core engine in too.

I'm glad to hear this, but I think its a bad idea to rely on each plugin dev to create this per host. Everyone will be repeating the same work, and every implementation will be different.

It also assumes plugin developers actually understand how this all works. This needs to be done in the octane core, not as nodegraphs per plugin

Yes - that's the plan, more details soon.

One thing I would say, Unity is not the sole PBR metallic workflow paradigm out there.

Daz Studio's included renderer, Nvidia Iray, operates on a metallic PBR material process as well, and OCDS developer Faceoff is always working very hard on getting Iray materials transferring overly properly to the Octane plugin. A lot of the channels in this Iray PBR-metallic material workflow, beyond the obvious "Albedo" (which I will always call Diffuse!), are not supported natively by Octane currently (ie. Dual Lobe Specular Weight, Metallic Flakes, Top Coat - like a sheen...)
But more, they are not supported by Unity....so, Unity is not at all the template.
AND you know what is interesting... a lot of the characters going to Unreal and Unity are from Daz Studio. And people have a HELL of a time getting the materials transferring over properly to these applications because of the differing channel names, and the outright lack of the receiving end supporting channels in Unity and Unreal.

I will say that I love the Unity material channel workflow, but, perhaps while the implementation of PBR should be done in the standalone as core, I would say that Otoy, in whole consideration of its plugin to standalone ecosystem, would be well served to confer with the plugin developers to see if there are channels, in the respective applications they are developing the Octane plugin for, that may give them problems if not 'included' in the later "Octane PBR".

[calus]

One thing I would say, Unity is not the sole PBR metallic workflow paradigm out there.

Daz Studio's included renderer, Nvidia Iray, operates on a metallic PBR material process as well, and OCDS developer Faceoff is always working very hard on getting Iray materials transferring overly properly to the Octane plugin. A lot of the channels in this Iray PBR-metallic material workflow, beyond the obvious "Albedo" (which I will always call Diffuse!), are not supported natively by Octane currently (ie. Dual Lobe Specular Weight, Metallic Flakes, Top Coat - like a sheen...)
But more, they are not supported by Unity....so, Unity is not at all the template.
AND you know what is interesting... a lot of the characters going to Unreal and Unity are from Daz Studio. And people have a HELL of a time getting the materials transferring over properly to these applications because of the differing channel names, and the outright lack of the receiving end supporting channels in Unity and Unreal.

I will say that I love the Unity material channel workflow, but, perhaps while the implementation of PBR should be done in the standalone as core, I would say that Otoy, in whole consideration of its plugin to standalone ecosystem, would be well served to confer with the plugin developers to see if there are channels, in the respective applications they are developing the Octane plugin for, that may give them problems if not 'included' in the later "Octane PBR".

Very good point !

I would also add, to not forget about the "surface shader" from Arnold 5, which is defacto the new standart for a UBER material model in VFX/animation:
https://support.solidangle.com/display/ ... rd+Surface

[milanm]

Thanks for the update!

Please have a look at this issue with the way Adaptive Sampling currently works. It's also present in this version. It leads to a huge waste of "rendering" time and also increased cost of rendering animations on ORC.

Original post and example scene file:
viewtopic.php?p=331486#p331486

@Goldorak

Below is a 640 x 360 render of a simple cube that takes ~6 minutes and 36 seconds to render in Octane.

Obviously, an exaggerated example of a bug in adaptive sampling.

Edit: To clarify, there is no contribution to the render after ~0.5 seconds. The problem is that rendering doesn't stop after the noise pass is completely green. For example, in a real world scenario test animation would render in 5-6 hours instead of 30 min. Test animations (clay render, diffuse only etc.) are needed to evaluate motion blur and depth of field and often the camera would move from a frame that needs 20 samples to a frame that needs 50000 samples. So the extreme example below renders ~6 minutes instead of 0.5 seconds.

Regards
Milan

[miko3d]

Regarding PBR ubber shader, and all its variances:

Go for the Disney Principled shader (with added specular transminsion).

Cheers,
Mikel

[Master]

Hello ,


Thanks for your attention
Are you rendering with the standalone version of octane or the plugin in the C4D software?

Thanks again !!
Sorry we're in a rush right now so i can't provide you the scene !

Regarding the support for Titan V: Could you send a screenshot of the Standalone and the device selection window? It sounds as if you are running the wrong version. FYI: I'm currently running Win 7 with GeForce driver 390.77 and the Titan V works as expected.

Regarding the scene that doesn't render: Could you send it to me so I can check what is going on? Thanks a lot.

[abstrax]

Hello ,

Thanks for your attention
Are you rendering with the standalone version of octane or the plugin in the C4D software?

Yes I was testing in the Standalone. Yesterday there wasn't a C4D plugin for 3.08 RC 1 available yet. Please keep in mind that plugins and the Standalone are completely independent, i.e. updating the Standalone to 3.08 RC1 doesn't make your plugin magically compatible with Volta. You would need to install a plugin based on 3.08 RC1.

Thanks again !!
Sorry we're in a rush right now so i can't provide you the scene !

No problem. I will wait until either another scene comes our way or you have time and can send us an example. Thanks anyway.