Shader question
by David Aiken · in Technical Issues · 12/10/2008 (3:16 pm) · 13 replies
Hi all..
I've got a car which has the following maps:
- diffuse
- specular
- normal
- displacement
- ambient occlusion
The surface is painted matte green and it only has to worry about dim sun on a rainy, overcast day.
Is there a suitable Torque Material for something like this or am i better off with a custom shader, perhaps based on something from the NVidia library? I'm looking into the Ubiq SSAO shader for the ambient occlusion, but alternative approaches would be helpful.
thanks for any help you can provide..
I've got a car which has the following maps:
- diffuse
- specular
- normal
- displacement
- ambient occlusion
The surface is painted matte green and it only has to worry about dim sun on a rainy, overcast day.
Is there a suitable Torque Material for something like this or am i better off with a custom shader, perhaps based on something from the NVidia library? I'm looking into the Ubiq SSAO shader for the ambient occlusion, but alternative approaches would be helpful.
thanks for any help you can provide..
About the author
#2
A TGEA example showing best practices for the asset pipeline.. preferably something from FX Composer 2 to TGEA (i.e. http://www.digitaltutors.com/digital_tutors/featured_story.php?story=16 ).. would be helpful. Is there a good reference for this?
12/14/2008 (2:32 am)
BTW.. specifically addressing this case.. my naive guess would be something like relaxed cone step mapping for high LOD (there are mud, scratches, and dents), dropping to normal mapping (parallax??) then straight texture lookup at distance. A TGEA example showing best practices for the asset pipeline.. preferably something from FX Composer 2 to TGEA (i.e. http://www.digitaltutors.com/digital_tutors/featured_story.php?story=16 ).. would be helpful. Is there a good reference for this?
#3
From http://www.codesampler.com/papers/Automated%20Shader%20Generation%20using%20a%20Shader%20Infrastructure.pdf :
"The na
12/14/2008 (1:46 pm)
After a little bit more poking about, it seems i've hit the Rain-Slick Precipice of Darkness :>). HotHead games is using their own shader infrastructure (http://forums.penny-arcade.com/showthread.php?t=56902) and there are a number of recent papers addressing "combinatorial shader explosion".From http://www.codesampler.com/papers/Automated%20Shader%20Generation%20using%20a%20Shader%20Infrastructure.pdf :
"The na
#4
After a little bit more poking about, it seems i've hit the Rain-Slick Precipice of Darkness :>). HotHead games is using their own shader infrastructure (http://forums.penny-arcade.com/showthread.php?t=56902) and there are a number of recent papers addressing "combinatorial shader explosion".
From http://www.codesampler.com/papers/Automated%20Shader%20Generation%20using%20a%20Shader%20Infrastructure.pdf :
The na
12/14/2008 (1:47 pm)
Hmm.. the system chopped the last post so i'll try again.After a little bit more poking about, it seems i've hit the Rain-Slick Precipice of Darkness :>). HotHead games is using their own shader infrastructure (http://forums.penny-arcade.com/showthread.php?t=56902) and there are a number of recent papers addressing "combinatorial shader explosion".
From http://www.codesampler.com/papers/Automated%20Shader%20Generation%20using%20a%20Shader%20Infrastructure.pdf :
The na
#6
After a little bit more poking about, it seems i've hit the Rain-Slick Precipice of Darkness :>). HotHead games is using their own shader infrastructure (http://forums.penny-arcade.com/showthread.php?t=56902) and there are a number of recent papers addressing "combinatorial shader explosion".
From http://www.codesampler.com/papers/Automated%20Shader%20Generation%20using%20a%20Shader%20Infrastructure.pdf :
The naive and most common approach to the problem of render-state inconsistency is hand-coding a collection of shaders that support only the minimum sub-set of features a particular rendering application requires. In other words, if we restrict what state settings can be applied by the run-time and force our modelers to obey a series of rules concerning lighting and texturing usage, we can manage a limited solution through hand-coding. In fact, this approach is widely popular in console and PC games.
Sounds like enough to get me started. A simple example from GG extending one of the simple DTS examples (http://tork.beffy.de/tutorials/simpleobjects/simpleshape.html ??) to include pixel and vertex shaders created in FX Composer 2, say, documenting some of the reasons behind the lighting/texturing (i think the number of lights has to be constrained unless deferred rendering or some other form of dynamic light support (?) is available), would IMHO help to increase the accessibility of TGEA to those looking for a fast way to get their game up/running in a sustainable way. Guidelines for extending this simple example would also be Really Good.
Maybe someone (Matt Vitelli or someone at GG with time?? Gerhard Botha?? ) can do something like Apparatus' guide to environment creation!! I can't help feeling i've missed some existing documentation that ships with TGEA to help TGE users to become productive. If you're into FPS game development it's hard to ignore shaders.
BTW this site seems particularly helpful for shaders and game development:
http://www.coretechniques.info/index_2007.html
12/14/2008 (1:57 pm)
It looks like the "i" in "naive" copied/pasted from the doc is non-ascii :>(. Resistance to ASCII is futile!After a little bit more poking about, it seems i've hit the Rain-Slick Precipice of Darkness :>). HotHead games is using their own shader infrastructure (http://forums.penny-arcade.com/showthread.php?t=56902) and there are a number of recent papers addressing "combinatorial shader explosion".
From http://www.codesampler.com/papers/Automated%20Shader%20Generation%20using%20a%20Shader%20Infrastructure.pdf :
The naive and most common approach to the problem of render-state inconsistency is hand-coding a collection of shaders that support only the minimum sub-set of features a particular rendering application requires. In other words, if we restrict what state settings can be applied by the run-time and force our modelers to obey a series of rules concerning lighting and texturing usage, we can manage a limited solution through hand-coding. In fact, this approach is widely popular in console and PC games.
Sounds like enough to get me started. A simple example from GG extending one of the simple DTS examples (http://tork.beffy.de/tutorials/simpleobjects/simpleshape.html ??) to include pixel and vertex shaders created in FX Composer 2, say, documenting some of the reasons behind the lighting/texturing (i think the number of lights has to be constrained unless deferred rendering or some other form of dynamic light support (?) is available), would IMHO help to increase the accessibility of TGEA to those looking for a fast way to get their game up/running in a sustainable way. Guidelines for extending this simple example would also be Really Good.
Maybe someone (Matt Vitelli or someone at GG with time?? Gerhard Botha?? ) can do something like Apparatus' guide to environment creation!! I can't help feeling i've missed some existing documentation that ships with TGEA to help TGE users to become productive. If you're into FPS game development it's hard to ignore shaders.
BTW this site seems particularly helpful for shaders and game development:
http://www.coretechniques.info/index_2007.html
#8
Torque automatically generates shaders that handle a selection of common tasks, such as applying basic specular, normal maps, diffuse textures, and other general modeling needs. It's not designed to handle advanced effects necessarily (although you can definitely do a lot with it), so CustomMaterials allow you pretty complete control over shader generation and application via external shader generation tools (or hand-created shaders).
To get a better feel for the Materials system, you should probably go take a look at the build in documentation, followed by taking a look at the TDN Materials Overvew.
12/14/2008 (4:22 pm)
I -think- part of the confusion might be not quite understanding the difference between the Procedural Generation system ("materials"), and using custom created shaders ("CustomMaterial").Torque automatically generates shaders that handle a selection of common tasks, such as applying basic specular, normal maps, diffuse textures, and other general modeling needs. It's not designed to handle advanced effects necessarily (although you can definitely do a lot with it), so CustomMaterials allow you pretty complete control over shader generation and application via external shader generation tools (or hand-created shaders).
To get a better feel for the Materials system, you should probably go take a look at the build in documentation, followed by taking a look at the TDN Materials Overvew.
#9
In the current state of the lighting system, only two lights are set up per mesh. In all honesty, the lighting system suffers from some serious flaws, the most prevalent being the lack of true shadow mapping. Until something more mainstream (deferred rendering, perhaps) is integrated, it's pretty hard to use lights well besides the global sun light. In terms of basic lighting, many algorithms can be adapted from RenderMonkey/FX Composer examples. The major issue is in how constants are handled. It's not as simple as adding a new variable and adjusting a slider. Ultimately we need a more unified architecture. It looks as if Torque is heading down that path, but only time will tell.
12/14/2008 (5:06 pm)
Hi David,In the current state of the lighting system, only two lights are set up per mesh. In all honesty, the lighting system suffers from some serious flaws, the most prevalent being the lack of true shadow mapping. Until something more mainstream (deferred rendering, perhaps) is integrated, it's pretty hard to use lights well besides the global sun light. In terms of basic lighting, many algorithms can be adapted from RenderMonkey/FX Composer examples. The major issue is in how constants are handled. It's not as simple as adding a new variable and adjusting a slider. Ultimately we need a more unified architecture. It looks as if Torque is heading down that path, but only time will tell.
#10
The content pipeline is another area of confusion for me. The DTS pipeline does not seem to be extensible to Materials. A material in the real world (of interest if you're writing the latest FPS) has weight, hardness, flammability (possibly a sore point if you've been playing Far Cry 2), and visible properties which can only be shown via shaders. As i understand it, Showtool is based on an older version of TGE and upgrading it to handle shaders (assuming the DTS format or some other mechanism supported them) would be onerous. Fine - the less tools the better (apologies to David Wyand.. i'm almost certainly expressing an uninformed opinion). Perhaps it's possible to do a reasonable level of WYSIWYG in the authoring tool or, ideally, pipe the content live into the game's lighting/physics environment.. probably a FAQ :>(. I notice that there are open-source tools (http://sourceforge.net/projects/colladamaya/ and the like) that might form the foundation of something like this. IMHO this kind of thing is squarely in the engine domain.. rebuilding these widgets for each game is wasteful.
Collada seems to be a way to pass material definitions across tools. I'm not a huge fan of XML as it often seems to move the problem around while increasing bloat, but it is inherently flexible and would seem to allow for TGEA-specific and game-specific extensions. Matt Fairfax expressed fondness for Collada at one point ().. i know he's been quite busy, but perhaps there has been progress on this front.
I know i'm not alone in this. HotHead has their own scalable, cross-platform shader management with collada. Perhaps GG could persuade them to contribute a resource or a presentation of some sort which would help the Unwashed!! Maybe HotHead or GG could incorporate some version of it into TGEA. Are they using ubershaders? HLSL fragments? Dynamic generation at compile time? Dynamic generation at runtime? I think Wolfgang Engel dislikes the latter (http://diaryofagraphicsprogrammer.blogspot.com/2008/12/hlsl-50-oop-dynamic-shader-linking.html ).. is this equivalent to TGEA procedural Materials? They struck me as very convenient for prototyping, but a bit black box for a shipping game.
I'm enlightened to hear that deferred rendering is more mainstream than TGEA.. isn't the decision game-specific still? I can understand why games with a lot of dynamic lights would use it (a la Dead Space), but if the scene is sun-lit is it justified? In any case, my ignorance is showing here. GofW uses an amazing number of lights (http://74.125.47.132/search?q=cache:bgqc_4F4kOIJ:www.unrealtechnology.com/Downloads/Slides/xfest-gfx.ppt+unreal+engine+3+static+lights&hl=en&ct=clnk&cd=2&gl=ca ).. guess i was too busy ducking to notice them :>(.
Obviously there are limits to what you can do with an Indie engine. Expanding the pipeline to incorporate flexible material definitions would be Nice, though. Matt Fairfax expressed a fondness for Collada at one point (http://www.garagegames.com/mg/forums/result.thread.php?qt=75436 ).. has the fondness persisted?
In any case, one of the reasons i chose Torque was the responsiveness and knowledge of its community so i feel sure progress is being made on these fronts.. i just want to learn how to best approach shaders.
12/14/2008 (6:02 pm)
The difference between Materials and Custom shaders is, indeed, interesting. If you can point me to a tutorial or link which provides some guidance as to how to solve my problem then that would be Great! What algorithms are actually used by the Materials? What is the LOD system to ensure a tank on the horizon isn't rendered with a full-blown shader? How should custom shaders be written to avoid combinatorial explosion?The content pipeline is another area of confusion for me. The DTS pipeline does not seem to be extensible to Materials. A material in the real world (of interest if you're writing the latest FPS) has weight, hardness, flammability (possibly a sore point if you've been playing Far Cry 2), and visible properties which can only be shown via shaders. As i understand it, Showtool is based on an older version of TGE and upgrading it to handle shaders (assuming the DTS format or some other mechanism supported them) would be onerous. Fine - the less tools the better (apologies to David Wyand.. i'm almost certainly expressing an uninformed opinion). Perhaps it's possible to do a reasonable level of WYSIWYG in the authoring tool or, ideally, pipe the content live into the game's lighting/physics environment.. probably a FAQ :>(. I notice that there are open-source tools (http://sourceforge.net/projects/colladamaya/ and the like) that might form the foundation of something like this. IMHO this kind of thing is squarely in the engine domain.. rebuilding these widgets for each game is wasteful.
Collada seems to be a way to pass material definitions across tools. I'm not a huge fan of XML as it often seems to move the problem around while increasing bloat, but it is inherently flexible and would seem to allow for TGEA-specific and game-specific extensions. Matt Fairfax expressed fondness for Collada at one point ().. i know he's been quite busy, but perhaps there has been progress on this front.
I know i'm not alone in this. HotHead has their own scalable, cross-platform shader management with collada. Perhaps GG could persuade them to contribute a resource or a presentation of some sort which would help the Unwashed!! Maybe HotHead or GG could incorporate some version of it into TGEA. Are they using ubershaders? HLSL fragments? Dynamic generation at compile time? Dynamic generation at runtime? I think Wolfgang Engel dislikes the latter (http://diaryofagraphicsprogrammer.blogspot.com/2008/12/hlsl-50-oop-dynamic-shader-linking.html ).. is this equivalent to TGEA procedural Materials? They struck me as very convenient for prototyping, but a bit black box for a shipping game.
I'm enlightened to hear that deferred rendering is more mainstream than TGEA.. isn't the decision game-specific still? I can understand why games with a lot of dynamic lights would use it (a la Dead Space), but if the scene is sun-lit is it justified? In any case, my ignorance is showing here. GofW uses an amazing number of lights (http://74.125.47.132/search?q=cache:bgqc_4F4kOIJ:www.unrealtechnology.com/Downloads/Slides/xfest-gfx.ppt+unreal+engine+3+static+lights&hl=en&ct=clnk&cd=2&gl=ca ).. guess i was too busy ducking to notice them :>(.
Obviously there are limits to what you can do with an Indie engine. Expanding the pipeline to incorporate flexible material definitions would be Nice, though. Matt Fairfax expressed a fondness for Collada at one point (http://www.garagegames.com/mg/forums/result.thread.php?qt=75436 ).. has the fondness persisted?
In any case, one of the reasons i chose Torque was the responsiveness and knowledge of its community so i feel sure progress is being made on these fronts.. i just want to learn how to best approach shaders.
#11
Users of engines like TORQUE and OGRE were a key voice in the changes relating to global variables, macros, and object-space lighting -- these options were specifically added to make life simpler for you.
and from NVIDIA Developer Newsletter #42 - Siggraph 2008 (http://developer.nvidia.com/object/devnews042.html):
Extra macros for support of DCC apps such as 3DSMax, XSI, and game 3D engines like Torque and OGRE have been provided to HLSL effects.
But i haven't been able to find specifics yet. Can anyone help?
12/14/2008 (6:19 pm)
I'm also a bit curious about the NVidia tools after seeing the following at http://developer.nvidia.com/forums/index.php?showtopic=1900:Users of engines like TORQUE and OGRE were a key voice in the changes relating to global variables, macros, and object-space lighting -- these options were specifically added to make life simpler for you.
and from NVIDIA Developer Newsletter #42 - Siggraph 2008 (http://developer.nvidia.com/object/devnews042.html):
Extra macros for support of DCC apps such as 3DSMax, XSI, and game 3D engines like Torque and OGRE have been provided to HLSL effects.
But i haven't been able to find specifics yet. Can anyone help?
#12
12/14/2008 (6:34 pm)
BTW the ShaderX4/5/6 "3D Engine Design" sections look helpful.. they include some of the same authors featured at http://www.coretechniques.info/index_2007.html . I just mention it for those coming across this thread later..
#13
Does anyone know of a good, game-ready, real-time ubershader that could handle this material, or perhaps a good reference for writing such a beast to work within a TGEA environment/lighting context? I'm thinking something along the lines of XNA's BasicEffect shader or maybe Doylle's shader from the Game Artist forums. I realize that TGEA may lack the level of combinations that would normally justify writing an ubershader.. but i'm interested in learning.
12/16/2008 (7:10 pm)
Ok.. at the risk of being irritating i'm back to the original question. Does anyone know of a good, game-ready, real-time ubershader that could handle this material, or perhaps a good reference for writing such a beast to work within a TGEA environment/lighting context? I'm thinking something along the lines of XNA's BasicEffect shader or maybe Doylle's shader from the Game Artist forums. I realize that TGEA may lack the level of combinations that would normally justify writing an ubershader.. but i'm interested in learning.
Torque Owner David Aiken
I'm looking for documentation/guidance on the standard Materials and custom shaders available in the TGEA environment. Something which says:
- which Materials/custom shaders ship with TGEA, and a description of their intended use (perhaps along the lines of the NVidia library).
- information on how TGEA handles LOD would be helpful (objects at detail level 2 probably don't need an expensive shader)
- an example showing how to handle failover (like displacement mapping on DX 10 to, say, parallax occlusion on DX 9)
- import of an FX Composer 2.. and maybe Shader FX (showing my 3DS prejudice :>) shader