Tweaks to Frob highlight

[rebb]

I believe this is equivalent to "bumpmap heightmap(models/darkmod/props/textures/bc_gembag_h, 6)" so I could rewrite these defs manually before processing them with the script.

 

Is that really necessary ? If the script recognizes "blend bumpmap" and then parses the "map xyz" in, it should be fine i think.

 

I could teach my script to figure these cases out. Let me try.

 

However, I am a bit worried about the scale keyword, I don't think that will work with the new hightlight as it doesn't have a scale or individual scales for the individual maps.

 

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 ?

[Tels]

Is that really necessary ? If the script recognizes "blend bumpmap" and then parses the "map xyz" in, it should be fine i think.

 

Going to try this now.

 

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 .

 

Maybe we can just rescale the texture and remove the scale keyword? (Unless the texture is used in two different scales in two different materials).

 

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 ?

 

I can try, first need a way to let the script figure these cases out

[rebb]

One of the problems is that the script no longer adds the frobhighlight to materials that do not have a frobhigh light already.

 

That is fine for skipping the collision materials, but f.i. the tdm_trees.mtr file has materials w/o fob highlight, meaning you could never have a frobbable tree that highlights.

 

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.

[Tels]

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.

 

The problem is that:

 

* we should make a complete toolkit, not something like "80% done"

* many materials were copy&paste and they got a frobhighlight rather random (wether the original had one or not), not by careful planing etc.

 

Inserting them with the script would be much easier than someone going through and adding them all afterwards manually...

[OrbWeaver]

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 .

 

Just adding a vertex parameter for scale would probably cover the majority of cases; I don't think I've ever seen a texture-coordinate modification keyword other than "scale" used in a material.

[Baal]

With all these special cases it would be cool if the script could give a list of files/definitions that have these (bump-, diffuse-, specularmap) stages instead of the short syntax. The problematic materials are hopefully not to many so that someone can adjust them by hand.

 

The scale keyword, for example, can also be used in the frob highlight stage but then it will scale all 3 textures.

 

Is that really necessary ? If the script recognizes "blend bumpmap" and then parses the "map xyz" in, it should be fine i think.

I would prefer the script to do that but I'm not sure how much work that will be for Tels. Maybe it's enough to identify the special cases (special meaning materials that use the blend *map stage for at least on texture).

[Springheel]

Inserting them with the script would be much easier than someone going through and adding them all afterwards manually...

 

I think that makes sense. While there may be no need for a frobbable tree, it doesn't hurt anything to have the frob stage there for some use we haven't considered.

[rebb]

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 .

[Springheel]

How would the shader deal with materials using a color keyword?

[rebb]

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

[rebb]

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

[Tels]

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

 

Yes, but I had no idea it was directed at me

 

In Chalice, go through the gate in the door, get the key, go back outside and open the door (or just go through it in noclip), there is a patch (I think) in front of the fire and it was greenish in my fiest test.

 

Sorry, didn't have time to day to work on TDM.

[rebb]

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]

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 ...

 

Uh, maybe parm11 is used for something else, too? If parm11 == 1, it could be interpreted as "green = 1.0"?

 

Also, rebb, how do you recon the chance that setting parm11 == 0 .. 1.0 (e.g. instead of just 0 or 1) could influence the frob-shader? If it could multiple the value of parm11 into the color, then we could have the frobhighlight fading in/out (instead of just switching on/off) as well as make it script controlled?

[rebb]

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. :/

[rebb]

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.

[greebo]

Re DDS: Any warning messages in the console? Is the diffuse matching powers of two in its dimensions?

[rebb]

I didn't look for a warning yet, the diffuse is 1024x1024.

 

Edit : Checked a conDump now.

 

"WARNING: Couldn't load image: models/md5/chars/guards/elite_citywatch/elite_citywatch_cloth"

 

I'm not sure why it wouldn't load this, its in the proper dds/ directory and has a lowercase extension, and has been compressed like the wiki says.

[Tels]

I didn't look for a warning yet, the diffuse is 1024x1024.

 

Edit : Checked a conDump now.

 

"WARNING: Couldn't load image: models/md5/chars/guards/elite_citywatch/elite_citywatch_cloth"

 

I'm not sure why it wouldn't load this, its in the proper dds/ directory and has a lowercase extension, and has been compressed like the wiki says.

 

There is a script for that:

 

perl devel/tga2dds models/md5/chars/guards/elite_citywatch/elite_citywatch_cloth.tga

 

Only tested on Linux, but you can maybe get some inspiration The difference is probably an ALPHA on the TGA or not, this warrants different DDS compression.

 

I have uploaded the DDS created by my script here:

 

http://bloodgate.com/tmp/elite_citywatch_cloth.dds

 

(I wonder why we had a TGA in the first place, didn't we convert everything to DDS already?)

[rebb]

Thanks Tels, i've tried it with this file, but it's still not loading .

 

It's in "\dds\models\md5\chars\guards\elite_citywatch". I've tried putting it into the same directory where the TGA was, but it still didn't load.

 

Could someone else try this please ? ( make sure the .tga file is renamed first so it doesn't get loaded instead )

[greebo]

I guess you're running into D3's folder depth limitation for DDS files. You cannot have DDS files more than 5 folders deep (you're having 6 levels) - D3 just doesn't want that, only the id people know why this unfortunate limit is there in the first place.

[rebb]

Ughhhhh ... :wacko:

[Springheel]

Wow, I had forgotten about that. What a pain.

 

Is it worth reorganizing the character textures so they're not that far down? Many of them are 1024x1024.

 

I could handle that while I'm converting characters over (though it's not going to be fun).

[greebo]

If it's not too much work, I'd say yes, we should remove the 6th level from those shader folders - we need to convert these files to DDS anyway and this keeps us from doing so. And it caused rebb a little headache, it seems.

 

(It appears that this is the single most stupid limitation I've seen so far in the D3 engine (and on top of that, it's completely undocumented), once the source is open, I'd like to see a rationale for implementing this folder-depth limit...)

[Tels]

If it's not too much work, I'd say yes, we should remove the 6th level from those shader folders - we need to convert these files to DDS anyway and this keeps us from doing so. And it caused rebb a little headache, it seems.

 

Oh, yeah, please reorg them - I should have known about that limitation but I did forget. Will code in a check into the DDS script in 5 minutes so it at least warns.

 

Edit: Done.

 

What a pain!

 

Edit: I happily convert the DDS afterwards with a script.

 

(It appears that this is the single most stupid limitation I've seen so far in the D3 engine (and on top of that, it's completely undocumented), once the source is open, I'd like to see a rationale for implementing this folder-depth limit...)

 

Something to do with regular substance abuse

 

(Just kidding, it is probably something like "who needs more than 5 folder levels, anyway?")