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: 455
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:

Image

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

Image

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

Image

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:

Image

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:

Image

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

Image

Wrong shadow casting in all its glory:

Image

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:

Image

Do you see the two shadows of the bottle?

Image

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.

Image

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:

Image

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:

Image

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

Image

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

Image

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

Image

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

Image

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: 455
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: 455
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: 455
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:

Image

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:

Image

Watch the unattended bounce from the machine:

Image

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

Image

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

Image

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?

Image

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

Image

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:

Image

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

Image
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: 455
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:

Image

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: 455
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:

Image

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

Image

samplesize 64, compile time 43s:

Image

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: 455
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: 2139
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: Arch Linux package & torrent distribution, Parpax (map), Chameleon (map texture editor), Sloth (material file generator), gameplay design & programming, artistic direction
User avatar
illwieckz
Project Head
Posts: 455
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

Yesterday I successfully loaded a map (atcshd) in blender, exporting it as obj model with q3map2, something blender can grok.

If I talk about blender, it's not for editing, it's because blender knows how to bake stuff with multiple renderer, like the (OpenCL accelerated) Cycles renderer, and some others (you have choice). What I'm testing is to get a map loaded in blender, and if I get it right, bake some stuff. If all of these works with point and click, the next step would be to script that. When I talk about blender, it's not about editing, it's about baking.

Some quotes from irc:

<Supertanker> illwieckz, how do we fix q3map2 :D (lightmaps)
<illwieckz> hi Supertanker! I guess the better thing to do with q3map2 is to forget his lightmap capability, and dig to find a better renderer, but it's far beyond my knowledge.
<illwieckz> there is a trick doable: add an option to q3map2 to always put an extra pixel between lightmaps so a an automated tool can apply some filters using a mask made of these extra pixels, but it's just filtering crap, but it allows to generate smooth high resolution lightmaps from crappy low resolution ones.
<illwieckz> the first big issue with q3map2 lightmaps is they are done for a 1996's 1024x768 screen. the second big issue is it does not fit today's quality requirement, shadows must not be casted on light globes, light ray must be casted on shadows. lightmaps must be light maps, not shadow maps.
<illwieckz> that's why I dream of whatever opensource raycaster, but I don't have the skill for that. perhaps dig in https://www.blender.org/manual/render/c ... aking.html and http://blender.stackexchange.com/a/86 etc.
<Supertanker> illwieckz, I was thinking of using Blender :) Sadly that means a lot of manual clipping, or using q3map2's autoclipping, which I hear is terrible.
<kharnov> please do not bother with blender for mapping, it's not worth the pain
<illwieckz> kharnov, when I talk about blender, it's not about editing, it's about baking. What I dream of is to have a command-line tool that imports a map in blender, bakes lightmaps and exit
<kharnov> i was talking about the full mapping pipeline in blender, please don't do that to yourself
<illwieckz> I don't want to think about it, even thinking about it is something I don't want to do to myself
<kharnov> yes
<illwieckz> also, any lightmap baking alternative to q3map2 must be usable in command line mode, in an headless scenario. so if I quote the "blender" name in a lightmap talk, it means I implie that the ui must not be seen, and no one interaction must be needed
<illwieckz> ./magical_script.py --mapfile plat23.map --lightmapdir plat23/
<illwieckz> and let your OpenCL compute unit sweating for you, hopefully, GPU don't have emotions, so they can work on maps using blender.
<illwieckz> one first step would be to export a .map file to a model blender understands, invisibiling the things it does not need (like invisible clip surfaces etc.), even if the baking must be done by hand at this step, and even if the baking does not work, it would be an awesome step, it means we would be able to render lightmaps with another renderer one day. we need to be able to load a map in blender without human intervention: just to load it, not to edit it. load a finished map, so we can script actions on it.
<kung_> cant you just use a bsp2obj converter and import the obj natively into any engine?
<illwieckz> q3map2 -convert mapname.bsp -format obj
<Supertanker> woah that works?
<illwieckz> I loaded atcshd.obj


Image

q3map2 also knows to export ase but blender don't have an official and builtin loader for that.
q3map2 exports is very buggy and must be improved (for example it looks like to not support game profile, being stuck on quake3 stuff).

The other big issue with map export is the .mtl produced alongside the .obj references every shader name as shadername.tga, but of course, they are not real textures, they are just entires in .shader script. So, blender fail to find no one texture. Adding .shader reading in blender is not an option.

There is a thing I thought about, q3map2 knows how to read and render .shader files. It's its job to do it to render lightmaps, since it's just painting shadow and lights over .shaders it computed and rendered first. So, is it possible, for every <shadername> referenced by a bsp and found in a .shader file, to export to an arbitrary directory a tga file that contain the computed texture from <shadername>. This way, blender (or any other renderer) can load the precomputed shader as textures. What do you think about it? Is it possible to modify q3map2 to export a computed tga for each shader?

This way the workflow would be that:

Code: Select all

# get mapname.obj and mapname.mtl (-objpath is fictional)
q3map2 -convert mapname.bsp -format obj -objpath directory/maps/mapname.obj
# get textures/something/stuff.tga from textures/something/stuff shader in scripts/something.shader (-exportshaders and -exportedshaderdir are fictional)
q3map2 -exportshaders -exportedshaderdir directory/
# run a magical scripts that import obj in blender and bake lightmaps (fictional)
blender_render.py --map=directory/maps/mapname.obj --exportedshaderdir=directory/ --lightmapsdir=directory/maps/mapname/
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 1 guest