Tweaks to Frob highlight

[greebo]

@rebb: can you adjust the shader such that the pulse is using an entity shaderparameter (parm10 or something), I'll take care of the SDK side of things then. Seems like the pulse will be off by default, but we'll keep the option, I'd say as the code is already there.

[rebb]

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.

[greebo]

Ok, so I assume the material posted above is the most current one?

 

Are there any volunteers to apply this tweaked frob highlighting method to a few materials (like statues, crates and loot) to see what a script would need to do? Once that's done, we only need to convince Tels to write a custom Perl script, or find somebody else doing it in Python or something else.

[Tels]

Ok, so I assume the material posted above is the most current one?

 

Are there any volunteers to apply this tweaked frob highlighting method to a few materials (like statues, crates and loot) to see what a script would need to do? Once that's done, we only need to convince Tels to write a custom Perl script, or find somebody else doing it in Python or something else.

 

Just send me a PM with the changes you want to have, and allow me a few days (social life takes away all my free time

 

No, honey, I didn't say anything, yes, I am on my w*pluggetspulled*

 

Edit: Don't forget it to add to http://wiki.thedarkmod.com/index.php?...rParm_variables

[rebb]

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.

[Tels]

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.

 

Ugh. Do we really want to add nearly one page of conditional blocks for *each* material? That will create a lot of copy&paste

 

Maybe material definitions can inherit from some generic definition?

[rebb]

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.

[rebb]

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.

[greebo]

So, the actual frob-highlight stage is looking like this?

 

// TDM Frob-Highlighting
{
	if ( parm11 > 0 )
	blend 	  gl_one, gl_src_color
	program 	frob.vfp
	vertexParm  0	0
	fragmentMap 0	models/darkmod/props/textures/crate03_local
	fragmentMap 1	models/darkmod/props/textures/crate03_d
	fragmentMap 2	_black
}

 

I assume this replaces the other two frobhighlight stages we had before?

[rebb]

Yep

[greebo]

@Tels: from what I see, the job description for a script would be:

 

- Go through all the materials.

- Find the terms for diffusemap, bumpmap and specularmap

- If no bumpmap or no specularmap => use _flat for bump or _black for specular

- Remove the existing frobhiglight stages

- Add the above one, with the correct names for diffuse, bump and specularmap

 

(Alternatively, the script could remove one of the existing highlight stages, and replace the contents of the second one with the contents of the block above.)

 

The existing shaderstage(s) can be recognised by

 

{ if ( parm11 > 0 )

 

ignoring whitespace.

[rebb]

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.

[Tels]

@Tels: from what I see, the job description for a script would be:

 

- Go through all the materials.

- Find the terms for diffusemap, bumpmap and specularmap

- If no bumpmap or no specularmap => use _flat for bump or _black for specular

- Remove the existing frobhiglight stages

- Add the above one, with the correct names for diffuse, bump and specularmap

 

(Alternatively, the script could remove one of the existing highlight stages, and replace the contents of the second one with the contents of the block above.)

 

The existing shaderstage(s) can be recognised by

 

{ if ( parm11 > 0 )

 

ignoring whitespace.

 

We have about 2000 material definitions, but even with that, writing a script that implements the above (and does it correctly) is very probably far more work than just replacing the material blocks manually.

 

The reason is that I currently don't have a parse that preserves everything to be able to write the material out like it was before (minus the old and plus the new code).

 

That means I either need to write such a parser (not gonna happen with the +1h I have per week for TDM, sorry) or I hack together a script which just filters - but that is very error prone. Gah....

 

Let me think a day, I have a free night on Wednesday...

 

Edit: Actually, I could use the existing parser to get the diffusemap/bumbmap names, and then use this info in a simpler filter script which can just replace whole blocks with a new block. Still, will take a few hours.

[Tels]

So, the actual frob-highlight stage is looking like this?

 

// TDM Frob-Highlighting
{
	if ( parm11 > 0 )
	blend 	  gl_one, gl_src_color
	program 	frob.vfp
	vertexParm  0	0
	fragmentMap 0	models/darkmod/props/textures/crate03_local
	fragmentMap 1	models/darkmod/props/textures/crate03_d
	fragmentMap 2	_black
}

 

I assume this replaces the other two frobhighlight stages we had before?

 

Is it somehow possible to re-use the diffusemap name like so:

 

// TDM Frob-Highlighting
{
	if ( parm11 > 0 )
	blend 	  gl_one, gl_src_color
	program 	frob.vfp
	vertexParm  0	0
	fragmentMap 0 NORMALMAP
	fragmentMap 1	DIFFUSEMAP
	fragmentMap 2	_black
}

 

e.g. are there some keywords that would refer back? That would greatly simplify things

[rebb]

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.

 

Is it somehow possible to re-use the diffusemap name like so:

 

// TDM Frob-Highlighting
{
	 if ( parm11 > 0 )
	 blend	   gl_one, gl_src_color
	 program	 frob.vfp
	 vertexParm  0	0
	 fragmentMap 0 NORMALMAP
	 fragmentMap 1	DIFFUSEMAP
	 fragmentMap 2	_black
}

 

e.g. are there some keywords that would refer back? That would greatly simplify things

 

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.

[greebo]

Well, if a script turns out to be too much work, then I will place my bets on a betamapper teamwork initiative, to distribute various material files evenly among a few people, and let them chew through them. Grunt-work, but possible within a few hours if many people are working together.

[Baal]

If we have to do it manually I'll help with it. That's probably easier than writing a parser for the material definitions. And I guess doom's parser is not in the SDK?

[greebo]

If we have to do it manually I'll help with it. That's probably easier than writing a parser for the material definitions. And I guess doom's parser is not in the SDK?

Doom's parser wouldn't help much, but we have working parser code in DarkRadiant. I could expose a number of methods to Python scripting, but still, the ground problem is to preserve the existing materials including comments and indentations as much as possible. Sounds like a script won't cut it here.

 

Maybe you could run a quick test on one .mtr file (say, some tdm_models_decorative one) to estimate how much work would be actually necessary?

[OrbWeaver]

Doom's parser wouldn't help much, but we have working parser code in DarkRadiant. I could expose a number of methods to Python scripting, but still, the ground problem is to preserve the existing materials including comments and indentations as much as possible. Sounds like a script won't cut it here.

 

I thought of that too, the problem of course is that DarkRadiant's parser contains only the functionality that is needed for DarkRadiant itself, and there is a whole load of stuff missing. It won't even understand those vertex program blocks, let along preserve them or allow them to be modified.

 

You're also correct about the indentation and commenting; all of this would be normalised (i.e. removed in the case of comments) if an automatic parser was used.

[rebb]

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.

[Baal]

using Python and Regular Expressions

I thought about the same thing but I too don't have much experience with python. I guess one could process a material definition file line wise, assign them to blocks through the parentheses and check them with appropriate regular expressions.

[greebo]

Either that or maybe I can also do a quick fix-up parser in C#, which I have available at work (don't have Python there). Whatever it is, we should get this done rather soon.

 

ad manual grunt work: 2000 material definitions divided by 10 people is 200 each. This takes about 2 hours per person, I estimate. Feasible.

[Tels]

Doom's parser wouldn't help much, but we have working parser code in DarkRadiant. I could expose a number of methods to Python scripting, but still, the ground problem is to preserve the existing materials including comments and indentations as much as possible. Sounds like a script won't cut it here.

 

Maybe you could run a quick test on one .mtr file (say, some tdm_models_decorative one) to estimate how much work would be actually necessary?

 

Yeah. but my free evening is wednesday, which is only tomorrow

[Tels]

Either that or maybe I can also do a quick fix-up parser in C#, which I have available at work (don't have Python there). Whatever it is, we should get this done rather soon.

 

Uhm, I don't know how long it took you guys to decide "we should do it", but can't you wait at least a few days until I actually *tried* something? Does every change have to be debated for weeks only to be implemented overnight? *sigh*

 

As for the parser, look at:

 

devel/lib/Games/D3/Parser.pm

 

it already exists... (and you can estimate how much work it would be to build a new one), but I need to tie it in with a filter to replace the blocks etc. And deveoping this, debugging it etc just takes time (and a not-so-sleep-deprived tels). A bit more patience please

[Baal]

I don't know perl and, after looking into the file, I lost the will to learn it.