TSE - some more info
by Brian Ramage · in Torque Game Engine · 03/21/2004 (4:36 am) · 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.
About the author
#42
Cg's main point is its cross-compiler. You can have the Cg compiler generate output in many formats, including some assemblies. So it's 99% like we'll be able to code in Cg, generate some output and copy'n'paste it somewhere into the TSE.
03/23/2004 (3:38 am)
@People worrying about Cg:Cg's main point is its cross-compiler. You can have the Cg compiler generate output in many formats, including some assemblies. So it's 99% like we'll be able to code in Cg, generate some output and copy'n'paste it somewhere into the TSE.
#43
Everything that uses shaders 'supports' Cg.
03/23/2004 (3:54 am)
It's this easy, right now: You have a Cg file in your project, and you have it build with a custom build step to use the Cg compiler and output as shader assembly. This is preciesly why I avoid using 'Cg'. We HAVE Cg support, half of Cg is a shader cross-compiler. The other half is a runtime, we do NOT use the runtime right now.Everything that uses shaders 'supports' Cg.
#44
Sounds like Cg is a marvel in itself if it does that :)
03/23/2004 (3:56 am)
Cool, i'll pretend to understand that :)Sounds like Cg is a marvel in itself if it does that :)
#45
03/23/2004 (7:32 am)
Will there be any new shadows with the shader engine? I was looking at Synapse Gaming Lighting Code Pack and they have new shadow technics for dts objects.
#46
Things may have changed over the last few months. There have been new releases for Cg, so I may look at that again and see what's going on. If it's not working well, then the OpenGL layer will use GLSL instead. I suspect GLSL might be the best implementation, but Cg would be easier if it works. I'm not sure if Cg runs on Mac or Linux, that may be an issue as well.
03/24/2004 (1:59 am)
We developed the Marble Blast FX demo using Cg and it worked pretty well until I tried to use it on an ATI card. Cg is (was?) optimized for nVIDIA hardware which supports some swizzling that ATI hardware does not, and so some shaders would not run on Radeons. HLSL is better at detecting and running on ATI and other vendors than Cg is. Things may have changed over the last few months. There have been new releases for Cg, so I may look at that again and see what's going on. If it's not working well, then the OpenGL layer will use GLSL instead. I suspect GLSL might be the best implementation, but Cg would be easier if it works. I'm not sure if Cg runs on Mac or Linux, that may be an issue as well.
#47
03/24/2004 (2:55 am)
Cg has (at least) a Linux implementation of both the runtime and the compiler. Not sure about Mac. I'd have to research it, and I am not going to unless I have a REASON TO...*nudge nudge*
#48
03/24/2004 (3:45 am)
I just started looking into shaders last night, and it appears Cg does support windows/linux/os x - you can download the toolkits at http://developer.nvidia.com/object/cg_toolkit.html. It's the only shader language I've looked into so far, but it looks nice. 
#49
Since people seem interested in learning about them, I decided to do an informal comparison of the languages. I was going to post it here, but it got to be too long. If anybody is interested, check out the separate thread and post any q's or comments you have. :)
03/24/2004 (10:44 am)
It seems that the shading languages themselves are getting quite a bit of attention in this thread. Since people seem interested in learning about them, I decided to do an informal comparison of the languages. I was going to post it here, but it got to be too long. If anybody is interested, check out the separate thread and post any q's or comments you have. :)
#50
03/24/2004 (10:45 am)
Hehe, just finished reading it. Very informative :D
#51
Looks great guys!
I have a quick question about TSE:
-I noticed that the specs listed in the dev shot mentioned dynamic lighting, but not shadows. Does TSE still use light maps or does it support true per-light shader/lighting calculations with shadows out of the box? Can anyone elaborate on the lighting?
Clearly I would like to port my existing technology to TSE and I'm trying to get a feel for the new system.
Thanks.
John.
03/24/2004 (11:38 am)
@GG,Looks great guys!
I have a quick question about TSE:
-I noticed that the specs listed in the dev shot mentioned dynamic lighting, but not shadows. Does TSE still use light maps or does it support true per-light shader/lighting calculations with shadows out of the box? Can anyone elaborate on the lighting?
Clearly I would like to port my existing technology to TSE and I'm trying to get a feel for the new system.
Thanks.
John.
#52
03/24/2004 (5:43 pm)
We don't yet have dynamic shadows in (either projected or stencil), so that's going to be another one of those milestones like implementing OpenGL. It DOES have lightmap shadows however, so the terrain and interiors will be lit similar to before. Lightmap shadows mask out specular as well, so they are realistically integrated with the shaders, not just slapped over them.
#53
*hurries up and finishes docos*
03/24/2004 (6:26 pm)
Ahh.. god I'm drooling over maybe getting to help with some TSE work.*hurries up and finishes docos*
#54
Thanks for the info Brian.
John.
03/26/2004 (1:52 am)
Excellent, that should make integration fairly straight forward.Thanks for the info Brian.
John.
#56
I received your email and tried getting back to you, but the emails I sent failed with:
John.
03/27/2004 (1:58 pm)
Josh,I received your email and tried getting back to you, but the emails I sent failed with:
Final-Recipient: rfc822; joshw@garagegames.com Action: failed Status: 4.4.7 Unable to contact host for 1 days, Diagnostic-Code: smtp; Persistent Transient Failure: Delivery time expired Last-Attempt-Date: 26 Mar 2004 4:03:38 +0000Are you guys having email issues? I wouldn't be surprised if comcast was acting loopy, but I figured I'd ask.
John.
#57
If anyone else sent emails, my apologies as well.
03/27/2004 (8:36 pm)
Yeah, sorry John. I haven't been able to log into my email for days :( No idea what's going on, it just says the connection was refused. I'll have to check it out when everyone's back in the office on Monday. If anyone else sent emails, my apologies as well.
#58
03/27/2004 (8:43 pm)
Thats cool, just send me an email when it's working and we can pick our conversation back up.
#59
1. I recall from last year's GDC the 3DState engine advertising a feature called something like design-by-analogy, where rather than creating shaders from primitives and combiners, the designer would specify something like 'like-ice' or 'like-chrome' or 'like-smoked-glass'. Is something like this possible with TSE design?
2. Extensibility. It would be nice if it was possible to start building a ready-made shader effects library that included community contributions, so that for the most part TSE licensees could pick stock effects from the library rather than developing them in parallel independently. This might offset some of the increased content overhead associated with shaders.
3. Bonus suggestion: shader packs.
03/28/2004 (10:34 pm)
Two suggestions:1. I recall from last year's GDC the 3DState engine advertising a feature called something like design-by-analogy, where rather than creating shaders from primitives and combiners, the designer would specify something like 'like-ice' or 'like-chrome' or 'like-smoked-glass'. Is something like this possible with TSE design?
2. Extensibility. It would be nice if it was possible to start building a ready-made shader effects library that included community contributions, so that for the most part TSE licensees could pick stock effects from the library rather than developing them in parallel independently. This might offset some of the increased content overhead associated with shaders.
3. Bonus suggestion: shader packs.
Torque Owner John Vanderbeck