Jump to content
The Dark Mod Forums

Tracker 3881: Cubemap Lighting Beta


nbohr1more

Recommended Posts

I've encountered a bug in the projected cubelight implementation: I made a cubic spotlight parallel with the ground, and it insisted on trying to draw outside its bounding box, apparently at constant (moderate) brightness. Setting "falloff" "1" and un-uncommenting zeroClamp didn't help.

 

(Right is omni cubegrate6; next is projected cubegrate6; left is a projected, non-cubic lanternbot spotlight. The omni cubelight has a nice rounded falloff compared to the ordinary projected light.)

post-35144-0-51399100-1510504357_thumb.jpg

 

Standard id Tech 4 omni lights project a texture along an axis like a stick of rock; they're 'point' lights for shadows/bump mapping, but when it comes to placing one in a map it's more like a column of illumination, usually with a falloff to hide the fact it isn't a sphere. (That's why people earlier in the thread are getting excited about cubelight lamps that don't project their textures like this.) Projected lights are more like a pyramid with a point and a wide end.

 

Something that projected lights can do and I don't know how to reproduce with omni cubelights is that projected lights can start their outward projection at a distance from the light origin instead of projecting right from a point:

 

(Far is projected non-cubic; middle is projected cubic; near is cubic omni.)

post-35144-0-05764800-1510503040_thumb.jpg

 

As for technical details, we'd need nbohr1more to comment. (In particular I'm not sure whether the angle/width of a projected cubelight has anything to do with the 'FOV' of the projection, so to speak.)

Some things I'm repeatedly thinking about...

 

- louder scream when you're dying

Link to comment
Share on other sites

I'm confused if we're talking about ambient or interaction lights here.

We have separate GPU programs for these: interaction and ambientInteraction.

I assume it's interaction light? It sounds like you want a falloff texture on your cubic light with a project-like cubemap.

I can add that but can you provide a test map and assets for testing?

Link to comment
Share on other sites

I'd be interested to hear any other people's opinions first, but my current thinking is that the option of using spherical falloff on projected lights would be nice to have. Projected lights are pretty handy if you want something like a spotlight: you can project a texture onto an arbitrary quadrilateral, from an arbitrary starting distance, just by dragging points around in DR. But they fall off to a noticeably straight edge.

 

And yes, those are non-ambient lights. (I don't know whether anyone has found a use for projected ambient lights in maps...)

Some things I'm repeatedly thinking about...

 

- louder scream when you're dying

Link to comment
Share on other sites

I'd be interested to hear any other people's opinions first, but my current thinking is that the option of using spherical falloff on projected lights would be nice to have. Projected lights are pretty handy if you want something like a spotlight: you can project a texture onto an arbitrary quadrilateral, from an arbitrary starting distance, just by dragging points around in DR. But they fall off to a noticeably straight edge.

 

And yes, those are non-ambient lights. (I don't know whether anyone has found a use for projected ambient lights in maps...)

Tell you the truth I am looking for opportunities to lose as many textures as possible for performance reason.

What do you think about having a formula falloff instead of texture.

E.g. falloff = 1/(1+distance^2);

Witch1.gif

Link to comment
Share on other sites

Apologies for taking some time to get involved in the discussion, due to some misapplication of terms.

 

 

I tried to get a side-by-side comparison with the regular grate6, but TDM either refused to load the map ('ERROR: Image 'lights/grate6' has been referenced with conflicting cube map states') or outright crashed. (Shall I file a separate tracker issue for that?) So here all three lights have been changed to projected, non-cubic grate6:

 

 

I don't think a bugtracker's needed, the error is normal as normal (pointLight) lightdefs need a 2d projection texture, the light definition will simply not accept an image that's part of a cubemap/a cubemap material in the "map" field.

 

Then wait for next beta

BTW how projected lights are technically different from point lights? Can't you bake projection in the light cubemap?

 

I think it's important to get the terminology right, here. There's two types of lights in-editor - Omni and Projected. Five types of light definitions (by keyword) - fog light, point light, ambient light and then our two (at least there were only two last time I checked), new ones - ambientcube and cubic. All of those could be set to either be Omni or Projected.

 

I don't know, then, exactly what you're asking. If you're asking what the difference between Omni and Projected is -- an omni light is basically two projected lights glued back to back. A lot of information concerning falloff and the cheese-slice method these lights use is available on the wiki, and in nbohr1more's avatar (if one squints hard enough). Point lights use 2D projection textures, this use of "projection" should not be confused with the "Projected" light type.

 

 

 

I'd be interested to hear any other people's opinions first, but my current thinking is that the option of using spherical falloff on projected lights would be nice to have. Projected lights are pretty handy if you want something like a spotlight: you can project a texture onto an arbitrary quadrilateral, from an arbitrary starting distance, just by dragging points around in DR. But they fall off to a noticeably straight edge.

 

And yes, those are non-ambient lights. (I don't know whether anyone has found a use for projected ambient lights in maps...)

 

Projected lights have a hard cutoff because their shaders oftentimes don't have good falloff images (or ones optimized to work for proj. lights). Check out the lanternbot light to see a light definition with good falloff (it's basically biground1 used as a falloff, but it does the trick). Dragofer's hand lantern uses a falloff like that to ensure a smooth fade.

 

As such, I don't know if an algorithm will be needed, yet I must admit that it falls on the mapper's shoulders to properly update any light definitions they wish to use with Projected lights. It's a burden, yes, but it is also more control in the hands of the mapper.

 

As an side note, I'm still musing over more falloff methods for cubic lights. Last time we talked about this, only spherical falloff was there.

 

 

To nbohr1more, I want to say that I still haven't had a chance to setup a test environment for lights in the 2.06 beta. A large part of it is I still fear that artifacting bug I showed earlier in the thread is present and there's nothing I can do about it (thanks, Nvidia). Then again, if a bunch of stuff has been moved over to GLSL, it might have disappeared. I'll post when I have something to report.

 

My FMs: The King of Diamonds (2016) | Visit my Mapbook thread sometimes! | Read my tutorial on Image-Based Lighting Workflows for TDM!

 

 

Link to comment
Share on other sites

The latest Nvidia drivers should fix those bugs along with Sikkmod's HDR.

For Windows 10 you need the Fall Creator's Update for them to work properly.

I haven't heard of any problems with Win7/8 ?

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

I think it's important to get the terminology right, here. There's two types of lights in-editor - Omni and Projected. Five types of light definitions (by keyword) - fog light, point light, ambient light and then our two (at least there were only two last time I checked), new ones - ambientcube and cubic. All of those could be set to either be Omni or Projected.

 

I don't know, then, exactly what you're asking. If you're asking what the difference between Omni and Projected is -- an omni light is basically two projected lights glued back to back. A lot of information concerning falloff and the cheese-slice method these lights use is available on the wiki, and in nbohr1more's avatar (if one squints hard enough). Point lights use 2D projection textures, this use of "projection" should not be confused with the "Projected" light type.

How do you set a light to be Omni or Projected?

From my point of view, there are two light shaders: ambient and point.

Point shader takes has a position and can cast shadows.

Ambient does not.

Each of the two can be cubic or "2d". The latter one takes two 2d textures for falloff and projection.

I still don't see where Projected fits here.

Link to comment
Share on other sites

As I'm aware, projected lights are a pyramid whereas point lights are a cube.

 

They both use the 1D + 2D projection image \ falloff image setup but projected lights only radiate towards one vector:

 

https://www.iddevnet.com/doom3/editor_light.php

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

How do you set a light to be Omni or Projected?

 

In DR? Select a light, press L for light properties, and the option is there.

 

To make fine adjustments to a selected projected light, press V for vertex mode and you can select the control points and drag them. (This also works on omni lights but the only available control point is the light centre: some TDM lights, like fireplace flames, oscillate it at runtime to make shadows bounce. Omni lights are mostly manipulated in DR by resizing the bounding box.)

 

I don't think a bugtracker's needed, the error is normal as normal (pointLight) lightdefs need a 2d projection texture, the light definition will simply not accept an image that's part of a cubemap/a cubemap material in the "map" field.

grate6 and cubegrate6 both work individually; what failed was placing them in the same map. My hunch from the error message was that the engine expects lights/grate6 to point to either lights/grate6.tga or six image files with suffixes like _pz, etc. and can't handle cases where both need loading as lights/grate6 and map versus cubeMap/cameraCubeMap determines which applies. Still, as bugs go it's an avoidable niche case.

 

Projected lights have a hard cutoff because their shaders oftentimes don't have good falloff images (or ones optimized to work for proj. lights). Check out the lanternbot light to see a light definition with good falloff (it's basically biground1 used as a falloff, but it does the trick). Dragofer's hand lantern uses a falloff like that to ensure a smooth fade.

 

Top image, left-hand light in this post is the lanternbot spotlight. There's some falloff there, but it's clearly to a straight edge compared to the cubelight on the right. (Since falloff images are effectively 1D.)

 

Five types of light definitions (by keyword) - fog light, point light, ambient light and then our two (at least there were only two last time I checked), new ones - ambientcube and cubic. All of those could be set to either be Omni or Projected.

Also blend lights.

 

Tell you the truth I am looking for opportunities to lose as many textures as possible for performance reason.

What do you think about having a formula falloff instead of texture.

E.g. falloff = 1/(1+distance^2);

Witch1.gif

 

Formulae could be good as an option. Have you seen the _quadratic internal image? It's useful in making light flares:

textures/darkmod/sfx/flare_quadratic
{

	//sort far
	noShadows
	translucent
	nonsolid
	deform	flare	13 + sintable[time*0.2]
	qer_editorimage	textures/darkmod/sfx/candleglow.tga

	{
		blend 		add
		map 		_quadratic
		
		red		0.3 //* sintable[time*0.1]
		green		0.3 //* sintable[time*0.1]
		blue		0.2 //* sintable[time*0.1]
	}


}

Edit: _noFalloff is also an internal image, used as the falloff image by lights/defaultProjectedLight.

Edited by VanishedOne

Some things I'm repeatedly thinking about...

 

- louder scream when you're dying

Link to comment
Share on other sites

No, DR is all Chinese to me.

I mean the result flags in the material file.

Omni/projected lights aren't distinguished in material defs. (Before cubic lights were introduced it was safe to assume any light material could be used with either light type. You can even make projected foglights if for some bizarre reason you want a pyramid of fog.) They have different entity spawnargs in map files.

 

Basic omni light:

{
"classname" "light"
"name" "light_1"
"origin" "0 0 0"
"light_center" "0 0 0"
"light_radius" "320 320 320"
}

Basic projected light:

{
"classname" "light"
"name" "light_1"
"origin" "0 0 0"
"_color" "1.000 1.000 1.000"
"light_right" "128 0 0"
"light_target" "0 0 -256"
"light_up" "0 128 0"
}

Basic projected light with defined starting distance:

{
"classname" "light"
"name" "light_1"
"origin" "0 0 0"
"_color" "1.000 1.000 1.000"
"light_right" "128 0 0"
"light_target" "0 0 -256"
"light_up" "0 128 0"
"light_end" "0 0 -256"
"light_start" "0 0 -64"
}
  • Like 1

Some things I'm repeatedly thinking about...

 

- louder scream when you're dying

Link to comment
Share on other sites

Sikkmod's original implementation included both types since it wasn't possible to branch based on a material flag

without a source code mod to the renderer. This was also done to let mappers re-use their projections rather than

needing to create two sets of projection images.

 

With TDM, we can mix both standard 1D+2D lights with cubic lights so projected cubic lights are an open question.

If the current projected form just uses the bottom image then it's really redundant.

 

Sorta tangential is Duzenko's proposal for falloff behavior. We cannot replace all falloff Image textures in standard lights

with an equation since no equation would account for all custom falloff behaviors and such a replacement would break

existing maps. We can, however, offer a new light type that has a math based falloff and doing so might also make it

easier to convert part of the renderer to a forward+ architecture. All lights with math based falloff get rendered forward+ style (etc).

At the very least it would reduce texture access operations so that would be handy to have. Doing this for the "projected"

cubic light would be a good fit but it would be a bit wasteful since you'd be loading all those extraneous cube images at map start.

  • Like 1

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

Haven't used those yet, but shouldn't cubic lights be omni-only by default?

 

 

Well, that's what's under discussion. I suggested that spherical falloff, which the cubelights can have, could be a good option for projected lights.

 

As far as I could tell from a quick test, the projected cubelights that exist in ARB don't change the 'field of view' from 'inside' the cube when the projection gets wider, so the projection texture works in practice like a regular projected light's. Which is probably what you want from a spotlight or similar.

Edited by VanishedOne

Some things I'm repeatedly thinking about...

 

- louder scream when you're dying

Link to comment
Share on other sites

Now I think we're on the same page in terms of point/projected lights.

Now looking in the backend render code I can see that arb2 path uses separate GPU programs for point and projection, but cubic only.

GLSL path makes no distinction at all.

Are we talking about cubic projected or "regular" projected lights?

Also how do we call the "regular" lights (e.g. not cubic)?

Link to comment
Share on other sites

The image above is cubic omni light (left) vs cubic projected light (right). That's cubicLight. (Although maybe we should start using Omni/Spot convention, as lights with textures or cubemaps are technically projected lights, right? So we can avoid "projected omni" vs "projected projected" which is confusing).

 

But, as I just found out, another cubic light type was also added, called ambientCubicLight. It seems like it... projects a cubemap reflection onto surfaces? (without parallax correction, mind you). Not sure why would you ever need that...?

Edited by Judith
Link to comment
Share on other sites

AmbientCubicLight is an approximation of HL2's IBL \ Precomputed Irradiance Transfer solution.

 

It uses Irradiance images in the same format as AMD's cubemapgen program but you can also convert standard images via an image program in the material

 


lights/mountain_sunset
{    
    ambientCubicLight
    lightFalloffCubeMap env/skyboxes/skybox_mountain_sunset/mountain_sunset
    {
        cameraCubeMap makeIrradiance(env/skyboxes/skybox_mountain_sunset/mountain_sunset)
        colored
        zeroClamp
    }
}

Sikkpin's original Doom 3 version:

 

cubic11.jpg

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

The image above is cubic omni light (left) vs cubic projected light (right). That's cubicLight. (Although maybe we should start using Omni/Spot convention, as lights with textures or cubemaps are technically projected lights, right?

In that technical sense I suppose even ambient lights are projected lights. :unsure:

Some things I'm repeatedly thinking about...

 

- louder scream when you're dying

Link to comment
Share on other sites

Sense of clarity for mappers is more important IMO. Good old Unreal got it right: Omni, Spot and Ambient were the main light types. Then you could make them projected, noshadows etc with properties. Here we have light types defined both by two shapes and different types of light materials, which is confusing. Same goes for calling Spots 'Projected'.

 

Edit: cubicLight seem to have spherical falloff by default, although I'm not sure where it's defined. I think having noFalloff option for cubicLights is a good thing, if e.g. you want to use them for fake lightmaps, where you need to adjust the size of the light to match the room.

Edited by Judith
Link to comment
Share on other sites

It's arguable that sources like https://www.iddevnet.com/doom3/editor_light.php got it wrong, but here we are. :mellow:

 

Edit: cubicLight seem to have spherical falloff by default, although I'm not sure where it's defined. I think having noFalloff option for cubicLights is a good thing, if e.g. you want to use them for fake lightmaps, where you need to adjust the size of the light to match the room.

 

 

You can't set a falloff Image in the material but you can add a "falloff" "0" argument for the light entity. That, however, is what triggers the HL2 style shading.

That was about an earlier version of the ARB shaders, though, so I may be quoting incomplete or out-of-date information. There now appears to be something called lightFalloffCubeMap but I don't think this stuff is documented yet.

Edited by VanishedOne
  • Like 1

Some things I'm repeatedly thinking about...

 

- louder scream when you're dying

Link to comment
Share on other sites

I'm not saying that ID got it wrong, but having Projected Lights with texture projections is a bit unfortunate. The same goes for Unreal's Directional Lights, which are not spots, neither omni... Mostly just broken :P

 

Anywhoo, it just came to me that ambientCubicLight could actually be useful, if they were parallax-corrected and used with some kind of cubemap sampling option. If you could place a few of those over reflective floor e.g. in a corridor, and you could render cubemaps for where such lights were placed, you could have really nice mirror-like fake reflections. I believe we discussed that elsewhere already.

 

Edit: yes we did: http://forums.thedarkmod.com/topic/19147-parallax-corrected-cubemaps/

Edited by Judith
Link to comment
Share on other sites

Ah, dangerous question: it encourages us to dream up proposals for, say, cubic blendlights. Or cubic foglights. (I'm not serious about that one; although apparently ET:QW used hemispheric fog, so who knows...?)

 

In seriousness, let's say that if there's anything left (spherical falloff?) once we're done pondering projected cubelights, then let's make a tracker entry.

  • Like 1

Some things I'm repeatedly thinking about...

 

- louder scream when you're dying

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recent Status Updates

    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 4 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
    • nbohr1more

      Please vote in the 15th Anniversary Contest Theme Poll
       
      · 0 replies
×
×
  • Create New...