Indigo Renderer Forum

Zom-B wrote:It seems that GPU rendering has a general darker phong material then CPU based rendering:

CPU:

cpu.jpg

GPU:

gpu.jpg

Something that can be fixed?

Is the material using bump ? Because bump might be stronger on GPU, therefore the material would look darker.

CTZn wrote:Is the material using bump ? Because bump might be stronger on GPU, therefore the material would look darker.

Yes, the material uses bump, but comparing both images in full 2560x1440 res showed that the bump height seems the same, just darker "base material".
Anyway, I did a quick test without using bump, but same darkening of the material appeared here too!

Zom-B wrote:Anyway, I did a quick test without using bump, but same darkening of the material appeared here too!

Oki

A few GUI related Issues:

- Loading Textures doesn't show TIF files in directories, but it should!
- The Displacement channel hast still some numeric field, next to texture button. isn't that obsolate?
- Also the numerical field for Blend channel should gray out if a Texture is chosen to controle the blend

..and still in Phong materials the exponent entry is grey, while it should be changeable.

Pibuz wrote:..and still in Phong materials the exponent entry is grey, while it should be changeable.

ehm.... Phongs definition of existence is to have a Exponent, you can't deactivate it, but edit value and set a texture, where is the issue?

Correct. No exponent, no Phong !

The checkbox should be removed plain and simple :)

Yep, that should be removed to avoid misunderstandings :)

BTW, I was referring to another issue which has been already fixed.. Sorry guys

I spotted another little issue: when a supported GPU is not detected, you cannot change the render mode, even if you stop the render. Sounds like Indigo assumes as "always checked" the GPU acceleration feature if enabled in the bridge app before the export process. As one cannot uncheck that, Indigo cannot render in different render modes..

(..I know: I'm testing on a very old machine, with a lousy card guys, but still it can happen :P)

..another silly request: could it be possible to add support for a spherical background image (just to get little reflections on windows when working with outdoor shots..) NOT casting shadows nor light?

Hi I've been playing around with clouds and spotted this weird behavior when rendering in different modes. Any fix/workaround for that? Thanks!

I had much more consistent results by using a constant film (linear 0.035, could have been camera), though they were showing discrepancies. Specially intriguing between GPU and non-GPU PT.

Reinhard will react to the brightest pixel in the render, greatly altering the overall luminosity. MLT is also not to be simply discarded when sss is in use !

PS: I downloaded the fog material and modified the scattering value to 0.2, not a blender user here. Test sphere radius was 100m.

Hi, the current CPU PT has optimisations for IOR=1 media which are not present in the GPU accelerated modes, so it'll take quite a lot longer to converge in those situations; this will be resolved eventually.

Haluperido, could you please share a simplified PIGS with me ? The same scene with just one typical cloud.

I would like to check:

- wether triangles are missing on the clouds (depending on the surfacing technique used)
- scene span
- best material and engine settings for the current beta. Expectedly MLT on PT would have been better but let me check this up.

Sure! PIGS in attachment. Have fun ;)

Clouds are just subdivided cubes with displace modifier (procedural cloud texture from blender), they might contain overlapping faces, and some faces are pointing inwards here and there if displacement factor is to big (it renders as a black area).

Cloud mesh in PIGS is quite smooth and hopefully you won't find too many mesh related problems - it's about 70x90x70meters

This is really a sampling issue, meshes or scene span aren't involved indeed...

Thanks a lot, amazing results with path tracing. Clouds rendering is going to be tremendously fast when these optimisations will be ported !

MLT is in fact derived from the primary tracing method, single or bidirectional path tracing. If one is performing poorly MLT on top will only do so much.

The poor performance of bidir with subsurface scattering is due to the constrain defining it: the path must be traced "clearly" in both directions to generate a sample. Scattering of rays within media is preventing outstanding bidir paths to emerge, generating much fewer samples than single path tracing would.