From: lawrence bertoldi (lberto++at++adelphia.net)
Date: 09/08/2004 05:51:49
Will the exporter work on the latest version of Maya? This has been a
problem in the past!
Alexander Lechner wrote:
>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
>>>-----------------------------------------------------------------------
>>>
>>>
>
>
>
This archive was generated by hypermail 2b29 : Wed Sep 08 2004 - 06:15:06 PDT