[info-performer] Re: performer multipass

Date view Thread view Subject view Author view

From: Rick van Haasen (rick.van.haasen++at++philips.com)
Date: 07/20/2005 08:14:58


Hi Alexej,

because i didn't get any response, i developed my own multipass-mechanism
for the Onyx.
it's sad that i had to reinvent the wheel, the "old" pfShader did these
things already....

At the SGI visualisation days in Ruesselheim i talked to John Underwood of
SGI. Het mentioned that it should be possible to use the
"old pfShader". I should send him an email for this issue. Because i
already had my own solution i have not contacted him yet.
Maybe someone of SGI reading this mail could help?

Anyway, for my own solution i used the following approach:

Each pass has it's own geostate. Also each pass can have a pre/post
callback (this is the optional callback of the geostate).
One of the uses for this callback is for example to setup a specific
opengl blending mode: from the performer-api's i could not find
a way to fully control the opengl blending modes. From the callback, this
is can be done.

>From the "application setup" point of view, you start with a geoset that
needs to be rendered with a specific "mp-shader".
First the specific mp-shader is defined in terms of its passes, specific
geostate and callback functions.
I defined a class "ShaderMngr" which is used for defining the mp-shader.
One of the things it does is allocating a draw-bin
for each pass. All geosets of a certain pass will be put into this bin. In
this way, state-changes are minimized when
rendering multiple objects that use the same shader.

After all the passes of the shader have been defined, a geoset can be
"translated" to a "mp-geoset".
This is done by creating a "shaderpass" object for each pass, using the
geoset as argument.
This object creates a copy of the geoset. This is a "shallow copy",
meaning that the atributes like vertices are shared among all copies.
It does allow to change the geostate that belongs to the copy. The size
of each copied geoset is about 100 bytes.
To each copy of the geoset, the geostate that belongs to the shaderpass
is now connected.
Each copy of the geoset is connected to a new geode. This geode can have
a specific call back to do some setup for the pass
(not that this is different from the callback of the geostate: the
geostate callback is only called once before rendering all objects
that share this geostate, sometimes however you need some processing for
each object in the bin, this way you can do this).
All geodes will be connected to a "top" group node. It is this group node
that is attached to the scene.

The draw process will execute all defined bins in a specified order,
executing the passes for the "shadered geosets" in the correct order .

success,
Rick

 

Alexej Fink
2005-07-20 12:46

To
Rick van Haasen/EHV/RESEARCH/PHILIPS++at++PHILIPS
cc

Subject
performer multipass
Classification

Hello,

We ( two students of University of Hamburg ) have the same problem now, as
you mentioned on performer mailing-list:
http://oss.sgi.com/projects/performer/mail/info-performer/perf-05-02/0037.html

It seems that you never got any answers (mailing list search engine found
nothing fitting).

Did you ever found a solution for that problem?
We would like to make a multipass shader-prog.
"render the geoset 2 times, each time with a specific geostate." - was
also our approach.

Thank you in advance!

Alexej Fink


Date view Thread view Subject view Author view

This archive was generated by hypermail 2b29 : Wed Jul 20 2005 - 08:17:31 PDT