TSE - some more info
by Brian Ramage · in Torque Game Engine · 03/20/2004 (8:36 pm) · 72 replies
Hey guys, I've seen some questions asked about TSE in a few threads, I thought I'd answer a few here and clear some things up.
The TSE is a full engine, pretty much up to date with TGE 1.2. Merging a project from 1.2 could be a bit of a pain as we have changed every line of code that was previously pure OpenGL - so a lot of files have been at least slightly modified. In addition, there are a lot of features that have not yet been converted over to the new GFX layer including some editor functionality.
The TSE WILL fall back from pixel shader 2.0 to 1.0 all the way back to fixed function, so it will work on all types of hardware. There're two ways to specify shaders - through the base Material interface, and through the CustomMaterial interface.
The base Materials take datablock input for the textures, cubemaps, bumpmaps, specular settings, glow, etc and procedurally turn them into shaders. It even has multiple stages so you can create multipass materials. You don't need to write a line of code for those shaders - Joe and Weston used the base Materials to do all the shaders on the orc in the demo.
The second way is to use the CustomMaterial interface. With that, you can write your own HLSL or assembly shaders and specify the whole chain of fallbacks for each type of shader hardware. That means you can pretty much take some examples from RenderMonkey or FX Composer and drop them into the TSE and watch them run.
The graphics layer is a layer that we implemented that has its own API - a sort of cross between OpenGL and D3D. OpenGL and D3D implementations are derived from the GFX layer and take the same commands from it. This allows complete separation from a specific graphics API. We focused on D3D support from the beginning because it has more mature shader technology. We will be working on the OpenGL side of it soon, but currently it is not supported. Since we have so many Mac and Linux users, obviously we aren't going to ignore this, it is a priority.
The TSE is a full engine, pretty much up to date with TGE 1.2. Merging a project from 1.2 could be a bit of a pain as we have changed every line of code that was previously pure OpenGL - so a lot of files have been at least slightly modified. In addition, there are a lot of features that have not yet been converted over to the new GFX layer including some editor functionality.
The TSE WILL fall back from pixel shader 2.0 to 1.0 all the way back to fixed function, so it will work on all types of hardware. There're two ways to specify shaders - through the base Material interface, and through the CustomMaterial interface.
The base Materials take datablock input for the textures, cubemaps, bumpmaps, specular settings, glow, etc and procedurally turn them into shaders. It even has multiple stages so you can create multipass materials. You don't need to write a line of code for those shaders - Joe and Weston used the base Materials to do all the shaders on the orc in the demo.
The second way is to use the CustomMaterial interface. With that, you can write your own HLSL or assembly shaders and specify the whole chain of fallbacks for each type of shader hardware. That means you can pretty much take some examples from RenderMonkey or FX Composer and drop them into the TSE and watch them run.
The graphics layer is a layer that we implemented that has its own API - a sort of cross between OpenGL and D3D. OpenGL and D3D implementations are derived from the GFX layer and take the same commands from it. This allows complete separation from a specific graphics API. We focused on D3D support from the beginning because it has more mature shader technology. We will be working on the OpenGL side of it soon, but currently it is not supported. Since we have so many Mac and Linux users, obviously we aren't going to ignore this, it is a priority.
#62
2. You can distribute most shader materials without touching engine source. More advanced affects like atmospherics require modest source changes.
3. I assume the website will be updated to give the shader stuff a good home.
03/29/2004 (8:53 am)
1. We have a powerful interface for flexibly defining procedurally generated shaders. It's a bit lower level than "like ice" but it's still very easy to work with.2. You can distribute most shader materials without touching engine source. More advanced affects like atmospherics require modest source changes.
3. I assume the website will be updated to give the shader stuff a good home.
#63
03/29/2004 (11:07 am)
If you are planning to have support for Direct X and OpenGL do you have ato make a OpenGL and a DirectX version of every sahder you put in the game? 
#64
My understanding is that as long as you use the TSE materials library, you won't have to worry about API-specifc stuff.
03/29/2004 (1:45 pm)
James,Quote:
The graphics layer is a layer that we implemented that has its own API - a sort of cross between OpenGL and D3D. OpenGL and D3D implementations are derived from the GFX layer and take the same commands from it. This allows complete separation from a specific graphics API.
My understanding is that as long as you use the TSE materials library, you won't have to worry about API-specifc stuff.
#65
03/29/2004 (6:24 pm)
Both Josh and James are right ;) The GFX layer allows the use of either API with the same code BUT, not for any custom shaders. Procedural shaders will be created for whatever the current API being used is, but if you are hand writing anything, it will have to be platform specific. The only real way around this is to write our OWN shader language which might be a possibility down the road. 
#66
03/29/2004 (6:51 pm)
We could kind of generalize a shading language for the materials system. Like say, "Use the Phong-Blinn ilumination model, and these are the parameters," but I don't know if that is any more useful than what we have now. Unless we want to write a shader compiler. I really don't think that it would be time well spent at all considering the levels of optimization the Cg compiler does and such. Ours would be a waste of effort. Anyone who is seriously writing shaders really does not need a tool, from us, to do this. Would it be nice? Hell yeah, but lets be realistic.
#67
03/30/2004 (2:17 pm)
I said our own language, not our own compiler ;) Since GLSL and HLSL are very similar, it might be a good idea to set up our own language that would convert down to either one. Just an idea.
#68
03/30/2004 (4:41 pm)
That would be the way to go becasue hta twould support all platforms and drivers at once.
#69
04/01/2004 (10:50 am)
Yes, but it would be hard to port in shader examples from other languages. Though I suppose that wouldn't matter since you'd end up having to port them for cross-platform compatibility anyways.
#70
Thanks for any help
04/01/2004 (11:09 am)
Not sure if this is applicable but the default bumpmapping shaders that are included, can we get some details on those? Specifically all I'm wondering is if they use standard normal mapping. I'm in the processs of building prefabs and standard things and what not and am wondering if I should be making normal maps along with some of my textures.Thanks for any help
#71
04/01/2004 (11:10 am)
Doh, nevermind, I missed the answer to this already posted above. Been a week since I've read this thread. Thanks anyhow, I caught wind of Nvidia's plugin which is what I've been using and what I was looking for. Sweet. ;) 
Torque Owner Brad Shapcott
2. To clarify, I'd meant dynamic extensibility so that shader packs (containing stock materials, ready-to-assemble shader effects, and new shader programs) can be added as drop-ins without modification of engine source (which of course is also possible, but isn't what I'd meant).
3. In addition to commercial shader packs, it would also be nice to see a new top level category opened in the Resources section just for community-provided shader-related content, rather than burying this stuff in an existing category.