From: Radomir Mech (rmech++at++engr.sgi.com)
Date: 02/19/2002 12:08:20
Hi Rob,
if the light is not moving, you can use bins. You can create a new bin and
assign it to all geometry that you want to render multiple times.
You would have to take over the draw and render all bins in the first pass
and only the new bin in subsequent passes.
If the light or geometry is moving you would have to determine what geometry
may possibly be affected by the light at each frame. This you would have to
do even if you use a copy of your geometry for each pass, as Brian suggested.
It's too bad that it may be too late for you to use a higher version of
Performer.
In 2.5 you could use cull programs that would automatically put geometry
that is within a specified polytope (area affected by the light) into
a given bin. Then in your multipass renderer you would draw only that bin.
If 2.5 is an option for you see man pfCullProgram and sample code in
/usr/share/Performer/src/pguide/libpf/C++/cullPgmSimple.
Regards,
Radomir
Brian Furtaw wrote:
>
> So Rob what you are trying to do is possible. As you mentioned a
> pfLightSource acts on the entire scene. A pfLight controlled within a
> pfNode draw callback can be constrained to certain geometry. To do
> option (b) place your multipass geometry under a pfGroup and make a copy
> of it for every texturing pass you wish to make. Then in the draw
> callbacks of the nodes you just created apply the desired texture and
> the proper blend function. You will also need to use
> glPolygonOffsetEXT() so that you can elminate Z-fighting problems
> between the multiple passes of your rendered geometry.
>
> A very good example of how this is done can be found at
> http://www.dorbie.com/aqua.html#_cch3_886491694
>
> Take a look at "Texgen & Caustics" and "Post Texture Alpha Modulated
> Specular Term" sections in particular. All of these tricks can be
> accomplished in Performer 2.2 and up.
>
> Your option (c) using Performer 2.4 only works if you are using graphics
> hardware which supports multitexturing. Octane & Onyx do not have
> multitexture capability. Actually Onyx can do detail texture which
> multitexturing but a special case of it.
>
> If you have more question please don't hesitate to write,
>
> Brian
>
> Rob Krajcarski wrote:
> >
> > Hello,
> >
> > I am looking into ways of using multitexturing to make certain geometry
> > appear to be lit. From what I can tell I have three options:
> >
> > a) Use pfLightSource using projected textures
> > b) Perform a multipass render
> > c) Use Performer 2.4 and multitexturing
> >
> > Now, my main problem with options a & b is that I only want the
> > multitexture to affect certain geometry, and so it seems a whole lot of
> > wasted effort to re-render the whole scene, and I haven't been able to
> > limit the effects of the pfLightSource to specific geometry (I have had
> > success when using pfLights, but that's all). As for going to version
> > 2.4, that's pretty much out of the question in my current development
> > process....
> >
> > So, I'm wondering if there are ways to do redraw parts of the database,
> > (perhaps with pfDrawBin?).
> >
> > What I'm trying to accomplish is to have a 'complex' static lighting
> > patterns effect specific geometry. I'm sure that I could simply generate
> > precomputed textures offline since the lighting is static, but my feeling
> > (or guess) is that it will make things easier to change if I make the
> > layering of texture information dynamic. So if no one out there has
> > solutions to the multi rendering part of my problem, then maybe someone
> > can suggest a solution to my real problem :)
> >
> > Thanks for any help that you can provide...
> >
> > Rob Krajcarski
> > DCIEM
> >
> > -----------------------------------------------------------------------
> > List Archives, Info, FAQ: http://www.sgi.com/software/performer/
> > Open Development Project: http://oss.sgi.com/projects/performer/
> > Submissions: info-performer++at++sgi.com
> > Admin. requests: info-performer-request++at++sgi.com
> > -----------------------------------------------------------------------
>
This archive was generated by hypermail 2b29 : Tue Feb 19 2002 - 12:09:15 PST