Spooks
-
Posts
612 -
Joined
-
Last visited
-
Days Won
38
Posts posted by Spooks
-
-
I was testing for issue 4685 using heatHazeWithDepth two days ago with the latest public package, so yes, I can confirm it is still glitchy. A surefire way to make sure the glitch is visible is to increase the distortion. Rather than attaching a testmap for 4684, you can just test on the foglights_warp.map for 4685 (what I just tested on right now), but change the clear_warp material definition from the default to this:
textures/darkmod/glass/clear_warp { // Written by Tels, mainly based on // http://www.iddevnet.com/doom3/materials.php noSelfShadow noshadows twoSided translucent forceoverlays sort decal glass qer_editorimage textures/darkmod/glass/clear_warp_ed description "A reflecting, translucent material suited for large, flat glass panes" // this block makes the glass distort what you see through it // one unwanted side-effect is that this effect does not stack // and distorbs objects in front of the glass, too { vertexProgram heatHazeWithDepth.vfp vertexParm 0 0 , 0 // texture scrolling vertexParm 1 58 // magnitude of the distortion fragmentProgram heatHazeWithDepth.vfp fragmentMap 0 _currentRender fragmentMap 1 textures/sfx/vp1 // the normal map for distortion fragmentMap 2 _currentDepth } // this stage sets up the alpha mask (it doesnt render anything) // we use another glass texture for the alpha map, so that the reflection // shows more clearly and different from what the alpha map of our glass // says, that makes it more interesting { maskcolor map makealpha(textures/glass/glass1) } // now use the alpha mask to add some fake reflections { blend gl_dst_alpha, gl_one maskalpha cubeMap env/gen2 // tone down the reflection a bit red Parm0 * .2 green Parm1 * .2 blue Parm2 * .2 texgen reflect } // add our texture on top { blend gl_dst_color, gl_one map textures/darkmod/glass/crystal_milky red Parm0 * 0.2 green Parm1 * 0.2 blue Parm2 * 0.2 } // This is the code required for frob highlighting this texture { if ( parm11 > 0 ) blend gl_dst_color, gl_one map _white rgb 0.40 * parm11 } { if ( parm11 > 0 ) blend add map textures/darkmod/glass/crystal_milky rgb 0.15 * parm11 } }Then toggle r_useFBO.
-
I use a ReShade setup with a Debanding filter, which is pretty much just non-pattern dithering and it alleviates the issue. Not everyone has OpenGL 4.3 (iirc that was the required version for ReShade) however, so an inbuilt dithering shader in the post processing wouldn't hurt.
fake edit: hey, I started typing that first
-
com_asyncInput doesn't seem to affect it, no. For the record I have com_smp set to zero anyway, since the mutlicore support introduces major stuttering on my system.
*3 months for 2.05 beta, I checked
Stay strong out there.-
1
-
-
15102 - 4683: Shader-level ambient cubic light falloff (duzenko)
15103 - 4685: Fix for overfogged translucent surfaces (duzenko)
15104 – 4684: Change warp material shader to heatHaze (duzenko)
1) I can confirm that the scissor issue is gone now and cubic lights have proper falloff. I still would like an example lightDef with "lightFalloffCubeMap", as it's not recognized as a proper token no matter where I put it in my material.
2) I have added a note on mantis about this fix. It works great but it disables warp materials and possibly other fragment programs (couldn't think of any to try besides heathaze that's in water and glass materials).
3) I can confirm that nothing's really changed wrt heatHaze and it still distorts objects in front of it. I don't know if I should reopen that bugtracker, since this is technically still an issue with heatHaze rather than heatHazewithDepth being replaced.
Can the "dmap CTD" and "player inputs moving slower with lower framerates" bugs get addressed at some point? I only explicitly ask here because they're pretty major and I get an inkling that the beta testing phase is going to wind down soon (iirc it was about two months for 2.05). I don't want these to get skipped over.
e: http://bugs.thedarkmod.com/view.php?id=4673 can be safely marked as resolved now, it's been fine for about 2 update packages.
-
1
-
-
Just placed one of the springheel models in front of the glass, it's hard to see but it's still definitely there on the edges. Since this is the case we're effectively just replacing one graphical artifact for another, which is more of a sidestep than a fix.
-
Ah yes, I actually remember that bug. I have checked now and HeatHaze still distorts objects in front of it in 2.06 with or without FBO on.
If FBO is off by default, then that is more agreeable.
-
Bugtracker 4684: http://bugs.thedarkmod.com/view.php?id=4684
Other materials should be fixed in the same manner if needed
I'm not aware of the functional difference between heathazewithdepth and heathaze. The two look similar enough in the test map, but if there is two of them there must've been a reason for the depth version to be used over the regular in these warp materials.
On paper, I'm okay with slashing one if it no longer works with FBO, but if the solution is to replace every instance of "HeatHazeWithDepth" with "HeatHaze" in TDM's material definitions, this had better be done, rigorously, before 2.06 is publicly released, or the issue could hardly be considered 'fixed'.
-
1
-
-
Hey, is it just me or fog intensity changes when player looks around?
If you mean at the corners of the screen, then yes, since the fog is based on the player's viewport and looking at something at a more oblique angle will layer more fog on top.
I saw that the foglights issue has been fixed on the tracker and I will agree: It also seems like an engine limitation to me. The issue with the skybox probably lies in the fact that the portal_sky camera just exacerbates the issue of more distance = more fog. Even not considering the skybox, however, just looking at a particle that's wide enough to cover a fogged corridor and a nearby wall will make the bug apparent. The problem with sorting particles above fog is that the particle would look out of place when looked from far away, it being its normal color while the rest of the environment is fogged.
I guess we would need to do fog before transparent surfaces and somehow downmodulate those separately.The way I see downmodulation being done would be fogging the face (be it a particle quad or a transparent world brush primitive) based not on pixel depth but on face origin/normal. A very crude example: I've got a particle that's 500 units away and I can see the skybox behind it - all the quads in the particle should get fogged up for the value that a normal face would be at 500 units distance, instead of variably based on whether they're standing in front of geometry that's close by or the skybox.
At any rate, I'll test the afterfog keyword in the next package and report how it looks in-use.
-
Time for a news post?
Urging people to vote? Perhaps. I was thinking today that nbohr1more could probably hold off posting updates about major FM releases like Volta 2 until 2.06 comes out, so that people over on Moddb that don't follow too closely will have a more exciting update to read through.
-
1
-
-
I am assuming that the player is speaking out loud, which has been the case in some released FMs (mission 2 of NHaT and my FM off the top of my head). Therefore my argument was for keeping the channels distinct, unless you could implement a keyword in the soundshader definition that skips EFX processing.
I do agree that the names are arbitrary and as far as the sliders (not channels) are concerned, there may be little need to adjust one but not the other. The one fringe case would be a narrator talking over the player, but we've never had a simulcast fan mission before.
Commonplace sliders are usually Master, SFX, Ambient/Music and Voice. I think that would be more understandable for players, provided the sliders actually affect the labels they are assigned (SFX being just Master is absolutely true).
As far as mappers are concerned, there needs to be more documentation about what sound goes in what channel. The only reason I know about atdm:voice is because I stumbled onto this thread half a year ago. I have to assume the Player Volume slider just doesn't affect a bunch of missions since the PC lines are just hand-placed, omni speakers that get triggered by scripts/objectives.
-
1
-
-
I just went over the thread, interesting stuff.
(I'm with Spring on this, by the way: do we even need separate channels for player voiceover and narrator voiceover? Has there ever been an FM that uses both? It's nice to have options, sure, but it feels kind of cheesy to have both narrator and main character chatting up the player. Usually the main character is the narrator. I'm all for more clear setup here.)
Not to highjack the beta testing thread, I'd say 2.06's EFX in particular exacerbates the need for these two different channels. The fact that there hasn't been an FM to utilize them fully doesn't mean that an FM in the future might not want to use the narrator channel for anything from metanarrative stuff like a storyteller commenting on the adventure you're playing out (e.g. the Bastion game or a particularly hand-holdy version of Penny Dreadful), to player internal monologue or ghostly voices in your head (again, PD3), to developer commentary. Having none of these be affected by reverb is important.
The issue of naming the volume sliders is semantic. If anyone has a good idea of how they should be labeled to better communicate to the player what they're for, go ahead, but I think they're alright as they are.
-
a.k.a. boy, I'm glad I can type a topic title this crazy
Jokes aside, I'm requesting a set of decapitated heads and corresponding AI neck attachments for one of my missions. It may not be done for a while, but I've decided to ask well in advance because I know models requests take time. Arcturus would be the person to ask since, I believe, he's responsible for the AI models, but I'm posting it in the public forum to be safe. You could help too!
The assets would be used for horror missions and for that extra touch in dungeon locales with guillotines (or you can put them on a platter for a noble to eat, Indiana Jones style, sure, go crazy). Ideally, it would be one or two ai_head attachments to attach to actual AI. That would be a bit of the neck and the... stump, shall we say. Then, there'd also need to be several head gibs akin to the zombie_head.ase model. I say "one or two" since I don't know if a version for female heads would be too much work, what with the neckline on some of the noble models.
More generally speaking, our gore and horror assets are a bit lacking, but I should hopefully, at some point in the future, get around to create some stuff like better materials for pools of blood, more blood decals or bits of viscera.
-
3
-
-
Fair enough. Should I open a ticket on Mantis so they can be considered for inclusion in 2.07? Dragofer's OP was last updated in July and the lot of his models were being compiled during the 2.05 beta test by his admission, so it seems nobody got around to including them in this version.
-
I need to make a request here: I believe all of Dragofer's assets should be made part of the core mod for 2.06 as they are all high quality. The hookah's already been used in a couple of missions, but all I see in the model folder of his are a couple of his sphere lights. Given that a bunch of Epifire's models are implemented, I see no reason for these not to be.
Related, are
the spoilerific assets in Kingsal's new mission going to be added to the core mod once his mission is released?
-
- Popular Post
- Popular Post
WIP is progressing, slowly but surely. I don't want to show too much, so a filter will have to do. If you want the non-desktop wallpaper version, you'll have to wait!
-
15
-
Also I've been getting really strange performance issues on 2.06 that don't occur when tested on 2.05. But whenever I enter a more intensive area of a map the game slows down to this strange fluid and slow motion. And then when I am in a low demanding room it goes back to normal. But it feels very jarring. Anyone else experienced that?
Yep, I have logged it as issue 4665. I hope it gets looked at as it is very jarring, esp. with an engine as prone to FPS dips as TDM's.
-
1
-
-
I mean more that the way lights usually taper off is not present, hence the 'falloff' is missing. By all means you can rename the issue on the tracker for more clarity.
From the name I expected some specular highlights to appear, which did not happen. Then again, that was last week before the bugfix for bug 4673 was applied. I can test this keyword again but an example material definition with it would be appreciated.
-
Hello, I wanted to mention that I tried to insert the lightFalloffCubeMap keyword everywhere in the material last week, with little success. I also tried the makeAmbientMap console command yesterday, which works (!) but has a bunch of new parameters not present with envshot. Would be nice to have some documentation on both of those at some point in the future, probably not right away as the ambient cubemap light conversion to IBL seems to be WIP still.
I have listed the light clipping issue on Mantis: http://bugs.thedarkmod.com/view.php?id=4683
-
Yes, sorry, it was really late last night and I wanted to jot these down quick. The falloff for spotlights, on second look, seems fine. It must've been the aforementioned cubic lights bug (there were some in my test environment) plus lights just generally looking different with soft shadows on.
I'll straight up put the cubic bug on the tracker though, there've been a couple of posts on the cubemap thread about it already.
-
I just noticed envshot takes screenshots with the UI on, so you have a nice cubemap with a complimentary console window on each side. There's a command to hide the hud but uh, is this intentional, or...
-
^That one was already spotted, it's to do with FBO, although I don't think it's tracked on Mantis.
#4673 seems to be fixed (passing tex coords to bumpy environment shader) now; I was hoping that would also alleviate the rectangular cubic lights somehow, but no luck. While I was looking I also noticed something's up with falloff textures for projected lights, like the shot VanishedOne posted in the other thread with the lanternbot light... Might be worth looking into.
-
It is a bug and it happened in 2.3.0 but I've never been able to figure out the conditions for it to manifest with any sort of consistency. :/
-
One of my pet ideas has always been designing a level around a checkpoint conceit, like the save crystals in Legend of Grimrock. There are other examples of checkpoints, of course, like the notebooks in Silent Hill or the terminals in Dead Space, but I bring the crystal analogy up since I feel you would have to provide a lore explanation of sorts for something like that. Checkpoints that activate when the player is in a place or has done an objective seem a bit too arbitrary and meta to me.
-
Every properly made FM would have locations implemented already, we'd just be hitching the names and using the fades the location system uses for those seamless transitions. The only problem is that the cubemap light would have to have its light texture changed dynamically in-game, which I've not seen happen (but might be possible through script).
The problems with placing ambientCubicLights by hand currently is that they all have spherical falloff and as such you really cannot get transitions other than crossfades. In addition, odd shaped rooms are out of the question, which is not a problem with the location system.
Teleporting between map files: is this possible..?
in TDM Editors Guild
Posted
I remember this coming up recently in another thread. Full disclosure, I never did actually play Doom 3. Didn't the levels there use level transitions à la Half-Life 2 or were they single-run levels like the original Doom?
I think that level transitions would be really good for stuff like interior/exterior separation (this is the part where I bring up Dishonored), but the maps should remember the state of the entities therewithin and implementing that could be a hassle.