maya2osg-users

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

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

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

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

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

Re: [Maya2osg-users] Discussion of next changes

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

Hi Javier, Peter,

Thanks a lot for the discussions! My intent when I sent my message on 
Saturday was just to explain what I had in mind and maybe get a few 
ideas, I didn't want you to start doing anything in my place! :-)

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

My idea was to simply store the information needed (normal map texture 
filename, bump amount) somewhere, which could be read by our engine at 
file load time. I cannot generate the shader at export time, as our 
products generally use different shaders... So we just need to store the 
information somewhere appropriate (osg::Material or osg::StateSet 
description list for the normal map stuff, for example) and our engine 
will do the rest.


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

I was actually thinking we don't need anything special in Maya. The 
plugin would just see that the Maya material has a Bump2D node attached 
to the bump attribute, and would add a string in the description at the 
appropriate place (as I said, osg::Material or osg::StateSet) with a 
special tag saying that this is metadata. Something like:

maya2osg NormalMap filename:<some filename>.jpg bump:30

As I said, our engine would then parse this when loading the .osg file 
and load the normal map and appropriate shaders.

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

That's great, it will be very useful to us! Thanks!

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

I can give you some examples of what I would like, but I hope the 
description I gave above makes what I had in mind clearer.

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

I understand, I have 3 boys myself :-)

Thanks for your help,

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

Re: [Maya2osg-users] Discussion of next changes

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

  Hi J-S,

On Mon, May 16, 2011 at 8:31 PM, Jean-Sébastien Guay
<jea...@cm...> wrote:
>
> My idea was to simply store the information needed (normal map texture
> filename, bump amount) somewhere, which could be read by our engine at
> file load time. I cannot generate the shader at export time, as our
> products generally use different shaders... So we just need to store the
> information somewhere appropriate (osg::Material or osg::StateSet
> description list for the normal map stuff, for example) and our engine
> will do the rest.
>
>>    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).
>
> I was actually thinking we don't need anything special in Maya. The
> plugin would just see that the Maya material has a Bump2D node attached
> to the bump attribute, and would add a string in the description at the
> appropriate place (as I said, osg::Material or osg::StateSet) with a
> special tag saying that this is metadata. Something like:
>
> maya2osg NormalMap filename:<some filename>.jpg bump:30
>
> As I said, our engine would then parse this when loading the .osg file
> and load the normal map and appropriate shaders.

  I see your point, but I don't see how to implement it in a generic
way. If I understand correclty, what you are proposing is to add to
the exporter the specific code to check the properties you need (the
existence of a bump2D node attached, bump2D values such as bump depth,
etc...) and then add them to an OSG description field.

  I don't think this should be the way to do that. Then Maya2OSG code
will clutter with every specific every user finds.

  What I am proposing is to add a "osg_description" string attribute
to any Maya node that when detected by the exporter will be copied to
the description of the corresponding OSG node. This way, the mechanism
is generic and each user set the descriptions (in Maya) and use them
(in the OSG loading) however he wants.

  We are moving the logic to check the conditions and retrieve the
properties we are interested in from the plug-in code to Maya and the
user/artist. It can be easily automated in Maya, through MEL scripts,
shelf buttons, etc. It can also be easily edited by hand. This way,
specific needs are configured in the user Maya installation, not
included in the plug-in. The "generic description" mechanism can be
used to pass them from Maya to custom OSG-based application/loader.


>>    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!
>>   :)))
>
> I understand, I have 3 boys myself :-)

  Then I don't have to explain anything  X-D


-- 
Javier Taibo

Re: [Maya2osg-users] Discussion of next changes

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

Hi Javier,

>    I see your point, but I don't see how to implement it in a generic
> way. If I understand correclty, what you are proposing is to add to
> the exporter the specific code to check the properties you need (the
> existence of a bump2D node attached, bump2D values such as bump depth,
> etc...) and then add them to an OSG description field.
>
>    I don't think this should be the way to do that. Then Maya2OSG code
> will clutter with every specific every user finds.
>
>    What I am proposing is to add a "osg_description" string attribute
> to any Maya node that when detected by the exporter will be copied to
> the description of the corresponding OSG node. This way, the mechanism
> is generic and each user set the descriptions (in Maya) and use them
> (in the OSG loading) however he wants.

I really want to avoid the artist having to add anything to the Maya 
scene that is already there... You can add generic attributes that will 
be exported, that's fine, but anything that's already in the Maya scene 
(as a normal Maya artist that doesn't even know about the exporter and 
OSG would use Maya) should be exported automatically as well. At least 
the subset that is useful for now, and that subset can be expanded later.

What I meant about the bump2D node, is that all the information is 
already there in the material (as visible in the Hypershade) so why does 
the artist need to add anything at all? Plus, I'm trying to make a clear 
separation between the job of artist and the job of programmer. Adding 
custom attributes and specific information is not what an artist 
generally does, unless he falls under the description of "technical 
artist"... The artist just sets up the scene, the materials and so on to 
get the look they want. So my vision is to export all the information 
that's already there in a way that our engine can parse it later, and 
have a previewer app that is basically a stripped down version of our 
engine. Then the artist concentrates on the art, instead of doing some 
programming / configuration tasks as well (as they need to do with our 
current pipeline).

>    We are moving the logic to check the conditions and retrieve the
> properties we are interested in from the plug-in code to Maya and the
> user/artist. It can be easily automated in Maya, through MEL scripts,
> shelf buttons, etc. It can also be easily edited by hand. This way,
> specific needs are configured in the user Maya installation, not
> included in the plug-in. The "generic description" mechanism can be
> used to pass them from Maya to custom OSG-based application/loader.

As I said, I'm not against generic attributes, I'm against the user 
having to do extra steps to specify information that's already there. 
Even a shelf button is a step too many. Unless it's a button that does 
essentially "traverse the whole scene to create and set all generic 
attributes you need to", and in that case it could just be a set as a 
pre-export action that Peter already added support for, and why not do 
it by default then? Extra strings in the OSG objects' description list 
will not hurt anyone...

I hope we can find a way to satisfy both our visions :-)

Thanks,

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

Re: [Maya2osg-users] Discussion of next changes

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

  Hi J-S,

On Tue, May 17, 2011 at 1:09 AM, Jean-Sébastien Guay
<jea...@cm...> wrote:
> I really want to avoid the artist having to add anything to the Maya
> scene that is already there... You can add generic attributes that will
> be exported, that's fine, but anything that's already in the Maya scene
> (as a normal Maya artist that doesn't even know about the exporter and
> OSG would use Maya) should be exported automatically as well. At least
> the subset that is useful for now, and that subset can be expanded later.
>
> What I meant about the bump2D node, is that all the information is
> already there in the material (as visible in the Hypershade) so why does
> the artist need to add anything at all? Plus, I'm trying to make a clear
> separation between the job of artist and the job of programmer. Adding
> custom attributes and specific information is not what an artist
> generally does, unless he falls under the description of "technical
> artist"... The artist just sets up the scene, the materials and so on to
> get the look they want. So my vision is to export all the information
> that's already there in a way that our engine can parse it later, and
> have a previewer app that is basically a stripped down version of our
> engine. Then the artist concentrates on the art, instead of doing some
> programming / configuration tasks as well (as they need to do with our
> current pipeline).

  Of course, I absolutely agree with you here. What I meant was to
modify Maya to automatically do that for the artist.

> As I said, I'm not against generic attributes, I'm against the user
> having to do extra steps to specify information that's already there.
> Even a shelf button is a step too many. Unless it's a button that does
> essentially "traverse the whole scene to create and set all generic
> attributes you need to", and in that case it could just be a set as a
> pre-export action that Peter already added support for, and why not do
> it by default then? Extra strings in the OSG objects' description list
> will not hurt anyone...

  OK. What I want to avoid is to add specific code to the C++ plug-in.
My point is that it should be instead in the Maya user custom
configuration. But if we can solve it with a pre-export action, that
is a MEL script, it is perfect!. Everybody can make its own
pre/post-export scripts without cluttering the C++ code.

  And of course, we can develop a default set of scripts or a
collection of pre-built scripts, that could match your needs and serve
as a template for anybody to add its own needs.

  Could you solve your problem with a pre-export MEL script that fills
the Maya node descriptions that will then be automatically exported to
OSG node descriptions?

> I hope we can find a way to satisfy both our visions :-)

  I'm pretty sure that we can.


  I was thinking about other specific need that I had for the exported
GLSL shaders, that I didn't want to add to the trunk (as it is not
useful for anybody other than me), and didn't want to maintain an
independent branch either. But this is a topic for another thread :)


-- 
Javier Taibo

Re: [Maya2osg-users] Discussion of next changes

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

Hi Javier,

>    Of course, I absolutely agree with you here. What I meant was to
> modify Maya to automatically do that for the artist.

Perhaps that's the root of my lack of understanding of what you're 
suggesting... I was under the impression that we didn't have much 
control over Maya itself (other than through scripting), so when you say 
"modify Maya" I thought that was impossible. But from your reply below I 
assume you mean through scripting...

>    OK. What I want to avoid is to add specific code to the C++ plug-in.
> My point is that it should be instead in the Maya user custom
> configuration. But if we can solve it with a pre-export action, that
> is a MEL script, it is perfect!. Everybody can make its own
> pre/post-export scripts without cluttering the C++ code.
>
>    And of course, we can develop a default set of scripts or a
> collection of pre-built scripts, that could match your needs and serve
> as a template for anybody to add its own needs.
>
>    Could you solve your problem with a pre-export MEL script that fills
> the Maya node descriptions that will then be automatically exported to
> OSG node descriptions?

Yep, that sounds perfect.

I don't know how much you follow the osg-users list, but Farshid 
Lashkari who currently does most of the development for the Max export 
plugin is starting to do similar things there. Though he's going to do 
it directly from the C++ code I think. But the result is the same.

Perhaps we could try to follow the same naming and format convention for 
our version of this feature, that way it would be easier for us to parse 
the data. But I can do that, no need to jump in and do it all for me. :-)

Thanks again,

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

Re: [Maya2osg-users] Discussion of next changes

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

  Hi J-S,

On Tue, May 17, 2011 at 10:17 PM, Jean-Sébastien Guay
<jea...@cm...> wrote:
>>    Of course, I absolutely agree with you here. What I meant was to
>> modify Maya to automatically do that for the artist.
>
> Perhaps that's the root of my lack of understanding of what you're
> suggesting... I was under the impression that we didn't have much
> control over Maya itself (other than through scripting), so when you say
> "modify Maya" I thought that was impossible. But from your reply below I
> assume you mean through scripting...

  Well... OK. Perhaps, "modify Maya" is not the most adequate
expression (we don't have the source code)  :)

  I meant using scripts, of course. But don't say "we don't have much
control over Maya (other thatn through scripting)". The whole Maya UI
is built on MEL scripts, or at least it was so some time ago. The user
preferences are stored as MEL scripts and even the maya scenes when
saved in Maya ASCII format are no more than a big fat MEL script.

>>    Could you solve your problem with a pre-export MEL script that fills
>> the Maya node descriptions that will then be automatically exported to
>> OSG node descriptions?
>
> Yep, that sounds perfect.

  Well. I think that's the best solution then.

> I don't know how much you follow the osg-users list, but Farshid
> Lashkari who currently does most of the development for the Max export
> plugin is starting to do similar things there. Though he's going to do
> it directly from the C++ code I think. But the result is the same.

  About the osg-users list, I try to keep reading it, but the time I
have is quite limited. I just browse the messages and read some when I
find something interesting. Let's say that I read it "diagonally" (I
don't know if this expression is used in english) :)

  I saw a looooong thread about the Max export, but didn't read the
messages, as I don't use Max.

> Perhaps we could try to follow the same naming and format convention for
> our version of this feature, that way it would be easier for us to parse
> the data. But I can do that, no need to jump in and do it all for me. :-)

  Of course, if a similar thing is made in both exporters, we should
try to join efforts as much as possible and if a naming convention is
defined, let's follow it. I don't see any need to reinvent the wheel o
just "be different".

  Anyway, this is all in your hands ;)


  By the way, have you got a SourceForge account?


-- 
Javier Taibo

Re: [Maya2osg-users] Discussion of next changes

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

Hi Javier,

>    I meant using scripts, of course. But don't say "we don't have much
> control over Maya (other thatn through scripting)". The whole Maya UI
> is built on MEL scripts, or at least it was so some time ago. The user
> preferences are stored as MEL scripts and even the maya scenes when
> saved in Maya ASCII format are no more than a big fat MEL script.

Wow, that's impressive, I wasn't aware of that. Cool!

>    About the osg-users list, I try to keep reading it, but the time I
> have is quite limited. I just browse the messages and read some when I
> find something interesting. Let's say that I read it "diagonally" (I
> don't know if this expression is used in english) :)

That's understandable, I think I'm one of the few crazy people who tries 
to read all messages to keep up on what's going on and reply to as many 
as I can when I have an answer to a question... My post count is below 
Robert Osfield's but not by much last time I checked :-)

>    I saw a looooong thread about the Max export, but didn't read the
> messages, as I don't use Max.

In our company we use both, so I'm trying to develop (or at least 
suggest) improvements to both plugins to get to the same result. I would 
like to base our new content creation pipeline on these plugins as much 
as possible.

>    Of course, if a similar thing is made in both exporters, we should
> try to join efforts as much as possible and if a naming convention is
> defined, let's follow it. I don't see any need to reinvent the wheel o
> just "be different".

Great to hear that you're open to making things similar in both. It will 
make it simpler on our side when the time comes to read the output of 
both plugins in our engine :-)

>    By the way, have you got a SourceForge account?

Yes, "skylark13". Why?

Thanks,

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

Re: [Maya2osg-users] Discussion of next changes

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

  Hi J-S,

On Wed, May 18, 2011 at 1:25 AM, Jean-Sébastien Guay
<jea...@cm...> wrote:
>>    By the way, have you got a SourceForge account?
>
> Yes, "skylark13". Why?

  Just to add you to the project.

  Can you confirm if you have access to edit the Wiki pages? I think
it is a good place to collaboratively keep documented all new features
that we add to Maya2OSG.


-- 
Javier Taibo

Re: [Maya2osg-users] Discussion of next changes

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

Hi Javier,

>    Can you confirm if you have access to edit the Wiki pages? I think
> it is a good place to collaboratively keep documented all new features
> that we add to Maya2OSG.

When logged in, I can see "view source" at the top of the main page, but 
not "edit". I also tried the GLSL_shaders page, same result.

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

Re: [Maya2osg-users] Discussion of next changes

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

  Hi,

On Wed, May 18, 2011 at 3:02 PM, Jean-Sébastien Guay
<jea...@cm...> wrote:
>>    Can you confirm if you have access to edit the Wiki pages? I think
>> it is a good place to collaboratively keep documented all new features
>> that we add to Maya2OSG.
>
> When logged in, I can see "view source" at the top of the main page, but
> not "edit". I also tried the GLSL_shaders page, same result.

  Mmmm... I don't know how to give you access to it. I'll send a
message to SF support to ask them how can I give you access to the
Wiki.

  Peter, did you finally manage to get access to edit the Wiki?


  Regards,

-- 
Javier Taibo

Re: [Maya2osg-users] Discussion of next changes

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

Hi guys,

I've started looking at what you've done Peter for the pre/post-export 
script, it's cool that it's a MEL command. Is it possible from this 
field to call a function in a separate MEL script? Say I have a function 
called doPreExportStuff() in a file called preExport.mel, can I do 
something like (pseudocode)

loadMEL("preExport.mel"); doPreExportStuff();

?

If so that should be fine.

Second, I am getting an error when I click Export and the pre-export 
script field contains the default thing you put there (print( "preExp 
$path$file.$type " ) ;)  First of all there seemed to be a newline 
character in there at the end, because it would say:

print( "preExp 
C:/Users/jeang/Documents/maya/projects/default/scenesbox_normalmap_maya2osg.osg

" ) ;
// Error:  //
// Error: Unterminated string. //

So just before the closing quote there seems to be a newline. Then when 
I removed the newline, I got this:

print( "preExp 
C:/Users/jeang/Documents/maya/projects/default/scenesbox_normalmap_maya2osg.osg" 
) ;
preExp 
C:/Users/jeang/Documents/maya/projects/default/scenesbox_normalmap_maya2osg.osg
// Error: Too many arguments.  Expected 0, found 1. //

Is the print("preExp ...") supposed to call a function called preExp? 
The error is because this function does not exist? Or is it something else?

Sorry for my MEL newb-ness...

The other two examples (post-export exec( "osgviewer cow.osg" ) and 
preview exec( "osgviewer $file" ) work fine. They're great additions. 
Thanks.

Thanks in advance,

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

Re: [Maya2osg-users] Discussion of next changes

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

  Hi J-S,

On Thu, May 19, 2011 at 4:19 PM, Jean-Sébastien Guay
<jea...@cm...> wrote:
> Hi guys,
>
> I've started looking at what you've done Peter for the pre/post-export
> script, it's cool that it's a MEL command. Is it possible from this
> field to call a function in a separate MEL script? Say I have a function
> called doPreExportStuff() in a file called preExport.mel, can I do
> something like (pseudocode)
>
> loadMEL("preExport.mel"); doPreExportStuff();

  When you call a MEL function that is not defined, first Maya will
look in the scripts search path for a script with the same name and
.mel extension, so in this case you just need to call the function and
everything works automagically. If function name and file name do not
match, you can still load the file explicitly with

source "my_script_file.mel";

  You can omit the extension if it is ".mel". What you must be sure is
to define the function as global to be available outside this script
file. Example:

global proc maya2osg_removeOptionVars()
{
  ...
}


  Regards,

-- 
Javier Taibo

Re: [Maya2osg-users] Discussion of next changes

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

Hi Javier,

Great, thanks for the info!

J-S


On 19/05/2011 11:41 AM, Javier Taibo wrote:
>    Hi J-S,
>
> On Thu, May 19, 2011 at 4:19 PM, Jean-Sébastien Guay
> <jea...@cm...>  wrote:
>> Hi guys,
>>
>> I've started looking at what you've done Peter for the pre/post-export
>> script, it's cool that it's a MEL command. Is it possible from this
>> field to call a function in a separate MEL script? Say I have a function
>> called doPreExportStuff() in a file called preExport.mel, can I do
>> something like (pseudocode)
>>
>> loadMEL("preExport.mel"); doPreExportStuff();
>
>    When you call a MEL function that is not defined, first Maya will
> look in the scripts search path for a script with the same name and
> .mel extension, so in this case you just need to call the function and
> everything works automagically. If function name and file name do not
> match, you can still load the file explicitly with
>
> source "my_script_file.mel";
>
>    You can omit the extension if it is ".mel". What you must be sure is
> to define the function as global to be available outside this script
> file. Example:
>
> global proc maya2osg_removeOptionVars()
> {
>    ...
> }
>
>
>    Regards,
>


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

Re: [Maya2osg-users] Discussion of next changes

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

Hi J-S
> Second, I am getting an error when I click Export and the pre-export
> script field contains the default thing you put there (print( "preExp
> $path$file.$type " ) ;)  First of all there seemed to be a newline
> character in there at the end, because it would say:
>
> print( "preExp
> C:/Users/jeang/Documents/maya/projects/default/scenesbox_normalmap_maya2osg.osg
>
> " ) ;
> // Error:  //
> // Error: Unterminated string. //
>
> So just before the closing quote there seems to be a newline. Then when
> I removed the newline, I got this:
>
> print( "preExp
> C:/Users/jeang/Documents/maya/projects/default/scenesbox_normalmap_maya2osg.osg"
> ) ;
> preExp
> C:/Users/jeang/Documents/maya/projects/default/scenesbox_normalmap_maya2osg.osg
> // Error: Too many arguments.  Expected 0, found 1. //

Yes, I noticed something like this error message as well, but the 
problem is that it is not allways. E.g if you just change the filename, 
then the error goes away ... maybe. Unfortunatelly You cannot step into 
melcode, at least I don't know how, so its kind of hard to debug. But 
will take some time to look into this.

> Is the print("preExp ...") supposed to call a function called preExp?
> The error is because this function does not exist? Or is it something else?


Nope, so what I am doing there is just a demonstration what happens with 
$path, $file and $type. "preExp" is nothing, but a possible command that 
you could trigger in there, when you would define it. So I just print 
out the concatenated command string.
In you case, you would write( e.g. ) preExportCommand_JS and if you 
require the values of Filepath, Filename, Filetype ( the textfields 
above ) you can inject those with the given variables. Same is true for 
postExport.


> Sorry for my MEL newb-ness...

HAH, my revenge will be TERRIFFIC ... when we come to the point that 
I'll require osg help ... Javier, this revenge will include you as well 
!!! ;-)

Cheers, PP

Re: [Maya2osg-users] Discussion of next changes

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

Hi Peter,

> Yes, I noticed something like this error message as well, but the
> problem is that it is not allways. E.g if you just change the filename,
> then the error goes away ... maybe. Unfortunatelly You cannot step into
> melcode, at least I don't know how, so its kind of hard to debug. But
> will take some time to look into this.

If you can, thanks.

> Nope, so what I am doing there is just a demonstration what happens with
> $path, $file and $type. "preExp" is nothing, but a possible command that
> you could trigger in there, when you would define it. So I just print
> out the concatenated command string.

But why does that print("...") result in this error:

// Error: Too many arguments.  Expected 0, found 1. //

I find that weird.

Thanks,

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

Re: [Maya2osg-users] Discussion of next changes

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

Hi J-S,

> But why does that print("...") result in this error:
>
> // Error: Too many arguments.  Expected 0, found 1. //
>
> I find that weird.
>

In fact it doesn't. What the entry in the preExport does is conctatenate 
the file fields above and put the preExp infront. And this is also the 
result, wehn you check the script editor. The path-file-extension gets 
printed properly, but after that there some more issues. I think this is 
realted to something dieffernt. When one starts the UI for the first 
time certain Maya Variables are set, and I think I screw something up in 
this process. If you use it for the next time, everything goes right, it 
seems to be the initial set up. As said will check it.

But you detected another error in your message before, this one I get 
now as well
"Line 0.45: Unterminated string." There really seems to be an issue with 
the space before the second ". Will check that as well.

Cheers, PP

Re: [Maya2osg-users] Discussion of next changes

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

Hi,

all Issues fixed, detailed notes in Repo Log.

Cheers, PP
> Hi guys,
>
> I've started looking at what you've done Peter for the pre/post-export
> script, it's cool that it's a MEL command. Is it possible from this
> field to call a function in a separate MEL script? Say I have a function
> called doPreExportStuff() in a file called preExport.mel, can I do
> something like (pseudocode)
>
> loadMEL("preExport.mel"); doPreExportStuff();
>
> ?
>
> If so that should be fine.
>
> Second, I am getting an error when I click Export and the pre-export
> script field contains the default thing you put there (print( "preExp
> $path$file.$type " ) ;)  First of all there seemed to be a newline
> character in there at the end, because it would say:
>
> print( "preExp
> C:/Users/jeang/Documents/maya/projects/default/scenesbox_normalmap_maya2osg.osg
>
> " ) ;
> // Error:  //
> // Error: Unterminated string. //
>
> So just before the closing quote there seems to be a newline. Then when
> I removed the newline, I got this:
>
> print( "preExp
> C:/Users/jeang/Documents/maya/projects/default/scenesbox_normalmap_maya2osg.osg"
> ) ;
> preExp
> C:/Users/jeang/Documents/maya/projects/default/scenesbox_normalmap_maya2osg.osg
> // Error: Too many arguments.  Expected 0, found 1. //
>
> Is the print("preExp ...") supposed to call a function called preExp?
> The error is because this function does not exist? Or is it something else?
>
> Sorry for my MEL newb-ness...
>
> The other two examples (post-export exec( "osgviewer cow.osg" ) and
> preview exec( "osgviewer $file" ) work fine. They're great additions.
> Thanks.
>
> Thanks in advance,
>
> J-S

Re: [Maya2osg-users] Discussion of next changes

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

Hi, was too busy the last days, and I see the discussion is already much 
further, but just wanted to clarify what I meant at this point here.

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

So, yes, we can add a String Attribute to a Maya Node, maya2osg would 
search for it, and add its contrent to the apropriate osg description. 
It should be only one, as generic as possible. When you add such an 
Attribute, its a one liner in the Attribute Editor. If you wanna add 
multiple Values like, you need to do itsimilar to this way:
strength(value);offset(value);falloff(value);rad(value);

Thats ... wel unconfortable, isnt't it ? But we could creat a UI which 
can create such an attribute for a selected node, and list its contetn 
in a nice way, as big editable textfield. That would be a solution, but 
needs to be created and added to the plug-in source. And its an extra UI 
which an artist needs to get confortable with. But Attributes, Labels, 
Tags, etc. could be layout nicely. ANd that is what I meant with an 
additional window.

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

I saw that you committed some mel code, while I was looking into the 
problem :-) is it fixed ? I guess so, but I wonder about the command 
osgpreview found in maya2osg_preview. Can't find it anywhere, is it part 
of the plug-in ? Haven't build your submission yet.

Cheers, PP

Re: [Maya2osg-users] Discussion of next changes

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

  Hi,

On Wed, May 18, 2011 at 10:37 PM, Peter Wrobel <pp...@cg...> wrote:
> So, yes, we can add a String Attribute to a Maya Node, maya2osg would
> search for it, and add its contrent to the apropriate osg description.
> It should be only one, as generic as possible. When you add such an
> Attribute, its a one liner in the Attribute Editor. If you wanna add
> multiple Values like, you need to do itsimilar to this way:
> strength(value);offset(value);falloff(value);rad(value);
>
> Thats ... wel unconfortable, isnt't it ? But we could creat a UI which
> can create such an attribute for a selected node, and list its contetn
> in a nice way, as big editable textfield. That would be a solution, but
> needs to be created and added to the plug-in source. And its an extra UI
> which an artist needs to get confortable with. But Attributes, Labels,
> Tags, etc. could be layout nicely. ANd that is what I meant with an
> additional window.

  OK. You're the Maya UI master, so this is all yours. Certainly it
sounds good :)

> I saw that you committed some mel code, while I was looking into the
> problem :-) is it fixed ? I guess so, but I wonder about the command

  Not completely. There are still several pending problems. I
described some of them in other messages.

> osgpreview found in maya2osg_preview. Can't find it anywhere, is it part
> of the plug-in ? Haven't build your submission yet.

  Yes, it is a new MEL command defined in the plug-in. The syntax is
pretty like osgviewer. I also explained that in other message.


-- 
Javier Taibo

Re: [Maya2osg-users] Discussion of next changes

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

Hello Peter, Javier,

> So, yes, we can add a String Attribute to a Maya Node, maya2osg would
> search for it, and add its contrent to the apropriate osg description.
> It should be only one, as generic as possible. When you add such an
> Attribute, its a one liner in the Attribute Editor. If you wanna add
> multiple Values like, you need to do itsimilar to this way:
> strength(value);offset(value);falloff(value);rad(value);

Where will I see these attributes in Maya? Are they already exported in 
the OSG node descriptions? If not, how do I access them in the C++ 
plugin code to export them?

Also, I see on various (all?) Maya objects there is a Notes field at the 
bottom of the property editor. Perhaps special things could be added 
there, and that should be exported in the OSG node descriptions too?

Thanks in advance,

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