1.4's DynamicTexture and GUIs
by Tom Spilman · in Torque Game Engine Advanced · 05/04/2005 (2:07 am) · 101 replies
I'm currently looking to add rendering and interacting with a GuiControl mapped on to a shape or interior surface. First i'm trying to figure out what the best way to place this functionality into TSE. I looked at DynamicTexture from 1.4, but it's just a class and really doesn't elaborate on how it can/should be used in the overal flow of the engine.
Ideally the workflow would be like so:
1. Artist makes some *thing* and adds a dummy texture with a special name on it for the surface where the gui will be mapped.
2. The material is added which somehow marks one of it's textures as being a "gui texture" and the name of the GuiControl to render to it.
3. Thru a raycast i should be able to find the material hit and if it has a GuiControl associated with it. If so it activates it for interactivity.
Step 1 is easy. At the moment i'm mostly concerned with step 2.
Ideally this functionality would go into the Material class itself and not CustomMaterial or some other class derived from Material. This would allow a so called GuiTexture to be assigned to any stage/texture property and give the artist the most flexibility with effects overlaid on the gui texture.
I was thinking of something along the lines of what CustomMaterial does for it's special textures like $cubemap, $lightmap, $fog, $backbuff, etc. You could specify a $gui for one of the texture stages and have a gui property on the material datablock which is the guicontrol to assign to that GuiTexture.
Still... who updates the textures and GuiControls? I'm just starting to dig into this, but has anyone have any thoughts on how to integrate such a system into TSE?
Ideally the workflow would be like so:
1. Artist makes some *thing* and adds a dummy texture with a special name on it for the surface where the gui will be mapped.
2. The material is added which somehow marks one of it's textures as being a "gui texture" and the name of the GuiControl to render to it.
3. Thru a raycast i should be able to find the material hit and if it has a GuiControl associated with it. If so it activates it for interactivity.
Step 1 is easy. At the moment i'm mostly concerned with step 2.
Ideally this functionality would go into the Material class itself and not CustomMaterial or some other class derived from Material. This would allow a so called GuiTexture to be assigned to any stage/texture property and give the artist the most flexibility with effects overlaid on the gui texture.
I was thinking of something along the lines of what CustomMaterial does for it's special textures like $cubemap, $lightmap, $fog, $backbuff, etc. You could specify a $gui for one of the texture stages and have a gui property on the material datablock which is the guicontrol to assign to that GuiTexture.
Still... who updates the textures and GuiControls? I'm just starting to dig into this, but has anyone have any thoughts on how to integrate such a system into TSE?
About the author
Tom is a programmer and co-owner of Sickhead Games, LLC.
Torque Owner Kirk Longendyke
processedCustomMaterial.cpp arround line 120
void ProcessedCustomMaterial::setStageData() { ... if( !dStrcmp( custMat->texFilename[i], "$miscbuff" ) ) { mFlags[i] = Material::Misc; mMaxTex = i+1; continue; } if( custMat->guiTextureCanvas && custMat->texFilename[i] && !dStrcmp( custMat->texFilename[i], "$gui" ) ) { mStages[i].tex[GFXShaderFeatureData::BaseTex] = custMat->guiTextureCanvas->getTextureHandle(); } ... }and
void ProcessedShaderMaterial::setStageData() { ... // Load up all the textures for every possible stage for( i=0; i<Material::MAX_STAGES; i++ ) { if( mMaterial->guiTextureCanvas && mMaterial->baseTexFilename[i] && !dStrcmp( mMaterial->baseTexFilename[i], "$gui" ) ) { mStages[i].tex[GFXShaderFeatureData::BaseTex] = mMaterial->guiTextureCanvas->getTextureHandle(); } else if( mMaterial->baseTexFilename[i] && mMaterial->baseTexFilename[i][0] ) { mStages[i].tex[BaseTex] = createTexture( mMaterial->baseTexFilename[i], &GFXDefaultStaticDiffuseProfile ); } ... }though that's not quite correct, as I'm seeing error of
when executed. Of more fundamental concern however is it would appear theres some far more fundamental changes to the base code this was built off of, since it's now spawning additional *windows* ...
thoughts?