Previous Blog Next Blog
Prev/Next Blog
by date

cg shader/filter effects

cg shader/filter effects
Name:Paul Jan 
Date Posted:Jun 19, 2006
Rating:Not Rated
Public:YES
Comments:YES
RSS Feed:GarageGames Blog feedor Subscribe with .
Profile Page:View profile page for Paul Jan

Blog post
Well, I've installed a cg glow/blur filter into TLK, similar to Pisal Setthawong's work (http://www.garagegames.com/blogs/20289/10710) and I started to play around with it, with some interesting effects.

Before,

After.



To do:
What I need to do is expose the filters to torquescript, and modify DRL to adjust the filter.

Recent Blog Posts
List:07/03/06 - More CG DRL/Water
06/19/06 - cg shader/filter effects

Submit ResourceSubmit your own resources!

Aun Arinyasak   (Jun 19, 2006 at 01:40 GMT)
hmm ..... I did the same thing add the same CG effect from Pisal Setthawong's Blog post

the Darken glow works fine but couldn't get the blur effect working properly..


Any tips on that would be thankful..

Looking good and thanks :)

Aun

Alex Scarborough   (Jun 19, 2006 at 02:04 GMT)
Random question, but why not use GLSL instead of Cg? I've been wondering for a while now why there seems to be a fair amount of Cg work with TGE (publicized at least) but there has been virtually no discussion of GLSL in TGE.

Interesting screenshots by the way. Too much grey from the bloom for my tastes though.

Paul Jan   (Jun 19, 2006 at 02:06 GMT)
Yes, I had problems with the VERC blur as well. I ended up adding code from developer.nvidia.com/object/convolution_filters.html.

The cg function you want to use is convolve_tex_1D in convolve.cg - do 2 passes, one vertical and one horizontal, with a filter you can pass to it or just hardcode into it.

After playing around with above effect for a bit, I'm kinda depressed. I have no logical explaination for why it works that way. When I comment out all the stuff I know isn't doing anything, the blur effect is nice and subtle.
Edited on Jun 19, 2006 02:07 GMT

Paul Jan   (Jun 19, 2006 at 02:25 GMT)
Well, my CG choice was simply that I'd gone and added the CG water resource and I'd thought that I could reuse some code.

What I really want to do is expose most of the controls so that if someone doesn't like the bloom, they can adjust it. The above samples are an out-of-control example, 10 or so passes from the blur filter, and a texture pipe I thought I wasn't using... The real blur/bloom should be pretty subtle.

Manoel Neto   (Jun 19, 2006 at 14:53 GMT)
CG looks a bit easier to "drop in" into TGE, without having to modify the platform stuff, so it's the favourite tool for quick shader hack jobs. You could have a custom GUI control which uses CG and the rest of the engine code wouldn't care about that.

Also, if you are up to it, it's possible to make the shaders work in D3D mode as well, by writing a few wrappers to initialize/load/unload shaders and to set vertex/pixel shader constants, since Cg offers a D3D API as well.

Compatibility-wise, it would end up the same as GLSL, since you'd still need a SM2.0 card with the lastest drivers.
Edited on Jun 19, 2006 14:54 GMT

Alexander "taualex" Gaevoy   (Jun 19, 2006 at 17:48 GMT)
GLSL - is OpenGL only by nature
Cg works in OpenGL and D3D
Thus, GLSL will not work on XBox if you want to port it there.

I would go for Cg for safety :)

Alexander "taualex" Gaevoy   (Jun 19, 2006 at 17:50 GMT)
@Paul Jan

how did you do the bloom? Would you like to share an example reusing Cg code (init, profiles, etc) for the water in TGE, please?

Allyn "Mr_Bloodworth" Mcelrath   (Jun 19, 2006 at 18:09 GMT)
Bloom is not allways the best thing in the world.

Alexander "taualex" Gaevoy   (Jun 19, 2006 at 21:02 GMT)
@Allym

thank you for your input, it's very helpful.

Paul Jan   (Jun 19, 2006 at 23:11 GMT)
Well actually as it turned out, I didn't reuse cg code for the bloom - water reflection is primarily a vertex shading effect, where bloom is a pixel (fragment) shading effect. Still, once you've jumped through the hoops to install cg in torque, adding other cg is easier.

I'm trying to get DRL lighting effects in, but I really don't want to pay the framerate costs of the current resource, so it could take a while. :)

Game Programing Gems 4 has a DRL article (5.10) - where they use a luminance historgram, but their implementation is in C. :(

Alex Scarborough   (Jun 19, 2006 at 23:35 GMT)
@Paul Jan: As stated before, it is not difficult to rewrite DRL to use shaders, and it runs much faster when you do. It's a single MADD. Doubled my FPS instantly. Rewriting bloom to use a shader increased FPS even more.

Paul Jan   (Jun 20, 2006 at 00:08 GMT)
MADD?

Alex Scarborough   (Jun 20, 2006 at 00:12 GMT)
Mutiply-add

Paul Jan   (Jun 20, 2006 at 00:23 GMT)
Oh ya adjusting the gamma/luminence is easy - just throw a multiplier into the pixel shading mix - but for me the framerate killer is in the sampling (so adjustment is automatic) - at least when i'm trying it.
Edited on Jun 20, 2006 00:24 GMT

Paul Jan   (Jun 20, 2006 at 15:08 GMT)
Okay - I have it working now - mostly. Still some remnants of non-workey code that need purging, lest they rise up and cause a ruckus. No more wacky out of control blurring, and a more doom3-like environment. :)

Before

After

Edited on Jun 20, 2006 15:08 GMT

Alexander "taualex" Gaevoy   (Jun 20, 2006 at 18:12 GMT)
@Paul Jan: Looks much better, Paul :)

@All:
What will be the best place in the Torque pipeline to insert the post-render Cg effects? The rendering code is quite scattared, so I feel a bit lost...

Like bloom needs a path like screen->shader->pbuffer/texture->shader->screen with convolution vertical and horizontal filters...

Alex Scarborough   (Jun 20, 2006 at 20:01 GMT)
@Alexander "taualex" Gaevoy: Check out the DRL resource. It's a pure post-process effect. All the actual rendering takes place at the end of SceneState::renderCurrentImages and stores values that need to be stored over multiple frames in the client scenegraph.

Pisal Setthawong   (Jun 21, 2006 at 04:38 GMT)
@Paul Jan
I was planning to talk to you about the Cg Implementation in TGE just to exchange a few viewpoints on that, but since I don't have your email or contact and there was no blog in your profile until this moment, it was unfortunate, we couldn't talk. Anyway nice to see great things happening and the glow effect to work :) Do keep blogging!

I just thought about updating a little about the progress done in my part during the last few days. At the moment, I'm working on expanding my Cg implementation on TGE and making it more flexbile. First of all, I'm current seperating the Cg code into a seperate module, using namespaces to segregrate the additional Cg code from the rest of the engine. I also had to refactor the Cg code so that I seperate the intializiation of Cg, Loading Cg Programs, and the actual Cg part. With the refactored code, I could access most of these functions by using Console Access within TGE and make changes. One example would be choosing to load the Glow program, change it to the active Cg effect on the screen, and then later change factors such as the number of blur steps. This way I can also load other effects by console (Script). I can also turn off the Cg Effect immediately by console to compare the results. Though nifty, there are still many major bugs to weed, and a few things I plan to continue to work on.

Here are a few things that I still am thinking or planning to work on...
1) After every rendering pass, there should be an optional function that changes to certain variables that can affect the references between the app and the CgProgram that is done in the engine (e.g. at the moment it has to be done by script, using a schedule to regularly change a console app). This is still a question as at the moment, I can change this easily by console calls.
2) Related to part 1, how flexbile should it be? At the moment, I send extra information into the Cg program such as uniform float angle, but in this case I need to add this variable in the created Cg module part, add console access to it and change the value. In this case, I was thinking whether I should change this into a pool of variables that can be used. Though useful, this way it lowers readibility, and could be a maintainence nightmare for multipass effects.
3) Allow dynamic Changing of everything in the OpenGL RenderStates by console or should I simply write it as a seperate function, and choose which one to load and apply?
4) Should I allow expansion of functions by using external libraries and load it here? Sounds pretty an overkill, and not something I would want or want to do O_o

Hmm... decisions and decisions...

@Alexander "taualex" Gaevoy
Regarding where I put my glow, I put it in the SceneState::renderCurrentImage because I was planning a post-process effect. Glow can work in the post-process part, but it has to be applied to the whole screen, which means the Tron example of using alpha channels for glow won't work directly, you need to make more changes in different parts of the rendering pipeline. However what I had in mind was that I wanted to expand the whole screen effects (similar to those White Flash and Red Damage that are already in TGE) to include other effects such as drowsiness, drunkeness, and etc.

@Alex "Delerium" Scarborough
Regarding GLSL, the main reason I picked Cg was that it potentially would work for both OpenGL and DirectX implementation, and a secondary reason is that I'm teaching Cg in my class so it does conserve alot of my time LOL

Anyway talking about reality, Cg does have trouble when used in many ATI cards (might need some code change) due to many NVidia ****** so as mentioned, I want to add for other developers to be careful about the technology choosen in the project.

BTW, thanks for mentioning about the actual rendering part again, at least I know that I didn't hack into the wrong part of TGE :P

@Aun Arinyasak
One part might be putting the Cg program to activate in the wrong part of the program causing the effect not to appear. Another might be not specifying how many passes of the blur are done, so it does a grand total of 0 passes, and so the effect might not appear. If not this two, then I'm not too sure where else to look...
Edited on Jun 21, 2006 04:39 GMT

Paul Jan   (Jun 21, 2006 at 19:17 GMT)
Ow ow ow ... I just noticed that GL_LUMINANCE is just the sum of the RGB values clamped to [0,1] and not a true Y value (Y = 0.299R + 0.587G + 0.114B). As a result, my shading has had a tendency to go nuts on maps that aren't dark.

SETTIMO TUDOR EUGEN CRISTIAN   (Apr 10, 2008 at 16:21 GMT)
I Can add efx water mod to torque tge for real water?

You must be a member and be logged in to either append comments or rate this resource.