2.01 marginally faster than 2.00, but 1.54 faster still and resolves better.
octane render 2.01 40.62ms noticeably more fireflies
octane render 2.00 38.58ms still unresolved fireflies
octane render 1.54 45.27ms and much cleaner
OctaneRender™ for LightWave™ 2.0 - build 2.0.10
Moderator: juanjgon
I thought you were talking of a speed drop from 2.00 to 2.01.MrFurious wrote:2.01 marginally faster than 2.00, but 1.54 faster still and resolves better.
octane render 2.01 40.62ms noticeably more fireflies octane render 2.00 38.58ms still unresolved fireflies octane render 1.54 45.27ms and much cleaner
Yes, Octane got slower from 1.5 to 2.0. We added a whole lot of new render features which all affected render speed, even if the features are not used. It has been discussed a lot on the forums the last weeks. We are still working through a list of ideas, but there is only so much we can do here, so I can't make any promises that we can improve performance further in the near term.
The trench scene is affected more than most scenes, which is because it's dominated by ray-tracing (it has only one trivial material). Here on my 690 I see even a drop of 18% in path tracing, but in most scenes "only" 5-10%, in some cases 2.01 has the same speed as 1.5.
I'm worried about the noise though: Doesn't look right and we will have a look at it.
EDIT: Some parts are also rendered differently. Only direct lighting seems to be affected.
In theory there is no difference between theory and practice. In practice there is. - Yogi Berra
Thanks for pointing out the noise. There is a bug in direct lighting that creates that huge amount of noise. It will be fixed with the next release.MrFurious wrote:2.01 marginally faster than 2.00, but 1.54 faster still and resolves better.
octane render 2.01 40.62ms noticeably more fireflies octane render 2.00 38.58ms still unresolved fireflies octane render 1.54 45.27ms and much cleaner
In theory there is no difference between theory and practice. In practice there is. - Yogi Berra
Thanks Abstrax. Considering all the new goodies 2.0 brings us a 'minor' performance hit is excusable. Will be glad to see less noise though especially since I almost always use the Direct Lighting Kernel.
Cheers,
Dino.
Cheers,
Dino.
Dino Inglese
CG Artist
Melbourne Australia
Intel Core i7-4820K, 3x GTX 980ti
Windows 7 64bit, Modo 12.2v2 for PC
Octane build 4.04.0.145
CG Artist
Melbourne Australia
Intel Core i7-4820K, 3x GTX 980ti
Windows 7 64bit, Modo 12.2v2 for PC
Octane build 4.04.0.145
Only noticing this now playing around with the LW plugin.. indeed tons of noise with 'Diffuse': very simple scene, a single arch model and a single light using DL diffuse. Background noise taking ages to resolve. May need to switch back to 1.54 until this is addressed.
Dino Inglese
CG Artist
Melbourne Australia
Intel Core i7-4820K, 3x GTX 980ti
Windows 7 64bit, Modo 12.2v2 for PC
Octane build 4.04.0.145
CG Artist
Melbourne Australia
Intel Core i7-4820K, 3x GTX 980ti
Windows 7 64bit, Modo 12.2v2 for PC
Octane build 4.04.0.145
Good to know - thanks
about fireflies, it remains the problem, specialy visbible on glossy/specular surfaces with roughness values close to 0 ( but not =0, where it disappear ). It is not specific to octane but for all GPU renderes ( cycles, thea, which seems to be better for this but not perfect, as far as i've tested ).
It is a very ennoying problem - specialy with animation of glossy surfaces, because render time have to be huge to 'smooth' them ( and the integrated highlight-filters are not the ideal solotion, as it changes a lot the final look of the rendered picture ) and this make loose one of the biggest advantage of GPU renderer: speed.
I'm surprised that no real solution has been found for now around this, it would be a major step...
about fireflies, it remains the problem, specialy visbible on glossy/specular surfaces with roughness values close to 0 ( but not =0, where it disappear ). It is not specific to octane but for all GPU renderes ( cycles, thea, which seems to be better for this but not perfect, as far as i've tested ).
It is a very ennoying problem - specialy with animation of glossy surfaces, because render time have to be huge to 'smooth' them ( and the integrated highlight-filters are not the ideal solotion, as it changes a lot the final look of the rendered picture ) and this make loose one of the biggest advantage of GPU renderer: speed.
I'm surprised that no real solution has been found for now around this, it would be a major step...
Try increasing caustic blur.vipvip wrote:Good to know - thanks
about fireflies, it remains the problem, specialy visbible on glossy/specular surfaces with roughness values close to 0 ( but not =0, where it disappear ). It is not specific to octane but for all GPU renderes ( cycles, thea, which seems to be better for this but not perfect, as far as i've tested ).
It is a very ennoying problem - specialy with animation of glossy surfaces, because render time have to be huge to 'smooth' them ( and the integrated highlight-filters are not the ideal solotion, as it changes a lot the final look of the rendered picture ) and this make loose one of the biggest advantage of GPU renderer: speed.
I'm surprised that no real solution has been found for now around this, it would be a major step...
In theory there is no difference between theory and practice. In practice there is. - Yogi Berra
- BorisGoreta
- Posts: 1413
- Joined: Fri Dec 07, 2012 6:45 pm
- Contact:
Thanks for the daily build Juanjo.
I look forward to instance surface picking
I look forward to instance surface picking

19 x NVIDIA GTX http://www.borisgoreta.com
The latest daily build does not run on Win XP64.
.......entry point GetTickCount64 could not ......
2.01 standalone runs fine however.
.......entry point GetTickCount64 could not ......
2.01 standalone runs fine however.