Jump to content
The Dark Mod Forums

Tracker 3881: Cubemap Lighting Beta


Recommended Posts

I have no idea what cubic blendlights are, but parallax-corrected cubemaps in ambientCubicLights would be something practical mappers can actually use, as discussed here:

 

http://forums.thedarkmod.com/topic/19147-parallax-corrected-cubemaps/

 

Link to post
Share on other sites
  • Replies 179
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

Based on Rebb's work to make the Ambient light run it's own light interaction rather than piggy-back on the main light interaction, I have made a patch that allows you to add the "cubicLight" token to

I don't have a lot to add, I have not downloaded the test map, but I tested with my own: I can see very glossy results with the industrial cubemap. No banding, tested with GLSL on and off. Here is the

I thought this would take ten minutes but I ended up spending a good while troubleshooting. Anyway, here is the lamp with a more accurate projection...     The colors are too saturated, details too s

Posted Images

Do you have a test map for this?

For what, spherical falloff on projected lights? I can make one if we're taking the idea forward...

 

I have no idea what cubic blendlights are

Blendlights blend with anything in their volumes using the usual 'blend <src>,<dst>' modes. (Used for effects like the shadow under a moveable candle holder - NHAT has a blendlight tree canopy shadow - or for glares, or as a more flexible alternative to foglights.) So they'd be like that but with cubic protection textures. I'm not actually sure whether there'd be use cases; blendlights are a bit under-explored to begin with.

  • Like 1

Some things I'm repeatedly thinking about...

 

- louder scream when you're dying

Link to post
Share on other sites

Cubic Blendlights might come in handy for faked shadows, though in 2.07\SVN we already have Shadow Maps mostly working.

Still manually defining the occlusion in cube images is cheaper than doing alpha detection in the shadow map.

Might come in handy in some scenes. Thus far, shadow maps are universally cheaper compared to shadow volumes in our current test

cases which is quite unexpected as they are heavier in most other Doom 3 variants where they've been implemented.

  • Like 2

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 post
Share on other sites

Umm...

Is there any bug or feature request I can be useful here? Or is this more like a general discussion?

Duzenko's post earlier in the thread prompting for a concrete feature request has got me thinking. Now, I don't know what the roadmap is since I've no access to the internal dev forums, but ideally, I figure, all this probing around with cubemap lighting options would result in a cubemap lighting system for TDM. Have the particulars of such a system been discussed or outlined before?

 

Here, from my standpoint as a mapper (vis-à-vis a programmer), I'll put forward my idea of how cubemaps could be holistically implemented in TDM maps.

 

The location system in TDM is quite versatile, being able to change custom variables depending on a player's place in the level. Having played around with Obsttorte's fog script, which uses a location settings map object, I think it'd be easy enough to set up one ambientcubemap light and hook it up to an atdm:location_settings, just like we do with ambient_world, then have the cubemap change based on location. This solves the issue of manually placing cubemap lights, though not how and where all these cubemap references would be stored, nor manually taking the envshots (something Epifire's recent thread about spawnargs discusses).

 

I got the idea from observing how Dishonored/UE3 handles cubemaps and their transitions based on player location in the level. It's not quite the same as described here, but it's a close enough approximation. To top it off, DH's cubemaps aren't even parallax corrected, something which several people here would love to have (myself included).

 

Supporting this, or any, implementation of cubemaps would also require that the ambientcubemap lights are robust enough and that we update a bunch of our assets. See, cubemap lights were never really in consideration when some of the assets were made, so you'll come to find a lot of our models having very poor specular maps that do not interact with them well. The grandfather clock, metal studs on armor, paintings, those are just a few I've noticed while testing them out in 2.05.

 

As far as cubic lights are concerned, I still think they're a great addition that just needs proper assets to back up their usefulness. The cubic lampshade that rich_is_bored improved on is a great starting point, we just need more textures(cubemap images). Cubic lights are perfect for faking candle holder shadows, any sort of lantern shadow, torches and so on.

Edited by Spooks

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

 

 

Link to post
Share on other sites

The quoted bit in my post here is along those lines, I think; 'env_cubemap' refers to https://developer.valvesoftware.com/wiki/Env_cubemap

 

Location-based could be one aspect; physical proximity (within a visleaf?) could be another... As Epi's thread notes there's the question of how it's introduced into the material syntax (via spawnargs like in guisurfs? Using a direct keyword so you'd write e.g. 'cameraCubeMap localCubeMap'?).

Some things I'm repeatedly thinking about...

 

- louder scream when you're dying

Link to post
Share on other sites

Please post your test map in the cubemap thread

 

textest.map.txt

 

Per your request, duzenko, here is the map. Remove .txt from the end and compile. Please also create an empty .mtr file in root/materials and put this material definition in:

lights/ambientCube/skybox_desert_day_cube_IRRADIANCETEST
{	
	ambientCubicLight
	{
		// forceHighQuality
		cameraCubeMap	makeIrradiance(env/skyboxes/skybox_desert_day/desert)
		colored
		zeroClamp
	}
}

It's a carbon copy of a pre-existing cubemap light, with the makeIrradiance keyword added. You can remove it if you want to see the change.

 

This is how it looks on my system.

 

post-37271-0-06470000-1510950608_thumb.jpg

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

 

 

Link to post
Share on other sites
The location system in TDM is quite versatile, being able to change custom variables depending on a player's place in the level. Having played around with Obsttorte's fog script, which uses a location settings map object, I think it'd be easy enough to set up one ambientcubemap light and hook it up to an atdm:location_settings, just like we do with ambient_world, then have the cubemap change based on location. This solves the issue of manually placing cubemap lights, though not how and where all these cubemap references would be stored, nor manually taking the envshots (something Epifire's recent thread about spawnargs discusses).

 

This looks like overcomplicating things, why one would want to set up coordinates within location system, while you can manually place multiple ambientCubicLights, exactly where you want them, and set their radius accordingly? What we'd need is to make seamless transition between cubemap reflections as player moves between ambientCubicLights, but that should be done automatically by the engine, just like in the video I posted above (cubemap reflections before parallax correction).

Link to post
Share on other sites

Every properly made FM would have locations implemented already, we'd just be hitching the names and using the fades the location system uses for those seamless transitions. The only problem is that the cubemap light would have to have its light texture changed dynamically in-game, which I've not seen happen (but might be possible through script).

 

The problems with placing ambientCubicLights by hand currently is that they all have spherical falloff and as such you really cannot get transitions other than crossfades. In addition, odd shaped rooms are out of the question, which is not a problem with the location system.

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

 

 

Link to post
Share on other sites

The thing is, that would be helpful for what, some generic cubemaps that are switched per location?

 

If we want to have a proper parallax-corrected system in the future (and I think we do), and proper fake reflections, we'll need to rely on proper placement of ambientCubicLights in the world anyway, and their uniform radius (the same value for xyz). What is more, ambientCubicLight would need to have either some kind of cubemap sampler, or at least a parameter for envshot to be taken in-game, using origin point of such light. Unreal4/Unity5 have reflection probes that create preview in the editor, but as the DR's perspective view rendering is mostly shit, we'd have to rely on some in-game console commands, just like we take envshots now.

  • Like 1
Link to post
Share on other sites

Every properly made FM would have locations implemented already, we'd just be hitching the names and using the fades the location system uses for those seamless transitions. The only problem is that the cubemap light would have to have its light texture changed dynamically in-game, which I've not seen happen (but might be possible through script).

There's a setShader() script event for idLight, but unlike light colour it isn't set up for fading. I can think of ways to fade between two textures in a shader, but not between arbitrary textures/shaders in the current set-up (short of using two lights).

Some things I'm repeatedly thinking about...

 

- louder scream when you're dying

Link to post
Share on other sites

There are internal images (_scratch, _white, _black, _currentRender) created and updated by the engine that you can reference in material shaders. Couple that with some kind of probe entity responsible for capturing the local environment shot and dynamic reflections will be virtually automatic. You scatter a few of these probe entities in your map, link them up in a network, and the game should be able to handle blending between them. All you'd need to make use of the reflections in your materials would be to reference the internal image, say _probe.

  • Like 1
Link to post
Share on other sites

 

Per your request, duzenko, here is the map. Remove .txt from the end and compile. Please also create an empty .mtr file in root/materials and put this material definition in:

lights/ambientCube/skybox_desert_day_cube_IRRADIANCETEST
{	
	ambientCubicLight
	{
		// forceHighQuality
		cameraCubeMap	makeIrradiance(env/skyboxes/skybox_desert_day/desert)
		colored
		zeroClamp
	}
}

It's a carbon copy of a pre-existing cubemap light, with the makeIrradiance keyword added. You can remove it if you want to see the change.

 

This is how it looks on my system.

 

attachicon.giflight.jpg

Thanks

The problem that I can see with your map is no smooth-normal objects.

The way it works now: each object normal serves as cubemap tex coord.

So it you have a single normal across entire wall it will be lit with a single cubemap texel (effectively single color)

See the attached screenshot with a smooth-normal bust (light material uses source cubemap, not irradiance in this example)

No idea why the light is being clipped when looking from spawn point - I don't think it related to cubic lights.

If you want reflections, try the lightFalloffCubeMap keyword.

post-3508-0-62766900-1511030107_thumb.jpg

Link to post
Share on other sites

Hello, I wanted to mention that I tried to insert the lightFalloffCubeMap keyword everywhere in the material last week, with little success. I also tried the makeAmbientMap console command yesterday, which works (!) but has a bunch of new parameters not present with envshot. Would be nice to have some documentation on both of those at some point in the future, probably not right away as the ambient cubemap light conversion to IBL seems to be WIP still.

 

I have listed the light clipping issue on Mantis: http://bugs.thedarkmod.com/view.php?id=4683

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

 

 

Link to post
Share on other sites

I mean more that the way lights usually taper off is not present, hence the 'falloff' is missing. By all means you can rename the issue on the tracker for more clarity.

 

From the name I expected some specular highlights to appear, which did not happen. Then again, that was last week before the bugfix for bug 4673 was applied. I can test this keyword again but an example material definition with it would be appreciated.

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

 

 

Link to post
Share on other sites
  • 1 year later...

Let's talk about our 'standard' cubic lights

 

VanishedOne has brought to my attention that e.g. lights/ambientCube/skybox_industrial_01_cube is broken - as I'm sure many if not all other ambient cubic lights

 

http://bugs.thedarkmod.com/view.php?id=4902

 

Can anyone explain what that light supposed to look like?

 

The ARB2 version looks like a fake reflection but somehow the books and the statue in the test map don't get affected by it.

Link to post
Share on other sites

The ARB2 version looks like a fake reflection but somehow the books and the statue in the test map don't get affected by it.

Based on a quick test with "nospecular" "1" I think that's probably related to specularity. The ARB2 cubelight shaders have a rather overpowered specular: it tends to make metals, etc. look as if they're glowing in the dark compared to everything else.

Edited by VanishedOne

Some things I'm repeatedly thinking about...

 

- louder scream when you're dying

Link to post
Share on other sites

Based on a quick test with "nospecular" "1" I think that's probably related to specularity. The ARB2 cubelight shaders have a rather overpowered specular: it tends to make metals, etc. look as if they're glowing in the dark compared to everything else.

Right

 

So what's the desired effect of the ambient cubic light with that industrial texture?

Link to post
Share on other sites

I think there is still some conflation or confusion here:

 

Clarifications:

 

1) Cubic lights are supposed to be just normal lights with a cubic projection image and spherical falloff

2) In 2.07 I believe we normalized \ fixed the brightness of the ARB version to match the GLSL version

3) The specular formula in the ARB version is a little different than the GLSL version where it better matches standard lights

 

4) Ambient cube lights are meant to be used for a Global Illumination effect (Irradiance volumes)

5) They can take AMD precompiled Irradiance images but you can also use the makeIrradiance keyword to convert standard cubemaps

6) makeIrradiance seems to work OK but it still a little too inclined to produce specular

 

7) ARB ambient cube map shaders also have some strange behavior where specular can be too representative of a reflection.

(This may verge into a discussion about using PBR materials to control these issues)

 

8) There is probably some overlap between ambient cubemap and the discussion about parallax corrected cubemaps

9) Yes, ideally, Ambient Cubemap would have nearly the same utility as Valve's Irradiance volume \ Precomputed Radiance Transfer approach

  • Like 2

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 post
Share on other sites

I don't have a lot to add, I have not downloaded the test map, but I tested with my own: I can see very glossy results with the industrial cubemap. No banding, tested with GLSL on and off. Here is the kicker though, it's very much like you said, nbhor1more, you need the makeIrradiance keyword for the current version of the ambient cubic lights. It's just that seemingly none of the stock cubelights on offer have that keyword in their materials. While I can't say whether or not the banding VanishedOne shows in the bugtracker is not indicative of a bug, first order of business is fixing our materials to match the purpose of the lights, methinks.

 

On the flipside, here's something nice. I used envshot in the process of testing and it works fine! No need to resize the window and it doesn't capture the console anymore. I don't have a skybox in the map so I don't know if that's still a problem, but if it is, it's one for another thread and not this one.

  • Like 3

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

 

 

Link to post
Share on other sites

Double post, here's something else. I think we all tacitly know that the current state of the ambient lights is just a proof of concept and they will only be usable once development comes around to implementing automatic envshot taking and some sort of probing entity in the editor. Then, the irradiance maps would be generated by the engine.

 

Related to this, and for right now, I've a problem with makeIrradiance. I don't know how it works (and if it was posted here I have forgotten about it) but really looks like there is no directionality to the lights (which is to say they don't get affected by the normals), it's like the cubemaps are reduced to 2x2 or something when using the keyword. It's functionally indistinguishable from an ambient light in that regard. Conversely, even a 64x64 envmap with gradients from photoshop looks better without the makeIrradiance keyword although, yes, it seems to blow up the specularity for no apparent reason.

 

e: skipspecular 0 on the light or r_skipspecular in the console don't seem to remove the ambientcubemap's glossiness at all.

e2: the texture being made glossy doesn't even have a specular map, so yeah. definitely something wrong with the implementation.

edit 3: here have some screenshots

 

unknown.pngunknown.png?width=545&height=657

 

An ambientCubeLight on a test normalmap, no specularmap without makeIrradiance and with, respectively. Note the differences. At places where the normal map is flat, you can see banding, which MIGHT be the banding VanishedOne is seeing.

Edited by Spooks
  • Like 2

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

 

 

Link to post
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.


×
×
  • Create New...