Re: [Maya2osg-users] Discussion of next changes

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

Am 14.05.2011 22:33, schrieb Javier Taibo:
>> 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.

That would be better, but then, how would you like to pass bump value, 
and wether it is a bumpmap or normal map ? Do you want to recrreate 
those attributes on the 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.

Yes, I meant the notes field. The major point was that we ( or any user 
) should be able to pass any custom named attribute to osg,
without the plug-in recognizing them. I am fine with any other 
implementation of this approach, but the notes field has the advantage 
that it is already there and quite usefull for this porpose, will get 
saved with the file, and we would not need to create some new window, 
and take care that its saved per node in the file.
More over, with the xml approach <osg> NameValue Pairs </osg> we could 
keep Maya Notes as well as Custom Attributes.

Btw, I added also a preExportCommand Field, and this could be used, to 
collect maya data and write those into the approprite Description target 
( independent of the implementation )

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

So, this is done, a first draft, Pre Post Export Mel and Preview Mel. 
Pre and
Pre and Post will substitute $path to filepath, $file to filename and 
$type to filetype

Preview substitutes only $file to the camera based file name. If the 
access to $path , $file , $type is required, the Post Export Field can 
be used as well.

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

Sorry, if I screwed this up, but wouldn't know where to search. Need one 
more week, have exam on Saturday, and then I could help.


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

Thats good. For osgAnimation soem extra gui is needed, for being able to 
play animations, but we could let the viewer detect if there is the need 
for such gui.

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

Thanks :-) which layout do you suggest ? Do the scrollLists look O.K. on 
your Maya 2011 ?

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

See above :-)  but want to add here something. Custom Attributes are 
still fine and needed, e.g. if one just wants to override a maya shader 
with a custom one. All which can be represented within a osg file could 
become a maya attribute, we can even go so far that we add so 
AETemplates that add maya2osg subsection to the Attribute Editor ( nice 
one :-) ). But for all what we cannot represent within a osg file should 
go to osg description in a highly customizable way.


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

my suggestion is in the repo.



>
>    Regards,
>