duzenko

Two TDM threads plus the invisible OpenGL driver thread Adding more threads are not likely to help due to RAM access quickly becoming the bottleneck For all I know there's a naming confusion. The script idThread's all run on the main thread.

Please test

In that case we might as well use the new custom material shader I've added recently Do you have a test map for this?

Independent of light source meaning a separate material stage resulting in one more draw call and needing a new GLSL shader? Or rather a parameter for the ambient light interaction that adds brightness on visible rims when doing our existing ambient light interactions?

Right But the this rim highlight should only appear as a component of ambient light interactions, no? Because we already have some fresnel in the point light interactions.

We're talking ambient lights here, right?

Yes, I just need to be poked every so often so I remember that it's something useful for mappers/players What's the consensus on controlling this effect? Material flag / entity spawn arg / etc?

No, AFAIU the coal surface is considered "back-facing" and culled because of that. The stencil code seems to only process triangles facing away from the light. You can test that by switching materials on the two surfaces that make up the model. Currently one of them is noshadows.

Can you replace the funcstatic above with atdm:torch_cagelamp_hanging?

Is this it? // entity 894 { "classname" "func_static" "name" "func_static_2452" "bind" "func_pendulum_13" "model" "models/darkmod/lights/extinguishable/cagelamp_hanging.lwo" "origin" "-3479 3418 373" } If so, am I right that it's instantiated as an idStaticEntity in the C++ code and is not bound to any script?

What is "it" and where is it defined (as model or entity)?

Do you think that script does anything for lights that aren't toggled in game? I.e. the hanging light in NHAT is just on from the very beginning and since no changes happen then probably the script does not get called?

Try now I don't know why it was only the single pass broken but there was a bigger problem of duplicate/unnecessary views generated by the frontend

How about rename darkmod.cfg and start with an empty one?

I'm afraid we should pause on the single pass shadow maps for now The GS appears to be too slow for the task. Our current code does it on the CPU only when interaction is created/changes. It's slow with dynamic interactions, but there are not too many of them. I hoped the GS could do it in real time but alas it's about 40% slower than using the pre-computed index subsets

Not to start another verbal battle, but the important words have been spoken. As long as Biker can find his own fault and confess it in public, the matter is settled in my eyes. I know I'm not perfect by any benchmark so Biker you can have my compassion Personally I find the copy-pasted geometry in missions to be obviously pathetic but no more than that. What is more annoying for me is the repetitive pick N locks & frob M goblets gameplay.

What's your SS radius cvar value?

Sorry, can't repeat

Umm... The trivial fix is to add a noshadows flag to the compass light (which is also healthy in the performance aspect). Committed to svn. Please advise if I went in the wrong direction.

Try now

Try textureGather - that would quadruple the sample count

Try r_fullscreen "0"

After a quick playthrough there are things that left me wondering What happened to Carl and Bernard? And to Oscar? And what's Elma's role in that?

For starters, try it in a window

anoot.map, models/darkmod/lights/extinguishable/cagelamp_hanging.lwo One of the warehouses ]getviewpos -3439.24 3447.35 306.67 -17.7 -127.4 0.0