Re: [Maya2osg-users] Discussion of next changes

[Jean-Sébastien G. <jea...@cm...>]

Hi Javier,

>    I see your point, but I don't see how to implement it in a generic
> way. If I understand correclty, what you are proposing is to add to
> the exporter the specific code to check the properties you need (the
> existence of a bump2D node attached, bump2D values such as bump depth,
> etc...) and then add them to an OSG description field.
>
>    I don't think this should be the way to do that. Then Maya2OSG code
> will clutter with every specific every user finds.
>
>    What I am proposing is to add a "osg_description" string attribute
> to any Maya node that when detected by the exporter will be copied to
> the description of the corresponding OSG node. This way, the mechanism
> is generic and each user set the descriptions (in Maya) and use them
> (in the OSG loading) however he wants.

I really want to avoid the artist having to add anything to the Maya 
scene that is already there... You can add generic attributes that will 
be exported, that's fine, but anything that's already in the Maya scene 
(as a normal Maya artist that doesn't even know about the exporter and 
OSG would use Maya) should be exported automatically as well. At least 
the subset that is useful for now, and that subset can be expanded later.

What I meant about the bump2D node, is that all the information is 
already there in the material (as visible in the Hypershade) so why does 
the artist need to add anything at all? Plus, I'm trying to make a clear 
separation between the job of artist and the job of programmer. Adding 
custom attributes and specific information is not what an artist 
generally does, unless he falls under the description of "technical 
artist"... The artist just sets up the scene, the materials and so on to 
get the look they want. So my vision is to export all the information 
that's already there in a way that our engine can parse it later, and 
have a previewer app that is basically a stripped down version of our 
engine. Then the artist concentrates on the art, instead of doing some 
programming / configuration tasks as well (as they need to do with our 
current pipeline).

>    We are moving the logic to check the conditions and retrieve the
> properties we are interested in from the plug-in code to Maya and the
> user/artist. It can be easily automated in Maya, through MEL scripts,
> shelf buttons, etc. It can also be easily edited by hand. This way,
> specific needs are configured in the user Maya installation, not
> included in the plug-in. The "generic description" mechanism can be
> used to pass them from Maya to custom OSG-based application/loader.

As I said, I'm not against generic attributes, I'm against the user 
having to do extra steps to specify information that's already there. 
Even a shelf button is a step too many. Unless it's a button that does 
essentially "traverse the whole scene to create and set all generic 
attributes you need to", and in that case it could just be a set as a 
pre-export action that Peter already added support for, and why not do 
it by default then? Extra strings in the OSG objects' description list 
will not hurt anyone...

I hope we can find a way to satisfy both our visions :-)

Thanks,

J-S
-- 
______________________________________________________
Jean-Sebastien Guay    jea...@cm...
                                http://www.cm-labs.com/
                     http://whitestar02.dyndns-web.com/