Re: [Maya2osg-users] Discussion of next changes

[Javier T. <jav...@gm...>]

  Hi J-S,

On Mon, May 16, 2011 at 8:31 PM, Jean-Sébastien Guay
<jea...@cm...> wrote:
>
> My idea was to simply store the information needed (normal map texture
> filename, bump amount) somewhere, which could be read by our engine at
> file load time. I cannot generate the shader at export time, as our
> products generally use different shaders... So we just need to store the
> information somewhere appropriate (osg::Material or osg::StateSet
> description list for the normal map stuff, for example) and our engine
> will do the rest.
>
>>    Mmm... I still think we are mixing too much things there. I'd prefer
>> the custom attributes approach. I don't know what you mean with
>> "create some new window". You can create attributes without any new
>> development, just in the Attribute editor with Attributes>  Add
>> attributes... option. And it is quite easy to manage from MEL:
>>
>> addAttr -ln "normal_map"  -at double  |pSphere1;
>> setAttr -e-keyable true |pSphere1.normal_map;
>>
>>    Or course, once you have designed the attributes you need, you
>> should develop the artists tools to automate this (maybe just some
>> shelf buttons).
>
> I was actually thinking we don't need anything special in Maya. The
> plugin would just see that the Maya material has a Bump2D node attached
> to the bump attribute, and would add a string in the description at the
> appropriate place (as I said, osg::Material or osg::StateSet) with a
> special tag saying that this is metadata. Something like:
>
> maya2osg NormalMap filename:<some filename>.jpg bump:30
>
> As I said, our engine would then parse this when loading the .osg file
> and load the normal map and appropriate shaders.

  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.

  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.


>>    I'll take a look at it ASAP. Right now my daughters are dragging me
>> out of home. Quite a challenge was to be able to answer this message!
>>   :)))
>
> I understand, I have 3 boys myself :-)

  Then I don't have to explain anything  X-D


-- 
Javier Taibo