Why we need a real raytracer for lightmaps rendering

Ask questions about mapping in general, and show off your in-progress work.
User avatar
illwieckz
Project Head
Posts: 717
Joined: Sat Aug 11, 2012 7:22 pm UTC
Location: France
Contact:

Re: Why we need a real raytracer for lightmaps rendering

Post by illwieckz »

This comment is licensed under cc ​​by 4 and antecedent.

User avatar
illwieckz
Project Head
Posts: 717
Joined: Sat Aug 11, 2012 7:22 pm UTC
Location: France
Contact:

Re: Why we need a real raytracer for lightmaps rendering

Post 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

This comment is licensed under cc ​​by 4 and antecedent.

User avatar
illwieckz
Project Head
Posts: 717
Joined: Sat Aug 11, 2012 7:22 pm UTC
Location: France
Contact:

Re: Why we need a real raytracer for lightmaps rendering

Post 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.

This comment is licensed under cc ​​by 4 and antecedent.

User avatar
illwieckz
Project Head
Posts: 717
Joined: Sat Aug 11, 2012 7:22 pm UTC
Location: France
Contact:

Re: Why we need a real raytracer for lightmaps rendering

Post 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.

This comment is licensed under cc ​​by 4 and antecedent.

User avatar
Tom
Dragoon
Posts: 253
Joined: Tue Jan 15, 2013 3:34 pm UTC
Location: France

Re: Why we need a real raytracer for lightmaps rendering

Post by Tom »

It's like someone turned on the light. :thumbup:

mjt
Posts: 1
Joined: Mon Aug 31, 2020 9:24 pm UTC

Re: Why we need a real raytracer for lightmaps rendering

Post 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

User avatar
illwieckz
Project Head
Posts: 717
Joined: Sat Aug 11, 2012 7:22 pm UTC
Location: France
Contact:

Re: Why we need a real raytracer for lightmaps rendering

Post 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

This comment is licensed under cc ​​by 4 and antecedent.

User avatar
illwieckz
Project Head
Posts: 717
Joined: Sat Aug 11, 2012 7:22 pm UTC
Location: France
Contact:

Re: Why we need a real raytracer for lightmaps rendering

Post by illwieckz »

I'm doing some investigations on q3map2 side (and also related engine side that would be required by q3map2 changes) here:

https://gitlab.com/xonotic/netradiant/-/issues/183

This comment is licensed under cc ​​by 4 and antecedent.

Post Reply