Re: [Maya2osg-users] Discussion of next changes

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

On Sun, May 15, 2011 at 12:59 PM, Peter Wrobel <pp...@cg...> wrote:
>   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 ?

  Well. We should know what does J-S exactly needs, but I was thinking
that if the target is to replace the Maya2OSG shader with a custom
one, Maya node attributes could contain the information indicating
that this custom shader must be used and the extra information needed
for the shader. In any case, when you reach a bump2D node you already
have the shader half created, thats why I didn't see it. But of course
a previous traversal can be done in the shading network to check for
the attribute.

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

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

> Btw, I added also a preExportCommand Field, and this could be used, to

  What is this, the name of a MEL script that is called before exporting?

> collect maya data and write those into the approprite Description target (
> independent of the implementation )

  OK. I see it. If it is just a matter of reading description and
writing in the node description, it is quite transparent to the
exporter. But I still would prefer in this case that we use a custom
"osg description" field, not to mix it with Maya description.

> 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

  Great. I suggest that for all the new features we add we also supply
a example data set to illustrate its working and also to test it when
other modifications that could affect that are made. It should have
saved us some problems in the past.

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

  There is a mess in this part that I am trying to fix. The preview
option should use two file names: the scene file name and the camera
file name. I am trying to fix it and I will commit it with the
built-in "osgpreviewer" command.

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

  I'm taking a look at it. I will probably ask for your help, however.

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

  When I have uploaded the built-in command to svn trunk (it is
finished, but I am messing around with the MEL scripts) I will open a
thread on the list to make a new previewer where to merge the
functionality we need for osgAnimation.

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

  The old scroll lists I made (the primigenious UI :) look pretty ugly
in recent Maya versions, I understand this is one of the reasons you
changed the UI  :D

  Soon I will create a thread in the list with the current options and
we could discuss the contents we need on the UI and how to organized
it.

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

  I think this discussion would be much more productive with some
usage examples and so we can work on several prototypes to see which
one we like most.

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

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


  Regards,

-- 
Javier Taibo