OctaneRender® 1.024 beta 2.48 TEST (win) [OBSOLETE]

[pixelrush]

you should get the same result visually only it should get there much faster.
it should just cover the opening - think of putting a same size sheet of plywood on the outside...

[ROUBAL]

- Updated previous post with renders using alpha images : I confirm, png transparency is broken. Comparison images made with exactly same scene and settings, in Path tracing (PMC gives same result).

- I also confirm that the sphere material pops up sometimes when tweaking materials ,and I have to click on the mesh node to get rid of it.

- With the new slower refresh method, adjusting materials is more tedious, and Octane looks more like an ordinary "boring" renderer than our beloved fast interactive Octane. Please come back to fast refresh previous method in 2.5 !

[kubo]

relinking is not working properly yet, when relinking I need to click on any material and then switch back to the mesh node to update properly. Portal is working big time, I'm testing with an interior scene I had, the thing is, that scene was made with 2.46 and tested again with 2.47 and hence it had some opacity tricks to make glass and curtains and such work properly, so now since alpha is back to not working I've changed the curtains to specular and used an HDRI image as light instead of the sun(indirect light has always gone thru transparent materials) and added portals in the outside of the windows. I've tested with normals following the light direction (inside the room) and facing the light (outside) and at least in this scene it only works with normals in the light direction aka facing the inside of the room. The overall light in the scene has improved great time, much better, I'll post some test as soon as they get "cooked". I agree with most that the actual refresing rate is a little slow, and that a slider to control it would be neat, in small scenes the previous refresh rate would be fine, and with heavier ones set 5 or 10.
Also, a stupid related requests (I know abstrax said no requests but it's related) could it be that the portal material had a switch on/off so when off it would be a 0 opacity material or not considered at all? it would help to see fast how portals affect the scene, and could be turned of without having to reload the mesh. (Dont mean this as an update in short term, just as a thought in my few minutes playing with it)
Besides all, thanks for the update, it has many things to keep us amused and to play with.

[radiance]

Hi all,

I just want to add some comments regarding the many small bugs in this release and an explanation as to the scope of changes in this release that creates the issues.

As some of you may know already, NVIDIA made changes as of the CUDA 3.2 iteration to it's toolkit that broke Octane's multi-gpu functionality.
I am not sure why NVIDIA did this, but I assume (I am not sure though) it's a change related to trying to cripple the use of Geforce Products for CUDA computation in profesional markets.

The core engine system that handles devices, configures them, and schedules rendering accross one or more GPUs is at the core of the engine, and is a very complex 'heart' of the software.

In order to fix this, and make sure we have a future proof system to replace it, we had to rewrite this almost completely.
As this is the main engine that connects the user interface to the GPU based render core, it also handles most of the functionality of controlling the render engine, giving it commands, combining results, and driving the control, render passes, speed/performance statistics system and tonemapping, aswell as image output and display in the viewport.

The difference between 2.47 and 2.48 is that 2.47 had the previous framework, and 2.48 has this new framework in place.
Eg, under the hood Octane has a completely new and very different new 'engine'.

This has been a very complex and large development effort, taking many months to develop (although it's developed in a very good way, it has much advantages that will become clear to users during the next weeks, once bugs are fixed).
Due to Refractive Software spending a few months to rewrite this engine, which is not a change that gives much new functionality, eg it replaces an existing one, it may give the impression that not much development has happened, which is not correct. Since it's now nearly finished, we can finally move on to adding more features during the next months to finish v1.0 final, including many features that have been requested a lot. (eg instancing, new scene file IO format, etc...)

It's perfectly normal that this release has many issues. Much more than we can find ourselves (as every artist uses Octane in his particular fashion).
On the positive side, all the reported issues where are minor bugs, which we can fix very quickly.

We will be releasing additional TEST releases during the coming week, and we are certain it will not take more than a week to get everything working fine.

This is, after all, a TEST release, not a new beta that we advertise to customers.
This is why it's called 2.48 TEST and not 2.5

I also will explain a few things that are important for testing and providing feedback:

* Some kernels may give slower performance figures, but this is in most situations not the case, it's mainly due to more accurate performance stats in this new framework.
* A lot of peripheral functionality is missing or broken (eg control, turntable, some tonemapping things etc...)
* Portals are a very good new feature for improving performance, if used correctly (Roeland is going to write up a post in this forum today with some documentation on portals)
* The new framework offers linear speedup. (eg even with a very large amount of GPUS, like 8 GPUs, will give you 799-800% the speed over one GPU)
* You can add and remove GPUs while rendering, and you won't even lost your current result, it will simply keep rendering
* We have worked very hard on getting the PMC kernel's bugs fixed (eg the image brightness problems). Speed is not that important yet, we need to get it working %100 before we can make it fast, and we have a lot of optimizations we can do, so don't think this PMC kernel is what you will be using during the next months for production work.


I hope this explains some of your issues, we're looking forward to fixing all the reported issues and releasing another test release very soon, in a few days.

Radiance

[pixelrush]

Thanks for the reply. This test version seems pretty complete considering.
Look forward to another in a few days
Keep up the good work lads

[abstrax]

Just to let you all know: A few of the reported bugs I have already fixed. The Linux problem is also solved. Since there have been more issues than expected (many caused by the same error) I plan to release a beta 2.48b that fixes most issues and will be available for Linux, too. The Mac build probably will take some more time.

-> No worries, we are getting there

Cheers,
Marcus

[abstrax]

Great news! Just one question:

- the disadvantage of rendering full frames on each device is that you don't gain better intereactivity with more GPUs (it still renders faster though)

This concerns only active GPUs right? U still get the benefit of better responsiveness with separate display card?

What I meant is: In the past, having several GPUs rendering the same frame, sped up rendering of each frame. This way a render result could be displayed earlier as if it was rendered only by one frame.

Now, this advantage goes away, as each GPU renders completely independent from each other GPU, which means that each GPU has to render a complete frame and with that the speed until we can display the first render result after a change stays constant and does not drop, when you add more GPUs.

The main advantage of the new system is that each GPU is independent of the GPUs and can render as fast as possible and doesn't have to wait until the other GPUs have finished their part.

Cheers,
Marcus

[radiant]

* You can add and remove GPUs while rendering, and you won't even lost your current result, it will simply keep rendering

holy shit, i wasted two hours last night. AWESOME

[abstrax]

I noticed frames per seconds has been removed. It was nice to have to check the speed. Any chance to have it back?

We are not constantly refreshing the screen anymore and with that the idea of FPS doesn't make much sense. It would be possible to calculate frames per second out of the samples/second, but why don't you use the samples per second display? Or am I missing something here?

Cheers,
Marcus

[abstrax]

Hi there.
Just tested the new release with my new GTX 590 and I dont know ,but multy GPU
worked for me better with the preview release , even if the multy GPU not worked
properly with release 2.47. I know the sample counter has been updated ,but regardles
I think 2,48 is slower then 2,47. you shouldn't have changed anything about the Fps ore Ms/sec.
because now we cant compare with 2.47
regards
Rico

Which kernel are you talking about? Again, if you are doing performance comparisons, please compare render times.

The reason why samples/second has changed is because it was incorrect before and now it's correct. Obviously that makes it hard to compare against older results, but broken things should be fixed, shouldn't they?

Cheers,
Marcus