Light baking

[nbohr1more]

Or how about using the open city section of the training map..?

 

From what I recall there are already some unusual light textures (the falloff image and light texture are the same file in the definition??????) applied in that map but I will see if anything I do can improve the look (another one that would be hard to improve on though...).

Edited August 18, 2010 by nbohr1more

[Tels]

I took the liberty to add some wiki formatting:

 

* for bullet lists, add "*" in front of the lines (like so

* you can use [http://blah.com Some text] so it display better (did not do this yet)

* use either a space in front of lines, or add <pre> </pre> arond sections you want in monospace, like the examples from material shaders

* use things like |400px|thumb on images (so they don't span the entire monitor and then some This causes the images to appear on the right side, so to make the text stop wrapping around the image, e.g. restart the next headline as a new paragraph, use the template {{clear}} after this paragraph.

* use more deeper levels for headlines with === level 2 === etc, to organize your text better

 

Hope this helps

 

Btw, we also have nice templates for the left/right mouse button {{LMB}}, {{RMB}} as well as for keys like {{key|ENTER}} or {{key|ALT}}+{{key|P}} - use them if you want to show keyboard keys or mouse buttons to be pressed. (Remember to use uppercase letters, because thats whats on the keyboard, so use {{ALT}}+{{key|L}}, not {{ALT}}+{{key|l}}

[nbohr1more]

Thanks Tels!

 

It looks much more professional.

 

(Wishes Lunaran or Rich_is_Bored would take further liberties with the actual content... )

[nbohr1more]

The Training Mission city looks like a good candidate as there are places where the lighting looks really flat and it's even hard to distinguish geometry because of this.

 

As it currently stands the ambient is way too high to realistically enhance the lighting with this technique but I now have a good candidate (guinea pig ...) and some ideas.

 

It'll take me a "while" though...

[rich_is_bored]

I'm not terribly familiar with the technique. I have a rough idea how it works but I haven't sat down and tried it to work out the details.

[rich_is_bored]

I just did a quick test with an ambient light and it seems the changes made to the ambient light fragment program have introduced some interesting peculiarities.

 

In TDM ambient lights have a distance based falloff along the x and y axises even when you use a white image for both stages. Also, for some strange reason you have to include a black alpha channel in your images for the light to penetrate walls and illuminate back faces.

 

I have yet to determine what the case is with omni and projected lights. I suspect they will still work fine for this purpose.

[rebb]

In TDM ambient lights have a distance based falloff along the x and y axises even when you use a white image for both stages. Also, for some strange reason you have to include a black alpha channel in your images for the light to penetrate walls and illuminate back faces.

 

Could you supply a test-map package where this x/y problem happens ? Ambient and Standard Light are using the same texture-lookups so this does sound strange.

 

The "black alpha" requirement is explained in the test.vfp file, its a way to "detect" ambient-light that was used due to compatibility problems with earlier detection-algorithms.

 

It's possible that this requirement will be dropped in the future if other detection algorithms turn out to be compatible enough, in that case already adjusted ambient-light textures will still work though.

[rich_is_bored]

Everything required to see the problem is here...

 

 

 

It never occurred to me to look in the vfp for documentation. My first instinct was to look at the TDM wiki.

 

Thanks for the explanation.

[rebb]

Hmm, interesting - it seems that having multiple map-stages in the light material causes Doom3 to draw the light for each of those stages.

 

This seems to be the cause for your problem as well. It looks like the game ends up drawing the light once with your first map-stage ( ignoring the maskColor ), then draws again using the 2nd stage ( this time ignoring the maskAlpha ).

 

So you end up having an ambient-light and a standard light drawn on top of it.

 

The idea to reuse the alpha from another image is good, but apparently the game handles things differently for lights in some way.

 

Try commenting out either of the stages and do "reloadDecls", to see how the game treats that.

 

Btw an image for a full ambient without falloff would be "textures/lights/ambientlightnfo_amb".

 

Edit : For some reason the multiple maps don't bump up what's displayed by "r_showlightCount" - maybe because the game doesn't count map stages in light-materials ?

[nbohr1more]

I was thinking that the "shaped ambient" portion of the Strombine approach might run into TDM specific ambient concerns. I figured that giving the omni light nearly all the same properties as an ambient light should suffice.

 

We shall see.

 

Ha! We might be back on track after all.

Edited August 19, 2010 by nbohr1more

[nbohr1more]

Hmm, interesting - it seems that having multiple map-stages in the light material causes Doom3 to draw the light for each of those stages.

 

This seems to be the cause for your problem as well. It looks like the game ends up drawing the light once with your first map-stage ( ignoring the maskColor ), then draws again using the 2nd stage ( this time ignoring the maskAlpha ).

 

So you end up having an ambient-light and a standard light drawn on top of it.

 

The idea to reuse the alpha from another image is good, but apparently the game handles things differently for lights in some way.

 

Try commenting out either of the stages and do "reloadDecls", to see how the game treats that.

 

Btw an image for a full ambient without falloff would be "textures/lights/ambientlightnfo_amb" .

 

Edit : For some reason the multiple maps don't bump up what's displayed by "r_showlightCount" - maybe because the game doesn't count map stages in light-materials ?

 

 

If I fathom all that, then perhaps these aren't really separate lights... they are just stages that do not inherit from the previous stages? That may help further detail the advantage of this approach (and decode what Lunaran is up to )

 

I was poking around the fragment programs the engine uses for light shaders (four image lookups per pass, woo!) and I came to the realization that, if the engine has to split batches per light anyway to set up new light origins for the vector math, it is to your artistic advantage to paint a unique image for every light source. You've gotta design the shapes of your rooms with the light volumes that'll go into them in mind, but if you do that right you can fit one or two ambient light volumes over the room with maps painted to match just the lights and geometry in that room. The ambient usually looks so horrible because it's a consistently even brightness throughout the volume (that and the lack of normal shading in d3, which q4 'fixes'), but by painting light images for them you can get the smooth gradations that you'd need to better simulate scattered light. If you've got brightly colored surfaces in the room you can even fudge in a little colored radiosity ala the Cornell Box.

 

So maybe 2 separate lights can be packed into one light definition and have only the performance impact of one light?

Edited August 19, 2010 by nbohr1more

[rebb]

So maybe 2 separate lights can be packed into one light definition and have only the performance impact of one light?

 

No the performance impact is still there.

 

At least doing some tests with "r_showPrimitives" shows that the number of draw-calls goes up when having 2 map-stages in the light-material instead of one.

 

@Sneaksie :

[Tels]

Hmm, interesting - it seems that having multiple map-stages in the light material causes Doom3 to draw the light for each of those stages.

 

This seems to be the cause for your problem as well. It looks like the game ends up drawing the light once with your first map-stage ( ignoring the maskColor ), then draws again using the 2nd stage ( this time ignoring the maskAlpha ).

 

So you end up having an ambient-light and a standard light drawn on top of it.

 

The idea to reuse the alpha from another image is good, but apparently the game handles things differently for lights in some way.

 

Try commenting out either of the stages and do "reloadDecls", to see how the game treats that.

 

Btw an image for a full ambient without falloff would be "textures/lights/ambientlightnfo_amb".

 

Edit : For some reason the multiple maps don't bump up what's displayed by "r_showlightCount" - maybe because the game doesn't count map stages in light-materials ?

 

It makes sense that "r_showLightCount" only counts the lights, and not the stages (otherwise it would be called r_showLightStageCount

 

Also, it makes sense that each stage is drawn sep., as far as I know thats how stages work. Each stage is done as a sep. pass with the exception that somethings can be combined into one pass if I remember the early tech talks correctly. It was along the lines of "on some old hardware it does X passes, on newer hardware X/2 passes".

[rich_is_bored]

Just to rule out the possibility of using multiple stages as being the source of the problem, I'm now using a simple white image with a black alpha. The problem persists.

 

 

 

Notice the falloff despite the fact the image does not fade to black. Notice back faces are not illuminated.

 

This room should appear full bright as the texture is uniformly white. It does not.

[rebb]

Just to rule out the possibility of using multiple stages as being the source of the problem, I'm now using a simple white image with a black alpha. The problem persists.

 

Notice the falloff despite the fact the image does not fade to black. Notice back faces are not illuminated.

 

This room should appear full bright as the texture is uniformly white. It does not.

 

The test.vfp mentions that the Alpha-Channel isn't supposed to be fully black ( filled with RGB 0 ), because Doom3 then thinks that this Alpha-Channel is some sort of Artist-Error and instead drops it completely, which ends up making all the Alpha completely white.

 

Try filling the Alpha-Channel with RGB 1 ( on the 255 scale ) instead.

 

I guess its a good idea to just make a small wiki article on this.

[rich_is_bored]

Thanks for the tip. I've finally had some success.

 

 

 

It's not a practical example but it does demonstrate that it works in TDM. Just plop the file into the root of your Dark Mod installation, rename it to pk4, and then type "map test" at the console.

 

Basically I've taken what would normally be 3 overlapping lights and consolidated them into one. As an added bonus there is fake radiosity and soft shadows all painted in using GIMP and Inkscape.

[Diego]

I just thought of an algorithm that may be possible to implement. Fill out a region of space with small blocks of ambient light, then calculate radiosity of the present light sources and feed the blocks of ambient.

 

Yeah, it's not gonna happen. I just like the exercise

[SneaksieDave]

 

 

Hm. I'm getting this:

 

Yes it's renamed PK4 (and opens as such with winrar). I also tried taking the map out of the PK4 and into the /maps folder and recompiling, and even renaming it to testrich.map (though no 'test.map' is conflicting) but no dice. I can see in DR that this isn't what the map looks like, so I'm a bit confused at the moment...

 

Edit: oh damn, it looks sweet in DR though. Made my heart skip a beat, as for a split second I thought DR gained realtime soft shadows!

[nbohr1more]

Is that the 2nd version Sneaksie?

 

I hope the forum didn't replace his file with the first version since they have the same name

 

When my PC ban is over I'll have to check it out

Edited August 25, 2010 by nbohr1more

[SneaksieDave]

Not sure, just the one in the post above Diego's. Feel like I'm having a brainfart. Works fine in DR... loads wrong in TDM... recompiled... deleted from PK4 even... renamed even... tried in separate folder even... erm... huh?

[SneaksieDave]

Uh, discovered the reason, and it's not good. (Side topic)

 

The world is completely black (after re-dmap; otherwise it looks like my shot above) when the mapper doesn't include an "ambient_world" entity*.

 

I realize all release maps should include that, but to bust a map completely if it doesn't? Bit much.

 

 

 

 

Edit: *for those without new ambient and HDR this will work fine.

[SiyahParsomen]

It works fine, and looks fuc*ing awesome!!

 

great news. I'm on tracing this topic from now on.

[LEGION]

Uh, discovered the reason, and it's not good. (Side topic)

 

The world is completely black (after re-dmap; otherwise it looks like my shot above) when the mapper doesn't include an "ambient_world" entity*.

 

I realize all release maps should include that, but to bust a map completely if it doesn't? Bit much.

 

 

 

 

Edit: *for those without new ambient and HDR this will work fine.

 

Hey, is that how it´s meant to be? Because I only see that:

 

 

[SiyahParsomen]

I didn't have any problem. What I did is: extracted all files to my darkmod folder. maybe you should give a try in that way legion.

[Diego]

If I understood the technique correctly, this does not affect the light gem, right?