VanishedOne
-
Posts
1235 -
Joined
-
Days Won
24
Posts posted by VanishedOne
-
-
a bloated waterlogged zombie
At one point it was planned that Doom 3 zombies would expand or shrivel during their deaths. The code path is still accessible by setting shaderParm8 to nonzero on an entity with an MD5 model, but it appears to be horribly broken.
-
Haven't used those yet, but shouldn't cubic lights be omni-only by default?
Well, that's what's under discussion. I suggested that spherical falloff, which the cubelights can have, could be a good option for projected lights.
As far as I could tell from a quick test, the projected cubelights that exist in ARB don't change the 'field of view' from 'inside' the cube when the projection gets wider, so the projection texture works in practice like a regular projected light's. Which is probably what you want from a spotlight or similar.
-
I wondered whether someone had planned Fire Elementals to be in some manner demonic when I saw they have a suicide response to STIM_HOLY. (Though I think it's more likely someone forgot that holy water still carries a water stim like the regular water arrow result.)
The wiki reference to demonic spiders (assuming it wasn't written by a troper) might be a reference to this (which was abandoned because of dependency on Doom 3 assets), though perhaps only whoever wrote it knows for sure.
Ghouls apparently existed at one point, but as another entity class derived from D3 zombies; while standalone TDM has D3-free zombies, I'm not aware of any efforts to bring ghouls back, and honestly I've no idea how they differed from zombies.
-
1
-
-
Apparently there's code support for using _scratch to create GUI overlay transitions from the loading screen, which is why it has the loading image in it if you use it in a material (unless you're playing with mirrors or something). Is TDM's 'click to start' screen invoked at every map start or just once at mission start? If the former it might get in the way of using that.
-
No, DR is all Chinese to me.
I mean the result flags in the material file.
Omni/projected lights aren't distinguished in material defs. (Before cubic lights were introduced it was safe to assume any light material could be used with either light type. You can even make projected foglights if for some bizarre reason you want a pyramid of fog.) They have different entity spawnargs in map files.
Basic omni light:
{ "classname" "light" "name" "light_1" "origin" "0 0 0" "light_center" "0 0 0" "light_radius" "320 320 320" }Basic projected light:
{ "classname" "light" "name" "light_1" "origin" "0 0 0" "_color" "1.000 1.000 1.000" "light_right" "128 0 0" "light_target" "0 0 -256" "light_up" "0 128 0" }Basic projected light with defined starting distance:
{ "classname" "light" "name" "light_1" "origin" "0 0 0" "_color" "1.000 1.000 1.000" "light_right" "128 0 0" "light_target" "0 0 -256" "light_up" "0 128 0" "light_end" "0 0 -256" "light_start" "0 0 -64" }-
1
-
-
How do you set a light to be Omni or Projected?
In DR? Select a light, press L for light properties, and the option is there.
To make fine adjustments to a selected projected light, press V for vertex mode and you can select the control points and drag them. (This also works on omni lights but the only available control point is the light centre: some TDM lights, like fireplace flames, oscillate it at runtime to make shadows bounce. Omni lights are mostly manipulated in DR by resizing the bounding box.)
I don't think a bugtracker's needed, the error is normal as normal (pointLight) lightdefs need a 2d projection texture, the light definition will simply not accept an image that's part of a cubemap/a cubemap material in the "map" field.
grate6 and cubegrate6 both work individually; what failed was placing them in the same map. My hunch from the error message was that the engine expects lights/grate6 to point to either lights/grate6.tga or six image files with suffixes like _pz, etc. and can't handle cases where both need loading as lights/grate6 and map versus cubeMap/cameraCubeMap determines which applies. Still, as bugs go it's an avoidable niche case.
Projected lights have a hard cutoff because their shaders oftentimes don't have good falloff images (or ones optimized to work for proj. lights). Check out the lanternbot light to see a light definition with good falloff (it's basically biground1 used as a falloff, but it does the trick). Dragofer's hand lantern uses a falloff like that to ensure a smooth fade.
Top image, left-hand light in this post is the lanternbot spotlight. There's some falloff there, but it's clearly to a straight edge compared to the cubelight on the right. (Since falloff images are effectively 1D.)
Five types of light definitions (by keyword) - fog light, point light, ambient light and then our two (at least there were only two last time I checked), new ones - ambientcube and cubic. All of those could be set to either be Omni or Projected.
Also blend lights.
Tell you the truth I am looking for opportunities to lose as many textures as possible for performance reason.
What do you think about having a formula falloff instead of texture.
E.g. falloff = 1/(1+distance^2);
Formulae could be good as an option. Have you seen the _quadratic internal image? It's useful in making light flares:
textures/darkmod/sfx/flare_quadratic { //sort far noShadows translucent nonsolid deform flare 13 + sintable[time*0.2] qer_editorimage textures/darkmod/sfx/candleglow.tga { blend add map _quadratic red 0.3 //* sintable[time*0.1] green 0.3 //* sintable[time*0.1] blue 0.2 //* sintable[time*0.1] } }Edit: _noFalloff is also an internal image, used as the falloff image by lights/defaultProjectedLight.
-
I'd be interested to hear any other people's opinions first, but my current thinking is that the option of using spherical falloff on projected lights would be nice to have. Projected lights are pretty handy if you want something like a spotlight: you can project a texture onto an arbitrary quadrilateral, from an arbitrary starting distance, just by dragging points around in DR. But they fall off to a noticeably straight edge.
And yes, those are non-ambient lights. (I don't know whether anyone has found a use for projected ambient lights in maps...)
-
Ah, now I run a search for it... http://forums.thedarkmod.com/topic/7577-decals-and-blending-problems/
Apparently I've never used it on a light-interactive decal. Sorry about that.
As the linked thread says, you might need to move the decal slightly forwards if the surface below starts interfering with it.
-
I've encountered a bug in the projected cubelight implementation: I made a cubic spotlight parallel with the ground, and it insisted on trying to draw outside its bounding box, apparently at constant (moderate) brightness. Setting "falloff" "1" and un-uncommenting zeroClamp didn't help.
(Right is omni cubegrate6; next is projected cubegrate6; left is a projected, non-cubic lanternbot spotlight. The omni cubelight has a nice rounded falloff compared to the ordinary projected light.)
Standard id Tech 4 omni lights project a texture along an axis like a stick of rock; they're 'point' lights for shadows/bump mapping, but when it comes to placing one in a map it's more like a column of illumination, usually with a falloff to hide the fact it isn't a sphere. (That's why people earlier in the thread are getting excited about cubelight lamps that don't project their textures like this.) Projected lights are more like a pyramid with a point and a wide end.
Something that projected lights can do and I don't know how to reproduce with omni cubelights is that projected lights can start their outward projection at a distance from the light origin instead of projecting right from a point:
(Far is projected non-cubic; middle is projected cubic; near is cubic omni.)
As for technical details, we'd need nbohr1more to comment. (In particular I'm not sure whether the angle/width of a projected cubelight has anything to do with the 'FOV' of the projection, so to speak.)
-
Some bits of the image look pretty dark though, so using colour as the basis for the alpha mask might produce unwanted holes.
-
So the colour channels did save to the file. Strange; I wonder whether DECAL_MACRO messed something up.
You could try blend filter, like Obsttorte suggested. I would also try blend gl_dst_color, gl_src_color.
-
I'm not sure whether that was a question to stgatilov or a response to me that referenced stgatilov; if the latter, the answer's no.
-
-
Ambient light no longer lights things up from the player's eyes, it lights from the top down, so that causes normalmaps to look different.
Cheers. I think the use of specular colour is part of it too. Here (in ARB) the highlights further from the top have a clearly blue component:
The GLSL fragment shader has a commented-out bit about revisiting fresnel later, and I don't think it references specular RGB at all.
-
Ambient light, ARB versus GLSL:
Light is white lights/ambient_biground
Surface materal is:
ambTest { qer_editorimage textures/darkmod/nature/dirt/dirt_packed_muddy_ed bumpmap textures/darkmod/nature/dirt/dirt_packed_muddy_local { blend diffusemap map _white red 1 green 0 blue 0 } { blend specularmap map _white red 0 green 0 blue 1 } } -
Is there anything I can do per AI class to override mines' detonate_on_actor behaviour, so ghosts can walk through/over them without setting them off?
I can shoot broadheads through my ghost but he still triggers mines, even though they both seem to be technically projectiles. (Actually I don't mind being able to attack him directly, Thief-style; it's the idea of a ghost setting off landmines' sensors that makes him seem a bit too corporeal.) I've tried monkeying about with big_monster, clipmodel_contents, cylinder, mins, maxs, solid, use_combat_bbox, and also offsetModel in combination with these in hope of getting him to float above the mines. His materials (of those that aren't nodraw) are set to nonsolid (and noimpact). I'm guessing maybe his origin (at ground level) is involved.
This may or may not be related to the problem Destined was having with splash damage:
http://forums.thedarkmod.com/topic/17092-transparent-ai/page-3?do=findComment&comment=381645
-
1
-
-
@VanishedOne and Spooks:
Are some of the cubicLight problems being seen for projected lights?
As I recall, only "point lights" were implemented in GLSL. (After much begging...)
We weren't aware of any real compelling use case for projected lights with cubemaps so it
wasn't worth the battle at the time. If you really need projected cubicLights, I'll go back and
argue the case to Duzenko.
In the top image, in the starting room of ambientcube.map I've changed the middle light from projected to omni and resized its bounding box to restore the projection onto the floor. So the middle light is an omni cubegrate6 and the other two are projected cubegrate6.
I tried to get a side-by-side comparison with the regular grate6, but TDM either refused to load the map ('ERROR: Image 'lights/grate6' has been referenced with conflicting cube map states') or outright crashed. (Shall I file a separate tracker issue for that?) So here all three lights have been changed to projected, non-cubic grate6:
grate6 and cubegrate6 actually have a different grate image - the ordinary grate6 has more white near the edges - so here's a version of the second shot where I've overridden the grate6 image with one of the cubegrate6 faces:
(Edit: I originally said the cubic lights didn't have the wavy lines projected onto the back wall, but on close examination I can see them in the middle one; they're just weaker.)
If we assume the projection onto the ceiling is something you'd fix by altering the cubemap, then what stands out about the projected cubelights is their projection onto the back wall: it gives a much stronger impression of light hitting from above at a sharp angle.
On that evidence, I think projected cubelights merit further investigation. I'll post if I find anything interesting.
-
1
-
-
@VanishedOne and Spooks:
Are some of the cubicLight problems being seen for projected lights?
As I recall, only "point lights" were implemented in GLSL. (After much begging...)
We weren't aware of any real compelling use case for projected lights with cubemaps so it
wasn't worth the battle at the time. If you really need projected cubicLights, I'll go back and
argue the case to Duzenko.
The cubegrate6 lights in ambientcube.map are projected.
I'll reply to your final paragraph over on the cubic lights thread.
-
I'm not very familiar with that program, but which version are you using?
https://stackoverflow.com/questions/8267075/save-only-layer-mask-in-gimp#comment47255229_8271091
-
It sounds as though you want an alphatested material. Assuming your alpha channel is set up as 1 = opaque, 0 = transparent, then
name/of/decal { DECAL_MACRO { blend diffusemap map path/to/image alphaTest 0.5 } // here you could insert more stages: the bumpmap from the wood material, maybe a specular map if it's shiny paint }-
1
-
-
If the decal is meant to use alpha, and isn't meant to be alphatested (fully opaque or fully invisible depending on whether alpha > a threshold value; allows diffuse/specular/bump light interactions on the opaque pixels), then you may be looking for an alpha-related blend.
name/of/decal { DECAL_MACRO //activates some stuff decals often use { blend blend // alias for blend gl_src_alpha, gl_one_minus_src_alpha // which is (your image's RGB * its alpha) + (the colour of the surface below * one minus your image's alpha) map path/to/image } }Here light interaction will only be with the colour you get from the surface below, so depending on your needs you may encounter unwanted glow-in-the-dark effects. (This is why Obsttorte's talking about darkening and suggesting blend filter, which doesn't use alpha but multiplies the decal colour by the colour of the surface below. ) If you give us more information about the intended look we might be able to suggest a suitable blend mode.
-
More cubemap trouble. This is Epi's test map from the parallax cubemaps thread:
-
Possibly the same problem as the windowed door I posted earlier: this material displays its bumpmap in 2.05 but not 2.06.
xxxx { qer_editorimage textures/darkmod/nature/dirt/dirt_packed_muddy_ed bumpmap textures/darkmod/nature/dirt/dirt_packed_muddy_local { //blend add cubeMap env/gen1 texgen reflect } }When I removed the bumpmap line I encountered something else unexpected.
2.05:
2.06:
2.06 after I tried extracting env/gen1 from the .pk4:
The 2.05 and 2.05 images don't look any different when I extract them and look at them in IrfanView; and inside the .pk4, in both 2.05 and 2.06 they have a last modified date in 2014.
-
I had a look at the new GLSL interaction fragment shader from the 2.06 beta.
I seems to use a different test to decide whether to apply the default 0.026 specularity. rgb sinTable[time] no longer causes the specular stage to blink on/off.
I'm unsure without trying whether map _black alone to disable the default specularity will still work (is it testing for rgb 0 instead?).
(I haven't confirmed that it does work under ARB; it's something from the previously linked thread.)
I noticed that this bit...
// fresnel part, ported from test_direct.vfp ... color = color * light * var_Color.rgb * u_diffuseColor.rgb * lightColor(); return color;
...seems to multiply by the diffuse colour as nearly the last thing it does before returning, which matched my impression that the enhanced shader (both ARB and GLSL) scales the highlights by the diffuse RGB.
I experimentally modified it to be more like the simple interaction shader:
vec3 advancedInteraction() { vec4 fresnelParms = vec4( 1.0, .23, .5, 1.0 ); vec4 fresnelParms2 = vec4( .2, .023, 120.0, 4.0 ); vec4 lightParms = vec4( .7, 1.8, 10.0, 30.0 ); // compute the diffuse term vec3 color = texture2D( u_diffuseTexture, var_TexDiffuse ).rgb * u_diffuseColor.rgb; // compute the specular term float specularPower = 10.0; float NdotH = clamp( dot( N, H ), 0.0, 1.0 ); float specularContribution = pow( NdotH, specularPower ); vec3 specular = texture2D( u_specularTexture, var_TexSpecular ).rgb * u_specularColor.rgb; // fresnel part, ported from test_direct.vfp vec3 fresnelTerm = vec3(pow(1.0-dot(normalize(var_tc6), RawN), fresnelParms2.w)); vec3 R1 = vec3(min(NdotL - 0.3, fresnelParms.z)); vec3 rimLight = R1 * fresnelTerm * lightParms.y; vec3 R2 = vec3(0.026); if (dot(u_specularColor, u_specularColor) > 0.0) R2 = specular; R1 = vec3(dot(normalize(normalize(var_tc0)+normalize(var_tc6)), RawN)); float R2a = mix(lightParms.z, lightParms.w, R2.z); R1 = vec3(pow(R1.x, R2a)); R1 = R1 * fresnelParms2.z; vec3 R3 = vec3(fresnelTerm.x * fresnelParms.y + fresnelParms2.y); R1 = R1 * R3; R3 = color * 0.25; R3 = R2 * R3; R3 = R2 * 0.75 + R3; R1 = R1 * R3; vec3 LM = normalize( var_tc0 ); float R2f = min(1.0, max(0, LM.z * 4.0)); vec3 light = clamp((rimLight * R2f + vec3(NdotL)), 0.0, 1.5); // vec3 light = rimLight * R2f + vec3(NdotL); color = R1 * R2f + color; color = color * light * var_Color.rgb * lightColor(); return color; }Since I don't really know what I'm doing here I've probably broken something else, but it does seem the diffuse and specular stage RGBs can be disentangled like this.
-
1
-
Tracker 3881: Cubemap Lighting Beta
in TDM Editors Guild
Posted
In that technical sense I suppose even ambient lights are projected lights.