Using multiple texture maps in material via Proxies

[Guessmyname]

On a scale of 1 to 'are you nucking futs?', how hard would it be to hijack the Material Proxy system to add extra texture maps? I'd figure it working somewhere along the lines of this:

Code: Select all

LightmappedGeneric
{
   $basetexture      whatever/whatever
   $bumpmap      whatever/whatever_bump

   //custom vars
   $layer1transform   //equivalent to basetexturetransform

   Proxies
   {
      MaterialLayer   //add a texture map
      {
         material   "whatever/whatever_layer1"
            //filename of vtf, relative to materials.
            //Should blend via alphachannel if present   
         materialtransform   $layer1transform
            //ie "center .5 .5 scale 1 1 rotate 0 translate 0 0"
         blendmode      "normal"
            //standard blendmodes (ie additive etc)
            //bonus points if someone implements 'Overlay', 'Multiply' etc
         alpha      1
            //equivalent to $alpha
         uvchannel      1
            //what uv channel to apply this with. For models only; no effect on brushes.
      }
   }
}


This would allow for many, many more tricks when it comes to modelling large pieces of geometry (of the sort that involve a lot of tiling and uv fiddlery), and could be expanded on in other ways (for example, complex holograms with UnlitGeneric and $additive). I don't know how accessible things like the $envmapmask and $bumpmap would be to having these sort of modifiers, but they are, that would be awesome.

And on an unrelated note: Using black-to-white vertex colours as an 'alpha mask' of sorts for applying WorldVertexTransition textures to models? Doable? Possible? (Can you even access the model stuff from in the SDK code?)

I, sadly, am no coder; this is coming from the art side of things after drooling over the UDK's material editor and wondering if we could ever see something similar in Source. I'm just asking as a sort of feasibility study, and to gauge, should I suggest this to a few code-savvy friends of mine, how painfully they will rip out my spleen.

[-=Biohazard=-]

Adding additional textures this way won't be a good idea. The shaders in udk are also compiled in the end afaik, while these things done with proxies wouldn't be compiled and you'd have to reserve a lot of stuff, stuff which is rare. The standard shaders already use most of the 16 possible textures per pass, you would have to reserve the other samplers to make this work, and that'll be hard w/o crippling the shaders.

I'd rather suggest you to create a new shader that does the exact thing you need, that way you can use up the resources way more efficiently.

Other possible things would be adding more passes with each proxy. It would allow you to have way more textures per pass, but all in all not more than 4 active passes. Or you add a proxy that causes the model to be drawn another time with a material override (would sadly not work with the world).

And yes, with customized shaders you could load two albedos and blend between them on models for sure, though i don't think you can do that with vertexcolors, but why not just load another texture to define the amount of blending (or add it to a channel of another texture). I also don't think there's a way to define multiple uv maps per model...

[pfannkuchen_gesicht]

it's possible afaik, have a look at one of those rt monitor materials

[-=Biohazard=-]

it's possible afaik, have a look at one of those rt monitor materials

Those just use a special shader (unlittwotexture) that allows you to have... two textures layered on top. The way I understood it Guessmyname would like to have something way more flexible

[Guessmyname]

Nah, Biohazard had the idea right on the mark. Didn't know about the textures-per-pass thing; damn. Though the blending shader is an excellent idea! Would actually allow even more control than using vertex painting...

Thanks for the advice!

Re: Multiple UVs; it's entirely possible (for example, multiple materials on models use multiple UVs), but using 'extra' ones in Source is fairly pointless as it isn't used by anything (in the UDK, you need to create an extra, non-tiling UV set - unless the original is non-tiling already - if you want lightmapping on your model)