Maxwell Render | Official public forum

Hmm, similar notes...

1. I also wonder about approach to caustics. Softness implies the use of SPPM. GPU caustics feel unreal (in shown example reflective should prevail over refractive. CPU is correct.)
2. Low priority issue remains.
3. Fast Multilight finally works (& would really be nice if the fix is pushed to one last final v3).
4. Switching from Production (CPU) to GPU and then back, corrupts the CPU rendering while Draft & GPU stay OK (pic. 1).
5. Rendering is much slower in v4 than in v3: Draft--> 08:40 vs 03:14 /// Pro. --> 03:17 vs 02:40 (Why?)


Q:
Since you have a plan to make a hybrid engine (hopefully to fully exploit available hardware), are there also any plans to introduce or expose:
1. Intensity clamping?
2. Ray depth/bounces?
3. Denoising?
4. OpenCL computing?

First tests are discouraging, make me feel as beta testing

Production comparison



Draft comparison


v4 Quality comparison



* Differences in tone (v3 vs v4) noticed after rendering, didn't check for causes as library scenes were used (default settings).
**Nice to see light/caustics on GPU through glass (feels as almost physically accurate)

So far I discovered this:

All rendered via rhino plugin with FIRE.

1. direct seen 1x reflected from glass sun caustic draft CPU - none draft GPU - almost none (after relatively long time) production CPU - YES (very clear)
2. direct seen 1x refracted from glass sun caustic draft CPU - none draft GPU - blurred and little grainy not well defined borders production CPU - YES (very clear)
3. seen through glass 1 x reflected from glass sun caustic not tested yet, but you can predict based on other test here
4. seen through glass 1 x refracted from glass sun caustic draft CPU - none draft GPU - grainy and blurred but strong and visible (after relatively short time) production CPU - almost none (after relatively long time)

5. direct seen 1x reflected from metal mirror sun caustic draft CPU - none draft GPU - yes, clear but blurred farther edges production CPU - almost none (after relatively long time)
6. seen through glass 1x reflected from metal mirror sun caustic draft CPU - none draft GPU - yes, grainy and blurred but visible production CPU - none (after relatively long time)
7. seen in metal mirror through glass reflected from metal mirror sun caustic draft CPU - none draft GPU - yes, grainy and blurred but visible production CPU - none (after relatively long time)

Just direct seen 1x reflected from glass sun caustic is almost completely missing in GPU rendering.
Is there possibility to render "GPU production" in FIRE (Rhino plugin)?

So this is very good news. After 11 years of known limitation this is big step for mankind . There will be a lot of optimisations that have to come, but for me, this is bigger breakpoint that GPU rendering alone in V4.

Patrik

Sorry for such a amateur simple tests.










picture share

burnin wrote:Hmm, similar notes...

1. I also wonder about approach to caustics. Softness implies the use of SPPM. GPU caustics feel unreal (in shown example reflective should prevail over refractive. CPU is correct.)
2. Low priority issue remains.
3. Fast Multilight finally works (& would really be nice if the fix is pushed to one last final v3).
4. Switching from Production (CPU) to GPU and then back, corrupts the CPU rendering while Draft & GPU stay OK (pic. 1).
5. Rendering is much slower in v4 than in v3: Draft--> 08:40 vs 03:14 /// Pro. --> 03:17 vs 02:40 (Why?)


Q:
Since you have a plan to make a hybrid engine (hopefully to fully exploit available hardware), are there also any plans to introduce or expose:
1. Intensity clamping?
2. Ray depth/bounces?
3. Denoising?
4. OpenCL computing?

First tests are discouraging, make me feel as beta testing

* Differences in tone (v3 vs v4) noticed after rendering, didn't check for causes as library scenes were used (default settings).
**Nice to see light/caustics on GPU through glass (feels as almost physically accurate)

Switching engine is an addressed issue, hope it will be fixed in first patch.
CPU being slower on V4 have no dev justification as nothing huge have changed on engine code. It seems to be just a deployment issue, and hope to have it solved on first patch too.

As for the questions. We won't expose a lot of parameters that lead the engine to be less physically accurate, or need the user to do a lot of tweeks. There is work in progress in some of those things but they will be automatically used, not exposed. No OpenCL porting is planning yet.

PA3K wrote:So far I discovered this:

All rendered via rhino plugin with FIRE.

1. direct seen 1x reflected from glass sun caustic draft CPU - none draft GPU - almost none (after relatively long time) production CPU - YES (very clear)
2. direct seen 1x refracted from glass sun caustic draft CPU - none draft GPU - blurred and little grainy not well defined borders production CPU - YES (very clear)
3. seen through glass 1 x reflected from glass sun caustic not tested yet, but you can predict based on other test here
4. seen through glass 1 x refracted from glass sun caustic draft CPU - none draft GPU - grainy and blurred but strong and visible (after relatively short time) production CPU - almost none (after relatively long time)

5. direct seen 1x reflected from metal mirror sun caustic draft CPU - none draft GPU - yes, clear but blurred farther edges production CPU - almost none (after relatively long time)
6. seen through glass 1x reflected from metal mirror sun caustic draft CPU - none draft GPU - yes, grainy and blurred but visible production CPU - none (after relatively long time)
7. seen in metal mirror through glass reflected from metal mirror sun caustic draft CPU - none draft GPU - yes, grainy and blurred but visible production CPU - none (after relatively long time)

Just direct seen 1x reflected from glass sun caustic is almost completely missing in GPU rendering.
Is there possibility to render "GPU production" in FIRE (Rhino plugin)?

So this is very good news. After 11 years of known limitation this is big step for mankind . There will be a lot of optimisations that have to come, but for me, this is bigger breakpoint that GPU rendering alone in V4.

Patrik

Just to clarify, there's only 1 GPU engine. No such GPU Draft or GPU production, just GPU.

So, the main claim from Next Limit was 100 percent identical output/features/quality between GPU and the standard CPU.

Seeing the current differences in caustic calculation, I wonder if this current build is to be considered to be final regarding the current features, or is this just some preview version, costly for sure, but meant to meet the final CPU quality eventually (speed improved by GPU to a certain degree?)

when i use gpu and hdr only , the render result always black

Aniki wrote:So, the main claim from Next Limit was 100 percent identical output/features/quality between GPU and the standard CPU.

Seeing the current differences in caustic calculation, I wonder if this current build is to be considered to be final regarding the current features, or is this just some preview version, costly for sure, but meant to meet the final CPU quality eventually (speed improved by GPU to a certain degree?)

Any difference between engines should be considered as something we are working on / will work on. No final status of any feature if looks different.

seghier wrote:when i use gpu and hdr only , the render result always black

Can't reproduce that. I just tested an scene with a cube and only hdr and see the same on GPU than on CPU (using FIRE). Can be more specific? Maybe it's fixed on 4.0.0.6.

luis.hijarrubia wrote:

seghier wrote:when i use gpu and hdr only , the render result always black

Can't reproduce that. I just tested an scene with a cube and only hdr and see the same on GPU than on CPU (using FIRE). Can be more specific? Maybe it's fixed on 4.0.0.6.

here my test

https://www.youtube.com/watch?v=NzGu25ybKVo

luis.hijarrubia wrote:Switching engine is an addressed issue, hope it will be fixed in first patch.
CPU being slower on V4 have no dev justification as nothing huge have changed on engine code. It seems to be just a deployment issue, and hope to have it solved on first patch too.

As for the questions. We won't expose a lot of parameters that lead the engine to be less physically accurate, or need the user to do a lot of tweeks. There is work in progress in some of those things but they will be automatically used, not exposed. No OpenCL porting is planning yet.

In the development of the code, reasons for slowdowns & bugs are never huge... God & the devil are in the detail.

Still could you give at least a hint as what approach is used for caustics (GPT, SPPM, MLT, VCM...) as on the OP example GPU version is looking a bit strange. What's the angle of light source in relation to glass & mirror?


Anyway, thank you for that piece of information.

[/quote]

Just to clarify, there's only 1 GPU engine. No such GPU Draft or GPU production, just GPU.[/quote]

Thank You for Your answer Luis. I was reffering to this:



Patrik

^There's no Production Quality for GPU rendering. GPU is one and the same engine in use for Final and for Fire

Back on topic
Made a similar scene as shown on OP to check caustics & consider physical accuracy.
Calculated on CPU



Maxwell4 CPU Production


Maxwell4 GPU (Draft)


You can get the scene causticsM~R4 here.

gpu actually give bad results and cpu is better ;
this is quick comparaison between thearender and maxwell ; why maxwell need sl : +25 for caustics ?

what that mean ?
Reflection/Refraction passes are still not supported in the GPU engine and will be disabled for rendering.

sometimes when i made change in the scene and try to render i got this error message
Cannot export scene
Check studio console for details
and this is the details :
Error saving scene: Write MXS : Cannot write MXS file in the specified path [ID: 5]
when i close studio and open the scene again the problem solved