Script variables in Material Definitions
by Kirk Longendyke · in Torque Game Engine Advanced · 09/04/2007 (9:45 am) · 4 replies
Mostly out of crosity, though admitedly, I'm sure theres plenty of uses for the notion: is there any *Stock* methodologies for utilising a scripted variable in a material definition, say...
?
The reseach I've squeezed in to date (pretty low priority tbh) has suggested otherwise... Granted, if we really REALLY just couldn't live without mixnmatch for this particular case, it aint horribly complicated to set aside a squared-off face on a seperate swapable texturesheet and run it through that way, just thinking further on down the line to things like, say, blending a damage texture on top of the base texture with alpha determined by the object's health, as a for instance... Fully aware of course that this'd likely run counter to the batching philosophy to a degree, since you'd need one 'texture' per-asset at that point, of course.
Again, mainly curious to see just *how* far away the notion is from engine usage intent.
new Material(buggy_body002a)
{
baseTex[0] = "./enzored";
bumpTex[0] = "./enzoredb";
glow[0] = false;
emissive[0] = false;
pixelSpecular[0] = true;
specular[0] = "0.5 0.5 0.5 0.5";
specularPower[0] = 64.0;
FXIndex = 7;
preload = true;
baseTex[1] = "./" @ $Pref::PaintjobOverlay;
};
$Pref::PaintjobOverlay = enzodecal;?
The reseach I've squeezed in to date (pretty low priority tbh) has suggested otherwise... Granted, if we really REALLY just couldn't live without mixnmatch for this particular case, it aint horribly complicated to set aside a squared-off face on a seperate swapable texturesheet and run it through that way, just thinking further on down the line to things like, say, blending a damage texture on top of the base texture with alpha determined by the object's health, as a for instance... Fully aware of course that this'd likely run counter to the batching philosophy to a degree, since you'd need one 'texture' per-asset at that point, of course.
Again, mainly curious to see just *how* far away the notion is from engine usage intent.
#2
Yes, and no, and it depends on how you define "feeding shader constants by script".
If you are talking about iteratively providing data from script to a specific shader per frame, then yes of course it's a bad idea, but TorqueScript provides a variety of capabilities for a scripter to help define how a shader is going to operate via not only the Materials system, but the ability to use persistent global variables to setup data sets of importance to the shader.
The OP's example implies the ability to change a material definition during run time, which would require a re-run of the procedural shader, but that isn't necessarily a bad thing if properly framed--you wouldn't want to do it truly "on the fly" most likely, but you could stage those adjustments (and re-runs of the procedural shader generator) well enough such that the delay wouldn't be noticeable.
09/11/2007 (10:08 am)
Quote:
Heretic.
http://msdn2.microsoft.com/en-us/library/bb219737.aspx
Feeding shader constants by script is not worth it.
Yes, and no, and it depends on how you define "feeding shader constants by script".
If you are talking about iteratively providing data from script to a specific shader per frame, then yes of course it's a bad idea, but TorqueScript provides a variety of capabilities for a scripter to help define how a shader is going to operate via not only the Materials system, but the ability to use persistent global variables to setup data sets of importance to the shader.
The OP's example implies the ability to change a material definition during run time, which would require a re-run of the procedural shader, but that isn't necessarily a bad thing if properly framed--you wouldn't want to do it truly "on the fly" most likely, but you could stage those adjustments (and re-runs of the procedural shader generator) well enough such that the delay wouldn't be noticeable.
#4
01/11/2008 (7:31 am)
Re-exec the script containing the Material? 
Torque Owner AcidFaucet
http://msdn2.microsoft.com/en-us/library/bb219737.aspx
Feeding shader constants by script is not worth it.