Re: Cg, GLSL and uniform parameters

[Steve Baker <sjbaker1@airmail.net>]

Miguel Osorio wrote:

> Well, I'm having some trouble with that issue also. I mean, for an initial implementation,
> I'm relying on GL state for accessing matrices (modelview, projection and texture), material
> properties and lights.

Yeah - you certainly need to use the 'trackmatrix' thing to keep all the useful matrices
there.

Materials and lights though...I'm not so sure.

If you try to implement an entire general-purpose OpenGL lighting model in every shader, you'll
end up with something complicated and dog-slow.   Until we spin through some more generations of
hardware, you need to implement only the tiny subset of the lighting model that you actually
need...and often, that means passing partially calculated intermediates into the shader.

> I understand that without reference to GL states one can define new material models, new
> light properties, etc, and implement them exclusively with programmable shaders.

Yep - and that's for TWO reasons - one is because you can do better than the standard lighting
model - the other is because you can simplify the standard model where you don't need all of
the archaic support for modes you'll never use.

> But then again, I'm not really feeling the need to completely abandon some of OpenGL's standard
> models, since I also want to support the traditional fixed-function pipeline.

Keeping support for both standard pipeline and shaders can get nasty...however, I too am going
that route until we have the confidence to abandon the standard pipeline.

> > I think you should consider quite carefully whether you truly need access to the classical OpenGL
> > states.   I've found that being free of that mess is the best thing that ever happened to OpenGL.
> > There are a few OpenGL states that can usefully be passed through as Uniforms - but you certainly
> > don't need all of them.
> I agree we don't need all of them, of course. My approach is to use as much of the most common GL
> states for my shaders, which doesn't mean that I won't be able to implement more sophisticated
> shaders that rely on more "application dependent" states (as opposed to traditional OpenGL states).

I'm tending to find that a lot of what we traditionally think of is some complex set of GL states
that interact to produce some effect.   With shaders, you can skip all of that messiness and just
have the shader do what you want.  So rather than (say) turning texture on and off for four separate
texture units depending on the demands of each object you're rendering - you bind a shader that's
appropriate to that object which uses exactly the number of texture units it needs and that just
made all that texture enabling/disabling irrelevent for those objects.

Where that DOESN'T work well is for global effects like fog and (to some exent) lighting.

> Could you please give me some examples of uniform parameters that are used in vertex and fragment
> shaders?

Well, I've been doing this in a rather specialised set of applications (flight simulators) - but we
have things like the depth of displacement in a displacement map, the parameters of a complex
particle system, which way gravity points....a bunch of ad-hoc effects.

> I'm only beginning to explore the subject,
I think pretty much everyone is new to this - it's such a radical change to the way we work, even
the manufacturers and driver writers are still feeling their way.

I fully expect to have to totally re-think things in six months or a year.

---------------------------- Steve Baker -------------------------
HomeEmail: <sjbaker1@airmail.net>    WorkEmail: <sjbaker@link.com>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
           http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----