Re: [Maya2osg-users] Discussion of next changes

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

  Hi all,

On Sat, May 14, 2011 at 6:47 PM, Peter Wrobel <pp...@cg...> wrote:
>> 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.

  I also have a similar problem. I need a modification to the shaders
for a specific use. I really don't have to replace them, but to add
some computations that will end in a second render target. I'm keeping
a modified version of the plug-in, but it would be nice to make it
easy to make these changes and maintain them.

  By the way, J-S, this is for a work that I am presenting in your
country next month (http://nss.cs.ubc.ca/nossdav2011/index.html). But
it is a little far from Montreal  :)

>> 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.

  Every node in Maya can have additional attributes. It is quite easy
to create them, and check their existence and their value from the
exporter. I did that some years ago for the content creation pipeline
a VR system (called The Empty Museum) we developed in my old lab. We
exported some special nodes such as audio sources, proximity sensors
or visibility sensors from Maya to our VR system. They are
reminiscences of this code in Maya2OSG source code. The comment

 	// POLYGON MESHES (AND CUSTOM NODES)

  in dagnode.cpp is because there was where I checked the attributes
for some of these special nodes.

> 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

  I don't believe that bump2D is the right node to place it. I suppose
it should go in the Maya shader or maybe in the affected geometry
mesh. It depends on how you will use it.

> 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.

  Yes, in this case it should be in the Maya shader.

> 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 ).

  I would avoid to use the Maya description field (do you refer to
what appears as "Notes" in the Attribute Editor?), to avoid collision
in scenes where this field is already used, but to create custom
attributes. It's cheap and easy, and they can be mapped to OSG
description or other properties however we want.

>> 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.

  I agree. This could perfectly be a new export option (more to the option box).

>> 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

  Maya2OSG has the preview button. It has appeared a bug recently,
however, and it doesn't show the scene with the right camera, but I
have it on top of my Maya2OSG-related TO-DO list.

>> one, we could add one, and by default it could just run osgviewer, but

  Actually I was using a slightly modified version of osgviewer to be
able to show the scene from exactly the same camera you have in Maya.
I also was thinking to include it as part of the plug-in, to avoid
calling an external application with all the problems it has (to be
reachable in the path, etc...). However it doesn't mean we shouldn't
have an option to select other preview application. In fact, I think
currently all of us use a different previewer :)

  Once I had it integrated in the plug-in, Peter, we should try to use
this previewer for both normal scene previewing and osgAnimation
previewing. Maybe it is just easy to merge both viewers.

>> 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 we all agree in this aspect.

>> 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.

  Yes, this is working nice, Peter. Thanks, it is much easier now. One
of the first things we must sort first is the plug-in options and the
GUI layout (and at last keep only a unique version of the GUI that has
all needed options in a nice layout :)

>> 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

  Mmm... could be interesting.

> now I like the description field tag approach much more, as it really

  I don't know if I understand you about the "description field tag",
if it is the "notes" field at the bottom of the attribute editor, I
don't like it very much, I would prefer custom attributes.

> 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.

  What do you exactly mean with the path fields? If you mean a field
in the GUI (exporter options) where to select an external previewing
application, it is OK for me. Maybe with a checker to enable/disable
it to select using the built-in previewer or the external previewer
supplied in the field.


  Regards,

-- 
Javier Taibo