Replacing fixed function rendering pipeline with shaders

OpenGL Development JOGL Development
#1

Hi,

Have been reading a bit about CG lately, and I really would like to learn more about it. Although, I have a few questions regarding the use of CG in a game rendering engine, which I hope some of you may know the answer to:

1: Is it possible to replace the common “fixed function” rendering pipeline with CG shaders?

2: If so, what advantages/disadvantages follow that approach? I would guess it will be more effective to keep the fixed function pipeline, but are there any serious performance overheads (Or am I making no sense here… :smiley: )?

3: If I implemented a toon shader in CG, how low can I go on the GPU requirements (regarding OpenGL extensions and whatnot, GF4MX420 and ATI alikes?) ?

I understand that this may be in the wrong forum, but I mostly write 3d code in JOGL, like it a lot.

Thanks

#2

1: Yes, in fact you may have to :o

2: I guess it’s more or less the same.

3: No idea. I would suggest to benchmark it :wink:

Btw. if you use GLSL instead of CG, you could utilize ShaderGen, which generates GLSL shaders equivalent to the selected fixed functionality.

#3

I think I may have to read the CG tutorial book by nvidia. As for ShaderGen… It looks good, but I make a point in developing everything on Linux. Really just want to build a very simple graphics rendering engine without a scenegraph and a bare minimum of features (as i dont believe that a scene graph is a logical way to represent reality, or maybe Im just beeing silly). That is why I thought that shaders would be nice to plug in features to the rendering pipeline using AOP. AOP kicks donkey.

Thanks for the post.

#4

I would not use CG and stick to GLSL since it is part of the OGL standard.

What do you think is a logical way to represent reality, then? There has to be some management of objects in your 3D space and I think this alone defines a scene graph, so you will most likely create one :o

Oh… dunno, maybe you are falling prey to the golden hammer syndrome :wink:

#5

Alright, Ill have a look at GLSL then, but from what I hear, GLSL is only supported on newer cards (I wouldnt know, since I have never looked at programmable shaders since now).

As for the scene graph, I have a few Ideas that seem more logical to me at least, but I havent had a chance to try them out yet, since I would need a rendering pipeline first (at least to confirm the results visually). Will post the results and the explanation of it all here for sure, when I have something to show.

LOL @ the golden hammer syndrome statement (I admit, I sometimes get carried away ::slight_smile: ) but I really belive that AOP (AspectJ) provides nice features to make the code easier to read and modify. Wheter it will do any good in a rendering pipeline, is yet to be discovered.

#6

That’s true… what generation of cards are you targetting. You will however be able to write GLSL shaders and compile them to something useful on older cards with the CG compiler, but then you have to use the CG library to pass variables to the shader… so you might indeed be better of using CG from the start if you want to target older cards…

However thinking about the time you might need to get an own engine working (tried that myself), you can safely target shader model 3.0 :stuck_out_tongue:

As far as I can tell, a scenegraph is more of a compromise for handling 3D objects easy enought to use them from the developers point of view while being able to store the objects under the hood in a way that allows for optimized querying (culling, collisions etc.) and rendering technics (state sorting, imposters etc.).

I am not a big promoter of AOP since it IMHO hides to much of the control flow and it is very easy to shoot yourself in the foot :wink: On the other hand I like to use IOC con

#7

GLSL is supported on GF-FX cards (and IIRC ATi’s 9700 cards) and onwards. With Cg you can write shaders which target slightly lower cards (GF4 Ti not MX) but as they don’t have proper shader support anyway what you can do is extremely limited.

The GF4 MX is really just an overclocked GF2, and can’t really do anything interesting shader-wise. If you want to write effects for that you’re limited to simple texture combiners (ugly, difficult to use), although you can use vertex shaders as these get emulated on the CPU (although that just raises the question of why not just do it on the CPU yourself).

If all you want is a toon shader on your MX, I’d just do it on the CPU.

#8

Thanks for the post, why couldnt anyone tell me this before :wink:

#9

[quote=“krigun,post:1,topic:28358”]
Yes. A bit difficult to cover all cases though (and usually unnecessary).

[quote=“krigun,post:1,topic:28358”]
Advantages:

  • You have full control.
  • You use a single pipeline for everything (in case you add more sophisticated effects later).
  • Performance may be better in certain cases, since you know exactly what needs to be done. The fixed pipeline may be doing a lot of extra work when it’s not needed.

Disadvantages:

  • Difficult to get right, a lot of stuff to add support for.
  • Using the fixed pipeline is easier (e.g. turning on one more light), whereas you have to take care of everything when using shaders.
  • Worse performance if fragment shaders are used (though FSH capable hardware should be fast enough anyway)

[quote=“krigun,post:1,topic:28358”]
As low as GeForce 3 and ATI 8500. Don’t expect to able to do much more complicated stuff though.

About scenegraphs: Scene Graphs - just say no :wink:

#10

IMHO that article looses most of it’s credability by claiming that most games are CPU, not GPU limited. ::slight_smile:

Although I do agree that one ‘uber tree’ is never going to work.

#11

[quote=“Orangy Tang,post:10,topic:28358”]
That’s true actually, most games are indeed CPU limited.

#12

Every game I’ve played on my pc in the last couple of years has been fill-limited, even with effects turned down. Unless you’re classifying ‘most games’ as ‘rts games’.

#13

No, I really mean most games. If you run a game on a high-end CPU with a high-end GPU, you’re most likely going to be CPU limited. You can see this clearly in benchmarks. New GPUs can’t get far away from their predecessors in terms of performance, when tested on “current-gen” games. That’s because they are CPU limited, adding a more powerful GPU produces no gain (on the same level of detail, same resolution, etc). Anyway, that’s what I’ve been reading in every performance related paper (by NV & ATI usually) in the past years.

That doesn’t mean you can’t get GPU limited, it is just more common to see CPU limited games.

#14

[quote=“Spasi,post:9,topic:28358”]
Advantages:

  • You have full control.
  • You use a single pipeline for everything (in case you add more sophisticated effects later).
  • Performance may be better in certain cases, since you know exactly what needs to be done. The fixed pipeline may be doing a lot of extra work when it’s not needed.

Disadvantages:

  • Difficult to get right, a lot of stuff to add support for.
  • Using the fixed pipeline is easier (e.g. turning on one more light), whereas you have to take care of everything when using shaders.
  • Worse performance if fragment shaders are used (though FSH capable hardware should be fast enough anyway)

Thanks for your excellent reply, really made things clearer on the shader matter.

And I must say that I share the opinions presented in that blog post. Thats why Ill say no to the scene graph :wink: . Wouldnt know too much about games beeing GPU or CPU limited, altough the latter seems more reasonable. Believe that this is especially true for Java games using JNI and all, although the performance is not at all that bad.