[Beta Testing 2.07]

By no means do I think it's somehow a problem in the crate. Or rather, if you think the 2.05 shader is the problem, the crate's not the only thing affected. I've noticed black splotches and over-brightened specularity on cylinder patches in my map that were not there during the previous beta. Here is a cropped picture, with magnification:

 

 

The light is coming from behind, from the window, and that four-sided, cylindrical patch exhibits the bug on a face that's facing somewhat away from the light, yet is getting inordinately strong specular (and clipping to black), compared to simple interaction shader or enhanced on beta 6. Honestly, I think there's something wrong with the 2.05 shader in and of itself, because I've encountered similar stuff in 2.06, like the stair models I talked about earlier in the thread. I don't remember it being this bad though. If needs be I can make a test map, but not today, maybe on Sunday.

[Beta Testing 2.07]

I've not had a chance to test since my last post, which was a workweek ago. When I said I "fixed it" I meant the remark from VanishedOne. I assumed the problem might have been fixed in beta 7 but as it has not I have indeed gone ahead and tracked it.

 

Reopen http://bugs.thedarkmod.com/view.php?id=4955. The bug is back on beta 7. I cross referenced both in my WIPs and in the view position in William Steele.

[Beta Testing 2.07]

Btw. why shadowcaulk? Models are there to cast their shadows (or those cast by a dedicated shadow mesh). This looks like a very uncommon way of doing things.

 

The wall modules won't seal the level. Why shadowcaulk over caulk then? Honestly, I don't remember why I do it now! I just remember there was a bad drawback with caulk that I discovered and it turned me to shadowcaulk, which did a better job. At any rate, one benefit is that you can freely turn off the shadow casting on any wall module in a concave room (conditionally through LOD or not), because if there is any light, it will be casting light on the wall modules, the modules themselves won't cast shadows inwards, to the room. The exception is the trim, but if it's minimal or the light is cast not too dramatically, the player won't notice. As regards to the material issue, don't worry guys i fixed it

 

Should I track this one?

[Beta Testing 2.07]

OK, I can confirm that the single pass shadow map mode now works with the alphaTested materials that I use in my WIP (we were discussing how it didn't look correctly wrt to the vines on one of the tombstones in The Warrens, but I haven't gone in to check). Regarding singlepass though, I was fortunate to turn it on and check, because I found a bad interaction with shadowcaulk by chance.

r_shadows 1 (or r_shadows 2 with singlepass mode 0):



r_shadows 2 with singlepass 1:



How the scene's set up in DR:

 

I really don't think this is related to the noFog change. Before you rush to fixing shadowpass though, while shadowpass 0 will fix shadowcaulk, it will not fix shadow/shadow2. Here's the problem: with shadow stencils, the front faces, facing the light, don't cast shadows? I don't know if that's the right way to explain it. With shadow volumes, shadowpass on or off, they do. Here's pictures to better visualize it:

 

Brush textured with common/shadow2 with r_shadows 1:

 

Same brush with r_shadows 2:

 

 

edit: I suppose a better way to phrase it is that with r_shadows 2, the the faces of the brush cast shadow in the gap created by the brush's volume itself, which should not happen.

[The Dark Mod Mission Stats for 2018]

I'll also point out that while greyboxing is standard, it is also, by another name, conventional. Here is a good inspiration post for anyone looking for pointers on how best to complete your FM. It's from an animator I respect, but use your noggin and let the power of metaphor deliver the point: http://felixcolgrave.com/post/179932218595/do-you-have-any-tips-for-a-scatterbrained

TL;DR: Do what works!

[Beta Testing 2.07]

Hey nbohr1more, sorry for not responding to the note in the bugtracker but weekend was kinda busy and at least some of that was me mapping, so hey yay for that at least. At any rate, I didn't need to package special testmaps for the fog issue, it seems the noFog update has fixed both shadowcaulk and shadow/shadow2/shadow_bak! I checked specifically before updating to beta5 and there is parity on my WIP; it looks how it's supposed to, that is.

 

I have a comment on 4955 being fixed, and that its fixed additional graphical glitches besides the light to instant shade bug posted by STiFU on page 9 (I've experience that one as well). I had very basic stair models made, basically one face divided into two tris, and the fresnel reflection was very bad and dependant on the subdivisions of the model (which is why I suspect the low-poly models like the simple cubic crates got affected). stgatilov already explained the issue in the note to that bugtracker entry, so I don't need to really guess though.

 

Speaking of that, though, that's probably why the pipe models look different now, Judith. I guess try turning off the advanced interaction shader?

[Beta Testing 2.07]

D'oh! I was using 1 instead of 0. Serves me right for testing at 2 am after a 14 hour workday, I guess. I can see it works now, too.

[Beta Testing 2.07]

Can someone who's used is_mantleable 1 check whether the behavior under this beta is consistent with the old one? I don't remember how it worked but testing it out now it doesn't do anything, any piece of furniture I set as not mantleable I can still mantle over, no matter if the fast mantles are enabled or not.

[Beta Testing 2.07]

To get an early look into this, what happens if you add the "translucent" keyword to your local copy of the shadow caulk material?

 

Well luckily, you were right on the money for this one. "translucent" solves the issue when placed after "forceOpaque" in common/shadowcaulk, but it does not work with the common/shadow material. Putting "translucent" before or after "forceshadows" doesn't work, only commenting out that keyword solves it.

[Beta Testing 2.07]

I see no artifacts in warp glass and I've been testing out the faster mantling. Gotta go to work RN but before I do, I filed http://bugs.thedarkmod.com/view.php?id=4951 as it's still present in the latest beta. I feel it's an important one to fix if you have architectural models and shadowcaulk walls to seal the map.

[Important member banned]

I was shrewd enough to keep backups of previous versions of the map on my Google Drive, the most primitive way of version control. To use the same example, when I received the decal version of the map, I just had to take one of my backups and revert back to working from that, instead of the decal version. BTW, the backup wasn't that recent, so I still had to redo a fair bit of work I had already done. That's on me for not copying my map to Drive on every single change I made, but should I have been expected to paranoidly do that? It's miraculous I even kept backups to begin with. Imagine if somebody had no concept of version control, they would just have to accept Bikerdude's additions with no recourse, save for manually editing out what he did and walking the entire map back. I guarantee you it would not be easy to do so, in that case, for he had a habit of not keeping the slightest courtesies like making all of his changes on a seperate Layer in DarkRadiant. edit: for the smaller changes, I had to do just that, manual reversion, which was not very fun at all.

[Important member banned]

 

If Biker takes work from someone else's mission and incorporates it into a new mappers mission then it's up to the new mapper to do what Spooks and Dragofer so easily did. JUST. SAY. NO!!!

 

Sure, not having admin or upload privileges helps, but IMO community shouldn't be asked for time, energy, and patience to comb through every new Biker's creation to see whether he copypasted something or not. People usually don't assume bad intent, and the last case was kind of an accident.

 

It seems like Biker doesn't understand the difference between using modules or prefabs, and copypasting whole portions of other people's maps (it's the same thing as with music, noone will sue you for using instrument samples, you end up in court for using someone else's instrument arrangement). He was confronted about it three times lately, and every time he made only cosmetic changes. He was immune to everything from calm requests to public shaming. That was a lot of time and energy wasted, by several people, that could be better spent on making content or helping others.

 

Firstly, I absolutely agree with the second paragraph and the point made on copying arrangements. Secondly, I want to address the point raised that it's the mapper's onus to "just say no." or that it's so "easy" to do so.

 

nbohr1more knows of the interactions me and Bikerdude had because he was a beta tester for my mission. While BD helped me optimize KoD and added to the map, I can't say that working with him was the smoothest. Multiple times I was extremely frustrated with changes he made without declaring his intentions first, changes that I had to take time out of my day to revert, which prolonged the beta testing period and speaks to what Judith is saying at the start. Multiple times I would plainly revert his changes, yet he would revert my revert back to what he did, like some stupid game of slapsies. I don't want you to get the impression that I'm still bitter about it, it was a long time ago, but I want to speak to a specific point.

 

As an example, one improvement of the map BD made was a version with many, many grime decals added to a bunch of the buildings. He had told me he was going to add "some" but I took it that he would use common sense. He did not. On loading the map, the framerate had dropped to half of what it was and when diagnosing it I found what I'd already suspected - the decals had doubled the drawcalls and in turn brought the FPS to single digits.

 

Seasoned mappers like him should know that we have a known, soft upper limit of drawcalls that your scene should have, in order not to destroy performance for users on older hardware. Hell, it was my first map and I knew it, but he did not even bother to check the one console command that would show you how many drawcalls you are getting and whether or not the scene was too demanding. It was a frustrating mistake, but not because I had to go ahead and remove every single decal by hand. No, I could just revert to an earlier version of the map. But I knew from experience how much time he had put in creating these decals. These things don't just get done in 20 minutes, it must've taken him an afternoon to do this. I was pissed because I felt guilty for having to erase somebody's work like that.

 

This is why it's not as simple or easy as "just saying no". You don't even have to invoke his seniority as a member of the community, or any other type of power dynamic. It's a fact that there is implicit guilt when somebody spends a lot of time on something and then expects it to be accepted as a valid addition by virtue of the effort put in it. The only reason why I had to flatout revert the changes was because I knew my responsibility to many players' experiences was bigger than my responsibility in honoring one person's effort. That's something that a lot of people can't do, because they either don't see the responsibility they hold for the players of their FMs (on account of being newbie mappers), or because it's not as drastic as this particular case was (but even then, I get the impression that BD had the propensity of giving your map a death by a thousand cuts). Either way, they get guilted - again, implicitly- into accepting something that might not be good in the long run because nobody wants to make a fuss.

 

Speaking to the guilt involved in deleting somebody else's hard work, I would be remiss if I didn't also mention this. The beta version of King of Diamonds is freely available for download. This was about as far as I had gotten with the FM before I went into beta testing and Bikerdude stepped in and changes began happening. You'll notice that the south-eastern portion of the map was completely removed and replaced with one that Bikerdude provided. I spent far more time than an afternoon's worth of adding decals in creating all of those houses, ten, twenty hours maybe? I don't want to exaggerate. Do you think that BD felt any guilt when he deleted all of that without asking me and presented me with his version? No, I don't believe he did. I accepted his changes because, comparatively (and, again, feel free to do the comparison yourselves, both map files are publically available), his layout was more interesting for the player than the previous one, but the fact remains and far more of my man hours went down the drain than his. The layout he made, as far as I know, was original, but the constituent buildings were more or less just prefabs.

 

Here's an excerpt from a PM that Bikerdude sent me in 2016 after another round of being chided over the same, old stuff caused him to reach out to me and ask me if his input in KoD was overbearing or arrogant. This is a large part of my response:

 

 

I understand that if someone was to ask you for input and perf. adjustments you'd start cutting with big strokes first, it's the same thing I would do. With that said, I could see how someone else would see it as overbearing. I remember several revisions where I got quite mad with some of the stuff I had to revert - hell, I don't remember what it was about by now, it's all water under the bridge - but still. Since I held KoD in low esteem - as the first FM I had to cut my teeth on - I wasn't too precious about losing anything I'd made like the SE quarter of the map's layout or the single story look of the center of the map. If I had grand, cool and - above all else - exact ideas about how things were supposed to look and where they were supposed to be though, I'd be ticked right off.

I think poor communication is to blame more than anything. A lot of times I could read what your changes were meant to mean from just how the map had changed, but somebody else might need them written out. If I got mad, I got mad more at the miscommunication between us rather than any of your specific inputs. All of this, really, it comes with the turf of you only working on perf. without foreknowledge of what certain areas might mean for gameplay/aesthetics. Again, it's a consequence of people (like me) asking for input at a late stage of map development. I don't think there's a solution to the problem of erasing somebody else's detail-intensive work other than consulting at a way earlier period when the map is still in dev-textures and the like.

 

 

I don't think this counts as airing any type of "dirty laundry" as I've only quoted myself, but there really isn't anything from BD to quote, he just replied to this with a laconic "glad i was more of a help than hinderance :)" and we moved on talking about computer parts stuff. If there's anything to take away from his one liner, "cool thanks" response, it's that in hindsight it is very ambiguous whether or not what I said to him stuck. Actually, considering our current situation, I guess it's unambiguous after all. It did not.

 

But back to my PM, do you see what I mean? Imagine if what you were working on was something you cared about, yet you still got the same treatment? Imagine you used the same sort of self-deprecating language in your PM reply to a forums member with 20 thousand posts because you "don't want to make a fuss". You've got to realize just how screwy this sort of behaviour is and how it erodes the community some of you are fanning yourselves over, turning it from a fellowship of collaboration and a shared craft to a slapfight between who gets the last word, or should I say the last level edit, in. Cynically, I may end by adding that practically all people that BD chose to have these "slapfights" with were either too inexperienced to know what he was doing or not present at the time to slap back, e.g. Spoonman.

 

I have and never will consider Bikerdude a bad person. Full disclosure here, I'm typing this message inside a text box that I'm looking at from a second-hand monitor he shipped and gifted to me, when my old one broke down right before KoD's release. He did not ask for anything in return, he did it out of kindness because I was out of a job at the time and low on money. If anything, you could say I have material reasons to defend him! Yes, he's a very helpful and resourceful person, which is why he's been given this much leeway. But it has been precisely the point of this entire post to remind you that helpfulness or resourcefulness should never counterbalance a history of unrepentant boundary crossing and lack of respect for artistic integrity. Do not, also, confuse the former as the founding pillars of the TDM community, so poised to crumble after BD's ban. Being helpful is a byproduct of our shared desire to make and play cool stealth levels, the actual bedrock of why anyone here sticks with The Dark Mod. Bikerdude has shown a history of disrupting just that. I'm not sad he's gone, I'm just disappointed.

[Beta Testing 2.07]

I don't know whether it's closely related, since this doesn't include the particle clipping through the wall like yours seems to, but I took this shot in The Elixir under 2.06. The overbrightness in the mirror compared to the scene it reflects is caused by a candle in the room behind, and eliminated when the candle is snuffed. (I hadn't filed a bug report because I was going to see whether I could reproduce it and didn't get around to it, but the visportalling seemed okay so I don't think it's a map bug.)

 

elixir_2018-09-26_02.32.45.jpg

 

Yes, the visportaling in the Reluctant Benefaction looked solid too, which is the first thing I thought to cause the bug as well.

 

I forgot about getviewpos! Thank you for reminding me, in The Night of Reluctant Benefaction (anorb2.map), the getviewpos for viewing the bug is "635.64 535.45 300.25 2.4 -84.2 0.0" . You can see the candle flame in the corner of the mirror and as you turn to the left, it's aspect will seem to skew and flip horizontally. If you set up the candle on the other side of the wall like I have in the screenshot, the candle flame will appear more or less in the center of the mirror.

 

I tried fiddling with toggling some of the "new" cvar settings but the bug seems persistent. Now that VanishedOne has corroborated there's been at least some weird behaviour regarding candles and mirrors I've filed a tracker issue, #4946.

[Beta Testing 2.07]

I can confirm that the ragdolls are a bit wonkier now, even still-standing AI that get blackjacked will skip about after falling. Not reproducible when loading and blackjacking the same AI. Seems random, i dunno :/ i don't want to send anyone on a goosechase.

 

I have a case of a candleflame showing inside a mirror on the other side of a wall. It's in Night of Reluctant Benefaction, I have a savegame here but I realize that I'm playing on beta 2 and not 3 so it's probably not gonna work, so I'll just supply screenshots.

 

The candle is in this room. It's on the table to the right, but move it like I have, so it shows better on the exact opposite side of that wall, where a mirror is. It's the place that you get up from jumping on an awning and opening a second floor window.

[Tutorial: Image-Based Lighting Workflows for TDM]

Hey, thanks! I tried those actions and while they definitely work with some brush scribbles, I don't think you get results with a rectilinear image like the cross :/ Maybe if you were to rotate it 45° or something with nearest neighbour filtering.

 

@judith I mean, it's certainly an available option. I'm a little hesitant on agreeing that it'd be "easier" but I've not touched GI solutions in Blender so I can't speak to it.

[Tutorial: Image-Based Lighting Workflows for TDM]

That method will still leave the edges sharp and only blur the middle, and you need the image to be way blurrier than that. Recall that any hard gradation step in the image will cause specular to crop up. You'd need each face to be touched by each adjoining face, and a diagonal cut of the adjoining faces' edges to fill out the cross at the diagonals. That's the only way to properly filter to an IEM imo. Here is a screenshot from within Lys with the "Dilate Results" option enabled to better illustrate what I mean.

 

 

I can see this working for a radiance map (considering the filtering in cmftStudio is borked, too) but not an irradiance one, since they're all smooth gradients. Median filter has a habit of keeping the edges between graphical structures too, so it can only go so far. I suspect the easiest way to make an irradiance map in an image editor is to just use the gradient tool and try fake it as best you can.

[Tutorial: Image-Based Lighting Workflows for TDM]

Parts 4 and 5 are now up! Boy, that sure was some intense typing. Please let me know if you have any questions I've not covered in these parts.

 

 

That's a huge help, thanks. AFAIK, irradiance maps were never super popular in games or rendering, it's either HDRI panoramas or cubemap sampling entities that capture the env shots automatically. But this could be useful as a IBL solution, at least in selected places. Btw. does current implementation affect diffuse only? (as in here: https://learnopengl.com/PBR/IBL/Diffuse-irradiance ) Second thing, instead of using external software, wouldn't it be easier to just stitch all cubemap sides to a cross, blur them, and separate them into images again?

 

Q1: The ambient cubic lights do not just affect diffuse. See the last screenshot in Part 5 for proof. An irradiance map will give you a diffuse, but a radiance map (or just the straight-up envshot cubemap) will give you the pictured specular mess. I can't tell you what's at fault here, but I hope the functionality of irradiance/radiance either gets decoupled from ambient cubic lights and into a new light type, or our materials somehow get fixed to accept radiance maps. Somewhat offtopic, originally I was going to post some screenshots of me putting radiance/specular cubemaps in the light definition and judging the results, but I cut it for time. It's peculiar but not particularly pertinent.

 

Q2: A gaussian blur is not the correct convolution filter for irradiance map but can certainly do in a pinch. The problem's not that, though. At least in Photoshop, blurring the cross with a colored background will just bleed the color into the cross. Blurring it without a background will just bleed transparent pixels. I don't think it would be different in GIMP, I don't see a way to do it that's not faster than using an external application.

[Tutorial: Image-Based Lighting Workflows for TDM]

Part 4

 

 

Let’s go back to what was said at the beginning of part 3. A workflow with cmftStudio only requires you to stitch a cube cross, a workflow with Lys also requires you to unstitch it. Both of those actions are to be performed in Photoshop. Therefore, I will structure this part thusly:

 

First, I’ll describe how to stitch the cubemap in PS. This is required for both Lys and cmftStudio.

 

Second, I’ll run through the cmftStudio process. At the end of it, you’ll have a game-ready IEM.

 

Third, I will consider Lys and its cube cross export.

 

Fourth, I’ll describe how to unstitch said cross in PS. At the end of this process, rather than the Lys export one, you’ll have a game-ready IEM.

 

Fifth, I will introduce a method to automate renaming the output faces, something you have to do for all three workflows, including the Cubemapgen one explained above.

 

 

Stitching the Cube Cross in Photoshop

 

Refer back to Fig. 13 at the beginning of the previous part. The cross that Lys accepts is in this format, a horizontal cross unwrapped to the left. Happily, that is also the format cmftStudio takes, so we don’t need to worry about orienting our cross differently. For Cubemapgen, the cross needs to be vertical, unwrapped at top. These steps will yield the first orientation.

 

Step 1: Load the cubemap faces into Photoshop.

 

Refer to [Fig. 6]. These are the input images, and they are ordered in alphabetical order. Alphabetical order is very important for the automated script to work. Select all six files, then drag and drop them into Photoshop. You should have six tabs, ordered alphabetically, like this.

 

[Fig. 19] The six cubemap faces are in separate tabs. t_forward.tga is selected. The image is zoomed in only for illustrative purposes.

 

Select the middle file, t_forward.

 

Step 2: Stitching

 

Like I said, you won’t need to do any of the following sub-steps manually. Photoshop has a macro system, a way to record and playback the actions you take in the app. The Action panel is accessed through the Window menu, or by pressing Alt+F9.

 

[Fig. 20] The Action panel.

 

Your list of Actions may or may not be empty, but you definitely won’t have the ones displayed here. At the end of this part, I will give you this “Cubemap Operations” folder in the form of an .atn file. All you need to do is open the file and the Actions I’ve prepared will get loaded in the panel.

 

Supposing, now, that you have these at the ready, simply run the ‘Stitch Cubemap’ Action. Provided that you did Step 1 correctly, your files are ordered alphabetically and you currently have t_forward open, you’ll get a proper cube cross in a few seconds. Be careful not to overwrite the t_forward tga, save this cross under another, descriptive name, again as a .tga.

 

This completes stitching. The following sub-steps will go into more detail of what the ‘Stitch Cubemap’ Action actually does, in order to better understand the workflow. I’ve gone to great lengths to ensure multiple resolution cubemaps can be transformed through this method, form 16^2 to 4096^2 pixels and any power of two in between. The cubemap for this tutorial has 256^2 px faces. Your cubemap cross should not look misshapen by the end of the Action, but if something does look off, peruse these sub-steps and execute them one by one to troubleshoot your problem.

 

If you have no problems, or don’t plan on working with cubemap faces over 256^2 pixels in size (a size which, for irradiance map conversion purposes, I recommend sticking with), feel free to skip these sub-steps.

 

Step 2.1: Loading the images into a single document

 

In the t_forward document, which you should still be in, double-click the Background layer and turn it to Layer 0.

 

Tab over to t_left. Select All, Copy, tab to t_forward, Paste. t_left will now be Layer 1.

 

Repeat the process with t_down, t_left, t_right and t_up, in that order.

 

At the end, t_up should be at Layer 5. You have six layers with all the faces in one document.

 

Step 2.2.: Align inside canvas

 

Ctrl+Alt+A to Select All Layers. With the move tool active, Align Vertical and Horizontal Centers. The layers must all align and be inside the bounds of the canvas. The Action script aligns centers, if this doesn’t work, try aligning to Top and Left Edges.

 

Step 2.3: Resize canvas

 

Ctrl+Alt+C to open the Canvas Size dialog. With ‘Relative’ checked, resize 200 percent Height. Anchor middle (no change from the default).

Ctrl+Alt+C. With ‘Relative’ checked, resize 100% Width. Anchor middle right.

Ctrl+Alt+C. With ‘Relative’ checked, resize 100% Width. Anchor middle left.

 

This is the safest way to resize the canvas into a 4:3 ratio (which gives us an 1024x768 px image in this case) without using decimal points and worrying about floating point precision.

 

Step 2.4: Distribute Layers into proper positions

 

Remember that Layer 0 is the t_forward image. It does not need to move.

 

Select Layer 1 (back face) from the layer list. With the move tool shift-click and move it to the far right. Make sure snapping is on so it neatly aligns to the right border of the document, it should be moved +50% to the right, relative to its original position.

 

Repeat the process with the other layers. They should all snap around your middle face. Remember the order you imported the layers by looking at the list of open files up top. Next is t_down, Layer 2, it goes 33.3% down, relatively. Layers 3 and 4 are left and right, respectively, the last layer goes up.

 

Step 2.5: Combine and save

 

The layers should be ordered correctly now. From the Layer menu, either Merge Visible (Ctrl+Shift+E) or Flatten Image. The difference is the former will keep the background of the cube cross transparent. It does not particularly matter if you save the .tga with transparency or not as we’ll be splitting it into faces later anyway. Neither program cares much for the alpha, but I recommend you Flatten Image just in case.

 

---

 

This concludes the sub-steps for manually stitching a cubemap in Photoshop. You may reproduce these steps in, say, GIMP, but I cannot help you automate the process. There are further external programs, like AutoHotkey, that you can use to automate this workflow, but you can automate anything with AHK by that mindset, so I would better stop before the tutorial gets too off the rails.

 

Whether you use the Actions I’ll provide later or do this by hand, the end result should be a cube cross .tga. This is now ready for import in either cmftStudio or Lys. Let’s go over cmftStudio first.

 

The cmftStudio Workflow

 

[Fig. 21] A screenshot of the cmftStudio UI, from the GitHub readme.

 

cmftStudio’s UI is somewhat non-standard, as I said before, but is not unintuitive. Take a minute or two to familiarise yourself, click around and get acquainted. When you feel a bit more comfortable, direct your attention to the right part of the UI. That is where all the cubemap filtering options are, the only thing of interest on the left side is that “Spheres” button at the very top. Make sure it is pressed, the default, single sphere model, will not preview your IEM.

 

Step 1: Load the cube cross into ctmfStudio

 

On the right-hand side, either click the ‘Edit’ button under the ‘Environment’ tab at the very top, or click on the three thumbnail images under the ‘Preview’ heading. This will open the environment sub-tab [Fig. 21], with Skybox, Radiance, and Irradiance options available to you.

 

Under the Skybox heading, click ‘Browse’ and load your cube cross .tga file into the program.

 

If you have saved it in the /env folder with the other cubemap faces, in order to avoid browsing to it every time you want to reach it you may want to just place the cmftStudio.exe in the folder, as the browse path defaults to “Runtime”, where the .exe is. If you’re working inside an FM folder, remember to remove the .exe before your mission releases, lest you end up distributing the software by mistake. Alternatively, just dump all your stuff on your desktop! It’s cool.

 

Step 2: Filter the cube cross to an IEM

 

The skybox will now appear in the background of the preview window, but the spheres will still preview the default cmftStudio materials. Do not attempt to filter the skybox with the Radiance filter. In my experiences, this either crashes the program or my display driver.

 

Under the Irradiance heading, click ‘Filter skybox with cmft’. Note the resize options available to you. The default gamma processing options provide output comparable to Lys’, which means they are a good standard. Don’t touch them unless you know what you’re doing. Click ‘Process’.

 

The filtering shouldn’t take too long. You can disable “IBL Specular” in the right-hand panel and lower the number of preview spheres from the left to see your irradiance map in motion. You can click the ‘Info’ button to magnify the 2D cross texture.

 

Step 3: Exporting the cube faces

 

Under the Irradiance heading, click ‘Save’. Choose a directory and a descriptive name, save as a .tga, make sure the ‘Output type’ is “FaceList” and ensure you’re saving without an alpha channel. Click save. Note that you may also export the irradiance map how you imported it, as a horizontal cross, but we don’t need to do this.

 

[Fig. 22] The exported irradiance faces in the folder.

 

The files once again need to be renamed, the schema is much the same as with Cubemapgen. After rename, your IEM is ready to be used in-game!

 

There is not much to be criticized with this workflow, cmftStudio allows you to save/load “projects” in order to keep your settings and has better, more user-friendly controls for image adjustments. If I had to spitball, I’d say it has less or an equal number of button-presses-per-IEM-made than Cubemapgen, and provides a better result.

 

The Lys Workflow

 

Here’s a big section title for nothing. I will not describe the process of navigating Lys’ UI and exporting an IEM here, for the sake of brevity. I maintain that you ought not buy the product for just one step, so if you are intent on using Lys for this, I suspect you already own it. Therefore, I need not explain an app you are already familiar with.

 

The result of a Lys export is an irradiance map inside a cube cross. In order to split the cross into its constituent parts, we need to go back to Photoshop.

 

Unstitching the Cube Cross in Photoshop

 

Unstitching requires several extra tools in addition to base PS. The first is Nvidia’s Texture Tools for Photoshop, namely the NVIDIA_CubeMapShuffler script. The second is an improved script for Export Layers to Files. This script, by default in older PS versions, has non-optional enumeration suffixes. The improved version removes them and allows for easier final rename.

 

Download and install both of these, per the instructions provided in the links.

 

Load the irradiance cube cross. Make sure you don’t have any other files open. Recall [Fig. 20], the Action panel. Naturally, to unwrap the cube, run the “Unstitch Cubemap” Action.

 

After the action runs its course, you will have a square image with all the cubemap faces in layers, stacked neatly and named properly.

 

[Fig. 23] The Export Layers to Files dialogue. If yours lacks some of these options, you’ve not installed the improved version properly, or have not removed the old version from its folder.

 

In order to output these to separate files, go to File > Scripts > Export Layers to Files... Export with the settings depicted above, replacing “tIEM” with the name of your irradiance map.

 

You know how .tgas in a folder look by now, so I’ll save you the illustrative image. Suffice it to say that the names on these aren’t quite perfect either. No matter what you do, the Export Layers to Files script will place a hyphen between your “File Name Prefix” string and the name of the layer. At the very least, you don’t need to remember z faces or the like, simply replace the hyphen with an underscore and the IEM is game-ready!

 

This is the extent of the Lys workflow, as you can see it is not very complicated, although the unstitching takes an intermediate amount of time due to the Nvidia scripts. Following, I will explain what the “Unstitch Cubemap”Action does for those who want to know, but be aware that I am far more skeptical to its repurposement in another application. The Nvidia Cubemap Shuffler script is what drives the process and that is a Photoshop-specific utility.

 

Step 1: Rotate the cube cross, use the Shuffler twice

 

First, rotate the image 90° counter-clockwise. The Cubemap Shuffler requires that the cross point downwards.

 

From File > Scripts, run “NVIDIA_CubeMapShuffler”. What it will do is create a new document, cut all six cubemap faces and place them in a horizontal strip format and in seperate layers, named X+, Z-, etc. This isn’t particularly useful.

 

Run the Shuffler again. It will create a third document, “InverseT”, that will reverse the process and “stitch” the cubemap faces back into a cross. Notice, however, that each face will be on its own layer. The net effect here, then, is that by running the Shuffler twice, we’ve separated the faces into layers without having to do any manual selection of our own.

 

The new cube cross is still pointing down. Let’s reset it to original position, rotate the image 90° clockwise. You’ll work in the “InveseT” document now, as far as the other two, the horizontal strip and the original cubemap cross, you can close them without saving.

 

Step 2: Rename layers

 

For easier export, the layers may be renamed to their game-compatible suffixes: forward, back, etc. The list from Cubemapgen will come in handy here again, so refer to that.

 

Step 3: Align and trim

 

With the layers renamed, we need a neat way to stack them and delete all the transparent pixels, returning this 4:3 ratio canvas to a 1:1.

 

Ctrl+Alt+A to Select All Layers. With the move tool selected, Align Top and Left Edges. Deselect the layers.

 

From the ‘Image’ menu, select ‘Trim…’. A surefire solution that does not invoke the Canvas Size dialogue, Trim can crop all transparent pixels out of the picture. Since all the layers now overlay each other in the top left corner, Trimming will crop the image down to contain just them, in a square. You may check off the Top and Left checkboxes in the Trim Away section of the dialogue but it ought not be necessary.

 

This encapsulates the “Unstitch Cubemap” Action. Export through the aforementioned layers to files script.

 

Automating Renaming

 

A final bump in the road that you may noticed here is that we have to manually rename all six, output files, no matter the workflow we use. Luckily, there are many batch renaming applications on the internet. Here I’ll review the one I’ve chosen to use.

 

ReNamer

http://www.den4b.com/products/renamer

 

Den4b’s ReNamer is a lightweight, but very flexible tool for non-commercial use under the CC BY-NC-ND 3.0 License. I recommend you download the portable version and I shall provide a mirror, redistribution link, in case the website ever goes down. It is so very easy to learn that I will skip relaying you information you can learn in its tutorial .pdf. Instead, I’ll just provide the three different rules for renaming each workflow’s output for your convenience. I will put them in a “Preset” which can be put in the app through the Presets > Import… option.

 

[Fig. 24] ReNamer’s main window. The output from a workflow, cmftStudio in this case, has been drag-and-dropped, to be renamed. The three rules, above, ensure any one of the three workflows described in this tutorial will get converted properly. You may drag more than one cubemap (i.e. more than six images) in at a time and expedite your work further.

 

 

Important Tools

 

Cubemap Operations.atn

IEM Renaming Rules.rnp

 

As promised, here are the coveted automation files you’ll need. With Photoshop open, double-clicking the .ATN file will add a “Cubemap Operations” folder to your list of Actions. Four actions are provided, the useful stitch/unstitch cubemap ones, and the not so useful “Set Up Guides” ones. These automate placements of preparatory Guides that I had to use while figuring out the process of stitching and unstitching, you may however find them interesting to play with. As for the .RNP, that is the ReNamer Preset file.

 

This concludes the main part of this tutorial. Phew! That was a lot of text now, wasn’t it? Come back to Part 5, where I will give a much needed summarization of all the methods previously explained, clear up some ambiguities I had purposefully left out, and provide yet more resources and mirror links.

 

 

 

 

Part 5

 

A Summary of Available Workflows

 

I understand that, although you’ve read all of the tutorial so far, you may still feel lost in the wealth of information here provided. As previously stated, I wish to engender a spirit of productivity and efficiency, so allow me to tighten up the instructions I have given you and succinctly relay the discrete steps you need to go through in order to use IEMs in the Dark Mod.

 

Step One: Take an envshot in game.

 

With the six resulting .tga files in your <root>/env folder as your input, you

 

Step Two: Use a cubemap filtering program to get an irradiance environment map.

 

You can use three distinct apps. With CubeMapGen,

 

--- load the inputs one by one

--- perform the filtering

--- export the output into six .tgas

--- use ReNamer to get them game-ready. Skip to step three.

 

Working with cmftStudio/Lys involves making a cube cross in PS first. With Photoshop,

 

--- drag and drop the 6 inputs at once. They should be alphabetically ordered and you should tab to the “forward” face.

--- run the “Stitch Cubemap” Action

--- save the cube cross as a different image than the “front” face

 

With cmftStudio,

 

--- load the cube cross from the right-hand side

--- perform the filtering

--- export the irradiance output into a face list of six .tgas, analogous to Cubemapgen

--- use ReNamer to get them game-ready. Skip to step three.

 

With Lys, drag the cubemap cross in, Ctrl+E to export the irradiance cross out. Then, back in Photoshop,

 

--- load the irradiance cross, make sure you don’t have any other document tabs open

--- run the “Unstitch Cubemap” Action

--- File > Scripts > Export Layers to File, use .tga

--- use ReNamer to get the files game-ready

 

Step Three: Write a light material.

 

In your materials folder, create a new .mtr file. Write a new light material for an ambientCubicLight and supply the “CameraCubemap” keyword with the name of your irradiance map. For reference, you may wish to copy one of the pre-existing materials that TDM already ships with.

 

Step Four: Place the light in DR and test in-game.

 

Give your light the proper texture from the previous step. Place it roughly in the middle of the recipient scene, or near where you took the envshot. Use “reloadDecls” and “reloadImages” in TDM’s console if need be. Presto! Done. You’ve got an irradiance map illuminating your environment.

 

Practical Concerns

 

Following, I will note a few extra facts and good practices you should employ when using IEMs. The cut and dry part of the tutorial is done, so now we can focus a bit more on the peculiar specifics.

 

The Question of Size

 

For the purposes of this tutorial, all cubemaps, imports and exports, have remained the same size — 256 by 256 pixels. Irradiance maps, however, can get away with much lower. IEMs are by and large just color gradations, so lowering their resolution results in minimal quality loss. In my tests I employed a 16x16 pixel IEM with success! I think this may be too much of an overkill though.

 

Generally, I would recommend you export and use 32x32, 64x64, or 128x128 sized IEMs. As far as the initial envshot, I’d advise to keep it at 512^2 tops. During my tests, I tried to take an envshot that was a 1024^2 but the faces came out glitched… whatever you choose, make sure to look over your envshots first for any graphical artifacts.

 

Another point towards smaller IEMs is that, given that we’re still working with .tga files, the file size stacks up fast. I leave it to you to weigh file size against visual fidelity via experimentations. Speaking of .tga though…

 

The Question of Type and Bit Depth

 

TGA files have a “Type” and bit/color depth. Cubemapgen and cmft save Type 2s while Photoshop exports Type 10s and compresses them with PackBits to boot. I profess to not really knowing what difference these types make, but sure enough, they all seem to work just fine so you shouldn’t worry about it too much. Bit depth though…

 

[Fig. 25, 26] I love Web 1.0 colors. A 16 bit vs. a 24 bit irradiance map. Screen brightened for illustrative purposes.

 

Do not use 16 bit depth! I have made it clear that you don’t need alpha channels in these .tgas, but please be aware of the depth you’re saving with, otherwise you will be greeted with this ugly banding effect. The envshots that the game spits out are 24 bits and that’s what I recommend sticking with, a quick glance at the tooltip or the properties of the file will tell you if your images are in the correct depth.

 

Light Considerations

 

I left the problem of “priming the pump” open in the beginning of Part 2. You may frown at the idea of providing extra set-up in order to take good basemaps for irradiance. Thinking through it logically, however, one must admit that for irradiant light to even exist in a scene, radiant light must be shining from somewhere. In other words, to say that the surfaces of an environment provide diffuse light is to say that they diffuse the point light incident on them. Point light has to exist first, ambient light follows.

 

Of course, it’s not that cut and dry in game. The IEM is just a color gradation so it doesn’t matter how the environment, captured by the envshot cubemap, is lit, or rather what it’s lit with, as long as the colors and brightness resemble incident point light somewhat. As mentioned, for my example cubemap I just artificially brightened the windows with ambient lights, because windows ought to be “bright” and emit a light stong enough to diffuse onto the opposite wall of the corridor. My point here is that you can use whatever types of lights or props you want to capture an envshot cubemap, so long as the final luminance across the scene varies in the way you think irradiant light should spread across the ambient cubic light’s boundaries.

 

This example scene, too, is a bit of a bottom-to-top scenario, as it’s clearly a work in progress. I actually advise you to do your “irradiance map light pass” after your level’s been already built, with big, principal lights and small details set, with brightly textured props and wallpapers chosen. This way, you’ll be capturing the most accurate and “up to date” version of your environment, hopefully minimizing the need for extra set-up. There is a caveat here, however, that we must not gloss over.

 

Recall the cube map tutorial I linked earlier. While outdated, a very pertinent point is made at the end of it.

 

“You have to take into consideration that in contrast to a true reflection, the cube map texture will not react to changes in the environment. So if you for example put the torch out, it will still be lit in the cube map. So it would be more practical to have non-extinguishable lights and no large moveables near the water.”

 

I mentioned that I intended to replace the orange, placeholder light at the end of the corridor with a light fixture, some sort of electrical lamp perhaps. Here is the problem: is this light going to be extinguishable? If so, the IEM will not magically update to turn its orange color off!

 

You must consider the gameplay of your level first and its appearance only later. Every light in the level that the player can extinguish, from candles, to lanterns to fireplaces, should be off when taking an envshot for an IEM. The IEM represents irradiant light from a static environment, so every dynamic, or moving, element that can somehow change the illumination in a scene drastically should be hidden or turned off. Yes, that means that you should be especially wary of brightly-robed Builder priests, like our friend for this tutorial, getting in the way of your envshot captures.

 

IEM Prep Considerations

 

To cut a long explanation short, I recommend you export your IEMs a bit brighter than what you expect to use in game!

 

Remember that the irradiance map from your files is shone through an ambient cubic light placed in the editor, and that is still very much a light, like any other. By default its color is white, which means it can only go down in brightness. What I’m getting at here is that if you have a bright IEM that’s not to your liking, you can simply lower the brightness of the ambient cubic light in DarkRadiant. If the IEM is too dark, however, there is nothing you can do short of either setting the “rgb” keyword in the material file above 1 (which clashes with the “colored” keyword and disables the light from being toggled on and off in-game) or just exporting the irradiance map again (which can get fiddly).

 

To export a brighter IEM, play a little with the image manipulation sliders in your program of choice. Recall, for instance, the gamma parameter sliders in cmftStudio. This is all more of a personal preference than a rule of thumb, but adjusting the color keyvar in DR not only allows you to dim the brightness but also to tint your IEMs on the fly, in the case that you want to “tone map” your scene more consistently.

 

Gameplay vs Looks

 

It’s not controversial to say that it’s important to see where you’re going in a video game. Light, however, carries a distinct connotation for Dark Mod players. In furnishing your levels with ambient cubic lights, you may make it appear too bright for a player to consider it “stealthable”. In fact, it may end being un-stealthable in earnest, with the ambient cubic light contributing far too much brightness to the lightgem.

 

The “ai_see” keyvar is an invaluable help in dividing “gameplay” lights and those that are “just for show”. With ai_see set to 0, a light will not contribute to the lightgem level. Setting ambient cubic lights to “invisible” to the light gem should be done on a case-by-case basis, but we can all agree that an IEM that raises the ambiance of the scene to daylight levels should not leave the lightgem pitch black. Certainly, much deliberation on the part of the individual level designer is needed to ensure that the player doesn’t feel at odds with what they are seeing and what their lightgem is telling them.

 

Scalability Concerns

 

This tutorial has dealt with the problem of providing Dark Mod environments with more gradient, realistic looking ambient lighting through a reasonable workflow that can be undertaken by the intermediate mapper. Lighting one corridor for the purposes of show may have been easy, lighting an entire map is a different issue. The question of the scalability of IBL lighting in TDM is one that is currently beyond the scope of this tutorial. Plainly put, nobody’s put it to the test! How could they? I only informed you about the possibility of this approach just now, didn’t I?

 

I invite you to give this approach a try and share your results here. Since I am so obviously invested in this topic, be assured that I will personally investigate how well this method pans out in building the full level that our dear corridor is but a part of. In a future post, I hope to give you a detailed account of any problems I run in when scaling IEMs to a full level and how I troubleshoot them.

 

I’m aware that you may still be unimpressed with the time-vs-value proposition of the screenshots here provided. Maybe an IEM doesn’t look like it’s worth the effort. Be that as it may, it is just another tool in the toolbox of the industrious level builder. I have omitted several other lighting tricks I supplement my scenes with, purely for the sake of clarity. Keep in mind that in no way has this been a “showcase” of how good an IEM lit scene can look. That, too, I hope to provide once this level’s finished. Speaking of, I should probably stop typing and get back to actually making it. All that builder whistling in the background is getting on my nerves…

 

Important Links and Resources

 

Thank you so much for taking the time to read my tutorial. Below, you will find a list of important links, some repeated from above, some new and some mirror links, just in case.

 

The programs involved:

Lys, cmftStudio, Cubemapgen, ReNamer.

 

For Photoshop, you need:

Cubemap Operations and additionally, if you plan on using Lys,

Nvidia Texture Tools and Improved Export Layers to Files

 

Additional links, including mirrors:

 

ModifiedCubeMapGen.exe

A mirror of V1.66 from the Google Code Archive.

 

cmftStudio 32bit Windows binary

The GitHub page for cmftStudio does not provide x86 binaries. I had a friend compile the source code for me (and you), here it is. Being compiled from the latest code, this version has some differences to the installations offered on the main page. Fullscreen, for instance, works. Radiance map filtering, however, still seems to be broken. You can go in the .conf file with Notepad and adjust the settings in it, such as RAM allocation &c.

 

cmft.exe

cmftStudio is the “GUI counterpart for cmft”. This is the command line tool I previously mentioned. Curiously, downloads in the GitHub page for this project are available for both OSX and Linux, but not Windows. I’ve filled this gap; this is the Windows 64bit binary, again compiled by my friend for the sake of convenience. Note, you do not need this file in order to use cmftStudio!

 

ReNamer 6.9

Mirror link. A zip containing a portable version of ReNamer. Note that I have bundled in the Renaming Rules, so this is a two-in-one download.

 

Nvidia Photoshop Plugins, 32bit and 64bit versions.

Mirrors of the downloads available on Nvidia’s website.

 

Export Layers to Files.jsx

Mirror of the Gist file above.

 

 

 

 

 

 

 

 

[Fig. 27] May The Builder bless you with slick and efficient work.

 

[Tutorial: Image-Based Lighting Workflows for TDM]

Hello, everyone! In this multi-part, comprehensive tutorial I will introduce you to a new light type that has been available in The Dark Mod since version 2.06, what it does, why you would want to use it and how to implement it in your Fan Missions.

 

This tutorial is aimed at the intermediate mapper. Explanations of how to use DarkRadiant, write material files, etc. are outside of its scope. I will, however, aim to be thorough and explain the relevant concepts comprehensively. Let us begin by delineating the sections of the tutorial:

 

Part 1 will walk you through four, distinct ways to add ambient light to a scene, the last way using irradiance environment maps (or IEMs). Lighting a scene with an IEM is considered image-based lighting. Explaining this concept is not in the scope of this tutorial; rather, we will compare and contrast our currently available methods with this new one. If you already understand the benefits IBL confers, you may consider this introductory section superfluous.

 

Part 2 will review the current state of cubemap lights in TDM, brief you on capturing an environment cubemap inside TDM and note limitations you may run into. Three cubemap filtering applications will be introduced and reviewed.

 

Part 3 will go into further detail of the types of inputs and outputs required by each program and give a walkthrough of the simplest way to get an irradiance map working in-game.

 

Part 4 will guide you through two additional, different workflows of how to convert your cubemap to an irradiance map and unstitch it back to the six separate image files that the engine needs.

 

Part 5 will conclude the tutorial with some considerations as to the scalability of the methods hitherto explained and will enumerate some good practices in creating IEMs. Typical scenes will be considered. Essential links and resources will be posted here and a succinct list of the steps and tools needed for each workflow will be summarized, for quick reference.

 

Without further ado, let us begin.

 

 

Part 1

 

Imagine the scene. You’ve just made a great environment for your map, you’ve got your geometry exactly how you want it… but there’s a problem. Nobody can appreciate your efforts if they can’t see anything!

 

[Fig. 1] This will be the test scene for the rest of our tutorial — I would tell you to “get acquainted with it” but it’s rather hard to, at the moment.

 

The Dark Mod is a game where the interplay between light and shadow is of great importance. Placing lights is designing gameplay. In this example scene, a corridor with two windows, I have decided to place 3 lights for the player to stealth his way around. Two lights from the windows streak down across the floor and a third, placeholder light for a fixture later to be added, is shining behind me, at one end of the corridor.

 

Strictly speaking, this is sufficient for gameplay in my case. It is plainly obvious, however, that the scene looks bad, incomplete. “Gameplay” lights aside, the rest of the environment is pitch black. This is undesirable for two reasons.

 

It looks wrong. In real life, lights bounce off surfaces and diffuse in all directions. This diffused, omni-directional lighting is called ambient lighting and its emitment can be termed irradiance. You may contrast this with directional lighting radiating from a point, which is called point lighting and its emitment — radiance. One can argue that ambient lighting sells the realism of a scene. Be that as it may, suppose we disregard scary, real-life optics and set concerns of “realism” aside…

 

It’s bad gameplay. Being in darkness is a positive for the player avatar, but looking at darkness is a negative for the player, themselves. They need to differentiate obstacles and objects in the environment to move their avatar. Our current light level makes the scene illegible. The eye strain involved in reading the environment in these light conditions may well give your player a headache, figurative and literal, and greatly distract them from enjoying your level.

 

This tutorial assumes you use DarkRadiant or are at least aware of idtech4’s light types. From my earlier explanation, you can see the parallels between the real life point/ambient light dichotomy and the aptly named “point” and “ambient” light types that you can use in the editor. For further review, you can consult our wiki.

 

Seeing as how there is a danger in confusing the terms here, I will hereafter refer to real life ambient light as “irradiant light”, to differentiate it from the TDM ambient lights, which are our engine’s practical implementation of the optical phenomenon. A similar distinction between “radiant light” and point lights will be made for the same reason.

 

Back to our problem. Knowing, now, that most all your scenes should have irradiant light in addition to radiant light, let’s try (and fail, instructionally) to fix up our gloomy corridor.

 

[Fig. 2] The easiest and ugliest solution: ambient lights.

 

Atdm:ambient_world is a game entity that is basically an ambient light with no falloff, modifiable by the location system. One of the first things we all do when starting a new map is putting an ambient_world in it. In the above image, the darkness problem is solved by raising the ambient light level using ambient_world (or via an info_location entity).

 

Practically every Dark Mod mission solves its darkness problem¹ like this. Entirely relying on the global ambient light, however, is far from ideal and I argue that it solves neither of our two, aforementioned problems. Ambient_world provides irradiant light and you may further modulate its color and brightness per location. However, said color and brightness are constant across the entire scene. This is neither realistic, nor does it reduce eye strain. It only makes the scene marginally more legible. Let’s abandon this uniform lighting approach and try a different solution that’s more scene-specific.

 

[Fig. 3] Non-uniform, but has unintended consequences.

 

Our global ambient now down to a negligible level, the next logical approach would be hand-placed ambient lights with falloff, like ambient_biground. Two are placed here, supplementing our window point lights. Combining ambient and point lights may not be standard TDM practice, but multiple idtech4 tutorials extol the virtues of this method. I, myself, have used it in King of Diamonds. For instance, in the Parkins residence, the red room with the fireplace has ambient lights coupled to both the electric light and the fire flame. They color the shadows and enrich the scene, and they get toggled alongside their parent (point) lights, whenever they change state (extinguished/relit).

 

This is markedly better than before, but to be honest anything is, and you may notice some unintended side-effects. The AI I’ve placed in the middle of the ambient light’s volume gets omnidirectionally illuminated far more than any of the walls, by virtue of how light projection in the engine works. Moving the ambient lights’ centers closer to the windows would alleviate this, but would introduce another issue — the wall would get lit on the other side as well. Ambient lights don’t cast shadows, meaning they go through walls. You could solve this by creating custom ambient light projection textures, but at this point we are three ad hocs in and this is getting needlessly complicated. I concede that this method has limited use cases but illuminating big spaces that AI can move through, like our corridor, isn’t one of them. Let’s move on.

 

[Fig. 4] More directional, but looks off.

 

I have personally been using this method in my WIP maps a lot. For development (vs. release), I even recommend it. A point light instead of an ambient light is used here. The texture is either “biground1” or “defaultpointlight” (the latter here). The light does not cast shadows, and its light origin is set at one side of the corridor, illuminating it at an angle.

 

This solves the problem of omnidirectional illumination for props or AI in the middle of the light volume, you can now see that the AI is lit from the back rather than from all sides. In addition, the point light provides that which the ambient one cannot, namely specular and normal interaction, two very important features that help our players read the environment better. This is about as good as you can get but there are still some niggling problems.

 

The scene still looks too monochromatic and dark. From experience, I can tell you that this method looks good in certain scenes, but this is clearly not one of them. Sure, we can use two, non-shadowcasting point lights instead of one, aligned to our windows like in the previous example, we can even artfully combine local and global ambient lights to furnish the scene further, but by this point we will have multiple light entities placed, which is unwieldy to work with and possibly detrimental to performance.

 

Another problem is that a point light’s movable light origin helps combat ambient omnidirectionality, but its projection texture still illuminates things the strongest in the middle of its volume. I have made multiple experiments with editing the Z-projection falloff texture of these lights and the results have all left me unsatisfied. It just does not look right.

 

A final, more intellectual criticism against this method is that this does not, in a technical sense, supply irradiant light. Nothing here is diffuse, this is just radiant light pretending the best it can.

 

[Fig. 5] The irradiance map method provides the best looking solution to imbuing your scene with an ambient glow.

 

This is the corridor lit with irradiance map lights, a new lighting method introduced in The Dark Mod 2.06. Note the subtle gradients on the left wall and the bounced, orange light on the right column. Note the agreeable light on the AI. Comparing the previous methods and this, it is plainly obvious that an irradiance environment map looks the most realistic and defines the environment far better than any of the other solutions.

 

Why exactly does this image look better than the others? You can inform yourself on image-based lighting and the nature of diffuse irradiance, but images speak louder than words. As you can see, the fact of the matter is that the effect, subtle as it may be, substantially improves the realism of the scene, at least compared to the methods previously available to us.

 

Procuring irradiance environment maps for use in lighting your level will hereafter be the chief subject of this tutorial. The next part will review environment cubemap capture in TDM, the makeIrradiance keyword and three external applications that you can use to convert a TDM cubemap into an irradiance map.

 

 

 

1 “ Note that the color buffer is cleared to black: Doom3 world is naturally pitch black since there is no "ambient" light: In order to be visible a surface/polygon must interact. with a light. This explains why Doom3 was so dark ! “ [source]

 

 

 

Part 2

 

 

Cubemaps are not new to The Dark Mod. The skybox materials in some of our prefabs are cubemaps, some glass and polished tile materials use cubemaps to fake reflections for cheap. Cubemap lights, however, are comparatively new. The wiki page linked earlier describes these two, new light types that were added in TDM 2.05.

 

cubicLight is a shadow-casting light with true spherical falloff. An example of such a light can be found in the core files, “lights/cubic/tdm_lampshade_cubic”.

 

ambientCubicLight is the light type we will be focusing on. Prior to TDM 2.06, it acted as a movable, on-demand reflection dispenser, making surfaces in its radius reflect a pre-set cubemap, much like glass. After 2.06, the old behavior was discarded and ambientCubicLight was converted to accept industry standard irradiance environment maps.

 

Irradiance environment maps (IEMs) are what we want to make, so perhaps the first thing to make clear is that they aren’t really “handmade”. An IEM is the output of a filtering process (convolution) which requires an input in the form of a regular environment cubemap. In other words, if we want to make an IEM, we need a regular cubemap, ideally one depicting our environment — in this case, the corridor.

 

I say a snapshot of the environment is ideal for lighting it because this emulates how irradiant light in the real world works. All radiating surfaces are recorded in our cubemap, our ambient optic array as it were, then blurred, or convoluted, to approximate light scatter and diffusion, then the in-game light “shines” this approximation of irradiant light back to the surfaces.

 

There is a bit of a “chicken and the egg” situation here, if your scene is dark to begin with, wouldn’t you just get a dark irradiance map and accomplish nothing? In the captured cubemap faces in Fig. 6, you may notice that the environment looks different than what I’ve shown so far. I used two ambient lights to brighten up the windows for a better final irradiance result. I’ve “primed the pump”, so to speak. You can ignore this conundrum for the moment, ways to set up your scenes for better results, or priming the pump correctly, will be discussed at the end of the tutorial.

 

 

Capturing the Environment

 

The wiki has a tutorial on capturing cubemaps by angua, but it is woefully out of date. Let me run you through the process for 2.07 really briefly.

 

To start with, I fly to approx. the center of the corridor with noclip. I then type “envshot t 256” in the console. This outputs six .tga images in the <root>/env folder, simply named “t”, sized 256x256 px and constituting the six sides of a cube and depicting the entire environment. This is how they look in the folder:

 

[Fig. 6] The six cube faces in the folder.

 

Of note here is that I do not need to switch to a 640x480 resolution, neither do I need to rename these files, they can already be used in an ambientCubicLight.

 

 

Setting Up the Lights

 

For brevity’s sake, I’ll skip explaining material definitions, if you’ve ever added a custom texture to your map, you know how to do this. Suffice it to say, it is much the same with custom lights. In your <root>/materials/my_cool_cubemaps.mtr file, you should have something like this:

lights/ambientcube/my_test_IEM_light
{
	ambientCubicLight
	{
		forceHighQuality
		//cameraCubeMap	makeIrradiance(env/t)
		cameraCubeMap		env/t
		colored
		zeroClamp
	}	
}

We’ll play with the commented out line in just a bit.

 

Firstly, let’s place the actual light in DarkRadiant. It’s as simple as creating a new light or two and setting them up in much the same way you would a regular ambient light. I select the appropriate light texture from the list, “my_test_IEM_light” in the “ambientcube” subfolder and I leave the light colored pure white.

 

[Fig. 7] The corridor in DR, top view, with the ambient cubic lights highlighted. I can place one that fills the volume or two that stagger the effect somewhat. Remember that these lights still have a spherical falloff. Preference and experimentation will prove what looks best to you.

 

Please note that what the material we defined does is load a cubemap while we established that ambientCubicLights only work with irradiance maps. Let’s see if this causes any problems in-game.

 

I save the map and run it in game to see the results. If I already have TDM running, I type “reloadDecls” in the console to reload my material files and “reloadImages” to reload the .tga images in the /env folder.

 

[Fig. 8] Well this looks completely wrong, big surprise.

 

Wouldn’t you know it, putting a cubemap in the place of an irradiance map doesn’t quite work. Everything in the scene, especially the AI, looks to be bathed in slick oil. Even if a material doesn’t have a specular map, it won’t matter, the ambientCubicLight will produce specular reflections like this. Let’s compare how our cubemap .tga files compares with the IEM .tgas we’ll have by the end of the tutorial:

 

[Fig. 9] t_back.tga is the back face of the environment cubemap, tIEM_back.tga is the back face of the irradiance map derived from it.

 

As you can see, the IEM image looks very different. If I were to use “env/tIEM” instead of “env/t” in the material definition above, I would get the proper result, as seen in the last screenshot of part 1.

 

So it is that we need a properly filtered IEM for our lights to work correctly. Speaking of that mtr def though, let’s not invoke an irradiance map we haven’t learned to convert yet. Let’s try an automatic, in-engine way to convert cubemaps to IEMs, namely the makeIrradiance material keyword.

 

 

makeIrradiance and Its Limitations

 

Let’s uncomment the sixth line in that definition and comment out the seventh.

 

cameraCubeMap makeIrradiance(env/t)

//cameraCubeMap env/t

 

Here is a picture of how a cubemap ran through the makeIrradiance keyword looks like:

 

[Fig. 10] Say ‘Hi’ to our friend in the back, the normalmap test cylinder. It’s a custom texture I’ve made to demonstrate cubemap interactions in a clean way.

 

Hey now, this looks pretty nice! The scene is a bit greener than before, but you may even argue it looks more pleasing to the eyes. Unfortunately, the devil is in the details. Let’s compare the makeIrradiance keyword’s output with the custom made irradiance map setup seen at the end of part 1.

 

[Fig. 11, 12]

 

A closer look at the brick texture reveals that the undesired specular highlighting is still present. The normal map test cylinder confirms that the reason for this is the noisy output of the makeIrradiance keyword. The in-engine conversion is algorithmic, more specifically, it doesn't allow us to directly compare .tga files like we did above. Were we able to, however, I'm sure the makeIrradiance IEM would look grainy and rough compared to the smooth gradient of the IEM you’ll have by the end of this tutorial.

 

The makeIrradiance keyword is good for quick testing but it won’t allow you fine control over your irradiance map. If we want the light to look proper, we need a dedicated cubemap filtering software.

 

 

A Review of Cubemap Filtering Software

 

Here I’ll introduce three programs you can produce an irradiance map with. In the coming parts, I will present you with a guide for working with each one of them. I should also note that installing all of these is trivial, so I’ll skip that instructional step when describing their workflows.

 

I will not relay you any ad copy, as you can already read it on these programs’ websites. I’ll just list the advantages and disadvantages that concern us.

 

Lys

 

https://www.knaldtech.com/lys/

 

Advantages: Good UI, rich image manipulation options, working radiance/specular map filtering with multiple convolution algorithms.
Disadvantages: $50 price tag, limited import/export options, only available on Windows 64-bit systems.

 

cmftStudio

 

https://github.com/dariomanesku/cmftStudio

 

Advantages: Available on Windows, OSX and Linux, free, open source software, command line interface available.
Disadvantages: Somewhat confusing UI, limited import options, missing features (radiance/specular map filtering is broken, fullscreen doesn’t work), 32-bit binaries need to be built from source (I will provide a 32-bit Windows executable at the end of the tutorial).

 

Modified CubeMapGen

 

https://seblagarde.wordpress.com/2012/06/10/amd-cubemapgen-for-physically-based-rendering/

 

Advantages: Free software, quickest to work with (clarified later).
Disadvantages: Bad UI, only Windows binaries available, subpar IEM export due to bad image adjustment options.

 

 

Let’s take a break at this point and come back to these programs in part 3. A lot of caveats need to be expounded on as to which of these three is the “best” software for making an irradiance map for our purposes. Neither of these programs has a discreet workflow; rather, the workflow will include or exclude certain additional programs and steps depending on which app you choose to work with. It will dovetail and be similar in all cases.

 

 

Part 3

 

 

The aim of this tutorial is twofold. First, it aims to provide the most hands-free and time-efficient method of converting an envshot, environment cubemap to an IEM and getting it working in-game. The second is using as few applications as possible and keeping them all free software that is available for download, much like TDM itself.

 

The tutorial was originally going to only cover IEM production through Lys, as that was the app I used to test the whole process with. I soon realized that it would be inconsiderate of me to suggest you buy a fifty dollar product for a single step in a process that adds comparatively little to the value of a FM, if we’re being honest (if you asked me, the community would benefit far more from a level design tutorial than a technical one like this, but hey, maybe later, I’m filling a niche right now that nobody else has filled). This led me to seek out open-source alternatives to Lys, such as Cubemapgen, which I knew of and cmftStudio, which I did not.

 

I will preempt my own explanations and tell you right away that, in my opinion, cmftStudio is the program you should use for IEM creation. This comes with one big caveat, however, which I’m about to get into.

 

Six Faces on a Cross and The Photoshop Problem

 

Let’s review. Taking an envshot in-game gives you six separate images that are game-ready. Meaning, you get six, split cubemap faces as an output, you need six, split irradiance map faces as an input. This is a problem, because neither Lys nor cmftStudio accept a sequence of images as such. They need to be stitched together in a cube cross, a single image of the unwrapped cube, like this:

 

[Fig. 13] From Lys. Our cubemap has been stitched into a cross and the “Debug Cube Map Face Position” option has been checked, showing the orientations of each face.

 

In Lys only panoramas, sphere maps and cube maps can be loaded into the program. The first two do not concern us, the third specifically refers to a single image file. Therefore, to import a TDM envshot into Lys you need to stitch your cubemap into a cross. Furthermore, Lys’ export also outputs a cubemap cross, therefore you also need to unstitch the cubemap into its faces afterwards if you want to use it in TDM.

 

In cmftStudio you can import single map faces! Well… no, you can’t. The readme on GitHub boasts “Input and output types: cubemap, cube cross, latlong, face list, horizontal and vertical strip.” but this is false. The UI will not allow you to select multiple files on import, rendering the “face list” input type impossible.² Therefore, to import a TDM envshot into cmftStudio you need to stitch your cubemap into a cross. Fortunately, the “face list” export type does work! Therefore, you don’t need to unstitch the cubemap manually, cmftStudio will export individual faces for you.

 

In both of these cases, then, you need a cubemap cross. For this tutorial I will use Adobe Photoshop, a commercial piece of software, to stitch our faces into a cubemap in an automated fashion (using Photoshop’s Actions). This is the big caveat to using cmftStudio, even if you do not want to buy Lys, PS is still a prerequisite for working with both programs.

 

There are, of course, open source alternatives to Photoshop, such as GIMP, but it is specifically Photoshop’s Action functionality that will power these workflows. GIMP has its own Actions in the form of Macros, but they are written with python. GIMP is not a software suite that I use, neither is python a language I am proficient with. Out of deference for those who don’t have, or like working with, Photoshop, I will later go through the steps I take inside the image editor in some detail, in order for the studious reader to reconstruct them, if they so desire, in their image editing software of choice. At any rate, and at the risk of sounding a little presumptuous, I take it that, as creative types, most of you already have Photoshop on your computers.

 

 

 

 

² An asterisk regarding the “impossibility” of this. cmftStudio is a GUI for cmft, a command line interface that does the same stuff but inside a command prompt. I need to stress that I am certain multiple faces can be inputted in the command line, but messing with unwieldy prompts or writing batch files is neither time-saving nor user-friendly. This tutorial is aimed at the average mapper, but a coder might find the versatility offered in cmft interesting.

 

The Cubemapgen Workflow

 

You will have noticed that I purposefully omitted Cubemapgen from the previous discussion. This is because working with Cubemapgen, wonderfully, does not need Photoshop to be involved! Cubemapgen both accepts individual cubemap faces as input and exports individual irradiance map faces as output. Why, then, did I even waste your time with all the talk of Lys, cmftStudio and Photoshop? Well, woefully, Cubemapgen’s irradiance maps look poor at worst and inconsistent at best.

 

Comparing IEMs exported from Lys and cmftStudio, you will see that both look practically the same, which is good! An IEM exported from Cubemapgen, by default, is far too desaturated and the confusing UI does not help in bringing it to parity with the other two programs. If you work solely with Cubemapgen, you won’t even know what ‘parity’ is, since you won’t have a standard to compare to.

 

[Fig. 14] A comparison between the same irradiance map face, exported with the different apps at their respective, default settings. Brightened and enlarged for legibility.

 

This may not bother you and I concede that it is a small price to pay for those not interested in working with Photoshop. The Cubemapgen workflow is so easy to describe that I will in fact do just that, now. After I do so, however, I will argue that it flies in the face of one of the aims of this tutorial, namely: efficiency.

 

 

Step 1: Load the cubemap faces into Cubemapgen.

 

Returning to specifics, you will remember that we have, at the moment, six .tga cubemap faces in a folder that we want to convert to six irradiance map faces. With Cubemapgen open, direct your attention to these buttons:

[Fig. 15]

 

You can load a cubemap face by pressing the corresponding button or using the hotkey ‘F’. To ensure the image faces the correct way, you must load it in the corresponding “slot”, from the Select Cubemap Face dropdown menu above, or by pressing the 1-6 number keys on your keyboard. Here is a helpful list:

 

X+ Face <1> corresponds to *_right

X- Face <2> corresponds to *_left

Y+ Face <3> corresponds to *_up

Y- Face <4> corresponds to *_down

Z+ Face <5> corresponds to *_forward

Z- Face <6> corresponds to *_back

 

...with the asterisk representing the name of your cubemap. With enough practice, you can get quite proficient in loading cubemap faces using keyboard shortcuts. Note that the ‘Skybox’ option in the blue panel is checked, I recommend you use it.

 

Step 2: Generate the Irradiance Map

 

[Fig. 16] The corridor environment cubemap loaded in and filtered to an irradiance map. The options on the right are my attempt to get the IEM to look right, though they are by no means prescriptive.

 

Generating an IEM with Modified CubeMapGen 1.66 is as easy as checking the ‘Irradiance cubemap’ checkbox and hitting ‘Filter Cubemap’ in the red panel. There are numerous other options there, but most will have no effect with the checkbox on. For more information, consult the Sébastien Lagarde blog post that you got the app from. I leave it to you to experiment with the input and output gamma sliders, you really have no set standard on how your irradiance map is supposed to look, so unfortunately you’ll have to eyeball it and rely on trial and error.

 

Two things are important to note. The ‘Output Cube Size’ box in the red panel is the resolution that you want your IEM to export to. In the yellow panel, make sure you set the output as RGB rather than RGBA! We don’t need alpha channels in our images.

 

Step 3: Export Irradiance Map Faces

 

Back in the green panel, click the ‘Save CubeMap to Images’ button. Save the images as .tga with a descriptive name.

 

[Fig. 17] The exported irradiance map faces in the folder.

 

These files still need to be renamed with appropriate suffixes in order to constitute a readable cubemap for the engine. The nomenclature is the same as the table above: “c00” is the X+ Face, to be renamed “right”, “c01” is the X- Face and so on. Right left, up down, forward and back. That’s the order!

 

This is all there is to this workflow. A “cameraCubeMap env/testshot” in the light material will give us a result that will look, at the very least, better than the inbuilt makeIrradiance material keyword.

 

[Fig. 17] The map ended up being a little bright. Feel free to open Fig. 4 and this in seperate tabs and compare the Lys/cmft export with the cubemapgen one.

 

 

A Review of the Workflow

 

Time for the promised criticism to this workflow. I already stated my distaste for the lack of a standardised set of filtering values with this method. The lack of any kind of preset system for saving the values you like makes working with Cubemapgen even more slipshod. Additionally, in part 2, I said that Cubemapgen is the fastest to work with, but this needs to be qualified.

 

What we just did was convert one cubemap to an irradiance map, but a typical game level ought to use more than a single IEM. Premeditation and capturing fake, “generic” environment cubemaps (e.g. setting up a “blue light on the right, orange on the left” room or a “bright skylight above, brown floor” room, then capturing them with envshot) might allow for some judicious reuse and keep your distinct IEM light definition count down to single digits, but you can only go so far with that.

 

I am not arguing here for an ambient cubic light in every scene either, certainly only those that you deem need the extra attention, or those for which the regular lighting methods enumerated in Part 1 do not quite work. I do tentatively assume, though, that for an average level you would use between one and two dozen distinct IEMs. Keep in mind that commercial games, with their automated probe systems for capturing environment shots, use many, many more than that.

 

With about 20 cubemaps to be converted and 6 faces each to load into Cubemapgen, you’ll be going through the same motions 120 whole times (saving and renaming not included). If you decide to do this in one sitting (and you should, as Cubemapgen, to reiterate, does not keep settings between sessions), you are in for a very tedious process that, while effective, is not very efficient. The simple fact is that loading six things one by one is just slower than loading a single thing once!

 

The “single thing” I’m referring to is, of course, the single, stitched cubemap cross texture. In the next part, I will go into detail regarding how to make a cubemap cross in Photoshop in preparation for cmftStudio and Lys. It will initially seem a far more time-consuming process to you than the Cubemapgen workflow, but through the magic of automation and the Actions feature, you will be able to accomplish the cubemap stitch process in as little as a drag-and-drop into PS and a single click. The best thing is that after we go through the steps, you won’t have to recreate them yourself, as I will provide you with a custom Actions .atn file and save you the effort.

 

I advise you not to skip the explanations, however. The keen-eyed among you may have noticed that you can also load a cube cross in Cubemapgen. If you want to use both Cubemapgen and Photoshop together to automate your Cubemapgen workflow, be aware that Cubemap gen takes crosses that have a different orientation than the ones Lys and cmftStudio use. My macros (actions) are designed for the latter, so if you want to adjust them for Cubemapgen you would do well to study my steps and modify them appropriately.

 

For the moment, you’ve been given the barebones essentials needed to capture an envshot, convert it to an irradiance map and put it in your level at an appropriate location, all without needing a single piece of proprietary software. You can stop here and start cranking out irradiance maps to your heart’s content, but if you’re in the mood for some more serious automation, consider the next section.

[Beta Testing 2.07]

models/darkmod/architecture/doors/frenchdoor.ase, the glassdoor from Goldwell's missions that was included in the core, lacks the material textures/darkmod/glass/milky_lowfrob. I suggest creating it, the name implies it's just a regular milky glass without the frob highlight, but you may want to contact GW or simply go into his latest missions and see how he defined it in his .mtrs.

 

edit: just so I don't end up triple-posting, http://bugs.thedarkmod.com/view.php?id=4687

 

I have not forgotten about this. If there are any protests about nobody being available to test whether all the assets will integrate properly, I'll test each personally if need be.

[Beta Testing 2.07]

textures/darkmod/wood/panels/molding_white_painted_s does not exist. The offending material is textures/darkmod/wood/panels/molding_white_painted (e: and the _ns version!!)and no other molding has a specular map declared. Unless it's in the SVN, I suggest fixing the mtr.

 

e, @spring, i've not made bugtracker entries, i'm usually on it when it comes to mantis but i'm both busy with mapping and hope that singular texture fix requests don't need their separate bug entry.

[Beta Testing 2.07]

Problem regarding shadow maps (r_shadows 2):

 

The "Shadow Softness" slider in the GUI has a range between 0 and 5. At r_softshadowsradius = 0, the shadows will disappear. If the player turns off soft shadows completely, the lights will disappear also. This is all on a spotlight, so I actually believe this is the same bug I reported with regards to spotlights in the BFG beta thread. I still don't know what your guys' stance is on the default value for the SS radius, whether it be positive or negative. At any rate I recommend changing the minimum value for the GUI slider at the very least, because it will break projected lights when it's set to zero.

 

SinglePass 1 still disables transparent textures from casting proper shadows.

 

On beta two I can confirm parallel lights continue to be on stencil, I can also confirm clean snowflakes.

 

e: BD reported a missing texture last page, I can confirm that too but it's not 2.07 specific, I saw it before the beta.

[Beta Testing 2.07]

Is it true that glass surfaces will never overlap each other?

 

2.05 and prior, in the case of two glass surfaces, one would not be visible behind the other (if that is what you're asking clarification for). It indeed looked hacky and was a limited case but I noticed it enough to remember.

[Wishlist For Darkradiant]

How about a filtered search option? Instead of searching and scrolling through the search matches inside the entire list of entities/textures/etc. the windows would filter the folder tree to just show the entries in the list that match your typed search.

[Beta Testing 2.07]

I've reopened #4686. Lest you forget, I had already provided a test map in there. r_fboseperatestencil plainly disables r_useFBO and prevents it from being on. In-game AA is the only way for the heathaze materials to appear correct with FBO on.