Jump to content
The Dark Mod Forums

Spooks

Member
  • Posts

    612
  • Joined

  • Last visited

  • Days Won

    38

Posts posted by Spooks

  1. I got through both this and In a Time of Need recently. Two play sessions for Breaking out the Fence, the first was me enjoying the different areas (like the spider cave, which was great!) and the second one was me being annoyed by the high loot req. on the hardest difficulty since I was required to either get dock treasure, safe or boar secret in order to pass. In hindsight getting pissed off a long time after I've had a good time the first time unfairly colored my opinion of the FM - overall I think it's a little gem! On to Exhumed, I suppose!

  2. I've a pet peeve and I don't know if it's easy enough to fix. The _color argument should have 3 points of decimal precision instead of 2. When you pick a color, and the 0 to 255 values get turned into the 0 to 1 values the spawnarg works with, they'll have 2 points of decimal precision, which does not represent the full color gamut, and will possibly band the color you've chosen.

     

    You can observe this in the entity pane. Get an entity with a color argument (e.g. a _color on a light or an ambient_light on a location settings ent), then click on that argument. You have the raw 0-1 value in the type field and the RGB value below. Manually increase the RGB value by typing in its box. Suppose you have Blue at 17, which corresponds to 0.07. When you change it to 18, the raw value should change to 0.071 - 0.074, but it stays at two points of precision.

  3. Here's how I see the implementation of such a feature. Long post.

     

    DR writes into a .map file, in which the geometry is represented by a collection of primitives described by their vertices. Dmap then reads from the .map file in order to produce the .proc - the pre-processed geometry, triangulated and grouped into surfaces. The consequences of introducing a negative brush means that its vertex data has to be recorded somewhere too, much like with positive brushes.

     

    If you put the data in the .map file, then you hoist the responsibility of understanding and compiling that data into convex volumes, ready to be triangulated, onto dmap. This is a bad idea since DR isn't used solely by TDM map makers - if we introduced negative brushes in DR then tuned our dmap compiler to make sense of them, we'd be screwing everyone else who's using DR for their idtech4 projects. (This is why I've not suggested to greebo that he put "convert to func_group" in DR 2.0.4, the thing's only going to get fixed in TDM 2.0.4, it's still broken in D3 and other idtech4 games.)

     

    So, it's clear you've got to make this a completely DR-side feature, making DR spew an intermediary file containing negative brush info, then compile a final, regular .map file from that. The .darkradiant files already exist, and they hold layer information, so that'd be a fine place to store negative brush info.

     

    Then you draw your negative brushes in DR, and they're a DR thing and not children of worldspawn, and at savetime DR uses all those negative brushes to carve spaces and writes the .map file. But when you reopen it you don't really have the original positive brushes, just the carved versions! To avoid this, DR obviously shouldn't be reading the .map file for [positive] map geometry info, just writing into it.

     

    So really, you have 3 things to keep track of - vertex information for all positive brushes, vertex information for all negative brushes (and both of those have to be a DR-side ordeal), and then the .map output, which is the final file which dmap can read.

     

    You can see at this point you're not using DR to directly edit the .map file anymore, you're doing it behind an entire new level of abstraction. The whole thing is feasible and I could see some actual quality of life improvements coming from it, but it fundamentally changes Dark Radiant - how it stores brush information and how it displays it to the end user.

     

    The front-end is the least of a would-be implementer's problems. The most user-friendly interface IMO is to have a toggle (that could be bound to a keyboard button) to work in either negative or positive space, and a special option to select both types at once for layer assignment, movement, etc. The back-end, however, makes for a lot of problems.

     

    How do negative brushes interact with other DR features? If you group a negative brush and positive brushes into a func_static, does it carve everything, or just what's in the func_static? Should negative brushes just be their own entity altogether, like the worldspawn entity, but editor only? If you're using the CSG algorithms to carry forth this whole premise I've outlined, how do you make those algorithms not shit?

     

    It's a lot of effort that could be better spent on other parts of DR that would expedite a mapper's workflow by a far greater margin. How about DR having the equivalent of func_instance? Or Bethesda's Snap to Reference (ctrl+f "snap to reference" on that page and you'll find it)? I'm not trying to bust you balls or discourage you here, as I said I'm well aware of the benefits of negative brushes. Not saying those features would be easier to put in either - not by a long shot. But in the grand scheme of things there's far more useful features I pine for - substractive editing is pretty low on the list.

    • Like 1
  4. You can emulate a substractive building mode in DR if you really want. Make a cuboid as big as you want, then draw smaller cuboids inside it and use CSG Carve, then delete the brush you used for carving, or move it and carve again. You'll soon see the problem with it all though.

     

    Quake and its derivatives use Binary Space Partitioning, meaning you can't have concave brushes. The carving algorithms don't have the concept of cutting brushes symmetrically and the carve has to happen right away, so with enough carves your convex brushes will be reduced to mush. Even if you don't plan on doing any additive operations (which would be really hard at that stage), the compiled map will have a lot of degenerate triangles.

     

    It's kind of the same thing like trying to carve a torus inside of a sphere in Source's Hammer. Only bad things happen.

  5. That head/skin combo is definitely in 2.0.3, atdm:ai_burglar comes with it as default. The model head_02 is obviously not in the file structure, but the model is in fact models/md5/chars/heads/npcs/commoner_head02.md5mesh. No idea why the model spawnarg in the EntityDef and the actual model name differ, probably an md5 quirk.

  6. It seems to me that the rgb parameters work on cubemap stages ONLY when there are no diffuse/bumpmap/specular map blending stages set on the material. For Epi's purposes, if he wants to only use the heathaze program + any other material stage with a blend add/filter/etc. he can tint the cubemap fine.

     

    For opaque materials that need light interaction though, yeah, the method you described seems to be the only way to tint cubemaps. I've just tried it and it works, you have to define a new alpha stage above each of your three cubemap stages and put MaskRed etc. on them. Then you control each color's intensity through the alpha arguments of the makeAlpha stages above the corrseponding cubemap ones.

     

    Of course, easy way's just make a new, colored cubemap with the envshot command, but that's one thing, the ability to tint them in the material is another, so it's good to know it's at least possible.

     

    Edit: here's the code

     

     

    diffusemap 		textures/darkmod/tile
    bumpmap 		textures/darkmod/tile_local
    specularmap		textures/darkmod/tile_s_bright
    
    //For RED
    {
    	maskcolor
    	map makealpha (textures/darkmod/tile_s_bright) 
    	alpha 0.7
    }
    
    {
            blend gl_dst_alpha, gl_one
    	maskalpha
    	maskGreen
    	maskBlue
            cubeMap      env/gen2
            texgen      reflect
    }
    
    //For GREEN
    {
    	maskcolor
    	map makealpha (textures/darkmod/tile_s_bright) 
    	alpha 0.3
    }
    
    {
            blend gl_dst_alpha, gl_one
    	maskalpha
    	maskRed
    	maskBlue
            cubeMap      env/gen2
            texgen      reflect
    }
    
    //For BLUE
    {
    	maskcolor
    	map makealpha (textures/darkmod/tile_s_bright) 
    	alpha 0.6
    }
    
    {
            blend gl_dst_alpha, gl_one
    	maskalpha
    	maskRed
    	maskGreen
            cubeMap      env/gen2
            texgen      reflect
    } 

     

     

     

    edit edit: note that you can use different cubemaps for each of these makeshift "color stages", so you can go hog wild there if you wanted to do some super trippy effect. I mean it is cumbersome, but it's also pretty flexible.

    • Like 2
  7. I almost asked you the same question. :unsure:

     

    You're in luck, I just figured out a way!

     

    Looking over those material stages just now, I'm seeing the use of red/green/blue and a float value between 0 and 1 to modify the RGB value of the map. Well, when you make an alpha stage with makeAlpha, the resulting image wouldn't have any RGB values, just a grayscale alpha value.

     

    So, for a cubemap that's blended with gl_dst_alpha and a makeAlpha stage defining said alpha, this is how you can make the cubemap less bright:

    {
    maskcolor
    map makealpha (textures/darkmod/tile_s_bright) //here I use the specular of the texture
    alpha 0.5		//this darkens the alpha by half, modify it as you wish
    }
    	
    {
    blend gl_dst_alpha, gl_one
    maskalpha
    cubeMap      env/gen2
    texgen      reflect
    }
    

    As you can see, this lowers the output of the cubemap by darkening the alpha stage it's drawn with, so there's caveats - using other blending types on the cubemap stage will invalidate this method and if you're using that alpha stage for something else this might break the appearance of that. I still don't know why the rgb argument doesn't work on the cubemap stage proper (and no, "alpha" doesn't work either), but my best guess is "cubemaps are magic" and they don't obey the rules.

    • Like 2
  8. Are you using maskAlpha/maskColor to make sure other stages aren't overwriting the channels? Here's an opaque material that uses an image map:

     

     

     

    textures/darkmod/window/ornate/descriptive_name_goes_here
    {
    
    	glass
    
    	qer_editorimage textures/darkmod/window/ornate/round_pearly_white_ed
    		
    	bumpmap		textures/darkmod/window/ornate/round_pearly_white_local
    	diffusemap _black
    	specularmap	textures/darkmod/window/ornate/round_pearly_white_s
    	{
    	blend add
    	map textures/darkmod/window/ornate/round_pearly_white
    	red 0
    	green 0
    	blue 1
    	}
    	{
    	blend filter
    	map textures/darkmod/window/ornate/round_pearly_white
    	red 0.1
    	green 0.1
    	blue 0.4
    	}
    	{
            maskcolor				
            map makeAlpha(lights/spot01)
            }	
    	{
    		blend gl_dst_alpha, gl_one
    		maskAlpha
    		cubeMap env/gen2
    		texgen	reflect
    	}
    	{
    	blend gl_dst_alpha, gl_one
    	maskAlpha
    	map textures/darkmod/window/ornate/round_pearly_white
    	red 0.4
    	green 0.4
    	blue 0.6
    	}
    	
    	{
    		if ( parm11 > 0 )
    		blend	gl_dst_color, gl_one
    		map		_white
    		rgb		0.40 * parm11
    	}
    	{
    		if ( parm11 > 0 )
    		blend	add
    		map		textures/darkmod/window/ornate/round_pearly_white
    		rgb		0.15 * parm11
    	}
    
    	// TDM Ambient Method Related
    	{
    		if (global5 == 1)
    		blend add
    		map				textures/darkmod/window/ornate/round_pearly_white
    		scale			1, 1
    		red				global2
    		green			global3
    		blue			global4
    	}
    	{
    		if (global5 == 2)
    		blend add
    		program	ambientEnvironment.vfp
    		vertexParm		0		1, 1, 1, 1	// UV Scales for Diffuse and Bump
    		vertexParm		1		1, 1, 1, 1	// (X,Y) UV Scale for specular
    		vertexParm		2		global2, global3, global4, 1
    
    		fragmentMap		0		cubeMap env/gen1
    		fragmentMap		1		textures/darkmod/window/ornate/round_pearly_white_local			// Bump
    		fragmentMap		2		textures/darkmod/window/ornate/round_pearly_white			// Diffuse
    		fragmentMap		3		textures/darkmod/window/ornate/round_pearly_white_s			// Specular
    	}
    
    
    }
    

     

    Yes, I was, it seems my map for maskAlpha was the problem however. Too black I think. It looks proper now. While I have you attention, how's the "red/green/blue Parm0*0.2" in the cubemap stages supposed to work? Does it work? Neither that nor the "rgb 0.2" I've seen seem to affect the brightness of the cubemap. Not bogarting the thread or anything, it's relevant to windows.

     

    Reference from the thread I posted:

     

     

       {
            blend gl_dst_alpha, gl_one
            maskalpha
            cubeMap env/gen1
            // tone down the reflection a bit
            red     Parm0 * 0.2
            green   Parm1 * 0.2
            blue    Parm2 * 0.2
            texgen  reflect
        }
    

     

    • Like 1
  9. I think the heatHaze program is what you're looking for, the stained glass window materials AluminumHaste made might be a good starting point: http://forums.thedarkmod.com/topic/17203-transparent-stained-glass/

     

    For pointers, I've not done glass but the heathaze should distort the image behind it with the normalmap you provide, get a cubemap or a mirror stage on top of that if you want reflection as well.

     

    I've been playing with blending modes some more and I think any blendmode that references an alpha (eg gl_dst_alpha) actually means the opacity the material has rather than any abstract alpha value or alpha channel on an imagemap you feed the material. Pretty restrictive.

    • Like 1
  10. Okay, here's a question for you all. I looked around and it seems TDM has three options for Ambient Rendering, but I was never aware of that since the options menu only displays Simple and Enhanced (Enhanced being the equivalent of what I read being described as "Normal"). This stuff has been in since 1.03 and putting it in the console actually makes a difference, but hell if I know why it isn't in the menus. Can anyone give me a rundown?

     

    http://forums.thedarkmod.com/topic/13676-whats-the-difference-between-ambient-modes/ Reference thread.

     

    edit: hey here's a post

     

    edit edit: The one reason I'm investigating this is just trying to get better looking cubemapped materials.

     

    edit the 3rd: it's not worth updating the thread over this, but I'm just going to edit in this snippet I posted on Epi's thread, because I think this code's about the best I'm going to get for cubemaps for now and it's nice to have it here in one place. I suppose I'm done with env stuff for the moment.

    {
    maskcolor
    map makealpha (textures/darkmod/tile_s_bright) //here I use the specular of the texture
    alpha 0.5		//this darkens the alpha by half, modify it as you wish
    }
    	
    {
    blend gl_dst_alpha, gl_one
    maskalpha
    cubeMap      env/gen2
    texgen      reflect
    }
    
  11. Well if you set the diffuse to _black, you can make decals that only apply a bump/specular map, which is pretty nice! I can imagine a specular decal could be used for wet spots on walls/floors, and you can probably do fancy stuff like animate the texture too.

     

    However, say you have white slime on bricks, your diffusemap would be the slime and your bumpmap would be the brick normal map - but then put it on top of the brick and you have two brick bump maps overlapping - and for the trouble of aligning them in DR you may as well put the decal into the brick diffuse texture instead.

     

    How I imagine it in its simplest form, the decal would render its diffusemap in front of other materials, but let other materials' bumpmaps render in front of it.

     

    Slightly unrelated: http://wiki.thedarkmod.com/index.php?title=DDS_creation states that we currently don't support soft blending transparency, but this isn't true, saving a DXT 3 with an Alpha and using that with a "blend blend" then "map <the dds>" allows for smooth gradient alpha.

  12. Honestly, what I'd love with those sort of decals is if a source texture's bump map could affect the decal, like you see in those Wolfenstein screnshots. That would make grime decals 10x more believable. Bumping because I was looking into this too and I don't think you can do it with blend tricks in the material, might need a separate vertex program for that, which is wholly out of my league.

  13. You should double-check this empirically.

     

    I just did and you're right, and I'm wrong. It's really weird because I swear I had the problem I described in my map and that's how I fixed it. Totally weird. :wacko:

     

    @steve: Oh, this might just be what happened, as I wanted a location to be completely pitch black. I must've ended up putting the ambient there at 0.01 0.01 0.01 after doing what I described and thinking that fixed it. That explains it!

    • Like 1
  14. If you're looking for other software that's good with ambient sounds, ASMR Universe is on Steam, it's 3 euro, and it has the ability to import custom sounds, have sound paths, and save .wavs. I've not tried it, and think for that price it's more of a toy thing than a robust ambient sound utility, but it's worth checking out imo.

    • Like 2
  15. Firstly, from a flexibility standpoint, this is how I did the ambients in KoD (and how I'll probably keep doing it for any other FMs). My ambient_world light is set to 0.01 0.01 0.01. It's the minimum that isn't total darkness, so that the gamma slider works.

     

    Then, I consider the outside portions of the map as one huge location, and I put an info location entity, naming it info_location_global. On it, I put my actual ambient light, which used to be 0.04 0.06 0.05 (green tint, also past tense cause I changed it now). Any time the player goes inside some other location, I can change the ambient as I wish or just put the same value the outside has.

     

    Why the first step is important is this: suppose it's bright outside but you enter a cellar. It's going to be dark. Now, if you just had ambient_world set to, say 0.3 0.3 0.3 (overcast day outside), even if you put something like 0.1 0.1 0.1 on your location settings for your cellar, the actual light that you would get in there would be 0.4 0.4 0.4. That's because the lights are additive, and ambient_world is above locations in the hierarchy and will add to everything.

     

    This is why I recommend you, and anyone else, set ambient_world's luminance to be as low as the darkest expected place in your map, or just to the minimum of 0.01 - so you can additively add light through location settings without any worry. For KoD, this is how Adam's room works, it wouldn't be so dark if I hadn't set it up the way I described (since Goldwell has beta-tested the map he'll know what I'm talking about, for the rest of you - it's gonna come out soon enough!)

     

    Regarding the color, I like it, but make sure to vary the color tints between locations so it doesn't end up looking samey, as Obsttorte suggested. He also mentions the saturation and it's true, the ambient is supposed to represent the overall bounced light in a location and since it can't be anything more than an average, it's wise not to spike the saturation too much.

     

    TDS I'm pretty sure also used atmospheric fog, and if you can find some way to make the awful foglights work nice for you, I think it would give it a lot more depth. I think Shadowhide posted a screenshot here of a WIP where he had muted purple fog and a blue ambient complementing each other, which is more or less the TDS look. Looked really nice.

  16. Thank you, Steve. It's good to know it's in the pipeline. Whenever I get around to it I may post some examples of practical applications of func_groups in a mapping workflow.

     

    Edit: Though, off the top of my head, the biggest advantage would be func_static-like flexibility in the editor, with the option of drastically decreasing entity counts inflated by architectural pieces, allowing for a lot more leeway when it comes to modular building.

×
×
  • Create New...