Re: [Maya2osg-users] Discussion of next changes

[Peter W. <pp...@cg...>]

Hi J-S
> Hi all,
>
> In the next few weeks, I'll be looking to adapt maya2osg to our art
> pipeline. The changes I want to make won't change anything for you guys
> I think, but will make it easier to use our engine's custom shaders
> instead of the ones maya2osg generates, and will make it easier to do
> additional stuff after the conversion.
>
> 1. I would like to embed tags related to special properties in the OSG
> object descriptions. For example, our engine uses custom shaders for
> normal mapping, so we can't use the ones generated by maya2osg, but we
> still need to know which materials have a normal map. So I would add,
> for example, a tag saying the osg::Material has a normal map, the normal
> map filename, and the bump amount as special description fields that our
> engine can then parse when loading the file. Essentially, anything that
> can't be expressed in the normal OSG objects (like osg::Material) would
> need special tags so that our custom shaders can set the right values.
> These fields don't change anything when rendering the file so they don't
> change anything for your usage.
>
If I got you right you right, basically you want to override the GLSL 
Shaders which maya2osg generates and embeds in the osg file, is this 
right ? Wouldn't an attribute type string named osgOverrideShader, added 
to the bump2D node ( or any shading node ) be sufficient ? The artist 
could put the path to such a custom shader into this attribute, and when 
maya2osg detects such an attribute, the would will be inserted at the 
right position in the osg, or embeded.

Another idea would be to use the maya description field in the same way 
as you would like to use osg descriptions ( didn't know till now that 
this exists :-) ). We could use an xml ( osg begin-end ) like structure 
to signal the plug-in that the description should go to the 
corresponding osg object description, and whatever tags or syntax you 
use inside would be up to you.
But as there is not a one to one representation of nodes, and you can 
write descriptions into any maya node, we must decide which maya node 
maps to which osg node ( description field wise ).


> 2. I would like to add a field to specify a post-export command to run.
> This could be of the form "C:\path\to\command.bat %1" and %1 could be
> replaced by the exported filename. We generally encrypt the models we
> ship to customers, so this could be done with this mechanism
> automatically each time the artist exports his model.
No problem, basically its just one more textfield ind the export script, 
and can be triggered through the script as wel.

> 3. I would like to be able to specify a command for a previewer
> application. I don't remember if it's maya2osg or OSGExp (the Max OSG
> export plugin) that has a preview button, but if maya2osg doesn't have
> one, we could add one, and by default it could just run osgviewer, but
> we could specify another application if we want. In our case, we'd use a
> bare-bones app that uses our engine, so that the tags I mentioned in 1
> would be interpreted and the artist would see the model as it will
> appear in the final engine.
Same as above. And if the field is empty the usual commands would be 
used for previewing.
> I think I saw that the plugin currently saves the values of its fields
> in the scene file? Is that right? For 2 and 3, I think the values should
> be saved application-wide, but I don't know how to do that, so I would
> need a bit of help. But for the rest of the implementation of these
> features I'll be fine doing them myself, and I can then post them here
> for review and discussion.
>
No, all of the settings are saved as environment variables in the maya 
settings, and maintain the same from session to session. The same would 
happen for the additional paths.

> But I wanted to ask first, what do you think about these kinds of
> features? I think they don't change your usage of the plugin, but just
> add flexibility for users.
My plan was to add per object overrides of the gui settings sooner or 
later, in the same way like e.g. mentel ray per object overrides. Right 
now I like the description field tag approach much more, as it really 
gives more flexibility instead of offering and maintaining override 
attributes. Point 3 is also very usefull for me as I started to write my 
osgAnimationViewer, but this is on hold now.

So if Javier is fine with the Path fields I can add them and take care 
of the logic. Point 1 will surely require more discussion.

Cheers, PP
> Thanks in advance,
>
> J-S