Light baking

[nbohr1more]

This looks amazing! It does work with HDR but doesn't work with the new ambient nor with the texture brightness method.

 

I haven't gone through all the posts made here. So I don't have any grasp over this. I'd appreciate if someone points me to few informative posts or even wiki that explains how this works.

 

Doom 3 amazes me all the time with the stuff like this. Judging from the old materials similar to the one used in the map above, there seems to be some tests id made back when they were working on D3.

 

It'd be cool if it can be combined with some image space lighting, so that the static geometry and characters can have environment's reflection, similar to the new ambient lighting (see this image for example).

 

Maybe a blend light that projects a cubemap of the environment lighting? The problem is that the falloff Image is essentially one dimensional but it might still look better that the current lighting model???

[nbohr1more]

Nope.

 

That would make all the surfaces react to directional view ... It might be neat for some sort of projected material effect but that can be accomplished by regular material shaders. Actually you could do a crude angle based AO by setting the cubemap center view bright and the off panels gradient to dark.

 

What you would need to do is create a cubemap of the space then cut it into all six directions then project them with six "projected ambient lights" (ugh.. there goes performance... it might not be too bad???)

 

(Maybe some merit to this after all...? )

 

http://www.doom3worl...pic.php?p=25180

 

(I see that I may be confusing cubemap and cameracubemap behavior... hrmm... )

Edited September 1, 2010 by nbohr1more

[Mortem Desino]

If that's the effect you want, you don't have to overthink so much. There are grime decals available that easily emulate that.

[nbohr1more]

My apologies for the poor communication Mortem.

 

I jumped from a blendlight method back to a regular ambient light method without properly conveying the distinction.

 

My last example was more of a return to the Strombine type method rather than a faked shadow blendlight method.

 

Last example:

 

What you would need to do is create a cubemap of the space then cut it into all six directions then project them with six "projected ambient lights" (ugh.. there goes performance... it might not be too bad???)

 

(Just in case this thread wasn't already filled with too many tangents... )

 

While buzzing around the net looking for related information I stumbled into yet another light baking method:

 

Deluxe Map?

 

Another reference?

Edited August 31, 2010 by nbohr1more

[nbohr1more]

Looks like I'm late to the party (as usual) with cubemap based Radiosity in Doom 3:

 

http://www.doom3worl...ght=ambient+vfp

 

(some discussion claims that a cubemap cannot be used as an input, yet der_ton's demo does just that... I wonder if this has been revisted by anyone?)

Edited August 31, 2010 by nbohr1more

[Baddcog]

Only 5 1/2 years. Fashionable?

[nbohr1more]

Yep. I'm still catching up.

 

Beyond3d stopped referencing Doom3world 5 seconds after the game was released so there's a lot of stuff that I'm only discovering now. (Those Beyond3d folk are so fickle and trendy ...)

[Mortem Desino]

Oh, you and your magical cubemaps...

 

But I think I see now: you want pseudo-volumetric AO in your room by using a cube of blend-blend lights?

[nbohr1more]

That would be kinda cool (and was one of my conjectures). A Strombine style projection of a negative blendlight would do that for the most part but a cubemap might be able to make the effect angle dependent...?

 

My primary motivation was to help Bikerdude with his quest for light maps. The Strombine method is the closest that we can achieve (AFAIK) without Blender models. (I just have to finish the wiki for him). So all this remaining stuff is me coming to the realization that the Blendlight functionality can be used for some weird ideas. Then I remembered that Cubemaps were used in some Radiance methods and found stuff like this:

 

http://www.mpi-inf.m...uctureForGI.pdf

 

So now we're in Holy Grail territory. But as I expected, a lot of this ground has been covered in the hallowed halls of Doom3world.

 

Still... I think we might be able to project a cubemap throughout a room somehow and fake a 3d light texture. If the light can be made to project in reverse from a surface to a central point?

Edited September 1, 2010 by nbohr1more

[rich_is_bored]

That demo that der_ton cooked up was something he did using his model viewer. What you see there isn't applicable to Doom 3 until the source is released.

 

As for makeambient, i've never played with it.

[nbohr1more]

Thanks again for the clarifications Rich.

[nbohr1more]

Still... I think we might be able to project a cubemap throughout a room somehow and fake a 3d light texture. If the light can be made to project in reverse from a surface to a central point?

 

Hah!

 

We wouldn't have to!

 

1) Ambient lights pass through geometry so they do not occlude

2) Ambient lights have non-directional bump

3) Falloff Image can occlude the source and intensify the projection

 

So a cubemap of the environment with extra light bounces could be broken into projection images for a projected ambient with a reverse (from origin) Falloff Image for a bland image-space solution.

 

Coupled with some good local lights and the new dynamic ambient(?) it could look pretty nice... It would be neat if the normals and specular could be influenced from the correct direction but the direct lighting should add enough of that effect to overwhelm it's absence in the image-space ambient.

 

All that's missing is a way to easily position the projections.

 

I suppose you could put some object right where you want the lights to project from then noclip into it and collect the envshot... still pretty fiddly... it'd be cool if it could be automated...

 

Hrmm... A prefab with 6 projected ambients would speed the process...

Edited September 6, 2010 by nbohr1more

[nbohr1more]

Aside from the positioning concerns, the image editor work to capture just the lighting is a bit of a hassle.

 

In a perfect world envshot would have a parameter to exclude everything except lights. So this would likely require re-texturing to everything to flat colored textures prior to envshot capture or heavily editing contrast in Gimp...

[nbohr1more]

The first conceptual illustrations I've created in GIMP.

 

 

 

Edited September 8, 2010 by nbohr1more

[rich_is_bored]

In a perfect world envshot would have a parameter to exclude everything except lights. So this would likely require re-texturing to everything to flat colored textures prior to envshot capture or heavily editing contrast in Gimp...

 

Make a flat grey material like this...

 

textures/clayrender
{
 {
   blend diffusemap
   map _white
   rgb 0.5
 }
}

 

Then when you want to capture the lighting in a scene use this command first...

 

materialoverride "textures/clayrender"

 

Then do your envshot.

 

Then restore the original textures using ...

 

materialoverride ""

Edited September 9, 2010 by rich_is_bored

[Tels]

Make a flat grey material like this...

 

textures/clayrender
{
 {
   blend diffusemap
   map _white
   rgb 0.5
 }
}

 

Then when you want to capture the lighting in a scene use this command first...

 

materialoverride "textures/clayrender"

 

Then do your envshot.

 

Then restore the original textures using ...

 

materialoverride ""

 

Hm, can the env shot captured to a texture automatically?

[nbohr1more]

You're thinking of something similar to render-to-texture maybe?

 

I know have an old quote from Brian (id) that seems to indicate that envshot can be automated via SDK

 

"You should be able to implement an 'env_cubemap' pretty easily in the code. Take a look at idObjective::Event_CamShot. This is the function that's used to generate the objective screenshot used in that little tooltip window that pops up when you get a new objective. Those screenshots are generated as soon as the map loads."

[nbohr1more]

Sikkpin claims to have found a way to activate the use of Cubemaps with lights!!!!

 

Also, 3D light attenuation!!!!

 

 

http://www.doom3worl...&sd=a&start=520

 

 

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

 

(I'm trying not to get too excited... This will be a monster if true!!!!!! )

 

Chester Copperpot quotes "I have found the key to One-Eyed Willy" ...

 

 

Edit:

 

He has a picture of it working! (my workplace filter stripped it out)

Edited December 26, 2010 by nbohr1more

[nbohr1more]

Back to the old Strombine technique:

 

I went over and over the various ways that the Falloff Image affects the projection and had a small epiphany.

 

Rather than think of the Z-Projection texture and Falloff Image as artistic canvases that you must conceptualize to paint you volumes correctly, why not view them as "limited" XYZ data structures and devise a way to encode as much of a 3D texture into the available axis resolution for that structure. Then supplement the missing axis resolution via another complimentary projection.

 

That was when I thought that the Falloff Image can produce X shaped elements via a single pixel in the 2D image map. I worked out an imagined sequence where 2 complementary grids of falloff images pixels were modulated by two z projection images.

 

I am now more certain that Falloff Images can only relay 1D information. I have no idea what is done with any divergent data on the other axis but for now we will leave that as a frustrating factoid.

 

 

So... how can we get something akin to that design with the even further limited "1D" nature of the Falloff Image.

 

 

1) Get (Top View) Ortho-View shots of all the vertical levels in your map

2) Note where lights are oriented such that they are in the same (or near same) location in between two or more distinct levels on the same side or sides of all the affected levels

3) Once you have the highest count for light overlaps, create a z-projection texture that approximates the ambient radiance of each light noted light. Typically, this would be all lights on the left, right or middle exclusively.

4) Tricky part, create a Falloff Image that masks vertical levels that do not have light on side or location that is exposed in the z-projection from step 3

5) Do the same for the lights located on the opposite side (etc)

 

The trick is that each z-projection may brighten areas that overlap the other so in some cases the brightness of one or another (or both) may need to modified where overlaps occur and act in a complimentary fashion.

 

Ideally (pipe-dream?) you would have a tool that could analyze and distribute the light data between as many needed light volumes to reasonably illuminate an area and bake the projection images along with specifying the needed number and size of volumes. And as a bonus, you could specify less than ideal numbers (like only 2 volumes) where the result would be sloppy but would get the job done better than a flat ambient illumination.

 

This method could surmount the problem of butting light volumes against each other at the expense of higher light counts but should still be (in many cases) less expensive than lots of small ambient lights all over the place.

[nbohr1more]

OK!

 

Now we are rockin'

 

 

lights/ne_sunlight

{

{

	forceHighQuality
map lights/blur_cv.tga
zeroClamp
colored

}

{

	forceHighQuality
map lights/blur_cv.tga
zeroClamp

	colored

}

}

 

 

 

 

Above you can see two stages inside the same light.

 

I thought that was possible...

 

So:

 

1) Create your 3D Texture "Volume Light Map" in some unspecified 3D application

2) Cut it into 2D slices

3) (optional) Combine slices that run parallel illumination (as above)

4) Create sets of masking 1D falloff images

5) (optional) again optimize by combining falloff's where applicable

6) create a texture atlas or texture sheet which contains all the frames

7) create a material as above which contains multiple falloffs and image projection maps which are scaled from positions in the same texture atlas...

 

Obviously this would gobble-up texture memory but you would usually use a low resolution map anyway (at least this is the industry standard use... no worse the other games that use 3D textures for an ambient map).

 

So... can "scale" be used to isolate texture segments in light shaders the same way as it works for standard materials?

[Tels]

OK!

 

Now we are rockin'

 

Sometimes I worry for your health

 

So... can "scale" be used to isolate texture segments in light shaders the same way as it works for standard materials?

 

I think you mean "scale + translate" here?

[nbohr1more]

You are correct.

 

I wasn't sure if "translate" can only work for animations...

[nbohr1more]

More mistakes.

 

So, first I was wrong about the possibility of more than one falloff Image per material. I swore I saw it plain as day but it must've been a fever dream.

 

Next, to try and wiggle out of this, I have been trying without success to invoke a shader program from withing a light material. The fact that this is NOT IGNORED by Doom 3 means it's not impossible but it appears that the drivers don't like this action at all. Though, I've been using HeatHaze.vfp as my program... may something simpler or more akin to the light interaction (as intended) would work...

 

Final conceptual mistake?

 

Baring some breakthrough to re-paint the volumes with new falloff images in the same light pass, projecting large Strombine style ambient volumes over each other is not necessarily the best we can do performance-wise.

???

 

Instead, small rectangular solid projections that are only slightly larger than the wall or surface they hit might possibly be a closer ideal. You could conceptualize the projection the same way but then cut it into volumes as it hits geometry. I am not to happy with this approach as it resembles a UV style light map where the light details are constrained to the surface of the world geometry verses the Volume Light Map approach that affects all objects (including dynamic items, AI, etc) realistically. This also adds another layer of scale+translate complexity and would likely require new falloff Images for each volume

 

 

This did get me thinking about the original approach another way... Have SEED control the big volume projections such that overall projections can be toggled in scenes where they do not exhibit significant artifacts. Though this would only be practical for large enough volumes to not require any cross-fade hijinks over the visibility span.

 

 

So I think I've cornered all the possible avenues here. I have programmer over at Quake3world interested in solving the 3D texture to 1D+2D projection reduction set problem so an automated Strombine method might yet appear.

 

The last questions are:

 

Is there any way at all to get either Doom 3 or the ATI\Nvidia drivers to call an ARB shader program from within a light material? Could it be made to work by careful instruction order (footwork) in the Interaction.vfp?

 

(If so, the multi-paint method might be in the cards)

 

Can you just make the whole damn Interaction.vfp point to one 3D texture and bias ALL lights by it?

 

AKA is there a way to tell the Fragment Programs to access data other than what is fed via the material system?

 

 

(Worse case scenario: Feed every value via inline values in the actual shaders themselves... ) ?

[nbohr1more]

Thought of another way...

 

I don't like it though...

 

1) Create a distance marker somewhere on the map (tracked via SEED)

2) Create a table that has scale and translate values that decode a 2D texture atlas in a similar fashion to a UV map

3) Create a material stage that uses a SEED distance Parm and values from the table in step 2 to scale and translate to the part of the atlas that corresponds to the distance to the marker

 

It's essentially like creating your own UV manager in the engine.

 

Downsides:

 

1) Lots of CPU overhead? (unless static scale and translate decode is done at map load?)

2) Would require a tool to covert UV coordinates to Doom 3 friendly scale and translate values

3) As I've said before, I don't like 2D light maps with Doom 3, it's a volumetric engine.

 

(3D Light maps = 2D Light maps = )

Edited May 16, 2011 by nbohr1more