On Mon, Apr 7, 2008 at 11:01 PM, Mike Weiblen <[EMAIL PROTECTED]> wrote:
> Hi,
>
>
> On Mon, Apr 7, 2008 at 4:13 PM, Yefei He <[EMAIL PROTECTED]> wrote:
> > Hi, Folks,
> >
> > This maybe OT but I'm hoping other OSG users may have worked on
> > the same issue. I would like to use per pixel shader lights as car
> > headlights in place of standard GL spotlights in my driving simulator
> > program based on OSG. The geometric models are loaded from external
> > files such as .ive or .flt models. My concern is, I don't seem to be
> > able to retrieve enough information for the current fragment inside
> > the shader. For example, some faces in a model may be set to not
> > to be lit, i.e. GL_LIGHTING is disabled on those faces. Is there a
> > way to retrieve this information from inside the shader?
>
> Yes, you can pass it via a uniform. But if you're asking if there's a
> built-in uniform, no there isn't. You can see the list of built-ins
> (at least for GLSL 1.10) on the glsl_quickref.pdf.
>
> And in general, from the GLSL standpoint as a standard, the momentum
> is away from built-ins. Else it winds up as the union of every
> possible application's desired state being exposed as uniforms, adding
> burden to every shader and consuming uniform storage arrrays, which
> are a finite resource.
>
> -- mew
To add to that, the trend is toward making the API align better with
modern hardware (see plans for OpenGL 3 and beyond), and modern
hardware doesn't have those state bits/registers anymore (with the
exception of the parts of the pipeline that are not yet programmable).
Instead of the driver emulating fixed functionality that you don't
really want to use anyway, the responsibility for this type of state
management is shifted to the application developer who understands
what the shader needs as inputs. The hardware has general purpose
registers/stream-buffers, so that's what you'll be asked to use in the
leaner API (and driver) world.
You may want to generate shaders optimized for particular state
combinations so you don't waste instructions on code paths you know
will not be taken in the shader for many primitives (the driver is
undoubtedly doing this to some extent for the emulated fixed-function
paths). In that case you would be swapping between shaders instead of
changing uniform values to make your state changes. An alternative is
to use an "ubershader" that has many conditionals to switch behavior
based on uniform values. Given the number of different combinations,
you might end up with something in-between (e.g. a small number of
shaders with a small number of conditionals) or perhaps a system to
generate shaders from code fragments at runtime.
There are new NV extensions that let you set up uniform buffers
("bindable uniforms") so you can stream your uniform values to the
card instead of using "immediate mode" calls (glUniform*) to set your
uniforms. I'm not sure if support for that extension has landed in
OSG core yet, and it requires recent hardware (DX 10 class only?).
Leif Delgass
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
