Forum posts

Sweet deal. Thanks for the info. This saves me a chunk of change.

Can we discuss this elsewhere? My thread was hijacked after only the second post.

Hey, kids.

I just ordered an EVGA GTX460 a moment ago, and am thinking about going the SLI route with a second one in a few months when I work up a little more expendable income. I'm running everything off of MSI's NF750-G55 mainboard. The board has been great, with PCI-e running at 16x speed when a single slot is occupied. The issue is that the two PCI-e slots clock themselves down to 8x speed when SLI is enabled.

There seems to be very little information to find online regarding what the slot speed on a motherboard's PCI-e slot does to a graphics card's bottom-line performance. My question is, given these circumstances, should I also shop around for a new motherboard that allows both PCI-e slots to clock at 16x speeds if I do decide to set up SLI? Will both slots operating at 8x speeds nullify any potential performance benefits of the additional graphics card?

Thanks.

I would be with Huntey on this one if it weren't for your compile log, but it's definitely clear RAD isn't doing a full compile.. It might still be worth it to throw a cordon around the whole map and compiling to be absolutely sure it isn't a leak. You might also want to try opening both this map and a brand-new, empty map up at the same time and copying all the geometry and props over from the old to the new, in case there's some unseen bug hiding in the old .VMF.

I have vague memories of a similar problem that I was experiencing a while ago. Is Windows returning an error that vrad.exe has stopped working, or does the progress counter in the compile window simply stop? If it's the former of the two, I found that vrad.exe seemed to be crashing after it had completed all of its lighting calculations and was preparing to stop, so I could simply let it "crash" and the map, itself, would be compiled successfully.

If the progress counter just stops, try killing vrad.exe through the task manager and then see if you get properly compiled results; killing it should tell the compiler to move on to the next step in the compile process, if I'm not mistaken.

Rebuild your cubemaps after you've BSPZipped everything together. I don't know why it seems to be throwing them out after you've used BSPZip, but when you rebuild them they get saved into the .BSP, anyway.

It's a great laptop, I'll agree. But damn... that's expensive as hell. A friend of mine found one similar to that model (perhaps a few tiers down in the processor and graphics department, if my memory serves me) except it came with a BluRay reader/DVD burner combo drive and a 2-year warranty that was all on sale for $1100. I think you could surely do a hell of a lot better than $1600+.

http://www.notebookcheck.net/

Also a good resource. These folks benchmark hardware (namely, notebook graphics cards) and show you a comparison across the spectrum. It's pretty handy for getting your bearings and understanding how the particular setup you're looking at stacks up against what you could end up getting. Just punch the graphics card model into the search bar.

http://slickdeals.net/

Keep your eyes peeled. Every once in a while, a manufacturer will put up a really nice deal and users will discover it and submit it to this site. It might make your search a little easier.

If you're going to go with one of the major manufacturers, the general rule I try to follow is to only consider buying products that are being put on sale. Since building a laptop is probably a little more involved than you'd like to be, you're at the mercy of whatever the manufacturers want to charge. You can get some pretty bangin' deals, but you've gotta be patient.

It's like sex, but for your eyes:

It would be worth your while to remove everything from the motherboard except the CPU, CPU fan, and RAM and remove the motherboard from the case. Then try starting it out in the open like that. I ended up having a really strange issue once where the motherboard, processor, and everything else worked outside the case. When I installed everything inside the case, one of the standoffs in the case was touching a part of the PCB of the motherboard and shorting some of the leads, causing it to immediately turn off after turning on.

That said, the evidence seems to be pointing to a dead mobo. Hopefully this test will prove that otherwise.

Maybe? I'm still learning about ssbumps. I don't really know how much you can really deal with that though.. Like I said, it may be an inherent issue with ssbumps.

What the heck is that pixelation all about? see the small squares?

That's the texture compression in the normal map that gets applied by default when you throw it into vtex.exe. The file size is smaller, but it screws up the normal data near sharp transitions. No good.

Assuming you aren't using VTFEdit, when you compile your texture for the normal map, create a .txt file with the same name as the normal map and save this in it, with quotations:

"normal" "1"
"nocompress" "1"

Then drag-and-drop that onto vtex.

I love XSI.. but the support for it is almost non-existent. The SMD tools for it are ancient, too, especially the import function. It's functional, but if you wanna import a decompiled model that's been rigged, all you get are the nulls; no bones, no animation controllers, nada. Yuck.

I guess the "best" choice in this matter is 3ds Max, but if you've got a good exporter for Blender, more power to you. Start crankin' out those models, sir!

@Atom:

I'm not sure what causes that.. I think it has to do with how they changed the math that calculates the surface normal. You can sort of see how the pixels of the ssbump map don't really blend and transition as smoothly as they do in the traditional method. This sort of issue is present in the ssbumps Valve, themselves, have put out too. It seems to be a tradeoff between an overall upgrade in lighting behavior with a hit in absolute accuracy and up-close detail.

I guess that leaves it up to you as far as which method is better for a given situation.

Also, I don't know how this works with world geometry textures, but on models, you can have albedo and normal maps whose dimensions don't match, and the engine will scale them in such a way that their edges will match. If you want more detail in the normal map, it might be worth trying to make one at twice the resolution and see if it scales correctly in-game. This way, you'd get 4 texels of normal map data for every individual texel in the albedo, diminshing that stair-stepping effect you're seeing in the engine.

Hell yeah, Mass Effect was awesome. I have an old save file I could make use of to start Mass Effect 2, but I wanted to play through 1 again cos it was so excellent.

I understand they got rid of overheating and added ammunition, which is sort of a weird decision. It could go either way in terms of gameplay benefit..

Making gibbing props is a lot of fun. It's so satisfying to see your efforts come alive in-game like that.

I want to begin work on a metrocop replacement model, just so I will have fought my way through the whole process. It's so cumbersome, though, getting all the vertex weights correct. Fortunately, you can compile it with the existing character animations, so no headaches there!

Yes, I made the same mistake. You are trying to make the ssbump from a b&w heightmap, but it doesn't work that way. You have to create the normal map first, and then use that normal map to create the ssbump map

You can make an ssbump from a heightmap if you use Valve's tool that's included in the Orange Box SDK. Info here.

Also:

And what's a dudv map?

dudv maps are only necessary when running the game in DX 8. DX 9 and higher use the normal map for refraction calculations, and the dudv map can be eliminated if you don't plan on making whatever your project is DX 8-compatible.

.. Just fyi.

And yes, Valve is the company that developed ssbumps, and are the only folks who've implemented it.

Before this you would normally fake some lighting on the original texture (that's the diffuse) so it looked more realistic in-game. You don't have to do that now because ssbumps can take care of it.

So much better stated than my 11-line-long, jargon-filled explanation.

Sure.

When Valve developed ssbumps, they combined ambient occlusion element, aka the "natural" shadowing that occurs when surfaces that face each other are near (read this if you're unfamiliar), with the normal data that's contained within the normal map for a given texture. Ambient occlusion is really handy in game art because it implies 3-dimensionality and a "sense of proximity" among the elements within a texture, but when painted into the albedo, it's totally static. The reason why it's contained within the normal map instead of the albedo/diffuse is that, with self-shadowing normal maps, the ambient occlusion is meant to be directional, and disappear when it's directly illuminated, creating a more dramatic and more accurate result. This means that if you paint any actual light into the albedo, it essentially eliminates the effect the ssbump is trying to achieve.

Here's a shot of one of L4D's brick textures, as seen in Hammer. Hammer doesn't render normal maps in its 3D viewports, so what you're looking at is purely the albedo:See how flat-looking it is? That effect is totally eliminated in-game, when the AO of the ssbump starts working its magic:I lit the wall from below to show you how much more natural the result is when using ssbumps on textures that are lit from bizarre or unusual angles. Because no light/AO is in the albedo, you get both directional highlights AND directional AO, and lighting it from any angle will still produce an accurate result.

Fire up Hammer for Half-Life 2 some time and look at the brick textures, and then compare them to some found in Left 4 Dead; you'll quickly spot the difference. I hope I haven't confused you any more than you already are.

I don't see what so-called special feature ssbump offers

.. You don't see the directional shadows being cast on the far side of each tile? The effects of the ssbump would probably be more apparent on a texture that has more intense 3-dimensional elements in it.

Probably the best feature they offer is the lack of any need to paint any actual light into the diffuse. This makes the texture look much more believable when illuminated from below or from the sides - directions from which you would never paint light into the diffuse - or when working with ground textures. Take a closer look at the brick wall that's next to the fire in the fist alleyway of No Mercy or the gravel-covered ground of the construction site in Dead Air to get a better idea of their effects, Striker.

Edit: Oh dang, we just shut him down, completely.

They did? Where?

I've seen some folks implement parallax mapping into the Source engine with some pretty good-looking results; I had no idea Valve actually went ahead and did that. Why would they go through the trouble of implementing it just to remove from the engine it when EP2 was released?

Valve wrote up the technology behind the process in this paper. It's pretty brilliant stuff.

As for my texture, Soup, I totally agree with you. The diffuse texture is piss-ugly in terms of coloring (the lighting isn't helping, either), but that was sort of a secondary concern I had for the texture. A few ssbump projects of mine prior to this derived the heightmap for ssbump generation from the diffuse texture after I had done a little doctoring (the results sucked). For this one, I started by painting a heightmap first, then used that as a reference for generating the diffuse. The results look marginally better, but really don't stack up at all in comparison to the artwork that the Interloper had posted.

The more I look at that screenshot, speaking of which, the less I am convinced that it's just an ssbump map in action there. It almost looks parallax mapped, but the artist only mentioned creating a normal map in his post, so I guess he just did a really good job. I can't get over how accurately it portrays the 3-dimensionality of the diffuse texture; I really want to find out what his process was!

And as for baking normals in a modeling app, that's always a good option, but I don't have any sculpting app to work with; just XSI. I want to see if I can figure out a decent process for generating accurate results just in Photoshop. Oh, and when I said, "hand-generated ssbump," I meant, "hand-generated heightmap that was thrown into Valve's compiler."

Cha!

Above: Hand-painted rock texture (it doesn't look like rock but you'll see why below.
Below: Hand-painted rock texture with a hand-generated ssbump applied to it:These things are a real pain to get decent-looking. You end up having to paint your textures with absolutely no lighting or AO to speak of, which makes using photographic references in the albedo next to impossible. That said, those two elements are both entirely dealt with when the heightmap is compiled into the ssbump and the ssbump is rendered in-game, which can be pretty handy. Your heightmap has gotta be spot-on, though; mine isn't.

I was inspired by this screenshot and artist posted on Interlopers a while back. Wish I had Shopping skills like he has...:

Punched in "Ralph Vaughan Williams" as the station seed 4 days ago and haven't "Disliked" a song yet!

Map to classical music. It's zen-like.

BEHOLD.The first test.. it's a little messy and it screws with your eyes a bit.Tree! The 3D effect is a little less apparent because of how far from the cameras the tree was, but it's still pretty visible near the base.I was struggling to find some places in my house with a lot of regularly-spaced 3D elements. The counter did a pretty decent job; I like the champagne glass especially...... and flowers do an even finer job!

Taking these shots in such a way that your eyes don't want to roll out of their sockets is a little tricky. The first shot has the point of convergence for the two cameras relatively close; it makes looking at the edges of the photograph a little nauseating. The last three have the cameras' orientations nearly parallel, and I think it works quite a bit better. It's a shame that red-cyan anaglyph 3D glasses screw with color as much as they do. We'd probably see a lot more of this kind of work, otherwise.

$ssbump

^^ Problem.

What you have posted is a regular normal map, not an SSbump map.

http://developer.valvesoftware.com/wiki/$ssbump

Remove that line from the .VMT and the normal map should begin working correctly. Furthermore, the reflection mask for textures utilizing normal maps is located in the alpha channel of the normal map. I'm not certain if that is ignored if no alpha channel is saved in the normal map, but you may want to try adding just a completely white alpha channel to the normal map, and adding "$normalmapalphaenvmapmask" to the VMT somewhere.

It's also worth noting that there is a LOT of light already found in the base texture; to add to what Urby has mentioned, it may be more difficult to see how well the normal map is behaving with all that light in the texture showing through as well. Just keep that in mind.

Source being so model and prop heavy is becoming a nuisance since I still can't get a model compiled for source, even then would it look as standardly good as the rest of the assets.

What problems are you running into?

It's really dependent upon how much detail you need. If constructing the column from brushes provides the detailing you need (especially considering the wonders a good texture can do for adding detail), then make it a func_detail and don't bother wasting time to create a model. If, however, the column needs detail that exceeds the services of CSG (IE, if it needs good rounding or detail that is smaller than 1 Hammer Unit by 1 Hammer Unit), the model would be the best route.

It's certainly worth pointing out that model geometry is cheaper to render than world geometry, and you'll suffer less of a performance overhead from turning world geometry into models. It's also worth pointing out that models take several times longer to produce than brushed shapes, and also don't illuminate as cleanly as world geometry does.

It would be worth it to look at how Valve deals with this issue. Just noclip around some of their maps and look at how some details are modeled and some are brushed. Just remember that turning geometry into func_details is your best friend when it comes to wrestling with compile times.

I hope this helps ya!

Looks good. What program is that? Cos you're right - learning Max or XSI or some other, more "main-stream" modeling program will quickly do away with any problems of getting models into Source.

What do you plan to do with this model? If you intend it to be a view model, the only advice I might give would involve adding a few more polygons to the handle of the gun to smooth it out. If you intend on making it a world model for NPC's to wield, on the other hand, you could probably stand to remove a few polygons until just the basic shape remains, and imply any roundness in how you shade the weapon's texture.

If you don't intend on using it for either of the above two purposes, please ignore everything I just said.

So let me make sure I understand the basic idea of what you're trying to accomplish here..

You want to generate a texture that incorporates the lighting in the original texture with the shadowing and highlighting effects that the bump map would provide, thereby baking said shadows and highlights into the original texture, itself, in addition to the flat lighting? Am I close?

I'm not familiar with many modeling packages (only one, to be exact), but I know that XSI has a "bake albedo" function included with Ultimapper, which will allow you to essentially bake whatever the surface of the model looks like into a single texture, bump maps and all. I wouldn't be surprised if other modeling packages include such a feature... the process you'll likely have to follow is this:

1 - Apply the original texture to a square polygon
2 - Apply the bump map
3 - Add a light to the scene to cause the bump map to do something.
4 - Find whatever function your program can provide that will sandwich everything together for you

If you can't seem to find anything, you can use a quick and dirty method that I use to "bake" texture effects without any actual specialized program to help:

1 - Get a square polygon and apply your texture to it
2 - Apply any other texture effects like normal maps or ambient occlusion or whatever
3 - Create an orthographic camera whose aspect ratio is 1:1 and position it so the square polygon fills its entire screen space exactly
4 - Configure your renderer so that there is sufficient antialiasing and enable any necessary rendering effects to get the texture effects to work correctly.
5 - Render. Wait. Wank, perhaps.
6 - The result will be a render of the polygon with everything working together: essentially, you'll have a texture with everything sandwiched down into a single item.

... Assuming I answered the question you actually needed to have answered, the above method can be used in any modeling app that offers the ability to render. I hope this was helpful!

I remember my friends and myself discovering cartridge tilting with N64 games last year. We began screwing around with Super Mario 64 - tiling the cartridge would yield screwed up sound and animations. If the cartridge was called on to load anything, the game would freeze and you'd need to reset the system, but if you reseated the cartridge correctly before doing anything like changing areas or talking to characters, you could resume playing and then tilt it again, and the game would continue to function.

I am a fan of Louis Armstrong.

This article may be of interest to you, Satchmo:

http://www.clinicaplanas.com/fundacion/articulos/articulo8/articulo8.htm

It outlines "Satchmo's Syndrome," so named because of a similar injury that Louis Armstrong, himself, sustained during his career, forcing him to sit out from playing for a year.

I'm a music student in my sophomore in college and I suffered a similar malady my last year of high school. This injury was on the lower edge of my upper lip, just left of center (where the mouthpiece rim rests). It became enough of a problem that I needed a surgeon to go in to excise the crappy bits and stitch the healthy bits back together, with some apparently good results. I think I have the surgery photos lying around somewhere, if you'd like to take a look at them (Hopefuly you won't be on your lunch break, either ). Neat stuff.

Anyway.. about my name.

I have a hard time remembering the actual origin of my name.. the only memories I have are of my brother and myself at young ages, stuck on long car trips, trying to entertain ourselves by coming up with as many oxymorons as we could. Rotator Splint happened to be (a crappy) one that stuck out in my memory, so when I registered, I chose it. I hate it now.

I usually set my Steam alias to "Aggressive Napkin" these days; yet an other nonsensical imagining after staring at a blank "Name:" text field for 20 minutes. At least that one is a little less bizarre.

I really like what the AO in that engine does for the scene. Details really pop because of it. I will agree that it's a little on the strong side, though. In any case, very nice looking!

Valve has done some pretty fantastic stuff with Source, but I've got to admit that it's beginning to look a little dated to me..

We're golden.

Hell yeah, I'll give some of those knives a shot. My modeling skills are fairly adequate, but texturing would likely pose a more challenging obstacle to overcome with some of these ones, especially in the TF2 style. My purpose with this particular project is to get a working replacement for the Spy's knife compiled. Once I have that whole process ironed out (I use XSI, so the bullshit with the weightmaps has been getting in my way with this stuff for years), I'll begin working on some cooler-looking and more detailed knives for him. The default knife is sort of neat.. but so bland and uninteresting.

Good thing us modders exist.

I like what you've done there
But you're using Bears as a reference

Heheheheh, yeah.. but it was the only real-world, physical reference I had on hand.

I like this one much more:No smoothing errors with flat handles! I used one reference picture (not as a rotoscope) and free-handed much of the detailing. I can't actually figure out what make and model this particular knife is - I think it's a 'budget' line of knives from a more obscure company. I just chose it cos the detailing looked neat.

I think I need to make the screws at the ends of each handle larger (the screws in their current form would require some pretty tiny hex keys!), and I just noticed that I left a groove out of the top edge of the blade; I'm too lazy to put it in and re-render it, so just use your imagination.

Hey folks.I recently upgraded the components in my computer because they were having some real trouble keeping up with the games I was running. There has been a marked improvement, but there are some recurring issues I keep running into with Source than don't seem to go away, no matter what hardware I have installed.

Namely, as you can see from the shots above, I'm getting periodic hitches when running a game. The framerate is just fine, and the space between each hitch is glass-smooth, but 3 or 4 times a second, +showbudget shows a spike in seemingly random readouts. This problem is unique to Source Engine games, and becomes more pronounced when playing networked Source games, like Team Fortress 2.

What I find so irritating is that this issue is nowhere to be found in systems that my friends have, whose hardware is considerably older and more out-dated than mine. Moreover, I don't really know where to start in trying to sort this out; dropping settings does nothing, and even though +showbudget can be affected by background applications, stopping every process that I can halt safely and even a fresh installation of Windows don't do anything to resolve it. The only conclusion I can come to is that there is some bottleneck in the hardware.

This is what I have under the hood:

• MSI NF750-G55 Motherboard
• AMD Phenom II X2 Black Edition @ 3.1 GHz
• 4 GB DDR3 @ PC 1600 RAM
• nVidia GeForce 260 w/ 512 MB GDDR3
• 2x Seagate Barracuda 250 GB HHD's @ 7200 RPM
• Windows 7 Professional, 64-bit

Thoughts?

There are some pretty nasty smoothing issues on the handles I can't seem to resolve. This model is the first iteration of a replacement for the Spy's knife, if I can get compiling TF2 models figured out..

I have to get that smoothing cleaned up; otherwise the weirdness will show through when the player is cloaked and the handles of the knife have become translucent.

Weird. Ordinarily, I would accuse overheating or poorly constructed geometry in Hammer of being the cause of those rendering issues, but since they render just fine elsewhere.. Try copying the probematic geometry into a new, blank Hammer map and see if they appear there too.

To answer your first question about func_areaportals, you need to understand a little about how Source renders its worlds. Maps, upon compiling, are split into hundreds of individual sections called "leaves." These sections consist of all the explorable space available to the player, and the reason for doing this is to maximize performance. The engine analyzes the leaves the player is in at runtime, and if the leaf a player is in can draw an unobstructed line to any other leaf, that outlying leaf is drawn, while ones that can't be "seen" by the player's leaf are not rendered.

Func_areaportals are a way to force the engine not to render a leaf or section of leaves that are still visible to the player, no matter what the case. The section to be closed to the player needs to be sealed completely by world geometry and func_areaportals; if it isn't, you'll end up with a leak. When the player is the appropriate distance from all the areaportals such that they're all closed, the entire set of leaves are closed, and rendering them stops.

This can be really handy for openings of buildings in large, expansive spaces. When the player is too far away from the building to see into the windows, but too close for the engine to know that it shouldn't render the building's interior, func_areaportals can prevent rendering without any overtly noticable change to what the player sees.

All that said, it won't fix the rendering fuckups.

Sounds like I'll be getting one in that case, Luke

I'll vouch as well, it's a handy little processor. I bought the X2 variant last semester in hopes of unlocking some of the cores while still saving a little change. I wasn't able to, but the two cores still pack a hefty punch. It ended up ridding me of just about all my performance hitches in TF2.

An other satisfied customer.

That's why people elect to walk down stairs.

... Weird. That should be working fine. My only guess is that the file path for $cdmaterials should be in quotations. Also, make sure the .VMT is actually found in the folder that $cdmaterials references, and make sure the .VTF that the .VMT references is in its respective folder, as well.

On a side note (time for a bit of teaching!), the .VTF doesn't actually need to be in the same folder that $cdmaterials calls for; all that needs to be there is the .VMT, with it referencing the file path to wherever the .VTF is stored. This is pretty handy for storing and organizing your texture and material files in whatever way you'd like, and allows for a single texture file to be referenced by several .VMTs, eliminating the need for any duplicate .VTFs.

If you still can't get the confounded thing working after some troubleshooting, you can always host the source files and I can take a look at getting them compiled.

We need to see the contents of your .QC and .VMT. The steps you posted look just fine to me. I'm betting my money on the possibility that there's a syntax error somewhere in one of those two files.

@Unbreakable:

Neat model; I really want to get into character modeling, but I haven't had any project ideas come along that spike my interest in starting a project: only a few half-ideas with no patience to back them up. For some time, I was working on a Stormtrooper character...... but that's about as far as I got. It's a pretty major time commitment, so if you get yours finished and in-game, it'll be more than I've ever done.

Good luck, sir.

Wow, that is pretty simple.

For some reason, I just can't bring myself to use VTFEdit on any regular basis. I guess I just like seeing what's going on with all the files I'm compiling. I should probably get over that and avoid future headaches.

Glad to know things worked out, in any case. It's really handy to familiarize yourself with how to work custom materials into Source. New textures can bring some real spice to an old game.

You can use VTFEdit, which is pretty handy, but I'm an old skooler, and use the command line programs manually. There are tons of guides on the internet, including the VDC, detailing the process of creating custom materials. Check them out some time; there are some pretty awesome things you can do with all the sexy shaders and effects Source has to offer.

All you need to keep in mind for this task is that for a texture to compile successfully, it needs to be a .TGA image whose dimensions are some power of two. That doesn't mean the texture needs to be square; you can have a texture that's 512 x 512, 512 x 1024, or even 2048 x 2, if you want. When saving the .TGA in, for example, Photoshop, an 8 bits/pixel image is gray-scale, a 24 bits/pixel image is in color, and a 32 bits/pixel image is in color and includes the alpha channel. For your purposes, the 24 bits/pixel variant is what you'd want to pick.

If you have trouble, let us know!

I think the ValveSource add-on for XSI supports .VMF files as well, but you have to jump through a hoop or two before you can export it as a model.

... To answer your question,

I'm an XSI user. From my experience, XSI will more than satisfy your prop modeling desires for any Source game (if you end up wanting to animate something one of these days). Max is a more popular choice, and even though I, myself, have next to no experience using that modeling app, there are still a couple of folks here that are pretty skilled with it that you could go to for help.

Those two are probably the two you would want to pick from because, a) LOTS of folks use them, and b) both of them have extensive Source support (.SMD exportation, character rig guides, the whole shebang). The only other program from that short-list that I'm at all familiar with is Blender, and while Blender is wildly powerful (and free!), its interface is not very intuitive. Blender would surely suit your needs (I know some folks at Interlopers that are die-hard Blender fans and have the work to prove it), but it would take you a while to learn how to use the program before you became facile enough to produce some real results, especially as a beginning modeler (at least, I assume you are so). Also, if you wanted to do anything more than prop modeling, I'm really not sure how well it would support the filetypes that Source needs to successfully compile animations.

If you don't really like using XSI or Max, do some research about how well other modeling apps support Source, and find one that suits you comfortably. Interface is a pretty important thing, so XSI and Max have my vote, followed closely by Blender, but everyone has their own taste, so you'll have to do some shopping around!

I can tell there's some neat detailing in there and the displacement work looks great, but it's too dark for me to see any of it!

You can keep that dark, dank atmosphere if you throw in some brighter lights with shorter falloff distances. That way, you'll get some juicy light contrast where you need it, but darker areas will remain to keep the atmosphere. The torch on the wall and the area on the right that looks to be an opening in the ceiling would be good spots to start, I think.