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: 438
Joined: Sat Aug 11, 2012 7:22 pm UTC
Location: France
Contact:

Why we need a real raytracer for lightmaps rendering

Postby illwieckz » Sat Feb 20, 2016 2:19 pm UTC

So, let's play with the metro map.

Original map (light entities + some light emitting shader, legacy build, the overall light ambiance is nice, but nothing is realist at all:



Original map (light entities + some light emitting shader, bounce max, very high res lightmaps (the higher q3map2 can do, more than 7h rendering):



In fact, the higher lightmaps resolution you use, the better you see how they are wrong:



In fact, q3map2's lightmaps are (alsmot) good only if you do low res resolution, because the renderer will blurry them on interpolation. Using low res lightmaps forces interpolation which is just a blurry process to hide the problems. Please hide this ugly render behind a naive interpolation on a low res lightmap the next time please:



Also, q3map2 has a -bounce option to do some radiosity, in fact, you must avoid it, because you will just create more wrong shadows. You can't do radiosity if you use point lights, radiosity only works if you only use light emitting shaders, and if you mix both, the results is wrong wrong wrong:



Why three shadows here since we have lights everywhere: light point shadow casting can't be good:



Wrong shadow casting in all its glory:



By default, it looks like q3map2 paints some lights and cast shadow over it, so, the more you have light sources, the more you get wrong shadows. How you can get shadows in front of a light source? In fact the mapper tried to workaround the wrong lights adding some surface lights to repaint light over the shadow, but it does not work, it gives uglier results since the shadow is now more contrasted with the lights:



Do you see the two shadows of the bottle?



So, q3map2 allows surfacelight and bounce for radiosity, but it's all wrong. Also, surfacelights only works if you subdivize them, if you don't subdivize them, they are acting a bit like point lights too, which is wrong. This is a surfacelight build, without bounce. The lights are ok, the shadow are ok, but there is some big places that are black just because they never receive any light since in physical worlds these parts must receives indirect lighting, that's why we need bounce.



So, this is a render with bounce (higher res lightmap, surfacelight only, heavy subdivision, maximum bounce). It takes more than 8 hours to render, burning my 8 core CPU at 78° for more than 8 hours. To get that another ugly rendering. But if it's very ugly, it's not wrong except the bounced light amount is too low:



So, the really big problem is the amount of bounced light is too low, badly, this is not a compile switch, it's a per-shader option, so you have to rewrite all the shaders, or tweak the q3map2 source code, things I haven't done. To look real, there must be more light on the ceiling, between the wall and the ceiling, and between the two railway. Increasing the amount of bounced light can lead to a natural looking render:



See the shadows behind the chairs: it's ok.



See the shadow behind the bottles: it's ok.



See the shadow on top right, from the stem that sustains the lamp: it's all ok:



See the shadow from the dock, it's all ok:



So, the bounce is wrong, not enough light bounced, and some other issues. But it shows we need a real raytracer. In fact, it's not a problem if the render lasts more time, because in fact we will save days of trials and error process, workarounding bad pointlights with bad surface lights that workarounds bad pointlights etc. If we use a real raytracer, the render will probably last longer (btw, there is probably raytracers that are fare far optimized than q3map2, and there is some opencl based raytracers now), but the mapper will save days without having to deals with issues, just putting lights and getting natural render. The only tweak the mapper have to do is to tweak the amount of light source, the intensity of light and the light color, which is already so much work.

Currently, 90% of time for the lighting part of the mapping process is spent to workaround bugs from that wrong q3map2 renderer, which is painting light and shadow with hacks. It was ok 20 years ago when everyone was playing on a 640x480 display that hides the problem.
This comment is licensed under cc ​​by 4 and antecedent.
User avatar
illwieckz
Project Head
Posts: 438
Joined: Sat Aug 11, 2012 7:22 pm UTC
Location: France
Contact:

Re: Why we need a real raytracer for lightmaps rendering

Postby illwieckz » Sat Feb 20, 2016 3:31 pm UTC

I'm using the metro map for theses tests because it's a nice example of a map mimicking real stuf.

In fact, there is a very easy way to get nice rendering with q3map2: if you never map some stuff that exists for real. Looks at the lamp for example in the metro map, if you remove them, you remove almost all the shadow issues, so you can do good looking lightmaps with q3map2 if you never map some real stuff. If you map pure fictional environments like Warsow mappers do, you will be very happy with q3map2.

The problem with q3map2 lightmap is: there is some real stuff you will never be able to map, the only fix is to not map them.

The lamps in the docks of the metro map are good example, if I remove them and put lights on wall/ceiling like every quake3 map do, the lighting is fixed! The problem is: q3map2 will never allow you to put volumetric pendant lamp inside rooms, never. There is things q3map2 can't render. At all.
This comment is licensed under cc ​​by 4 and antecedent.
User avatar
illwieckz
Project Head
Posts: 438
Joined: Sat Aug 11, 2012 7:22 pm UTC
Location: France
Contact:

Re: Why we need a real raytracer for lightmaps rendering

Postby illwieckz » Sat Feb 20, 2016 4:46 pm UTC

note: there is a -bouncescale option to scale how many light is bounced… expect screenshots. :wink:
This comment is licensed under cc ​​by 4 and antecedent.
User avatar
illwieckz
Project Head
Posts: 438
Joined: Sat Aug 11, 2012 7:22 pm UTC
Location: France
Contact:

Re: Why we need a real raytracer for lightmaps rendering

Postby illwieckz » Sat Feb 20, 2016 7:50 pm UTC

So, I removed all pointlights, disabled shadowcasting and I'm only hacking with surfacelight and bouncing.

I got that:



So, it looks very nice but the bounce is buggy sometime, I can probably fix this issues dividing the bounce scale on that specific shader to not bounce. Watch the green bounce:



Watch the unattended bounce from the machine:



But I guess I can do nothing to prevent this bounce bug:



Btw, look at this other screenshot (I cut down the map to speed up render time):



Next screenshots use wrong settings, but it reveals nice stuff. Do you see the light on the corridor? Remember that the neon light does not emit light at all, and ads does not emit light, do not be fooled by them. Ok, so do you see the light, even if the color is wrong?



The light is bouncing from the dock! Yes, it comes from outside:



So, with a more natural setting (remember than both neon light and ads does not emit light at all), the light in the corridor comes bounced from the outside:



Also, look at that, the dock is too much bright, but see how the light bounce inside the tunnel:

Last edited by illwieckz on Sat Feb 20, 2016 10:19 pm UTC, edited 1 time in total.
This comment is licensed under cc ​​by 4 and antecedent.
User avatar
Ishq
Project Head
Posts: 1138
Joined: Tue Mar 06, 2012 8:32 pm UTC

Re: Why we need a real raytracer for lightmaps rendering

Postby Ishq » Sat Feb 20, 2016 8:33 pm UTC

Nice analysis. I wonder how difficult it would be to integrate a ray tracer into q3map2.
User avatar
illwieckz
Project Head
Posts: 438
Joined: Sat Aug 11, 2012 7:22 pm UTC
Location: France
Contact:

Re: Why we need a real raytracer for lightmaps rendering

Postby illwieckz » Sat Feb 20, 2016 10:22 pm UTC

By the way, about the last picture:



This is how the dock much look while viewed from the tunnel if HDR was done by the renderer.
This comment is licensed under cc ​​by 4 and antecedent.
User avatar
illwieckz
Project Head
Posts: 438
Joined: Sat Aug 11, 2012 7:22 pm UTC
Location: France
Contact:

Re: Why we need a real raytracer for lightmaps rendering

Postby illwieckz » Sun Feb 21, 2016 1:52 am UTC

So, just for fun,

samplesize 8 (“final” build netradiant profile), compile time 11m22:



samplesize 16 (“test” build netradiant profile, 16 is q3map2 default), compile time 3m48:



samplesize 64, compile time 43s:



I don't know if I will do screenshot with shadow casting because it's broken in three cases (shadowcasting is unreliable with lightsurface) and I don't want to lose that time right now, but it's worst with higher res too. So, the higher lightmap resolution you use, the more problem you get. :confused:

PS: do not be surprised by the compile time, I cut off the map from everything except this room to do my tests.
This comment is licensed under cc ​​by 4 and antecedent.
User avatar
illwieckz
Project Head
Posts: 438
Joined: Sat Aug 11, 2012 7:22 pm UTC
Location: France
Contact:

Re: Why we need a real raytracer for lightmaps rendering

Postby illwieckz » Sun Feb 21, 2016 12:28 pm UTC

Just one thing to add to the "lightmapping with an external raytracer" dream, it must not be forgotten that any new raytracer must render both the lightmap and the lightgrid.

That's one of the two issues of anthill in unvanquished (a tremulous map baked with blender by Seeeker), it does not have lightgrid (it's why models are pitch black everywhere, btw, I don't know what is the other issue with anthill: why lightmaps are messed up).

The engine can use a default lightgrid if missing, but for final build we need lightgrid.
Last edited by illwieckz on Sun Feb 21, 2016 3:41 pm UTC, edited 1 time in total.
This comment is licensed under cc ​​by 4 and antecedent.
User avatar
Viech
Project Head
Posts: 2137
Joined: Fri Aug 03, 2012 11:50 pm UTC
Location: Berlin

Re: Why we need a real raytracer for lightmaps rendering

Postby Viech » Sun Feb 21, 2016 2:27 pm UTC

Point lights, from a mapper's perspective, are nearly useless. I'm not sure how well Dæmon supports them, but support in NetRadiant is close to zero. Compare with d3radiant to see what features are required to make light entities useful – we lack most of these features. I won't get into detail here. My point is, until we also plan big improvments to some map editor or a switch to the Doom 3 map format, etc, we can safely ignore point lights in this entire discussion and treat maps that use them as broken in that regard.

With deluxe maps (that we also need in addition to light maps for our normal mapping to work!) and light maps it may be possible to reconstruct a light grid. Not sure how big the effort would be.
Responsible for: & , (map), (map texture editor), (material file generator), gameplay design & programming, artistic direction
User avatar
illwieckz
Project Head
Posts: 438
Joined: Sat Aug 11, 2012 7:22 pm UTC
Location: France
Contact:

Re: Why we need a real raytracer for lightmaps rendering

Postby illwieckz » Wed Oct 05, 2016 7:41 pm UTC

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

Return to “Level Design”

Who is online

Users browsing this forum: No registered users and 0 guests