VanishedOne

Oh, I hadn't noticed the floor texture. I'll go back and check later (I think I may have moved position/angle between shots). I was talking about the candlelight on the walls.

Member since 07-June 15 189 posts Er... welcome, newcomer.

It's a bit hard to show in screenshots, but some mirrors seem brighter than the scenes they reflect: I searched tdm_cubeLights.mtr for makeIrradienceMap and got no results. (None of the lights I named exists without the .pk4 from the cubic lighting thread - there's a cubegrate6 and a cubeSky, but they don't have the same paths - but the cubic lights I can find listed in 2.06 don't look different definition-wise.) What scaling issues? If lights illuminating surfaces that were previously dark relates to 'Screen is Oversized in Fullscreen Mode (Image is too large to fit the screen area available)' then it's not at all obvious how. (I wasn't running TDM in fullscreen mode, by the way.) Sorry if I come across as ungrateful; it's just that in the context of the thread my mind is in a 'reporting glitches as a tester' frame, not an 'asking for tech support' one.

In my post about the cubic light, I forgot to mention it had "falloff" "1" set. I tried ambientcube.map from the cubic lights testing thread, and results were: With GLSL I can't see lights/cubegrate6.On the other hand, with GLSL I can see lights/cubesheen, which has never worked for me under the ARB shaders.Is the GLSL version designed to blend in more of the surface texture colour? Geometry in the lights/cubesouls room looks grey (exactly matching the surroundings) in ARB but green in GLSL.In some rooms (e.g. the lights/cubesky room), in GLSL all geometry looks consistently lit... apart from the cylinder. This doesn't happen under ARB. I tried that with soft shadows enabled and this happened:

Materials in the attached file display normally as worldspawn surfaces in 2.06, but as particles they either don't display at all or look different. bubbles.pk4.txt

Disabling AA in-game fixes it provided I entirely restart the program afterwards. My GPU is an integrated Radeon HD 8400 and the only settings I can find in the 'AMD VISION Engine Control Center' deal with stuff like power usage.

The normal map in this material no longer works: 2.05 2.06

Spark-line type effect with GLSL (it's hard to see in the dark but there's a railing on the opposite side of the landing:

I've got a fountain with distorting water: the filename I gave the prefab says Obsttorte made it so it's probably http://forums.thedarkmod.com/topic/11901-waterfalls/?do=findComment&comment=304109 The region with the water is jittering around on the screen. Happens in both GLSL and ARB.

I placed a cubic light (lights/ambientCube/cubeSky) in the corner here, and it glitches in GLSL mode:

With those shaders it works. Multi Core Enhancement doesn't seem to be working well on my machine: I'm seeing jerky movement, occasional light gem flicker, and instances of this in the console: WARNING: glClientWaitSync did not complete successfully (result code 37147) In 32-bit movement is smoother and I haven't seen the same console warnings but the occasional light gem flicker is still present. With soft shadows turned on I see these odd blue edges on these stairs from certain angles. It may be relevant that the stairs have a blue specular map. (Also, they use vertexColor in the diffuse and specular stages.) Edit: another soft shadow glitch. This patch of sunlight (from a parallel light) shouldn't be here, and with soft shadows off it isn't.

If that's directed to me, I don't have a means of acting on it.

WARNING:shaderCompileFromFile(glprogs/interaction.vs) validation Vertex shader failed to compile with the following errors: ERROR: 0:40: error(#143) Undeclared identifier: var_WorldPos ERROR: 0:40: error(#143) Undeclared identifier: u_modelMatrix ERROR: 0:40: error(#143) Undeclared identifier: u_lightOrigin2 ERROR: 0:40: error(#160) Cannot convert from: "3-component vector of vec3" to: "float" ERROR: error(#273) 4 compilation errors. No code generated Lights (edit: apart from ambient lights, and I haven't tested foglights or blendlights) are completely non-functional. Win8.1/64, same results in both 32- and 64-bit executables. 2.05: 2.06: WARNING:file skins/tdm_models_architecture_modules.skin, line 546: Expecting '{ ' but found '==' Someone inserted a ======= divider without comment syntax.

But if your diffusemap is _black then multiplication by anything will result in 0 0 0. Is the difference entirely down to the angle modification?

I'm trying to get a better handle on how the RGB stage keywords affect specular highlights. So far I've found the following: Specular highlights are strongly affected by RGB in diffuse stages. This is independent of the result of multiplying RGB by the diffusemap: you can have _black as the diffuse and still manipulate specular highlights with RGB in the diffuse stage. (For this post I'm using _black for diffuse and _white for specular, and no bumpmap.)Specular highlights are affected by RGB in the specularmap stage, but in this case there's a sharp cutoff somewhere. rgb sinTable[time] in the diffuse stage gives smooth fading. In the specular stage it gives an abrupt on/off toggle.Some searching brought me to the following discussions... http://forums.thedarkmod.com/topic/11893-ungoliants-mapping-questions/page-2?do=findComment&comment=242920 http://forums.thedarkmod.com/topic/11893-ungoliants-mapping-questions/page-13?do=findComment&comment=333331 ...and from those clues I found that both (1) and (2) above are true only of the enhanced interaction shader. The thing I still don't understand after reading the explanations in the linked thread is where the RGB of the diffuse stage comes into play.

I think breaking was designed as a one-way state change to the 'broken' material/sound/model, so if it's possible to 'unbreak' a light it won't be simpler than just setting the shaderParms with a script or intermediate entity.

TDM's code is setting the spawnargs; all I'm doing is triggering the func_static (by targetting a button at it). Lights can be triggered on/off* but unfortunately the shaderParm-changing functionality seems to be specific to func_statics (more precisely to the idStaticEntity spawnclass, which lights don't use). I think the programmer's comment about 'lights' probably refers either to additive blends (for Doom 3 control panels and the like with glow-in-the-dark elements representing lights) or to set-ups where you have a func_static representing a light's model and triggered along with the light, instead of a light using its own model. So you're right, it's not a complete solution when you want a light manipulated too. *Or set to a broken state, or dimmed a number of times before turning off, depending on what spawnargs are set. Edit: lights do seem to have code to set SHADERPARM_TIMEOFFSET when they turn on, and to set it and SHADERPARM_MODE when they break; the problem is that here you want to switch between two 'on' states. I suppose having two lights, only one active at a given time, could work. But at that point things are less simple anyway.

Can't tell without seeing them whether it's the same problem, but I've found that big blendlights may need to be (zero?)clamped, or they can act a bit like foglights when the player stands inside them and tint the entire scene. Or if it's to do with light passing through geometry, forceShadows might be worth a try...?

I just stumbled upon something: ================ idStaticEntity::Event_Activate ================ */ void idStaticEntity::Event_Activate( idEntity *activator ) { spawnTime = gameLocal.time; active = !active; const idKeyValue *kv = spawnArgs.FindKey( "hide" ); if ( kv ) { if ( IsHidden() ) { Show(); } else { Hide(); } } renderEntity.shaderParms[ SHADERPARM_TIMEOFFSET ] = -MS2SEC( spawnTime ); renderEntity.shaderParms[5] = active; // this change should be a good thing, it will automatically turn on // lights etc.. when triggered so that does not have to be specifically done // with trigger parms.. it MIGHT break things so need to keep an eye on it renderEntity.shaderParms[ SHADERPARM_MODE ] = ( renderEntity.shaderParms[ SHADERPARM_MODE ] ) ? 0.0f : 1.0f; BecomeActive( TH_UPDATEVISUALS ); } (SHADERPARM_TIMEOFFSET is parm4; SHADERPARM_MODE is parm7.) If I read the intent correctly, triggering a func_static is supposed to set the time offset as per target_setshadertime, and toggle parm7 and parm5 to track on/off state. No need for a script or extra entityDef (unless you want to use a script to fade a parm between values). A quick test with the following material seems to confirm that: shadertest { stone { blend diffusemap map _white red (time + parm4) green parm5 blue parm7 } } (Edited because shadertest{ confuses DR's parser and breaks the file.)

Actually jpegs should load in both DR and TDM, but they're normally used only as DR editor images. Otherwise FlakeBridge Monastery is the only FM I know of that uses them; I think they're discouraged because of compression artefacts or similar. Would 'the full treatment' involve writing a material definition? In that case, yes, you'll need one of those. As for copying stuff, I would ask the mappers involved (not least because they may have got parts of those map assets from elsewhere, under someone else's permission). Light rays are actually pretty simple to make with the built-in assets. Try this prefab: http://forums.thedarkmod.com/topic/10764-moon-ray/?do=findComment&comment=211589 Edit: or this one: http://forums.thedarkmod.com/topic/11266-moonlight-through-windows/?do=findComment&comment=220106

That could probably be done just by clamping the image and translating it. Edit: although having thought about how to keep the translation within bounds, tables might be the clearest way after all. The relevant script event is: So I expect you'd write something like $myObject.setShaderParm(9,1); Alternatively, there are a couple of Doom 3 entity defs that I think may have been removed from TDM but, if they ever worked, probably still would if restored: entityDef target_setshaderparm { "spawnclass" "idTarget_SetShaderParm" "editor_usage" "sets shaderparameters of targeted entities" "editor_color" "1 1 0" "editor_maxs" "8 8 8" "editor_mins" "-8 -8 -8" "editor_color _color" "color for the targeted entities" "editor_bool toggle" "if set (to 1), all shaderparms set to 0 or 1 will be toggled (0 to 1 and 1 to 0)" "editor_var shaderParm0" "value for shaderParm0 of targeted entities" "editor_var shaderParm1" "value for shaderParm1 of targeted entities" "editor_var shaderParm2" "value for shaderParm2 of targeted entities" "editor_var shaderParm3" "value for shaderParm3 of targeted entities" "editor_var shaderParm4" "value for shaderParm4 of targeted entities" "editor_var shaderParm5" "value for shaderParm5 of targeted entities" "editor_var shaderParm6" "value for shaderParm6 of targeted entities" "editor_var shaderParm7" "value for shaderParm7 of targeted entities" } entityDef target_setshadertime { "spawnclass" "idTarget_SetShaderTime" "editor_usage" "sets the negative (?!) current game time (as float in seconds) as TIMEOFFSET shader parm (4) when activated on targeted entities" "editor_usage" "it's -MS2SEC( gameLocal.time ), if that's any help..." "editor_color" "1 1 0" "editor_maxs" "8 8 8" "editor_mins" "-8 -8 -8" }

You can make stages conditional, so something like this should work: { if (parm9 == 0) map _white rgb sintable[time] } { if (parm9 > 0) map _white rgb pulsetable[time] }

Non-looping tables are possible: see the 'clamp' keyword described near the top of https://www.iddevnet.com/doom3/materials.php You might need to use a script that sets a shaderParm to the current time, so that the material's transition can be controlled on demand. Here's an example from Doom 3, where the game code sets parm7 to a monster's time of death to begin the 'burnaway' effect, then it's used as a time offset compared to the current time: { // burning corpse effect if parm7 // only when dead // make a burned away alpha test for the normal skin blend gl_zero, gl_one // don't draw anything map models/monsters/imp/imp_dis.tga // replace this with a monster-specific texture alphaTest 0.05 + 0.3 * (time - parm7) } { // burning corpse effect if parm7 // only when dead // draw the fire burn at a negative polygonOffset, so it is behind the other stages privatePolygonOffset -1 // stage-only polygon offset blend add blend gl_one, gl_zero map models/monsters/imp/imp_dis.tga // replace this with a monster-specific texture alphaTest 0.3 * (time - parm7) } Since you mention additive blending, if it's okay for the material to be rendered fullbright then using a GUI surface might be an alternative (more complex but more powerful). (I wouldn't bet on GUIs working in light materials, though.)

Trick or thief...

Actually DR does have a menu shortcut for binding: select intended bind child additionally select intended bind master in the top menu bar, go to Entity --> Bind selected entities