OctaneRender® 1.024 beta 2.47 (lin/mac/win) [OBSOLETE]

A forum where development builds are posted for testing by the community.
Forum rules
NOTE: The software in this forum is not %100 reliable, they are development builds and are meant for testing by experienced octane users. If you are a new octane user, we recommend to use the current stable release from the 'Commercial Product News & Releases' forum.
Post Reply
Zay
Licensed Customer
Posts: 1123
Joined: Sun Jan 17, 2010 2:53 am

I'm missing objects when reloading an OBJ file where I have moved objects around. But closing Octane and opening the OSC file seems to fix it. Is this the new way of reloading OBJ files? Or what was the changes to the OSC file system in this beta release?

Nice to finally use the roughness settings correctly from the MTL file :P

PMC seems to work ok for fire flies, although I thought it would clean up images faster than pathtracing in images with no fire flies - meaning less samples with PMC. Or did I miss something?
Win 11 Pro | i5 12600K | 32GB ram | 2x GTX 1080Ti + 3080Ti - studio driver 560.94| Modo/Blender/ZBrush/Daz/Poser
GeoPappas
Licensed Customer
Posts: 429
Joined: Fri Mar 26, 2010 5:31 pm

abstrax wrote:I forgot to exlpain the maxrejects option (don't have the UI in front of me): This slider should usually not be touched. -By lowering it, bias is introduced and the rendering is sped up. Should we remove it or leave it in?
I am always of the opinion that more options are better. You might never use them, but it's good to have just in case.
User avatar
abstrax
OctaneRender Team
Posts: 5509
Joined: Tue May 18, 2010 11:01 am
Location: Auckland, New Zealand

Zay wrote:I'm missing objects when reloading an OBJ file where I have moved objects around. But closing Octane and opening the OSC file seems to fix it. Is this the new way of reloading OBJ files? Or what was the changes to the OSC file system in this beta release?
No that is not ok. Could you please explain in detail, what you have done and what is happening, to let us reproduce the problem? Thanks.
Nice to finally use the roughness settings correctly from the MTL file :P

PMC seems to work ok for fire flies, although I thought it would clean up images faster than pathtracing in images with no fire flies - meaning less samples with PMC. Or did I miss something?
No, that assumption is incorrect. As I described before, path tracing is very good in scenes with lots of direct light and diffuse materials, i.e. scenes that have a very homogenous noise and no "fireflies". It's hard, if not impossible to beat that. Maybe we can speed up path tracing itself, but the path tracing algorithm works here very well.

Of course, as soon as you introduce glossy materials and lots of indirect light, path tracing becomes less good and often impractical. This is where the new kernel shines and improves things dramatically.

Again, try it out in different scenarios. As a rule of thumb: If it clears up fast in path tracing, stick to path tracing. If your scene doesn't clear up well in path tracing, try PMC.

Cheers,
Marcus
In theory there is no difference between theory and practice. In practice there is. - Yogi Berra
User avatar
radiance
Posts: 7633
Joined: Wed Oct 21, 2009 2:33 pm

Mugga wrote:Hey,

first of all big thanks for that pre-release.

I've also tested the new kernel, but not on an firefly scene with much light. The lighting from my testscene is only coming from an hdri.

In my scene, the new kernel is much slower compared to the pathtracing. With PCM i'm getting around 0.54 Ms/sec with my GTX 260, where pathtracing is at 2.00 Ms/sec.

Here the rendertime for 250 samples:
Pathtracing: 00:01:45
PMC: 00:07:46
Directlight: 00:00:42

But as others already encountered the overall system responsiveness is much greater with the new kernel. If the other kernels would achive the same responsiveness is would be awesome. It makes much more fun that way. But maybe this is because of the new cuda version (i also got a second video card installed gtx 430, but i disabled it for octane).

Hi,

Regarding pre-fermi GPUs, eg 8000, 9000 and GTX200 series,
we have not finetuned the kernel to run on these GPUs,
and as a result it can be quite slower than it should be.
(Most of our development machines have GTX4xx fermi class GPUs)

We will finetune the kernel for pre-fermi cards and the next update should provide similar rendering times.

Radiance
Win 7 x64 & ubuntu | 2x GTX480 | Quad 2.66GHz | 8GB
User avatar
radiant
Licensed Customer
Posts: 699
Joined: Mon Apr 05, 2010 12:00 pm
Location: Adelaide, Australia
Contact:

My god the caustics are so much more stronger now :D.
I can see alot of hard work and alot of wizardry level math involved, awesome work guys :)
Im now going to bake a 7k image of three gems.

Question:

Can you explain the controls exploration_strength, direct_light_importance and max rejects
Win8 Pro 64bit ULT|Intel Core i7 3930K|3.20 GHz|32 GB RAM|GTX 590|UD5 2011 socket||2x TB HD||Master Cooler HAF X||Blender 2.6||Maya 2012||Octane|
User avatar
Refracty
Licensed Customer
Posts: 1599
Joined: Wed Dec 01, 2010 6:42 pm
Location: 3D-Visualisierung Köln
Contact:

It might open up a different issue but did you think about integrating a 'adaptive' fire fly reduction. Usually the image is completely blurred out, but if it could 'scan' for bright pixel / shoot outs in an area and blur this area, then this could make the old pathtracing kernel even more effective.
User avatar
Refracty
Licensed Customer
Posts: 1599
Joined: Wed Dec 01, 2010 6:42 pm
Location: 3D-Visualisierung Köln
Contact:

radiant wrote:Question:

Can you explain the controls exploration_strength, direct_light_importance and max rejects
done
http://www.refractivesoftware.com/forum ... 4&start=30
User avatar
matej
Licensed Customer
Posts: 2083
Joined: Fri Jun 25, 2010 7:54 pm
Location: Slovenia

GeoPappas wrote:
abstrax wrote:I forgot to exlpain the maxrejects option (don't have the UI in front of me): This slider should usually not be touched. -By lowering it, bias is introduced and the rendering is sped up. Should we remove it or leave it in?
I am always of the opinion that more options are better. You might never use them, but it's good to have just in case.
I agree with this
SW: Octane 3.05 | Linux Mint 18.1 64bit | Blender 2.78 HW: EVGA GTX 1070 | i5 2500K | 16GB RAM Drivers: 375.26
cgmo.net
User avatar
Jaberwocky
Licensed Customer
Posts: 976
Joined: Tue Sep 07, 2010 3:03 pm

abstrax wrote:I forgot to exlpain the maxrejects option (don't have the UI in front of me): This slider should usually not be touched. By lowering it, bias is introduced and the rendering is sped up. Should we remove it or leave it in?

Cheers,
Marcus

Marcus

There are actually a few sliders in Octane that theoretically should not be touched.IE the default settings are for optimum use.

How about introducing a padlock button next to each of those ones.This would then indicate which sliders are at optimum settings already for the uninitiated.To go outside normal range with them you click the unlock button, maybe also have a reset button as well.

Just a thought.
CPU:-AMD 1055T 6 core, Motherboard:-Gigabyte 990FXA-UD3 AM3+, Gigabyte GTX 460-1GB, RAM:-8GB Kingston hyper X Genesis DDR3 1600Mhz D/Ch, Hard Disk:-500GB samsung F3 , OS:-Win7 64bit
User avatar
steveps3
Licensed Customer
Posts: 1118
Joined: Sat Aug 21, 2010 4:07 pm
Location: England

The new caustics are amazing. This is a very simply scene and the refraction through the diamond is amazing.
Attachments
1500 samples, 22 minutes
1500 samples, 22 minutes
(HW) Intel i7 2600k, 16GB DDR3, MSI 560GTX ti (2GB) x 3
(SW) Octane (1.50) Blender (2.70) (exporter 2.02)
(OS) Windows 7(64)
Post Reply

Return to “Development Build Releases”