Page 3 of 3

Re: Why we need a real raytracer for lightmaps rendering

Posted: Fri Jun 23, 2017 6:16 pm UTC
by illwieckz

Re: Why we need a real raytracer for lightmaps rendering

Posted: Thu Jul 27, 2017 8:46 pm UTC
by illwieckz
some experiments with nofast and lightsubdivision (see NetRadiant's MR !67:

Note: it's a cut-out of the map
Note: the dark line on ceiling is a known issue due to the geometry of this part (the original build already has this bug), I don't know how to workaround this properly yet.
Note: the light stage took hours for this room.
Note: light switches were: -lightsubdiv 100 -fastallocate -shade -dirty -patchshadows -randomsamples -samples 3 -samplesize 8 -bouncegrid -bounce 1 -deluxe -lightanglehl 1 -lightmapsize 1024 -external (more bounce can reduce and sometime remove the dark line effect on the middle of the ceiling, but it means adding days to compile time, so that's not a good solution)

Image
Image
Image
Image
Image
Image
Image
Image
Image
Image
Image
Image
Image
Image
Image
Image
Image
Image

Re: Why we need a real raytracer for lightmaps rendering

Posted: Thu Oct 04, 2018 6:04 pm UTC
by illwieckz
We have a very big issue. The bsp stage of q3map2 is very slow because of meta computation. For example with chasm map the whole compilation including 8 bounces last 16min on my computer, but the bsp stage itself lasts more than 6min. So, the point of computing lightmaps from bsp with a faster renderer is not that good if if we still have to wait 6min to produce the bsp first. Whatever the way lightmaps are rendered we have to speed-up that bsp meta computation.

Re: Why we need a real raytracer for lightmaps rendering

Posted: Tue Oct 16, 2018 1:50 am UTC
by illwieckz
Speaking about AMD OpenCL renderers, Unity managed to pipe AMD Rays into their tookchain to render their lightmaps:

https://blogs.unity3d.com/2018/03/29/am ... ghtmapper/

PDF from GDC2017 presentation (Radeon ProRender And Radeon Rays In A Gaming Rendering Workflow):
https://gpuopen.com/gdc2017-radeon-pror ... -workflow/