“sparks”
Most of modern path tracers use ray clamping (max sample intensity/max ray intensity) values to prevent fireflies. I am wondering of this GPULightmass uses it as well. If not, then that’s what could be attributed to those blurred fireflies. It definitely should be used.
I believe this is more or less a bug in GPULightmass’s adaptive sampler. Would you like to send me your scene (or a simplified version) for debugging?
Ray clamping is most useful when handling glossy/specular and other ‘spiky’ BRDFs. For lightmap baking the scene is pure Lambertian diffuse so it is currently not used. Still, I would try it to see its effectiveness :).
This looks really amazing. Any information on the CUDA version I need to have installed? I have 9.0176 and I got an error that said:
“CUDA driver insufficient for CUDA runtime version”
Works with swarm DR ?
Do you plan to implement support for Precomputed AO-Mask (if it’s possible)? :rolleyes:
Hi, encountered this issue when I am trying to build with GPU. Please help
@TZI9 look at the previous page
It’s not your CUDA version, actually you don’t even need CUDA SDK to be installed. It’s your display driver version that is too low.
Thanks to problems have been fixed
How did you fix it?
Hey @Muchasty how long took your bake?, excellent job btw!, and man!, you rock, just wanted to say, this should be a spotlight
The problem was two-sided material (replaced by one-sided ), not supported point light length ( replaced by spot), and sparks made from the one of LED emitter in my coffee machine model ( added node LightmassReplace to avoid bake cause all what is an emitter is used to add the light to the scene by the GPU Light mass).
Bake time 10 min. And I was very surprised when I saw that bake with active Swarm (I have prepared for net bake on CPUs) is made on all machines that have GPU on board in the network.
It also works if you set emissive boost to that staticmesh to be 0.0
Actually, it will help tremendously even with purely diffuse surface. Let’s say you have a strong sun light where small streak of light reaches deep part of the environment. If the sun is really strong, then variance of samples returned from that are will be significant.
Another very common case which can cause noise without ray clamping even in diffuse scenes are small and strong light sources very close to the surfaces.
On top of that, while I don’t know how your GPU path tracing works, generally, GPU path tracers do not do ray branching, and they also generally don’t support some irradiance/light caching for secondary bounces. In that case, having ray intensity clamping will actually help you that much more!
I have created two examples of the cases I’ve described above using offline renderer (Corona). All the offline renderers these days have ray clamping by default, set to some reasonable value (usually around 20, but for purpose of game engine, I think even 2 will be fine).
Here’s example of the sunlight case with ray clamping values:
Ray clamping OFF:
Ray clamping 20:
Ray clamping 5:
Ray clamping 2:
And here is example of the other case, small strong light source near the surface:
Ray clamping off:
Ray clamping 20:
Ray clamping 5:
Ray clamping 2:
So I definitely think it would help you a lot
EDIT: You may want to right click and open the images in a new tab to see it better without excessive compression
Looks VERY promising!
I’m planning a complete rework of GPULightmass using OpenCL. This may roll out in that reworked version.
GPULightmass is not a path tracer - it actually uses caching schemes which are very similar to light cache, otherwise it’ll be much slower like a pure brute force renderer.
If you do have secondary GI caching, then that’s very impressive Not many people managed to do that on GPU yet
As for OpenCL, I am a bit skeptical. Pretty much every GPU rendering developer I know of considers it inferior for some reason Reminds me of: watch?v=qHuqD2NxE30 (turn on CC captions)
It is the reason why GPULightmass is CUDA currently =)
Edit: Regarding caching I have something to say. I believe the reason why caching is easier for GPULightmass is, doing lightmap baking requires nearly all objects in the scene to have valid surface parameterization, which is very useful for cached lighting representation - if the parameterization causes problems for cached lighting, it will have definitely caused other bigger problems for lightmaps already. A problem is caching resolution, which I believe can be solved when I implement vray style retrace into GPULightmass.
Yep, retracing is usually quite important, especially to avoid light leaks. Anyway, I am looking forward for the updated version, and thank you for all the effort you’ve already put into it My utopian dream is to see this officially in UE4 one day and to see you working fulltime for Epic
Is there any chance to use this with SwarmAgent and use different PC in a network at the same time as you can do with CPU?