rebb

Did you make a black Alpha1 Channel, or an Alpha-Channel with a Value of 1 in it ?

Well, the only lead i had so far was that the default door material shows up fine, while others appear green after applying a different skin, and the one showing up fine is using a .DDS diffusemap while others use .TGA . So i tried converting a guard-diffusemap to .DDS, but ended up with a black texture on them instead of a green tinted one. I did follow the wiki and got the Compressonator from there. Great.

It should be easy to use parm11 in the frob effect somewhere, yep. This green tint stuff is really giving me a headache tho, it almost looks like it's some issue with the Doom3 material system, which is barred off because its not exposed in the SDK. Hope i'm wrong tho. :/

This green problem has me baffled right now. It makes no sense that a material would show up greenish, because parm11 is 0 when its unfrobbed anyway, so the frob stage isn't even showing. Apparently removing the frob-stage does help, but only after doing a full game restart, just doing "reloadDecls" doesn't seem to reload the material in this case. What the Taff ...

@Tels : Did you see the question about the green patch ?

Make sure that the light-projection image has an alpha-channel filled with a value of 1 ( 0-255 scale ), or the fixed ambient light won't catch on.

It can be modified to take an additional vertexParm that multiplies with the diffuse / specularmap.

About the greenish guards etc - which patch in which map is showing the greenishness ? I tried editing some materials of the guards, disabling the frob-highlight stages but they still remain green after reloading the materials, how strange. Maybe its more clear when looking at that offending patch .

Oops, wrong thread. Damn sleep deprivation. >_<

I think its ok to only replace already existing frob-highlight stages. If someone really wants a frobbable tree, they can always put that in manually, imo.

Is that really necessary ? If the script recognizes "blend bumpmap" and then parses the "map xyz" in, it should be fine i think. Yeah you are right, these special cases could be a problem, altho the vfp can be modified to take in some additional variables for texture offsets and scale etc, but those are limited . Would it be possible for the script to put in another type of "check-line", into materials where there are things like "blend diffusemap", "blend bumpmap", "blend specularmap" - so we could see how many those are and manually check what special stuff they do in these stages ?

A missing bumpmap and specularmap is ok, in case of a missing bumpmap the game just uses the vertex-normals - but diffuse is pretty important, otherwise you just have a black lump of geometry, at least on things that are supposed to be opaque. But the main use of the check-line is to know which materials aren't opaque, and that they should be looked at specifically to see what should go into the diffuse slot of the frob. So i'd say it's enough to only insert the check-line when no diffuse is found. This really seems to be quite the minefield of special cases, argh .

Hmmm, and those 663 all had the old frob-stages too ? If not, then it's probably enough to only put that check-line into materials that had frob-stages in the first place. 663 seems a bit much, but who knows .

I think i found whats causing the collision-models to show as black. Your script seems to insert the frob-stage into materials without checking if they had the old frob-stages in them. It would be best if the script detected the old frob-stages, and replaces them with the new one. Thats why the new frob-stage shows up in all the collision-materials too .

Hmmm, could your script maybe put a line like "//::CHECKPLEASE::" inside materials that have no diffuse/spec/normalmap, like that glass you mentioned ? So then one could do a simple filesearch and change the offending materials manually - since those probably aren't a lot, it should be quite manageable. Going to check stuff using your diff now, thanks .

Doing it manually sounds like a horrible chore to me, i'd feel really bad if that was forced on people . I've started experimenting a bit using Python and Regular Expressions - not sure if it will work out tho, i guess Tels has tons more experience. But with only 1 hour per week it might really take him a long time until it works.

Yeah it's probably tricky to write a script that automatically extracts the map assignments and feeds them into the new stage. I wonder if a really elaborate regexp could do it, but i haven't used a lot of regexp myself - so no idea how complex those can be. Unfortunately that doesn't work. Games like Prey, Quake4, ETQW made the idTech4 Material System a lot more versatile, in Doom3 its very basic tho. Btw, just to deflect a possible misunderstanding : the "fragmentMap 2" is only supposed to be "_black" if the containing material has no specularmap.

A tricky bit is probably materials where there is no direct "diffusemap xyz.tga" assignment etc, but where the diffuse/bump/spec is assigned inside a stage with the "blend diffuse-/bump-/specularmap" keyword.

Yep

I updated the frob.vfp and added some more models to the test/frobhilighting.map, it's on the SVN now. The overlay-effect used in the pulse is now done inside the .vfp, so there's no need for an extra stage for that.

I'm not sure what you mean by that - do you mean all the additional stages in the test-materials ? Most of these are from the other 3 frobhighlight-types, otherwise they couldn't be switched to using the alcoves in the test-map. Just the stage/block that contains the vfp-reference in it is the one needed for the fragment-program based effect.

The most recent on is on the SVN in the materials inside test_frobhilight.mtr , i can extend the test-map with a few more models and their respective materials.

The current pulse-effect is just a simple extra additive stage that can be bound to any free shaderparm. I don't mind if it gets voted off tho, it might get annoying when carrying something frobbable around for example. Performance-wise, i didn't notice anything, thats probably something for the people here who have very low-end systems to test. There shouldn't really be any tho, as the fragment-program is just being executed once per "pixel of the frobbed object". Not potentially multiple times like the interaction-program when theres multiple lights overlapping.

I'm looking forward to Thief4, as long as they make sure that it stays true to the Spirit of the Series, and doesn't get mushed up into something that is catered specifically to an adolescent target-audience.

Hell yeah, it's a new THEIF !