From: Alexander Lechner (alexander.lechner++at++vertigo-systems.de)
Date: 09/08/2004 02:50:09
On Wednesday 08 September 2004 11:26, yuri++at++yurix-sim.com wrote:
> Hello Alex,
>
> Certainly, there is a much tighter integration now of what you model and
> what you code. What DCC systems do you use (+plugins, custom
> macros/scripts, etc) to streamline this integration? Which file formats do
> you use that Performer can read and use your DCC-created shaders?
>
> Anybody else would like to contribute opinions in this regard?
>
> Regards,
> Yuri.
>
We wrote a custom PFB exporter for Maya. Artists use the CgFX plugin for Maya,
but unfortunately on Linux there is currently no working CgFX library (it
uses gcc 2.95). So we have to convert them manually (argh) to Cg.
Afterwards we use our own pfGeoStates (fpGeoStates in our notation) which can
handle Cg programs (in the pre/post apply callbacks).
Parameters are completely scriptable from our scripting layer (Elk/Scheme) or
from C++. Parameters can be generated from the read Cg source code.
Performer matrices 'Model', 'View' are automatically fed into shaders. As Cg
does not have semantics for uniform variables (in contrast to CgFX) we use
predefined variable names "Model", "ModelI" (inverse model matrix),
"ModelIT" (inverse transposed model matrix).
I am curious about the new pfShaderObjects. Seems like the PF-team though of
an ATI RenderMonkey integration.
Would be good to then have some kind of multi-pass-node as needed by CgFX and
also RenderMonkey to render effects.
Anyone else?
Best,
Alex
> Alexander Lechner writes:
> > On Wednesday 08 September 2004 04:06, Alexandre Naaman wrote:
> >> Hi Simon,
> >>
> >> > I have a question about the next Performer version, I hope someone can
> >> > help me:
> >> >
> >> > Will OpenGL Shading Language be supported and if yes: When is
> >> > Performer 3.2 supposed to be available?
> >> > I'm thinking about working with GPU programming in Performer and don't
> >> > want to start with the GL_ARB_vertex/fragment_program Extensions, if
> >> > the GL_ARB_Shader_Objects stuff will soon be supported. Therfore it's
> >> > very important for me, for how long I have to wait...
> >>
> >> Yes, support for GLSL will be in 3.2. At this point we're merely doing
> >> fine tuning to our support for GLSL and adding "external" features, like
> >> support for ATI's RenderMonkey, samples, documentation, etc.
> >>
> >> If there's anything in particular you'd like to see for this feature in
> >> 3.2 please advise. The API is more or less frozen but that doesn't stop
> >> us from making additions in other parts of the release.
> >
> > We've already implemented a Cg binding in our VR framework Avango (which
> > also features a Performer renderer). A crucial think I observed is a
> > tight integration of Geometry AND Shaders. For performance reasons it is
> > obvious to use pfGeoArrays, but I think they have a rather clumsy
> > interface in Performer. There should be more helper functions to cope
> > with them. Say for example when you want to generate binormals and
> > tangets for a geometry in a pfGeoArray or when trying to rearrange the
> > vertices in a cache friendly way, things get really complicated if you
> > want to do this in a general manner. When a pfGeoArray is being shaded by
> > a GLSL shader (or Cg), the attributes must be bound to the location the
> > shader expects them. Maybe there could be some clever way to match them.
> > Regarding parameters there should be some possibility to access the
> > current PF viewmatrix (without having to invert and post-rotate it!),
> > current model matrix and alike in the shaders. Maybe there could be some
> > special functions in pfGProgramParams to bind the current model matrix
> > (normal, transposed, inverted, inverted transposed) and so on to named
> > parameters.
> >
> > I really appreciate the hard effort you put into the integration of these
> > techonlogies as it's often more difficult to bring them into an exisiting
> > system than designing a system (using these technologies) from scratch
> > like NVSG.
> >
> >> In terms of timing, we should have Alphas/Betas soon. Stay tuned ...
> >> I'll let Allan reply to the details of the timing concerning the release
> >> of 3.2.
> >
> > Good news!
> >
> > Thanks,
> > Alex
> >
> >> Hope this helps,
> >>
> >> Alex.
> >>
> >> -----------------------------------------------------------------------
> >> 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
> >> -----------------------------------------------------------------------
> >
> > --
> > Alexander.Lechner ++at++ vertigo-systems.de
> > Engelbertstraße 30 | phone: +49-221-2405472
> > D-50674 Köln | fax: +49-221-34892616
> >
> > -----------------------------------------------------------------------
> > 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
> > -----------------------------------------------------------------------
-- Alexander.Lechner ++at++ vertigo-systems.de Engelbertstraße 30 | phone: +49-221-2405472 D-50674 Köln | fax: +49-221-34892616
This archive was generated by hypermail 2b29 : Wed Sep 08 2004 - 02:52:38 PDT