Getting CG Into Torque
by Owen "WDA" Ashcroft · in Torque Game Engine · 11/08/2003 (8:57 pm) · 16 replies
Spent the last 20 minutes popping CG into Torque, there is no guarantee that this is going to work, it compiles and I have access to CG commands, but it's past my bedtime and I have plenty of time to play with this tomorrow, if I have time.... But anyway for those having problems here is how I have integrated it.
Download the CG Toolkit - http://developer.nvidia.com/object/cg_toolkit.html
Make a directory called nVidia in your Torque Engine folder, so if it is installed C:\torque you nVidia directory is c:\torque\engine\nVidia
Copy all the CG header files into here (with their directories), so there should be 3 directories nVidia\Cg nVidia\CgFX nVidia\GL you only should need the nVidia\Cg, but you may want to use other things so if you stick them all in there then atleast they are available to you later.
Now load up the Torque source code, add a subfolder nVidia into Torque Demo -> Source Files and add these files to that subfolder: cgGL.h, cg.h, cgGL_depreciated_api.h, cg_profiles.h, cg_bindlocations.h, cg_datatypes.h, cgGL_profiles.h and cg_errors.h
You need to make changes to a number of these header files open up cgGL.h and find the code:
Open cg.h and just below #ifndef CG_DEPRECATED_API add #include "platformWin32/platformGL.h" (mines simply wouldn't compile with out it!)
Now you have to go through cgGL.h, cg.h, cgGL_depreciated_api.h and cg_profiles.h to adjust the include calls all includes that start have to be changed to "nVidia/Cg/XXXX.h" to use the adjusted Cg header files.
Finally goto the project properties, add the library directory that holds cg.lib cgGL.lib and then add them to be linked to finally.
The final step is to find somewhere to include the CG header files, I dropped them into platform.h so they are spread pretty much entirely across the Torque Engine.
That's it, as I said not tested with a shader so it may not work, but it should help those struggling for a starting spot.. I will get back to everyone with something more complete when I've sat down and written the code to actually run vertex and pixel shader programs.
Owen
Download the CG Toolkit - http://developer.nvidia.com/object/cg_toolkit.html
Make a directory called nVidia in your Torque Engine folder, so if it is installed C:\torque you nVidia directory is c:\torque\engine\nVidia
Copy all the CG header files into here (with their directories), so there should be 3 directories nVidia\Cg nVidia\CgFX nVidia\GL you only should need the nVidia\Cg, but you may want to use other things so if you stick them all in there then atleast they are available to you later.
Now load up the Torque source code, add a subfolder nVidia into Torque Demo -> Source Files and add these files to that subfolder: cgGL.h, cg.h, cgGL_depreciated_api.h, cg_profiles.h, cg_bindlocations.h, cg_datatypes.h, cgGL_profiles.h and cg_errors.h
You need to make changes to a number of these header files open up cgGL.h and find the code:
#ifdef __APPLE__ #include <OpenGL/gl.h> #else #include <GL/gl.h> #endifDelete it, Torque doesn't include these files directly and you will get all sorts of errors if you try to compile it with them still included.
Open cg.h and just below #ifndef CG_DEPRECATED_API add #include "platformWin32/platformGL.h" (mines simply wouldn't compile with out it!)
Now you have to go through cgGL.h, cg.h, cgGL_depreciated_api.h and cg_profiles.h to adjust the include calls all includes that start
Finally goto the project properties, add the library directory that holds cg.lib cgGL.lib and then add them to be linked to finally.
The final step is to find somewhere to include the CG header files, I dropped them into platform.h so they are spread pretty much entirely across the Torque Engine.
That's it, as I said not tested with a shader so it may not work, but it should help those struggling for a starting spot.. I will get back to everyone with something more complete when I've sat down and written the code to actually run vertex and pixel shader programs.
Owen
About the author
#2
I will keep an eye out for your content pack and see how you do it :)
Owen
11/09/2003 (6:13 am)
I kind of see what you're getting at, although, as you said it was a little more tedious I was far more interested in getting it into my project than being 100% neat and tidy about it. Plus this way is easier...I will keep an eye out for your content pack and see how you do it :)
Owen
#3
But, if you're still feeling lazy, just wait for my release. It'll have Cg integrated and bump+specular on most if not all torque objects. It's kinda funny slowing the game down and watching debris get lit up with bump maps and per pixel specular :)
I should add that my version will NOT support D3D as it'll probably double the time it will take me to get it out the door, plus you can optimize certain areas to run faster if not supporting D3D. The wrapper isn't very good anyway, so why bother? Hopefully I'll get it out for the holidays.
11/09/2003 (4:12 pm)
Yeah, it's fine for a local implementation - I actually used a very much more hacked implementation when I started out. When I interned at GG and saw how to load OpenGL, a little lightbulb went off and I was able to do it very cleanly. I also rewrote winGL.cc for Legends in the same way. It does get a little ugly if you don't know much about the preprocessor or calling convention types, as I learned through doing it.But, if you're still feeling lazy, just wait for my release. It'll have Cg integrated and bump+specular on most if not all torque objects. It's kinda funny slowing the game down and watching debris get lit up with bump maps and per pixel specular :)
I should add that my version will NOT support D3D as it'll probably double the time it will take me to get it out the door, plus you can optimize certain areas to run faster if not supporting D3D. The wrapper isn't very good anyway, so why bother? Hopefully I'll get it out for the holidays.
#4
11/09/2003 (5:32 pm)
I wouldn't worry about it, I was thinking of stripping D3D out anyway, the implementation isn't exactly wonderful...
#5
11/10/2003 (2:42 pm)
Hey I was wondering --- Is Cg usable with Radeon / ATI hardware? I just wanna know cause it would be a waste is I couldnt use the shaders programmed in Cg with my Radeon 9700 Pro. It would also be no good for other Radeon users. I only ask this because Cg is Nvidia's creation and they are competitors with ATI (obviously).
#6
11/10/2003 (4:59 pm)
Not sure, if there was an ATI compiler out there then yes, the code isn't (well CgFX is) designed purely for nVidia, frankly why the two can't cooperate on something as important as this I don't know.. but hopefully... 
#7
We used Cg for the development of Marble Blast FX. About half the shaders from that demo fail to run on my Radeon 9700. I was able to get some of them running again by taking out the swizzles that I was doing in Cg. However, there were others that would not work no matter how much I tweaked the Cg code. That was with the latest Cg compiler - 1.1. I haven't tried it with the runtime.
11/10/2003 (6:18 pm)
Before you jump on the Cg wagon you should know that some of your shaders will not work on the Radeon cards. The main issue that I've seen is with swizzling the components of the assembly registers. Swizzling can reduce the number of instructions a shader needs, so it's a nice thing to have. Unfortunately, the ATI cards don't support some of the swizzle operations that the nVIDIA FX cards have. I believe this might only a problem with version 2.0 pixel shaders, but it could also affect all vertex shaders.We used Cg for the development of Marble Blast FX. About half the shaders from that demo fail to run on my Radeon 9700. I was able to get some of them running again by taking out the swizzles that I was doing in Cg. However, there were others that would not work no matter how much I tweaked the Cg code. That was with the latest Cg compiler - 1.1. I haven't tried it with the runtime.
#8
I know the GF3 supports vp20/fp20, GF4 supports vp20/arbvp1/fp20, and FX support vp20/argvp1/fp20/fp30/arbfp1. I think that's how it goes for the FX cards, but I'm not definate. Anything with a v is a vertex program profile, and anything with an f is a fragment program profile. I don't know what ATi supports, although it must be a majority because Cg is pretty much HLSL, the DX9 shader language.
11/11/2003 (2:40 pm)
I also don't know if ATi cards support the fp20 fragment shader profile. Vertex programs have an ARB profile now, so those should be supported on either brand. Fragment programs, on the other hand, may only work with the very new arbfp1 (or arbfp2?) profile. I'd imagine that fp20 would only work on nVidia chipsets because I'm pretty sure it's based on the nv20 (gf3/4) instruction set.I know the GF3 supports vp20/fp20, GF4 supports vp20/arbvp1/fp20, and FX support vp20/argvp1/fp20/fp30/arbfp1. I think that's how it goes for the FX cards, but I'm not definate. Anything with a v is a vertex program profile, and anything with an f is a fragment program profile. I don't know what ATi supports, although it must be a majority because Cg is pretty much HLSL, the DX9 shader language.
#9
11/13/2003 (9:48 pm)
So then does this mean that the best way to implement shaders into Torque would be with the OpenGL shader language? It would seem that one would not want to use Nvidia's Cg or ATI's Rendermonkey, as you wouldn't want to have features that they could only access with a certain brand. Also, I am curious, does implementing Cg as you have shown above mean that shaders are integrated, so-to-speak, into Torque, or does other steps need to be taken. I noticed that you said you had not tried to use any shaders. Has anyone followed this and gotten shaders to work in their game?
#10
I've gotten shaders working. It's not that hard if you know what you're doing. It really isn't that painful getting shaders working if you just sit down and do it. The hard part is getting your effect working the way you want it.
11/16/2003 (10:33 am)
I'm pretty sure Rendermonkey is not a shader language. Cg is about the only thing you CAN do.I've gotten shaders working. It's not that hard if you know what you're doing. It really isn't that painful getting shaders working if you just sit down and do it. The hard part is getting your effect working the way you want it.
#11
_________________________________________________________________________________________________
MachineGOD
11/19/2003 (1:47 pm)
Well, has anyone here succesfully used cg shaders in torque after following this "tutorial"? I am curious to see if it has worked or not._________________________________________________________________________________________________
MachineGOD
#12
11/19/2003 (3:42 pm)
Haven't had a chance to actually put some in, been too busy moving halfway across the world, once my PC Is set up properly I will get back and look at this, see if I can get something to work :)
#13
List of openGL extensions and what cards support them:
www.delphi3d.net/hardware/allexts.php
11/19/2003 (4:09 pm)
Rendermonkey is just an ATI program to create shaders; something for artists to create vertex & pixel shaders visually. Reliance on Cg for shaders without a complete rewrite of TGE's renderer seems like the quickest and easiest way to get shaders into Torque. Though I have some doubts about using a language created by one 3d gfx card company. I haven't looked to see how close Cg is to DirectX 9's HLSL, but DirectX seems to have the most compatibility among different gfx cards (at least until OpenGL 2.0 comes out). Though that would require a rewrite. List of openGL extensions and what cards support them:
www.delphi3d.net/hardware/allexts.php
#14
11/20/2003 (2:59 am)
Scott: I agree but Torque would require a significant rewrite, either to an abstract API, with seperate OpenGL and DirectX code paths or to DirectX. It is quite a tempting project to actually do, but would be particularly time consuming. I'm still in 2 minds about it, if I was to do it I would follow the abstract API and submit that to the Torque Core project, I'd hate to be left behind when Torque continues because I've changed some seriously fundamental aspects of the engine.......
#15
Though it seems like there are some small levels of abstractions in the engine, from a quick reading of the docs (though no substitute for reading the code). I.E. standardized screen coords that are translated into the form OpenGL uses. An abstraction layer could be built upon that. (I understand that, that is only one single area. And there is most likely more I don't know of) Also the amount of function calls to replace and rewrite would be huge. For both OpenGL & DirectX & for other non gfx related portions of the engine that may rely on the data generated from the OpenGL specific rendering portion of the code.
In the most simplest form, OpenGL & DirectX draw pixels & the renderer(s) draw triangles made of pixels. To do so requires data. An abstracted layer between torque and rendering API's would juggle data into a form both enjoy, and the API's spit out the triangles. But getting to that point would take much time and work, though I believe it would be worth it to have a solid & separate OpenGL & DirectX renderer. Once removed from the bulk of the engine code, I believe newer features could be added more easily, without the feeling of a tacked on component (no offense meant to anyone). Though it seems like much of torque is made of tacked on pieces (when you start to add on resources & get farther away from what stock TGE can do), though many of the pieces are very solid and very polished.
Plus the renderer(s) &/or abstraction layer would have to be exposed to the scripting language in such a way that all the resources that depend on a preabstracted version of TGE wouldn't be broken. I see that as a major hurdle. Though again my knowledge of torque is limited thus far and I may be wrong.
Just some more thoughts.
11/20/2003 (8:38 am)
I can't seem to find the flowchart that showed how the different layers of the renderer are layered with each other; maybe there was no such flowchart to begin with... I have a rudimentary (basic--though I'm learning) understanding of how torque works (and openGL/DirectX) and general C/C++. I may be understating the level of work required to rewrite the renderer into separate OpenGL & DirectX paths on top of an abstract layer that, at the moment doesn't exist. Though it seems like there are some small levels of abstractions in the engine, from a quick reading of the docs (though no substitute for reading the code). I.E. standardized screen coords that are translated into the form OpenGL uses. An abstraction layer could be built upon that. (I understand that, that is only one single area. And there is most likely more I don't know of) Also the amount of function calls to replace and rewrite would be huge. For both OpenGL & DirectX & for other non gfx related portions of the engine that may rely on the data generated from the OpenGL specific rendering portion of the code.
In the most simplest form, OpenGL & DirectX draw pixels & the renderer(s) draw triangles made of pixels. To do so requires data. An abstracted layer between torque and rendering API's would juggle data into a form both enjoy, and the API's spit out the triangles. But getting to that point would take much time and work, though I believe it would be worth it to have a solid & separate OpenGL & DirectX renderer. Once removed from the bulk of the engine code, I believe newer features could be added more easily, without the feeling of a tacked on component (no offense meant to anyone). Though it seems like much of torque is made of tacked on pieces (when you start to add on resources & get farther away from what stock TGE can do), though many of the pieces are very solid and very polished.
Plus the renderer(s) &/or abstraction layer would have to be exposed to the scripting language in such a way that all the resources that depend on a preabstracted version of TGE wouldn't be broken. I see that as a major hurdle. Though again my knowledge of torque is limited thus far and I may be wrong.
Just some more thoughts.
#16
Also with CG calls to the script files would be made from within the engine itself, or the scripts embedded directly into the engine, it isn't the same language as Torque's script.
Torque isn't made of tacked on pieces, which it does appear initially, it is well thought out, for 80% of it atleast, there are areas that need to be redone but the engine actually balances out very nicely after you've worked with it for a while and you suddenly realise just what a nice job it is.
Also the Opengl portions of the code are purely rendering, the objects could be handed to anything, it's just OpenGL was chosen for the engine, of course there is some crazy axis stuff in the engine that doesn't make much sense, so you would have to translate the ingame axis to whatever system your actual render uses, my only gripe is that OpenGL is used primarily, I am still very tempted to write an abstraction layer so different rendering apis could be used..
11/25/2003 (2:23 pm)
The best way is to start from the entry point and see where the code moves through when initialising the render and other systems, it is very enlightening, takes a while to trace it but I felt much more comfortable making big changes afterwards..Also with CG calls to the script files would be made from within the engine itself, or the scripts embedded directly into the engine, it isn't the same language as Torque's script.
Torque isn't made of tacked on pieces, which it does appear initially, it is well thought out, for 80% of it atleast, there are areas that need to be redone but the engine actually balances out very nicely after you've worked with it for a while and you suddenly realise just what a nice job it is.
Also the Opengl portions of the code are purely rendering, the objects could be handed to anything, it's just OpenGL was chosen for the engine, of course there is some crazy axis stuff in the engine that doesn't make much sense, so you would have to translate the ingame axis to whatever system your actual render uses, my only gripe is that OpenGL is used primarily, I am still very tempted to write an abstraction layer so different rendering apis could be used..
Torque Owner Chris \"Hobbiticus\" Weiland
Also, if you feel like waiting a bit, I'll be releasing a content pack with something like that already implemented soonish :)