OTOY Forums

abstrax wrote: ...for PT and DL it should be fairly straight forward...

So the fastest kernels get even faster... Awesome! is it realistic for 3.x resources based on your current best guess? Or are we talking v4?

abstrax wrote:

Seekerfinder wrote:So logical. I'm surprised Octane has not implemented it yet. Probably not easy to do.

Until v3 it would have been very hard to implement since the film buffers were distributed over the devices and master/slaves and the sample rate is calculated from the noise of the main pass. Now that we have the film buffer on the master it should be fairly straight forward to implement for path tracing and direct lighting and it's on our to-do list. For the info channel kernel it won't be useful and I'm not sure if we can make it work for PMC, but for PT and DL it should be fairly straight forward.

The adaptive sampling mentioned in the GTC talk is something different and affects the light sampling.

That is exactly what these new kids on the block are saying: "Adaptive sampling is used in every render part such as light sampling, material shading and image sampling in general." (from http://www.fstormrender.com/features)

Whatever the jargon, they seem to have a method that prioritizes render power to where it's needed, particularly related to light sampling.

Just did an interior scene this week with some spots in PT when I was reminded of the massive slow-down effect of smaller light sources with respect to noise levels. After one hour of rendering on a 3-Titan X machine the images was still very noisy after an hour at HD. It's really the weakest point of most physical GPU renderers vs either physical CPU or a biased system. Focus / feature / spot lighting is so critical to composition. I know you're always working on these things but it would be great if this issue could be improved significantly in Octane.

Seekerfinder wrote: Whatever the jargon, they seem to have a method that prioritizes render power to where it's needed, particularly related to light sampling.

Note that "they" are just one person. FStorm is being developed by one single person, and he claims he started with it in May 2015 so not even a year ago. So basically, by the time we've walked around waiting for Octane 3.0, this guy have developed a whole new renderer that renders both as good and as fast as Octane (and in some cases faster).

Concidering the short development time, it already has some really basic features that Octane for 3Ds Max lacks, like a material converter that actually works, physical camera values (aperture size etc), a descent working dirt node with radius texture input, falloff with curves, adaptive sampling, etc. And I guess Otoy will let us wait a while longer for any of those, especially since the 3Ds Max plugin seems be the least prioritized developent of all within Otoy.

FStorm is not a production ready renderer yet and has a long way to go. But I've tested it and confirmed that it can render just as good as Octane, and faster, but the downsides is that its live rendering is not as responsive as Octane's yet, lacks SSS at the moment and a few other things.

I really love Octane, it's the only renderer I use, but I am always looking into alternatives. Even if Otoy are working hard with new stuff, the are not communicating their progress. My feeling is that they run their own agenda and are focusing on lots of complex things before even the most basic requirements of a renderer is taken care of. Time will tell with Octane 3, but I really hope they will prove me wrong.

Because all Octane code comes from Abstrax he has to rebuild his software from scratch to achieve Fstorm performance.
Otoy says to Abstrax to stop his development because Lightfield technology is more important.
Octane kernels are now obsolete.
Let's try to build a night scene with 100 ies lights using the path tracing kernel...

JohannesL wrote: Note that "they" are just one person.

Even more impressive then. I also love Octane. But sometimes it feels like they try and overtake the world with their great vision (which I love btw) instead doing things like create a properly 'curated' / standardized Live DB material library or fixing the SU plugin.

I agree with Gabriel that they are under-resourced. There's so much potential but they need more hands / brains on deck.

Seeker

gabrielefx wrote:Because all Octane code comes from Abstrax he has to rebuild his software from scratch to achieve Fstorm performance.
Otoy says to Abstrax to stop his development because Lightfield technology is more important.

Indeed Marcus is doing a great job

Best thing, FStorm has good working Octane Converter
You can already tell that "they" are a little afraid of people switching; direct links to the FStorm page will get deleted here.

RobSteady wrote:direct links to the FStorm page will get deleted here.

Never seen that happen, Rob. Not sure if the Octane devs are that insecure...

Seekerfinder wrote:

RobSteady wrote:direct links to the FStorm page will get deleted here.

Never seen that happen, Rob. Not sure if the Octane devs are that insecure...

Yep, just happened. Posted a link to the FStorm page in this thread and now it's gone without any notification or message:
viewtopic.php?f=27&t=53240&start=70

RobSteady wrote:

Seekerfinder wrote:

RobSteady wrote:direct links to the FStorm page will get deleted here.

Never seen that happen, Rob. Not sure if the Octane devs are that insecure...

Yep, just happened. Posted a link to the FStorm page in this thread and now it's gone without any notification or message:
viewtopic.php?f=27&t=53240&start=70

Wow. That's a bit sad I think...