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: Sat Jun 27, 2020 11:31 pm UTC
by illwieckz
The AMD Ryzen ThreadRipper 3990X is making GPU-based OpenCL rendering obsolete!

Joke aside, look at those compilation runs I've done:

Image

I've done three AMD FX-9590 times because my good old one seems to not be stable on stock frequencies anymore, so I've downclocked it a bit to produce data I can interpolate to guess what would be the time. Why I need this time ? It's to compare it with another benchmark someone else did with that CPU!

While I was running the test I noticed that q3map2 lightmapper scales very well! Whatever your CPU provides, q3map2 uses all the cores possible at 100%.

So, I made some extrapolation. Let's assume a single Ryzen ThreadRipper 3990X core would perform more than a single Ryzen 7 1700 core but less than a single Ryzen 3900X core. So let's guess how would perform 128 threads on a virtual Ryzen 7 1700 CPU and on a virtual Ryzen 3900X CPU, then take the mean of the result.

With the Chasm map, we would get something around 15 minutes:

Image

But, wait… Some months ago Phoronix benchmarked another ray tracer (C-Ray) on both the AMD FX-9590 and the AMD Ryzen ThreadRipper 3990X. Since C-Ray and q3map2 are both raytracers, what if the perfmormance multiplier would be the same between the same given CPU?

Image

With the chasm map, we would get something around 15 minutes, again:

Image

By using to different ways to guess the compile time on a AMD Ryzen ThreadRipper 3990X, by extrapolating others Ryzen CPU times with the same software or extrapolating other software time one the same hardware, I get similar time.

It means a large map like Vega would be compilable in “nofast” mode in 2 hours on an AMD Ryzen ThreadRipper 3990X (instead of almost two days on a AMD FX-9590)

The impressive thing is that AMD multiplied its CPU performance by 20 in 7 years, it's almost multiplying by 3 each year!

We would still appreciate Blender Cycle-based lightmapping for faster lightmapping time on more modest hardware, and for better lighting model.

Re: Why we need a real raytracer for lightmaps rendering

Posted: Sat Jun 27, 2020 11:39 pm UTC
by illwieckz
For reference, this is usual build with fast light and fast bounce (vega map):

Image

And this is build with nofast light and nofast bounce (vega map, 1 day and 18 hours of compilation on an FX 9590):

Image

The good news is that we can get almost the same result as the nofast one by only spending some minutes more (or seconds, depending on hardware) instead of hours if not days: by doing nofast light but fast bounces.

Re: Why we need a real raytracer for lightmaps rendering

Posted: Sun Jun 28, 2020 4:21 pm UTC
by Tom
It's like someone turned on the light. :thumbup:

Re: Why we need a real raytracer for lightmaps rendering

Posted: Mon Aug 31, 2020 9:33 pm UTC
by mjt
Ping me if you want a tour:

https://github.com/SomaZ/Blender_BSP_Im ... ng-modding

baking external lightmaps (hdr and ldr)
baking internal lightmaps (ldr)

Image

editing lightmap uv tcs and shader uv tcs
editing surface normals
editing entities
baking lightgrid
md3 import & export
a few more things to come I guess...

Right now there is some support for IBSP and RBSP

Re: Why we need a real raytracer for lightmaps rendering

Posted: Tue Sep 01, 2020 5:02 pm UTC
by illwieckz
Hi @mjt and welcome! Yes, I'm procrastinating to link this project for too much time… :-)

Baking with Cycles is going real, here is some screenshots stolen from Blendiant Task Force's discord, with Jedi Knight maps:

Image
Image
Image
Image
Image