Re: [osg-users] Future of osgdb_dae COLLADA - plugin?

Wed, 13 Sep 2006 03:10:39 -0700 

[EMAIL PROTECTED] wrote:


I think that your best bet would be to add the GLSL support to the
plugin and create a conditioner.
Yes, that would be one possible solution, the collada-importer should cleanly load GLSL-profiles, and any other necessary conversion could be done 
in another, separated conditioner.


I think Mike had made considerable progress in GLSL import in the
previous plugins. The source is still available in CVS on the
sourceforge project for the COLLADA OSG Plugin. That plugin was before
1.4 and the COLLADA FX (thought it might have been made during the beta
stages of 1.4) so there would need to be a lot of work to update the
import for COLLADA 1.4. But the code to convert into OSG should be very
useful. A lot of the new plugin is based on Mike's work from the old plugin.
I was looking through the codebase in the older CVS-versions, and the only import of shaders I found was in the branch osgdb_COLLADA, which seems to be the oldest one. Anyway, importing GLSL shaders shouldn't be any problems on the OSG-side. 


The COLLADA FX CG and GLSL profiles are *VERY* similar. Writing a
conditioner between the two might not be as dirty as you think. The
hardest part would probably be semantic mapping between the two shader
programs themselves. I don't know much about GLSL so that may not even
be true.
What I have done so far, is compiling the Cg-code into GLSL, and if I'm getting your concerns right, mapping semantics from Cg-code to GLSL, on the shader-src itself, often means replacing the Cg - variable with the right keyword from GLSL (like TEXCOORD0 input semantic should be mapped to gl_MultiTexCoord0...) 
For most of these cases, the CG-compiler takes care of that by itself.
But this is another point, the cg-compiler renames a lot of the uniform variables, so you have to restore them manually, if you want to use human-readable variable names in OSG. This is not too difficult, as you have the right names in the colladafx-file, and also in the commented header-section of the cg-compiler translated shader-source. Also you have to take care of the matrix-format by yourself, as Cg is using row-major and GLSL column-major. So I guess, the compiled glsl - code is not really intended to be used natively, without any Cg-interaction afterwards, though it is possible with some workarounds... I just hope we will see more compile-options for GLSL in future releases of Cg, so we might turn off the cgc optimization and renaming strategy, etc...
Anyway, I think it would be great if we have a separate conditioner for converting Cg stuff into GLSL until FXComposer2.1, or 
even the Maya-Plugin is natively supporting GLSL.

- heinrich



Robert Osfield wrote:

Hi Heinrich,

The COLLADA plugin is now in the core OSG, and will be part of 1.2, and
I have taken over as maintainer of the plugin from Andy.

I have hopes in the future that the COLLADA plugin will provide a smooth
art path route into and out of the OpenSceneGraph.  As yet the plugin is
still quite immature, and the COLLADA DOM itself is unlikely to be well
fleshed out yet.  Plugins for the modellers are also like to be
immature.  I was hoping that COLLADA would be a bit further along by
now, but its not yet there in turns of art path nirvana.  However,
unless we and others support and try to make it work for us it won't
mature rapidly and be what we all need.

My plan is to develop the plugin in conjunction with the community as is
done with the rest of the OSG, if you have a particular itch then feel
free to get stuck in and scratch it.  I don't personally have Maya, 3D
Studio, Lightwave or any other 3D modelling tools at my end to test
directly against so I'll need to defer to other to help test this route
out, I do plan to expose myself to Blender in the not too distant future
so this will be one thing I'll be able to test against personally. 
I was expecting to have GLSL route already implemented in our COLLADA
plugin, as was the original intention when Mike was at 3D Labs, but alas
3D Labs is not what it was, and Sony's priorities lie obviously with the
Cg art path route that Nvidia have dictated.  Personally I'm a bit
disappointed that Cg hasn't died already, it just messes up the
standardisation that OpenGL is supposed to be about.  Lack of proper
standardisation just wastes developer time and in the end just holds the
whole industry back.

Updating Marco Jez's osgNV to support the latest Cg is a possibility,
perhaps pulling a osgCg out of this, or perhaps just creating a new
osgCg from scratch.  I think Cg is a backward step  when viewed from a
mid-long term perspective that should be avoided, but do understand that
some developers will find it useful as a temporary measure for very
specific jobs.  The better current art part route via Cg compounds the
necessity for this temporary measure for others. 
At present I don't have any plans for osgCg work, and while there is a
chance that I may get involved in development of such a NodeKit, I don't
feel is appropriate to integrate into the core OSG.  This is partly down
to practicality and portability - the OSG really doesn't need any more
external dependencies to cause runtime and build problems across
platforms, but also down to wanting to the keep the OSG conceptually
clean - Cg is fork from OpenGL, a fork that the ARB decided wasn't an
appropriate path to take, and also long term, Cg is just a temporary
glitch in the OpenGL landscape, it should have died several years ago,
OpenGL 3.0 is where we are headed, not some kind of hybrid Cg / OpenGL
future.  Do we help perpetuate this, or help make sure that 3rd Party
tool makers like Alias get back on the horse and start pulling in the
right direction once more?

Robert.

On 9/11/06, *Heinrich Fink* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:

   Hi,

   I was playing around with the importer for OSG last month, to provide a
   faster pipe from Maya to osg.

   Unfortunately feeling software's plugin for maya does not support GLSL,
   and they have no plans to implement
   it so far. On the other hand, I guess an updated Cg-Plugin for OSG won't
   ever make its way into the core either. If you stick to the
   OpenGL specifications that much, it wouldn't be too consequent to do
   that.

   So if nobody either hacks the maya-importer to utilize GLSL, or
   implements Cg on OSG, I guess we have to wait for FX Composer 2 for a
   clean content-pipeline using shaders.
   (Modelling etc. in Maya, working on shaders in FXC2, maybe go back to
   maya again, etc...)
   But again, though the first 2.0 release will support GLSL it won't be
   integrated into the COLLADA FX framework... but probably will in 2.1...
   we have to wait, again

   Another probably very dirty solution, would be writing a conditioner
   converting the cg-profiles into glsl-profiles (the 1.5 cg-compiler has
   glsl-profiles which might be used for that....)

   So I was wondering what your plans on the further development on Andy's
   osgdb_dae - plugin are (especially the shader-part)?

   greets,

   heinrich

   _______________________________________________
   osg-users mailing list
   [email protected] <mailto:[email protected]>
   http://openscenegraph.net/mailman/listinfo/osg-users
   http://www.openscenegraph.org/



------------------------------------------------------------------------

_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/


_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/



_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Reply via email to