[Maya2osg-users] Discussion of next changes

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

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.

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.

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.

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.

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.

Thanks in advance,

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