Shiny pictures and upcoming resources
by Alex Scarborough · 09/24/2006 (11:57 pm) · 23 comments
It's been nearly a month since my last .plan, so seems like a good time for another one. And what a month it's been. Actually, what a week it's been. Illumina released a public demo, which marks the first time my shader work has been available in any form to the general public. Some people liked it, others didn't. Many had outdated drivers. It's definitely a learning experience for everyone involved. On a more personal note, I can't play the Illumina demo because I don't have a PC. So, I have no clue what it really looks like. It'd be great if someone could send me some screenshots or something.
More recently, Alan James put up a .plan showing off some new screenshots of Code Name: Monster Island. To be perfectly honest, I thought that Alan had switched over to TSE. Between the insane detail on that sewer monster, and how stunning the TLK shadows look it just seemed like TSE. Definitely a reminder that while code can improve the look of a game, nothing beats good art.
But what have I been up to? Believe it or not, I have been primarily focussing on backend work. Things that aren't shiny. Things that don't involve rendering at all. Well, mostly. I've done some rendering work.
First of all, I recently acquired GPU Gems, ShaderX3, and ShaderX4 (IGC refund). They're all incredible books, and anyone with an interest in rendering with shaders should seriously consider purchasing them.
Of course, it's hard to have three shiny new books on shaderized rendering, and not try and implement at least one effect. I decided that sub surface scattering was sufficiently shiny, and required very minimal work to get a basic version of it running. Kork got a nice overhaul from
to
Combine that with spherical harmonic lighting...
And then for kicks, do some image post processing
Not bad for an hour or so of work. That sums up my shiny rendering work in the past month though. So, let's look at the backend work I've done. I swear it isn't (too) dull. If it is, just skip to the end of the .plan which discusses those upcoming resources promised in the title. Then come back here and read about the boring backend work because it is the upcoming resources.
Torque's GUI System
has issues. Let's look at this example of a reasonably nice GUI:
Notice that it is instantly obvious that the last scrollbar is inactive. That should be a very simple thing to do. And indeed, Torque's gui system does have a nice setting for an inactive color to use if the control is inactive.
At least, it would be a nice setting if any of the gui controls actually used it. Oh, sure, guiTextEditCtrl uses it somewhat, but that's really about it. guiSliderCtrl? Nope, not at all. That was actually rather irritating, and was also a five minute fix.
Look ma, it's inactive!
After some more tweaking, I was able to get the default gui rendering commands (that maybe 1/2 the guis use) to use the inactive color so long as they are told that the gui is inactive. It isn't complete, but it's a start.
So, here's a shot of the sample GUI above, slightly modified, in Torque.
guiMLTextCtrl
Oh man, where to start on this bad boy. The code is messy and buggy. Things like selecting text in the middle of a line simply don't work. It subtracts 64 from 64, multiplies by 3, adds 1, and wonders why it doesn't get 12. Again, most of the bugs prove to be a simple five minute fix.
How I feel after having to fix setting the cursor position.
With these little bugs fixed, I tackled a somewhat larger task. Something which has been attempted on a couple of occasions is syntax highlighting in GuiMLTextEditCtrl, most notably in the script editor resource. However, using TorqueML to do syntax highlighting is a bad bad thing.
So I wrote a script controlled system for doing syntax highlighting.
Yes that is GLSL. Yes the colors are a little odd. I lifted them directly from Apple's GLSLEditorSample. In the console, I'm about to tell that GuiMLTextCtrl that half3 should be recognized as a GLSLDatatype keyword. No, half3 is not a GLSL datatype. Welcome to the joys of optimizing GLSL for nVidia cards (see those messy #defines at the top of the file? They are the happy dance GLSL developers must go through to make GLSL not suck on the FX series).
Dynamic Range Lighting
There are now, what, four dynamic range lighting resources for TGE? Three of which I've either written or include my code. All of them have one major caveat: they all force a sync point between CPU and GPU. This sync point kills performance, and can cause some decidedly unpleasant issues. TSE's DRL implementation avoids the sync point by not making the DRL effect dependent on any previous frame, which has some downsides of its own.
But hey, we have shaders now. Textures can hold whatever kind of data we want. Why should they be limited to lookup tables and color information?
So, I moved DRL over entirely to the GPU (if it has access to shaders at least). No more sync point. It determines the new tonemap in a shader, writes the scale and bias into a 1x1 texture, and then at every pixel during DRL rendering it grabs the scale and bias from that texture and applies it. This 1) brought a 20-50% FPS boost, which is just plain awesome, and 2) makes it very easy to adjust the DRL effect as a whole. All the CPU does is bind the various shaders and tell the GPU to downsample some textures. Shaders handle everything else.
How does it track data across multiple frames? A cheap hack. It has two 1x1 textures, and simply alternates between them. When writing data to one 1x1 texture, the other is bound and the current DRL info is read from it, modified, then written into the texture.
As a result of this, something happened that I haven't seen in a long long time. Torque became CPU bound again. Time spent in OpenGL went from 60-70% to 30-40%. Surely though, that number can be improved...
glBegin
is the devil. Here's a shot from the OpenGL Profiler, showing the top 3 most time consuming OpenGL calls in Torque.
Look at #1. Look at just how much more time it takes over #2. Look at how each call is, on average, 150 more expensive than #2.
I've begun a quest to completely purge glBegin from Torque. Does anyone want to help me?
TGE Shader Demo
I've been planning to release a demo of my shader work to the general public for some time now. The original plan was to have it ready for IGC. When IGC was cancelled, the demo was backburnered for a while. It's slowly coming back up on the list of things to do though. In fact, you probably noticed that my example gui was a shader parameter editor, and that my example of syntax highlighting was GLSL.
I've dropped the idea of a simple demo to show off what I can do. That's dull, and nothing more than an ego booster. Instead, I'd prefer to see what everyone else can do. Instead of releasing a demo showing off my work, I'm now planning to release a Torque based GLSL shader editor, allowing people to write and test their own GLSL shaders in a real game environment. Furthermore, it will be crossplatform unlike FXComposer or RenderMonkey, allowing Mac and Linux users to get in on the fun as well. It won't be as full featured as FXComposer or RenderMonkey, as the goal is to provide a sandbox, and not a serious shader IDE.
At the moment, I have around 80 example shaders, in addition to four libraries of shader functions, including image manipulation and lighting effects, which GLSL shaders may be linked against. I have also integrated 3Dlabs' GLSLParserTest into Torque, allowing people to check how conformant the GLSL implementation of their driver is with one simple console function.
You know what? Just supporting GLSL is boring. The TGE Shader Demo also currently supports Cg, ARB_vertex_program/ARB_fragment_program, and ATI_text_fragment shader. Admittedly, a fair amount of work still needs to be done to get those up to the same caliber as the GLSL implementation, but it is capable of loading and using shaders in those languages.
But that's all down the line a bit.
Upcoming resources
The gui work I've done will be packaged up into a resource after TGE 1.4.2 is officially released. It's quite handy. Jeff "Reno" Raab is also currently working on an integrated script editor using the syntax highlighting code I've written, so that should pop up within a month or so as well.
In my quest to purge glBegin from Torque, I've rewritten the particle and decal renders to batch rendering (and in the process broke the TLK enhancements to decals and particle emitters). Resources for those in stock TGE will probably go up after TGE 1.4.2 is officially released, with TLK resources shortly afterwards.
I will probably also release a modified DRL resource which purges glBegin. glBegin isn't exactly a major issue when DRL is running, but every little bit helps.
While I'm at all this batching, I should probably fix the precipitation renderer. Another after 1.4.2 is out resource.
And then there's the TGE Shader Demo. Ideally, I'll have that out before then end of this year (maybe later if I have to buy a commercial license to release it since it isn't a game). I'm trying to make it as easy to use as possible, which will probably necessitate a couple more editors, various features, and a lot of gui work. I also need to triple check the 3Dlabs license, seeing as a pretty large chunk of the shader code used in the TGE Shader Demo came straight from various 3Dlabs samples and utilities.
Well, that sums up my month. Or at least what I did with my free time in the past month.
If anyone wants to try out the gui fixes/enhancements or batched renderers before I put them up as resources, just email me and I'll be more than happy to send you what code I have right now. I really could use some feedback on how useable the syntax highlighting is, and if the batched renderers bring any sort of significant performance boost.
More recently, Alan James put up a .plan showing off some new screenshots of Code Name: Monster Island. To be perfectly honest, I thought that Alan had switched over to TSE. Between the insane detail on that sewer monster, and how stunning the TLK shadows look it just seemed like TSE. Definitely a reminder that while code can improve the look of a game, nothing beats good art.
But what have I been up to? Believe it or not, I have been primarily focussing on backend work. Things that aren't shiny. Things that don't involve rendering at all. Well, mostly. I've done some rendering work.
First of all, I recently acquired GPU Gems, ShaderX3, and ShaderX4 (IGC refund). They're all incredible books, and anyone with an interest in rendering with shaders should seriously consider purchasing them.
Of course, it's hard to have three shiny new books on shaderized rendering, and not try and implement at least one effect. I decided that sub surface scattering was sufficiently shiny, and required very minimal work to get a basic version of it running. Kork got a nice overhaul from
to
Combine that with spherical harmonic lighting...
And then for kicks, do some image post processing
Not bad for an hour or so of work. That sums up my shiny rendering work in the past month though. So, let's look at the backend work I've done. I swear it isn't (too) dull. If it is, just skip to the end of the .plan which discusses those upcoming resources promised in the title. Then come back here and read about the boring backend work because it is the upcoming resources.
Torque's GUI System
has issues. Let's look at this example of a reasonably nice GUI:
Notice that it is instantly obvious that the last scrollbar is inactive. That should be a very simple thing to do. And indeed, Torque's gui system does have a nice setting for an inactive color to use if the control is inactive.
At least, it would be a nice setting if any of the gui controls actually used it. Oh, sure, guiTextEditCtrl uses it somewhat, but that's really about it. guiSliderCtrl? Nope, not at all. That was actually rather irritating, and was also a five minute fix.
Look ma, it's inactive!After some more tweaking, I was able to get the default gui rendering commands (that maybe 1/2 the guis use) to use the inactive color so long as they are told that the gui is inactive. It isn't complete, but it's a start.
So, here's a shot of the sample GUI above, slightly modified, in Torque.
guiMLTextCtrl
Oh man, where to start on this bad boy. The code is messy and buggy. Things like selecting text in the middle of a line simply don't work. It subtracts 64 from 64, multiplies by 3, adds 1, and wonders why it doesn't get 12. Again, most of the bugs prove to be a simple five minute fix.
How I feel after having to fix setting the cursor position.With these little bugs fixed, I tackled a somewhat larger task. Something which has been attempted on a couple of occasions is syntax highlighting in GuiMLTextEditCtrl, most notably in the script editor resource. However, using TorqueML to do syntax highlighting is a bad bad thing.
So I wrote a script controlled system for doing syntax highlighting.
Yes that is GLSL. Yes the colors are a little odd. I lifted them directly from Apple's GLSLEditorSample. In the console, I'm about to tell that GuiMLTextCtrl that half3 should be recognized as a GLSLDatatype keyword. No, half3 is not a GLSL datatype. Welcome to the joys of optimizing GLSL for nVidia cards (see those messy #defines at the top of the file? They are the happy dance GLSL developers must go through to make GLSL not suck on the FX series).
Dynamic Range Lighting
There are now, what, four dynamic range lighting resources for TGE? Three of which I've either written or include my code. All of them have one major caveat: they all force a sync point between CPU and GPU. This sync point kills performance, and can cause some decidedly unpleasant issues. TSE's DRL implementation avoids the sync point by not making the DRL effect dependent on any previous frame, which has some downsides of its own.
But hey, we have shaders now. Textures can hold whatever kind of data we want. Why should they be limited to lookup tables and color information?
So, I moved DRL over entirely to the GPU (if it has access to shaders at least). No more sync point. It determines the new tonemap in a shader, writes the scale and bias into a 1x1 texture, and then at every pixel during DRL rendering it grabs the scale and bias from that texture and applies it. This 1) brought a 20-50% FPS boost, which is just plain awesome, and 2) makes it very easy to adjust the DRL effect as a whole. All the CPU does is bind the various shaders and tell the GPU to downsample some textures. Shaders handle everything else.
How does it track data across multiple frames? A cheap hack. It has two 1x1 textures, and simply alternates between them. When writing data to one 1x1 texture, the other is bound and the current DRL info is read from it, modified, then written into the texture.
As a result of this, something happened that I haven't seen in a long long time. Torque became CPU bound again. Time spent in OpenGL went from 60-70% to 30-40%. Surely though, that number can be improved...
glBegin
is the devil. Here's a shot from the OpenGL Profiler, showing the top 3 most time consuming OpenGL calls in Torque.
Look at #1. Look at just how much more time it takes over #2. Look at how each call is, on average, 150 more expensive than #2.
I've begun a quest to completely purge glBegin from Torque. Does anyone want to help me?
TGE Shader Demo
I've been planning to release a demo of my shader work to the general public for some time now. The original plan was to have it ready for IGC. When IGC was cancelled, the demo was backburnered for a while. It's slowly coming back up on the list of things to do though. In fact, you probably noticed that my example gui was a shader parameter editor, and that my example of syntax highlighting was GLSL.
I've dropped the idea of a simple demo to show off what I can do. That's dull, and nothing more than an ego booster. Instead, I'd prefer to see what everyone else can do. Instead of releasing a demo showing off my work, I'm now planning to release a Torque based GLSL shader editor, allowing people to write and test their own GLSL shaders in a real game environment. Furthermore, it will be crossplatform unlike FXComposer or RenderMonkey, allowing Mac and Linux users to get in on the fun as well. It won't be as full featured as FXComposer or RenderMonkey, as the goal is to provide a sandbox, and not a serious shader IDE.
At the moment, I have around 80 example shaders, in addition to four libraries of shader functions, including image manipulation and lighting effects, which GLSL shaders may be linked against. I have also integrated 3Dlabs' GLSLParserTest into Torque, allowing people to check how conformant the GLSL implementation of their driver is with one simple console function.
You know what? Just supporting GLSL is boring. The TGE Shader Demo also currently supports Cg, ARB_vertex_program/ARB_fragment_program, and ATI_text_fragment shader. Admittedly, a fair amount of work still needs to be done to get those up to the same caliber as the GLSL implementation, but it is capable of loading and using shaders in those languages.
But that's all down the line a bit.
Upcoming resources
The gui work I've done will be packaged up into a resource after TGE 1.4.2 is officially released. It's quite handy. Jeff "Reno" Raab is also currently working on an integrated script editor using the syntax highlighting code I've written, so that should pop up within a month or so as well.
In my quest to purge glBegin from Torque, I've rewritten the particle and decal renders to batch rendering (and in the process broke the TLK enhancements to decals and particle emitters). Resources for those in stock TGE will probably go up after TGE 1.4.2 is officially released, with TLK resources shortly afterwards.
I will probably also release a modified DRL resource which purges glBegin. glBegin isn't exactly a major issue when DRL is running, but every little bit helps.
While I'm at all this batching, I should probably fix the precipitation renderer. Another after 1.4.2 is out resource.
And then there's the TGE Shader Demo. Ideally, I'll have that out before then end of this year (maybe later if I have to buy a commercial license to release it since it isn't a game). I'm trying to make it as easy to use as possible, which will probably necessitate a couple more editors, various features, and a lot of gui work. I also need to triple check the 3Dlabs license, seeing as a pretty large chunk of the shader code used in the TGE Shader Demo came straight from various 3Dlabs samples and utilities.
Well, that sums up my month. Or at least what I did with my free time in the past month.
If anyone wants to try out the gui fixes/enhancements or batched renderers before I put them up as resources, just email me and I'll be more than happy to send you what code I have right now. I really could use some feedback on how useable the syntax highlighting is, and if the batched renderers bring any sort of significant performance boost.
About the author
#22
02/08/2007 (8:27 pm)
did the Torque shader demo get cancelled?
#23
I'm planning an in game editor for the Modernization Kit at some point, probably not in the near future.
02/08/2007 (8:34 pm)
The Torque shader demo evolved into the Modernization KitI'm planning an in game editor for the Modernization Kit at some point, probably not in the near future.
Associate David Higgins
DPHCoders.com