OctaneRender™ 4 RC 3

[enricocerica]

texture preview not showing up

2018-09-09 18_18_22-_Unsaved project - OctaneRender 4.00 RC3.png

Know problem which will be solved in next release

[wallace]

Hi,

I'm getting quite different Results compared to 3.08.
Roughness on Specular (Waterbottle) and Glossy Shaders (KitchenFronts) behaves differently.
Same Settings on both Renders (AI Light and Denoising turned Off)

Which BRDF model are you using?

If it's possible, can you share the scene with me? I understand the issue with specular material and have already fixed that (fix will be in RC4), but not so sure about the glossy material here as to why there is a difference between the two versions, would help a great deal with a sample scene.

[aufwind]

Hi,

I'm getting quite different Results compared to 3.08.
Roughness on Specular (Waterbottle) and Glossy Shaders (KitchenFronts) behaves differently.
Same Settings on both Renders (AI Light and Denoising turned Off)

Which BRDF model are you using?

If it's possible, can you share the scene with me? I understand the issue with specular material and have already fixed that (fix will be in RC4), but not so sure about the glossy material here as to why there is a difference between the two versions, would help a great deal with a sample scene.

Hi Wallace,

here a stripped down version with basic shapes and materials.

[coilbook]

I just want to say that there is still a problem with overlapping VDBs. In our case one small vdb is inside vdb cloud. The same step length but you can clearly see vbd border of a blue vdb helicopter. Hopefully you can look into it.

[Notiusweb]

I really have to congratulate developers on this release, it is indeed fast!!!

On smaller and simpler scenes, I actually am noticing if I reduce the amount of GPUs, or cut down on the Parallel Samples & Max Tile Samples, I get a faster load/compilation time, which effectively yields a net faster image completion time. (Even though, the potential render speed is slower, the computation to image completion is faster, so net is faster.)

But this is great news and great to work with. If somehow, one day the compilation speed of many GPU could equal that of 1 GPU, that would be phenomenal. But I understand that it likely could not ever exist. But if it gets closer, where data could be loaded to GPU as fast as 1, damn, that will be amazing.

With the 8 GPU I have, it's like a pack of rabid dogs waiting to maul a prey....You can see the GPU itching to get started as you pan the scene around.
So, if you only have 1 GPU/dog, it gets a quicker start on the mauling, but it takes a longer time to eat the whole prey.
Whereas, if you have 8 GPU/rabid dogs darting at the prey all at once, the 8 dogs have to wait a little to get in their initial bites, and they even get in eachother's way, so the mauling start time takes longer...however, once started, and the prey is subdued, they eat the entire prey way faster.

So when an animation has many frames, I play it by scene; more complex, more GPU. Less complex, less GPU (or lower parallel samples/Max tile samples).
This is all made possible by the faster actual rendering speed.
AWESOME!!!

[coilbook]

I really have to congratulate developers on this release, it is indeed fast!!!

On smaller and simpler scenes, I actually am noticing if I reduce the amount of GPUs, or cut down on the Parallel Samples & Max Tile Samples, I get a faster load/compilation time, which effectively yields a net faster image completion time. (Even though, the potential render speed is slower, the computation to image completion is faster, so net is faster.)

But this is great news and great to work with. If somehow, one day the compilation speed of many GPU could equal that of 1 GPU, that would be phenomenal. But I understand that it likely could not ever exist. But if it gets closer, where data could be loaded to GPU as fast as 1, damn, that will be amazing.

With the 8 GPU I have, it's like a pack of rabid dogs waiting to maul a prey....You can see the GPU itching to get started as you pan the scene around.
So, if you only have 1 GPU/dog, it gets a quicker start on the mauling, but it takes a longer time to eat the whole prey.
Whereas, if you have 8 GPU/rabid dogs darting at the prey all at once, the 8 dogs have to wait a little to get in their initial bites, and they even get in eachother's way, so the mauling start time takes longer...however, once started, and the prey is subdued, they eat the entire prey way faster.

So when an animation has many frames, I play it by scene; more complex, more GPU. Less complex, less GPU (or lower parallel samples/Max tile samples).
This is all made possible by the faster actual rendering speed.
AWESOME!!!

We got 10 Gigabit netgear router and I noticed slaves kick in very fast

[Elvissuperstar007]

nvidia 635m not work

[haze]

I just want to say that there is still a problem with overlapping VDBs. In our case one small vdb is inside vdb cloud. The same step length but you can clearly see vbd border of a blue vdb helicopter. Hopefully you can look into it.

Can you send me an orbx with these volumes in that setup please?

[haze]

nvidia 635m not work

Any error messages in the log?

[wallace]

Hi Wallace,

here a stripped down version with basic shapes and materials.

Hi aufwind,

I can confirm that the specular material is fixed, and the fix will be in RC4. However, for the glossy reflections/darkening, it's caused by the use of high coherency ratio, which means you'll need to leave it rendering at high sample count to get rid of those artifacts (it's mentioned in the tooltip of coherency ratio).

Alternatively, lowering the coherency ratio can decrease time of convergence.

Thanks,
Wallace