Spooks
-
Posts
612 -
Joined
-
Last visited
-
Days Won
38
Posts posted by Spooks
-
-
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.
-
AmbientCubic lights use a new irradiance method. I tried to advocate for as little variance from 2.05 as possible but Duzenko wanted a conceptual justification
for this type of light so I had to offer industry examples and he settled on something that there is documentation and tool workflows for. The current system works
best if you pre-bake the irradiance cube images in AMD's cubemap gen but we do have new makeIrradiance image programs to mostly cover that (doesn't look quite as good).
I've tried the makeIrradiance keyword since I didn't want to stitch together a proper cubemap to load in AMD's cubemapgen. The result was the light just becoming brighter (which I suppose is normal with how irradiance maps work) and the rectangular, no falloff behavior remaining. Is this just something that works in SVN but not in the beta branch?
-
r_useGLSL doesn't affect this, r_fboSharedDepth is set to 0. r_useFBO 0, however, makes the graphical glitch disappear, so nbhor1more hit the bullseye on that one.
Will proceed to file the cubemap issue to the tracker.
EDIT: Can someone elevate my privileges on Mantis, please? I wish to be able to assign relationships or tag these bugs correctly as 2.06 and not SVN at least.
-
@VanishedOne and Spooks:
Are some of the cubicLight problems being seen for projected lights?
As I recall, only "point lights" were implemented in GLSL. (After much begging...)
We weren't aware of any real compelling use case for projected lights with cubemaps so it
wasn't worth the battle at the time. If you really need projected cubicLights, I'll go back and
argue the case to Duzenko.
To finally answer the question, no and yes.
Omni cubic lights work as intended.
Projected (spotlight) cubic lights straight up don't work, there is a very tiny spot of light somewhere in their radius, which supports what you said, that there implementation simply isn't there. As far as I'm concerned -- and as it was stated in the other thread -- there's really no point to having a spotlight cubic light if it just projects the bottom part of the cubemap, so I'm not too fussed about this.
Both Omni and Projected (spotlight) ambientcubic lights exhibit the same problem - they're fullbright and rectangular. As I understand it there's an effort to integrate IBL so I assume they're broken because of that? I have several of these in my WIP but they are replaceable and I've not seen them used anywhere in new FMs, so 2.06 could possibly ship with them in this broken state.
I want to point something else important about the glprogs: a bunch of the interactions seem broken.
Here is a custom material with a cubemap stage:
textures/darkmod/stone/brick/blocks_large_sandstone2 { stone description "vine_friendly" qer_editorimage textures/darkmod/stone/brick/blocks_large_sandstone_01_ed {blend diffusemap map textures/darkmod/stone/brick/blocks_large_whitestone red .8 green .7 blue .6 } bumpmap textures/darkmod/stone/brick/blocks_large_yellowstone_local { maskcolor map makealpha (textures/darkmod/stone/brick/blocks_large_whitestone) //here I use the specular of the texture alpha 0.5 } { blend gl_dst_alpha, gl_one maskalpha cameraCubeMap env/skyboxes/skybox_darkland_ne/darkland_NE texgen reflect } { if ( parm11 > 0 ) blend gl_dst_color, gl_one map _white rgb 0.40 * parm11 } { if ( parm11 > 0 ) blend add map textures/darkmod/stone/brick/blocks_large_yellowstone rgb 0.15 * parm11 } // TDM Ambient Method Related { if (global5 == 1) blend add map textures/darkmod/stone/brick/blocks_large_yellowstone scale 1, 1 red global2 * .8 green global3 * .7 blue global4 * .6 } }This is how it looks in 2.05, the cubemap properly interacts with the normal map:
This is how it looks in 2.06, the cubemap does not interact with the normal map (and looks tilted, just like the screenshot VanishedOne posted shortly after the post I quoted above). The rectangular fullbright light on the right is how ambientcubic lights look:
Here is another material, this is just your regular clear_warp, plenty of released FMs use it. The screenshots are higher res because the difference is harder to spot.
2.05, here it looks normal:
2.06, now there are vertical bands at regular intervals that distort the image, you can see them distorting the vases and the leafing on the panelling texture on the right:
As I said, my first suspicion would be the vertex programs, stuff like heatHazeWithDepth.vfp and the interaction program that gets invoked when a cubemap stage is present in a material.
-
Ummm, Hell yeah....
I always wanted to play a first person Cities: Skylines
-
1
-
-
Nope, there is still a 32bit executable. I have a dual-core system and the beta seems to do just fine, so you don't need to worry about that either.
-
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.
-
Hmm, I haven't checked my Pinterest boards in ages... Let's pick some old stuff from there and provide some good content for this thread.
-
4
-
-
Please file a bugtracker issue.
Done and done, demagogue doesn't need to file one for the GUI bug now.
While we're on the bugtracker, any chance this will get addressed in 2.06? http://bugs.thedarkmod.com/view.php?id=4536
It's a relatively easy fix (the easy route, anyway); all the information is in the bugtracker and the attached thread.
edit: I should note I haven't actually tested if a stereo silence.ogg is in 2.06 or not, I'm just going off the bugtracker.
-
UI Bug: The up and down arrows for the default briefing GUI don't show, so you cannot scroll the text if it is more than a page.
-
I'm looking it up from DR's media browser (I have set my work environment to my TDM beta test folder) and the freshly downloaded .pk4's (I did a clean 2.06 install). The black wall in this image is supposed to be the texture:
-
I can second most all cubic light related issues VanishedOne has mentioned, they're borked on the temporary glprog files, I am also getting materials with cubemap stages not interacting with their normalmaps. I'll hold off on doing in-depth stress testing until something more stable comes along.
I get an on-mission-load crash in one of my WIPs every time, I've narrowed it down to Multicore Enhancement being on.
EDIT: I also get a guaranteed crash every time I dmap/testmap while in-game. I can load a map but I have to escape to the menu in order for it to work without crashing. I experienced rare crashes when switching between maps from the console in 2.05, this seems to have increased.
@greyman Please fix the following materials that were released in 2.05 with bad definitions:
textures/darkmod/stone/brick/red_sloppymortar_01
problem: "bumpmap textures/darkmod/stone/brick/red_sloppymortar01_local" =/= "red_sloppymortar_01_local.tga"
I see "textures/darkmod/wood/boards/planks_worn_brown" has already been fixed, good. There might've been more textures with bad defs, but I can't remember any right now. Must be paranoid.
I also noticed r_softshadowsRadius seems to be capped by the strength cvar. Is that intentional? Might be more flexible if this wasn't the case.More testing shows me the softening is dependant more on player distance rather than light distance to a surface. I suppose that makes sense from a performance standpoint.This is weird, r_showportals dosent appear to be working.
It's working on my end. Have you messed with hiding the UI or the rescaling? I haven't, but that may be the problem.
-
When I finalize the modules and layout and it comes to the environment pass, I'll see about contacting you about it. Thanks!
-
Is interior_mansion01/window01_seperate.lwo not in 2.05? I can send it to you if not, but I'm pretty sure it is.
It is. He probably missed the interior folder.
That is an interior version of mansion01_window02, what I used in the screenshot was mansion01_window04, which is both way bigger and only has one row of windowpanes.
I made a number of interior prefabs for one set of the external wall/window sets.
I created a lit skin for that window, should be on SVN.
I assume this is on the speedbuild thread you made? Thanks, I'll take a look and see.
-
Thanks, yeah, it's a shame that Spring's exterior mansion windows don't have an interior variation. I think a skin change can work in this case but I'm still not so sure if the geometry of the model will fit the interior, even when indented in the wall.
-
- Popular Post
- Popular Post
I really like that, Fieldmedic!
Here is my art test room for the current thing I'm doing. I'm also looking at making some modules, which is a lot of numbers and not a lot of flash so this is pretty much the only thing worth showing at the moment.
-
10
-
Indeed, the semi-transparent curtain is brilliant. I never thought of doing that before (doh!) what tupe of light did you use Omni I guess..?
What is that long projection light in the second shot, it looks awesome :-)
NB. the shots a very dark btw.
It is omni lights, the curtain materials is where the magic happens, it's off a codeblock either on my or Epifire's mapping threads.
The model is the harbour light Epifire made that's been included in 2.05 and the projection texture is the grate6 nbhor1 added with the cubemap update, but updated with a custom falloff.
They're supposed to be.
I assure you it looks proper in-game, and there is always the gamma setting.-
2
-
-
- Popular Post
- Popular Post
Pretty excited to play the map, Goldwell!
Here's an update on my WIP. I took about a month long break from it. Sad news for those expecting my new mission but hey, look at it from the bright side! That was one month I wasn't stuck in a rut and now I'm back working on it with some new ideas.
Here is a screenshot from what I'd done before:
And another of the room I made over the last two days:
-
19
-
If there is to be some sort of fog overhaul, I remind everyone of the myriad of checks to be done so the fog interacts properly with all that we have in the game. Skybox, particle emitters, water shaders, blend add keywords on materials, I can go on. There is still an upstanding issue with the current fog lights where fogged up skybox brushes will render in front of particles. Not sure if that's just a sorting issue with the particle materials or what, however.
-
It's good to know I wasn't going crazy, I've encountered a couple of completely unfrobable purses, one in A House of Locked Secrets comes to mind. I'm not a fan of piling entities in the browser, it's already super confusing to a newcomer looking at our candle entities, for instance. Right now the bug makes missions not able to be 100% looted, so I'm for reverting the change, SVN issues notwithstanding (dunno what's goin' on there!)
-
I've had trouble with those very entities too, I ended up abandoning them. If nobody else knows something that we don't, my advice is just make a patch with the gui texture, make it into a func static then give it its own text. Then you can manually place it close to an empty sign model.
-
I'm having trouble with this. The post process works half the time and at seemingly random looking angles the screen stops rendering. Without bloom it looks like the image is frozen, with bloom it quickly blooms up to a white screen.
I tried playing with switching interaction shaders, vsync and full screen without any success. It doesn't matter which map I use.
-
I've packaged everything into a pk4 and have made it available on my OneDrive.
OneDrive deems it "sensitive info" and requires a log in. I've downloaded it, but it would be nice to reupload this somewhere else besides OneDrive.
-
(For TDM: imagine everything in sombre desaturated colours)
The maker of Cryptworlds is already ahead of you:
Tracker 3881: Cubemap Lighting Beta
in TDM Editors Guild
Posted
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.