maya2osg-users

Re: [Maya2osg-users] Discussion of next changes

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

  Hi,

On Thu, May 19, 2011 at 4:22 PM, Jean-Sébastien Guay
<jea...@cm...> 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);
>
> 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?

  If you mean new attributes you create, they appear in the "Extra
Attributes" section in the Attribute Editor.

  You can create them from the Attribute Editor in the menu option
Attributes > Add Attributes or from MEL with addAttr (and then modify
its properties with setAttr). Example:

addAttr -ln "myattr"  -at double  |pSphere1|pSphereShape1;
setAttr -e-keyable true |pSphere1|pSphereShape1.myattr;

  You can access them from C++ through the MDependencyNode interface.
All attributes can be accessed in the C++ API as plugs (see MFnPlug).
There are several places in the plug-in where it is done currently.

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

  This is the generic description Peter was talking about, but I see
cleaner to use a custom string attribute for writing OSG descriptions
in it, because the Notes can be already used by the artists or the
scenes you are working with, and that could introduce confusion or be
a source of problems. What do you think?


-- 
Javier Taibo

Re: [Maya2osg-users] Discussion of next changes

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

Hi, one observation from my side ...


>> 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?
>    This is the generic description Peter was talking about, but I see
> cleaner to use a custom string attribute for writing OSG descriptions
> in it, because the Notes can be already used by the artists or the
> scenes you are working with, and that could introduce confusion or be
> a source of problems. What do you think?
>

I notice two camps of interest, but you can proof me wrong. Javier, you 
don't like cluttering the notes field, J-S wants to use as much of maya 
as is available, includeing the notes field, and me, I'd prefere the 
notes field as well.

What about giving both the options, so the user of the plug-In can 
decide. The ovehead for the plug-in should be minimal:

Search for attribute osgDescription, if found put its content into 
corresponding osg::Node
Parse the notes field for <osgDescription> ... </osgDescription>, add 
all content between the Keywords to corresponding osg::Node

All of us would be sattisfied, and Javier, I promise you I'll create a 
beautiful UI for you :-)

What do you guys think about that ?

Cheers, PP

Re: [Maya2osg-users] Discussion of next changes

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

  Hi guys,

  If both of you prefer the Notes field, I'm fine with that. I don't
think necessary to let configurable all possible options always to
keep all of us happy  :)

  Let's go ahead then with the Notes field. Certainly it has the
advantage that it is quite visible and easy to edit. If you encode the
osg description between the <osgDescription> ... </osgDescription>
tags it can coexist with previous (or later) notes.

  In conclusion, forget about the custom field and let's focus our
efforts in more productive features.


  Regards,


On Thu, May 19, 2011 at 6:48 PM, Peter Wrobel <pp...@cg...> wrote:
> Hi, one observation from my side ...
>
>
>>> 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?
>>    This is the generic description Peter was talking about, but I see
>> cleaner to use a custom string attribute for writing OSG descriptions
>> in it, because the Notes can be already used by the artists or the
>> scenes you are working with, and that could introduce confusion or be
>> a source of problems. What do you think?
>>
>
> I notice two camps of interest, but you can proof me wrong. Javier, you
> don't like cluttering the notes field, J-S wants to use as much of maya
> as is available, includeing the notes field, and me, I'd prefere the
> notes field as well.
>
> What about giving both the options, so the user of the plug-In can
> decide. The ovehead for the plug-in should be minimal:
>
> Search for attribute osgDescription, if found put its content into
> corresponding osg::Node
> Parse the notes field for <osgDescription> ... </osgDescription>, add
> all content between the Keywords to corresponding osg::Node
>
> All of us would be sattisfied, and Javier, I promise you I'll create a
> beautiful UI for you :-)
>
> What do you guys think about that ?
>
> Cheers, PP
>
> ------------------------------------------------------------------------------
> What Every C/C++ and Fortran developer Should Know!
> Read this article and learn how Intel has extended the reach of its
> next-generation tools to help Windows* and Linux* C/C++ and Fortran
> developers boost performance applications - including clusters.
> http://p.sf.net/sfu/intel-dev2devmay
> _______________________________________________
> Maya2osg-users mailing list
> May...@li...
> https://lists.sourceforge.net/lists/listinfo/maya2osg-users
>



-- 
Javier Taibo

Re: [Maya2osg-users] Discussion of next changes

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

Hi guys,

> I notice two camps of interest, but you can proof me wrong. Javier, you
> don't like cluttering the notes field, J-S wants to use as much of maya
> as is available, includeing the notes field, and me, I'd prefere the
> notes field as well.

I think notes is OK, because the things that would be added are clearly 
marked. So the exporter won't touch anything that's not between (as you 
suggest, but could be something else) <osgDescription> ... 
</osgDescription> tags.

In fact, all this started with the fact that Javier doesn't want to 
populate the node descriptions with material properties in the plugin's 
C++ code, so wherever we put it, it will be user-visible. If we could do 
this in the C++ code, it would be transparent to the Maya user (we 
wouldn't clutter the notes, and we wouldn't need attributes, but we 
could also export them if we want to).

I see these things as totally orthogonal. The Maya scene already has all 
the information to put the material properties in the node descriptions, 
so why require that they be put in the notes or an attribute at all? On 
the other hand, if the artist has put notes or attributes, these could 
be part of the exported file as well, nothing prevents that.

What do you think?

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

On Thu, May 19, 2011 at 7:42 PM, Jean-Sébastien Guay
<jea...@cm...> wrote:
> Hi guys,
>
>> I notice two camps of interest, but you can proof me wrong. Javier, you
>> don't like cluttering the notes field, J-S wants to use as much of maya
>> as is available, includeing the notes field, and me, I'd prefere the
>> notes field as well.
>
> I think notes is OK, because the things that would be added are clearly
> marked. So the exporter won't touch anything that's not between (as you
> suggest, but could be something else) <osgDescription> ...
> </osgDescription> tags.
>
> In fact, all this started with the fact that Javier doesn't want to
> populate the node descriptions with material properties in the plugin's
> C++ code, so wherever we put it, it will be user-visible. If we could do
> this in the C++ code, it would be transparent to the Maya user (we
> wouldn't clutter the notes, and we wouldn't need attributes, but we
> could also export them if we want to).

  The problem I see in doing it in the C++ code is that the number of
attributes that you can add is virtually unlimited. What attributes do
you need? Are you sure? And tomorrow? And what attributes will need
other users? This could be a huge big amount of code that will be
dragged by the plug-in.

  My opinion is that this overhead (and with overhead here I am not
talking only about performance) should be on the user side (not the
plug-in) so users can add all the attributes they need and only that.
Each user customize its own installation without affecting others.

  You say that need the material properties, but what properties are
you talking about? Some of the properties you want are not in the
material node, but in other nodes such as bump2D, and just as this
one, there can be a lot of nodes composing a huge and really complex
shading network. What subset of attributes do you need? or what
specific cases of shading networks are you going to support? And other
users?

  I don't know if we are understanding each other. My point is that
you cannot add support for every attribute and attribute combination
possible, and each user will have its own needs structured in its own
way, maybe incompatible among them and doesn't seem to be a good place
to implement that kind of thing the plug-in C++ code. Implementing it
in the Maya user side (through MEL scripts, customizations, or
whatever) and passing it to OSG descriptions with a generic mechanism
or using it in some other way will cover every user need without
bothering the others and without increasing complexity and size of the
plug-in code.

  Maybe we are talking about different things. Can you post an example
of exactly what you are proposing?

> I see these things as totally orthogonal. The Maya scene already has all
> the information to put the material properties in the node descriptions,

  Are you sure? Please, post a real example of the information you
want to retrieve from the Maya scene and where do you read it and
where do you want to write it.

> so why require that they be put in the notes or an attribute at all? On

  The reason to put it in the notes is to have a transparent way of
specifying whatever you can send and to what OSG node exactly.


-- 
Javier Taibo

Re: [Maya2osg-users] Discussion of next changes

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

Hello Javier,

>    I don't know if we are understanding each other. My point is that
> you cannot add support for every attribute and attribute combination
> possible, and each user will have its own needs structured in its own
> way, maybe incompatible among them and doesn't seem to be a good place
> to implement that kind of thing the plug-in C++ code.

I understand your point, but I don't see an unlimited amount of 
attributes. Essentially, there are a fixed number of things that will be 
useful to users once the scene is exported. I will have mine and others 
will have theirs which might not be the same set, sure, but once they 
are done they are done.

I see it as the role of the plugin to specify what it exports (at least 
a base set). If the user wants more than that, sure he can write a 
pre-export script to get out other things, but the basic set should be 
fairly complete. If you don't agree with this point then I guess I'll 
just write a pre-export script, so I just need to add code to maya2osg 
that will export notes into OSG node descriptions and we'll be done.

>    Are you sure? Please, post a real example of the information you
> want to retrieve from the Maya scene and where do you read it and
> where do you want to write it.

For example, for a material (say a Blinn/Phong), the osg::Material 
already contains the diffuse color, specular color, shininess, etc. Plus 
there is a diffuse texture in the same StateSet as the Material.

But if the user attached a texture to the bump attribute, I would need 
the filename of the texture, the amount of bump it contributes, and the 
coordinate space it is used in (bump = object space, normal = tangent 
space generally).

Likewise, if the user attached a texture to the specular attribute, 
that's a specular map, and we could export again the texture and the 
amount of contribution.

Since the exported information contains these different types of maps, I 
don't see any harm in putting the diffuse texture there either, just for 
completeness.

So I would add to the OSG node description this kind of string:

<maya2osg_material>
Material_name Diffuse <filename> <amount>
Material_name Normal <filename> <amount> <coordinate space>
Material_name Specular <filename> <amount>
</maya2osg_material>

or more concretely:

<maya2osg_material>
Ship_hull Diffuse textures/ship_hull_d.jpg 100
Ship_hull Normal textures/ship_hull_n.jpg 100 tangent
Ship_hull Specular textures/ship_hull_s.jpg 30
</maya2osg_material>

I would prefer this kind of string never be visible / editable by the 
user, since it's already specified by the Maya material. Putting it in 2 
places (and one which the user could just delete if they're not paying 
attention) is asking for trouble.

In general, artists are not programmers, they have their own workflow 
and if they build their scene in Maya so that it looks like they want, 
then the exporter should export that correctly without needing other 
operations / scripts.

For comparison, here's what was recently added to the 3DSMax exporter 
(OSGExp) to do the same thing:

---------------------------------------------------------------------
I've just committed support for the material description strings. Each 
material will have its own description string added to the root node. 
Here is a sample description:

# osgmaxexp material data
Name	Basketball
Map	Diffuse	0	1	images\bball_diffuse.jpg
Map	Bump	1	0.3	images\bball_normal.jpg	
---------------------------------------------------------------------

(the separator they chose is tab)

I think something similar would work. The only remaining point really is 
whether the plugin creates this string or a pre-export script does.

>    The reason to put it in the notes is to have a transparent way of
> specifying whatever you can send and to what OSG node exactly.

As I said, exporting notes is fine and IMHO is orthogonal to exporting 
attributes in the scene. If the artist put notes in the notes field in 
Maya, they should be exported as OSG node descriptions. This does not 
affect the discussion above. Rather, if exporting notes is added to the 
plugin, and we decide that what I want above will be done by a 
pre-export script that adds text to the notes, then we are done and I 
can start using it immediately.

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 Fri, May 20, 2011 at 1:31 PM, Jean-Sébastien Guay
<jea...@cm...> wrote:
>
>>    I don't know if we are understanding each other. My point is that
>> you cannot add support for every attribute and attribute combination
>> possible, and each user will have its own needs structured in its own
>> way, maybe incompatible among them and doesn't seem to be a good place
>> to implement that kind of thing the plug-in C++ code.
>
> I understand your point, but I don't see an unlimited amount of
> attributes. Essentially, there are a fixed number of things that will be
> useful to users once the scene is exported. I will have mine and others
> will have theirs which might not be the same set, sure, but once they
> are done they are done.

  I don't agree here. I think that with this reasoning there is an
unlimited amount of attributes.

> I see it as the role of the plugin to specify what it exports (at least
> a base set). If the user wants more than that, sure he can write a
> pre-export script to get out other things, but the basic set should be
> fairly complete. If you don't agree with this point then I guess I'll

  OK. Let's define this basic set then.

> just write a pre-export script, so I just need to add code to maya2osg
> that will export notes into OSG node descriptions and we'll be done.
>
>>    Are you sure? Please, post a real example of the information you
>> want to retrieve from the Maya scene and where do you read it and
>> where do you want to write it.
>
> For example, for a material (say a Blinn/Phong), the osg::Material
> already contains the diffuse color, specular color, shininess, etc. Plus
> there is a diffuse texture in the same StateSet as the Material.

  One question: is all this discussion limited to Material attributes
or are we talking about every kind of Maya node?

> But if the user attached a texture to the bump attribute, I would need
> the filename of the texture, the amount of bump it contributes, and the
> coordinate space it is used in (bump = object space, normal = tangent
> space generally).

  What if the user instead of a texture connected to the bump2D has a
more complex shading network (e.g. combining several textures and
other utility nodes)? You just ignore these cases and define a set
that is supported, I presume. But maybe other user needs it. This is
where I see a complicated situation to reach all the needs that can
raise, that are very user-specific. And this is why I see a virtually
unlimited set of attributes to export.

> Likewise, if the user attached a texture to the specular attribute,
> that's a specular map, and we could export again the texture and the
> amount of contribution.
>
> Since the exported information contains these different types of maps, I
> don't see any harm in putting the diffuse texture there either, just for
> completeness.
>
> So I would add to the OSG node description this kind of string:
>
> <maya2osg_material>
> Material_name Diffuse <filename> <amount>
> Material_name Normal <filename> <amount> <coordinate space>
> Material_name Specular <filename> <amount>
> </maya2osg_material>
>
> or more concretely:
>
> <maya2osg_material>
> Ship_hull Diffuse textures/ship_hull_d.jpg 100
> Ship_hull Normal textures/ship_hull_n.jpg 100 tangent
> Ship_hull Specular textures/ship_hull_s.jpg 30
> </maya2osg_material>
>
> I would prefer this kind of string never be visible / editable by the
> user, since it's already specified by the Maya material. Putting it in 2
> places (and one which the user could just delete if they're not paying
> attention) is asking for trouble.

  We absolutely agree in this point. I'll never say the contrary.
Artists should not be able to touch anything more than the minimum
necessary. It wasn't at any time what I was defending. The logic we
are talking about, be it on the C++ code or in MEL scripts, is
responsibility of the programmers and should automate the process to
the artist.

> In general, artists are not programmers, they have their own workflow
> and if they build their scene in Maya so that it looks like they want,
> then the exporter should export that correctly without needing other
> operations / scripts.
>
> For comparison, here's what was recently added to the 3DSMax exporter
> (OSGExp) to do the same thing:
>
> ---------------------------------------------------------------------
> I've just committed support for the material description strings. Each
> material will have its own description string added to the root node.
> Here is a sample description:
>
> # osgmaxexp material data
> Name    Basketball
> Map     Diffuse 0       1       images\bball_diffuse.jpg
> Map     Bump    1       0.3     images\bball_normal.jpg
> ---------------------------------------------------------------------
>
> (the separator they chose is tab)
>
> I think something similar would work. The only remaining point really is
> whether the plugin creates this string or a pre-export script does.
>
>>    The reason to put it in the notes is to have a transparent way of
>> specifying whatever you can send and to what OSG node exactly.
>
> As I said, exporting notes is fine and IMHO is orthogonal to exporting
> attributes in the scene. If the artist put notes in the notes field in
> Maya, they should be exported as OSG node descriptions. This does not
> affect the discussion above. Rather, if exporting notes is added to the
> plugin, and we decide that what I want above will be done by a
> pre-export script that adds text to the notes, then we are done and I
> can start using it immediately.

  OK. I let you take the decission. I think our opinions are clear
right now. If you want to define a basic set of "autoexported"
attributes, it is OK. I have only two requests: to have one config
parameter (export option) to enable/disable this feature and to
document the process and the exported attributes in a wiki page.


  Regards,

-- 
Javier Taibo

Re: [Maya2osg-users] Discussion of next changes

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

Hi Javier,

Sorry for the length of time I took to answer, I've been busy training a 
new employee (we're now a team of 2 graphics programmers at my company, 
after being the only one for over 3.5 years).

>    One question: is all this discussion limited to Material attributes
> or are we talking about every kind of Maya node?

In my case, it is limited to materials. As you said it may not be true 
for others, and it may not be true in the long run, but I believe in 
incremental implementation. :-)

>    What if the user instead of a texture connected to the bump2D has a
> more complex shading network (e.g. combining several textures and
> other utility nodes)? You just ignore these cases and define a set
> that is supported, I presume. But maybe other user needs it. This is
> where I see a complicated situation to reach all the needs that can
> raise, that are very user-specific. And this is why I see a virtually
> unlimited set of attributes to export.

I am really thinking only of what is useful right now in real-time 
rendering. But yes, this is not totally obvious to users, just to me. I 
don't think anyone will need to export a file that has a complex shader 
network with procedural textures and I don't know what else, simply 
because it is obvious to me that the final file will be used in an OSG 
program, and therefore we can't do everything a user making a model for 
offline rendering for film use would expect...

Just a few basic things that are not supported by the fixed pipeline and 
most general file formats, but that we want to use in our engine.

>> I would prefer this kind of string never be visible / editable by the
>> user, since it's already specified by the Maya material. Putting it in 2
>> places (and one which the user could just delete if they're not paying
>> attention) is asking for trouble.
>
>    We absolutely agree in this point. I'll never say the contrary.
> Artists should not be able to touch anything more than the minimum
> necessary. It wasn't at any time what I was defending. The logic we
> are talking about, be it on the C++ code or in MEL scripts, is
> responsibility of the programmers and should automate the process to
> the artist.

But your suggested solution was to have a script that would place 
strings either in the Notes on a Maya node, or in a custom attribute. 
Both of these are user-visible in Maya, are they not?

My point in doing it in the C++ code was that it's a (mostly) one-way 
layer between Maya and the .osg file you export. Thus, anything created 
in the C++ code will never be visible to the Maya user. If you have a 
way of doing the same thing from script, then I have no argument 
anymore. I'll do it in script, because I agree with all your other 
points (the set of things to export being different for everyone, the 
ease of doing it in script instead of in C++, etc.)

I just don't want it to be in Notes or something like that, because then 
the user can edit it / break it.

Sorry for being difficult on this...

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,

On Wed, May 25, 2011 at 8:34 PM, Jean-Sébastien Guay
<jea...@cm...> wrote:
> Sorry for the length of time I took to answer, I've been busy training a

  Don't worry about that. We all have jobs and family and... even a
life outside OSG!  :)

> new employee (we're now a team of 2 graphics programmers at my company,
> after being the only one for over 3.5 years).

  I know what you're talking about. It's quite time consuming.
Especially in this case that you have doubled the team :)

>>    What if the user instead of a texture connected to the bump2D has a
>> more complex shading network (e.g. combining several textures and
>> other utility nodes)? You just ignore these cases and define a set
>> that is supported, I presume. But maybe other user needs it. This is
>> where I see a complicated situation to reach all the needs that can
>> raise, that are very user-specific. And this is why I see a virtually
>> unlimited set of attributes to export.
>
> I am really thinking only of what is useful right now in real-time
> rendering. But yes, this is not totally obvious to users, just to me. I
> don't think anyone will need to export a file that has a complex shader
> network with procedural textures and I don't know what else, simply
> because it is obvious to me that the final file will be used in an OSG
> program, and therefore we can't do everything a user making a model for
> offline rendering for film use would expect...
>
> Just a few basic things that are not supported by the fixed pipeline and
> most general file formats, but that we want to use in our engine.


>>> I would prefer this kind of string never be visible / editable by the
>>> user, since it's already specified by the Maya material. Putting it in 2
>>> places (and one which the user could just delete if they're not paying
>>> attention) is asking for trouble.
>>
>>    We absolutely agree in this point. I'll never say the contrary.
>> Artists should not be able to touch anything more than the minimum
>> necessary. It wasn't at any time what I was defending. The logic we
>> are talking about, be it on the C++ code or in MEL scripts, is
>> responsibility of the programmers and should automate the process to
>> the artist.
>
> But your suggested solution was to have a script that would place
> strings either in the Notes on a Maya node, or in a custom attribute.
> Both of these are user-visible in Maya, are they not?

  You can create the attributes editable or visible as you need. This
avoid users to touch them, even see them (though seeing them should be
useful for debugging, and artists still can't break anything)

> My point in doing it in the C++ code was that it's a (mostly) one-way
> layer between Maya and the .osg file you export. Thus, anything created
> in the C++ code will never be visible to the Maya user. If you have a
> way of doing the same thing from script, then I have no argument
> anymore. I'll do it in script, because I agree with all your other
> points (the set of things to export being different for everyone, the
> ease of doing it in script instead of in C++, etc.)

  I am wondering... is the way you export materials and treat them in
your engine incompatible with Maya2OSG exported GLSL shaders?

  This part of GLSL export is a work in progress, so it is being
modified. I even don't know how to do some things. There are some
tradeoffs between flexibility and efficiency I have in my TO-DO list.


> I just don't want it to be in Notes or something like that, because then
> the user can edit it / break it.

  That seems reasonable. I didn't like to have it there also. I
disagree there with Peter.

> Sorry for being difficult on this...

  Don't worry. difficulties is where the fun is  ;)



-- 
Javier Taibo

Re: [Maya2osg-users] Discussion of next changes

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

Hi all,

now I am confused ... @J-S, I thought, that this is what you wanted ? :

1.) Collect Maya Shading Attributes as far as possible through the plug-in
2.) Add any ( un ) imaginable Attributes as Tags added as maya notes 
into osg::Node Descriptions

@Javier, in the end I don't care as well, any string attribute should be 
as good as the notes field.
Anyway, the phase of implementing and testing this feature will surely 
show the "right" way :-)

  Cheers, PP
> On Wed, May 25, 2011 at 8:34 PM, Jean-Sébastien Guay
> <jea...@cm...>  wrote:
>> Sorry for the length of time I took to answer, I've been busy training a
>    Don't worry about that. We all have jobs and family and... even a
> life outside OSG!  :)
>
>> new employee (we're now a team of 2 graphics programmers at my company,
>> after being the only one for over 3.5 years).
>    I know what you're talking about. It's quite time consuming.
> Especially in this case that you have doubled the team :)
>
>>>     What if the user instead of a texture connected to the bump2D has a
>>> more complex shading network (e.g. combining several textures and
>>> other utility nodes)? You just ignore these cases and define a set
>>> that is supported, I presume. But maybe other user needs it. This is
>>> where I see a complicated situation to reach all the needs that can
>>> raise, that are very user-specific. And this is why I see a virtually
>>> unlimited set of attributes to export.
>> I am really thinking only of what is useful right now in real-time
>> rendering. But yes, this is not totally obvious to users, just to me. I
>> don't think anyone will need to export a file that has a complex shader
>> network with procedural textures and I don't know what else, simply
>> because it is obvious to me that the final file will be used in an OSG
>> program, and therefore we can't do everything a user making a model for
>> offline rendering for film use would expect...
>>
>> Just a few basic things that are not supported by the fixed pipeline and
>> most general file formats, but that we want to use in our engine.
>
>>>> I would prefer this kind of string never be visible / editable by the
>>>> user, since it's already specified by the Maya material. Putting it in 2
>>>> places (and one which the user could just delete if they're not paying
>>>> attention) is asking for trouble.
>>>     We absolutely agree in this point. I'll never say the contrary.
>>> Artists should not be able to touch anything more than the minimum
>>> necessary. It wasn't at any time what I was defending. The logic we
>>> are talking about, be it on the C++ code or in MEL scripts, is
>>> responsibility of the programmers and should automate the process to
>>> the artist.
>> But your suggested solution was to have a script that would place
>> strings either in the Notes on a Maya node, or in a custom attribute.
>> Both of these are user-visible in Maya, are they not?
>    You can create the attributes editable or visible as you need. This
> avoid users to touch them, even see them (though seeing them should be
> useful for debugging, and artists still can't break anything)
>
>> My point in doing it in the C++ code was that it's a (mostly) one-way
>> layer between Maya and the .osg file you export. Thus, anything created
>> in the C++ code will never be visible to the Maya user. If you have a
>> way of doing the same thing from script, then I have no argument
>> anymore. I'll do it in script, because I agree with all your other
>> points (the set of things to export being different for everyone, the
>> ease of doing it in script instead of in C++, etc.)
>    I am wondering... is the way you export materials and treat them in
> your engine incompatible with Maya2OSG exported GLSL shaders?
>
>    This part of GLSL export is a work in progress, so it is being
> modified. I even don't know how to do some things. There are some
> tradeoffs between flexibility and efficiency I have in my TO-DO list.
>
>
>> I just don't want it to be in Notes or something like that, because then
>> the user can edit it / break it.
>    That seems reasonable. I didn't like to have it there also. I
> disagree there with Peter.
>
>> Sorry for being difficult on this...
>    Don't worry. difficulties is where the fun is  ;)
>
>
>

Re: [Maya2osg-users] Discussion of next changes

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

Hi Peter,

> 1.) Collect Maya Shading Attributes as far as possible through the plug-in
> 2.) Add any ( un ) imaginable Attributes as Tags added as maya notes
> into osg::Node Descriptions

I actually don't really care *how* it's done. I just don't want the tags 
to be visible by the Maya user.

I spoke about notes before because I thought I preferred notes to custom 
attributes, it seemed more general to me. But anything that's added to 
notes will be visible to the artist, and I don't want that.

However, I think that the notes should be exported in osg::Node 
descriptions, yes. But that is a separate issue.

What I want, really, is:

1. collect Maya shading attributes (any way)
2. put the information in osg::Node descriptions (any way)
3. this information should not be visible to Maya users

So if the easiest way is to

a) make a script that does 1, then puts it in custom attributes
b) modify the plugin C++ code so it exports custom attributes as 
osg::Node descriptions

then that's what I'll do.

> @Javier, in the end I don't care as well, any string attribute should be
> as good as the notes field.

I really don't see them as mutually exclusive. If the artist / modeler 
has put some useful information in the Notes field, then it should be 
exported in the OSG file as osg::Node descriptions. Custom attributes, I 
don't know exactly what they are (perhaps I should have a quick read in 
the Maya help files) but if they're just strings attached to a node, 
then they should probably be exported as osg::Node descriptions too. An 
osg::Node can have any number of descriptions, so one can be the Notes 
if it was not empty, and then each custom string attribute can be an 
additional one (with a clear tag to identify which is which).

I'll try to do something (proof of concept) today so that we can stop 
talking about it and do something about it :-)

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 Thu, May 26, 2011 at 3:27 PM, Jean-Sébastien Guay
<jea...@cm...> wrote:
> Hi Javier,
>
>>    You can create the attributes editable or visible as you need. This
>> avoid users to touch them, even see them (though seeing them should be
>> useful for debugging, and artists still can't break anything)
>
> OK, I'll have a look. Can you give me an example of how to create an
> attribute? Through scripting I assume... And then in Maya where will I
> see this attribute? And in the C++ plugin code?

  OK. Let's say you want to create new attributes to a node. First,
select the node. If it is a Maya material (e.g. lambert1), for
instance, and you have selected its tab in the Attribute Editor and
push the button "Select". This way you have selected the material node
and not the geometry you first selected.

  In the Attribute Editor menu, select "Attributes" > "Add Attribute".
This opens a dialog where you must select at least the attribute name
and the data type. The newly created attribute appears at the end in
the section "Extra Attributes".

  This is the manual way to create attributes. Now let's see how can
we make it from MEL.

  Open the Script Editor and take a look at the MEL attributes that
were called to create the attribute (addAttr and setAttr). This is a
good place to learn how things are done in MEL (apart from reading
documentation). If you want to see more verbosity go to the menu
"History" and check the option "Echo all commands", but for the
attribute creation, it shouldn't be necessary.

  If you want to hide the attribute, specify "-hidden" parameter to
"addAttr" and if you want to make it not editable, specify "-lock" to
setAttr. You can use getAttr to access the attribute values.

  For more information about addAttr, setAttr and getAttr syntax,
check the documentation (F1) at the end, in section "Technical
Documentation" -> "Commands".

  From C++ you can access the attributes with the plug interface (see
MPlug and MFnDependencyNode classes in C++ API documentation). You can
see several examples of this along the Maya2OSG code. For instance,
take a look at particle.cpp to see how attributes like "lifespan" are
accessed:

  MObject obj;  // this is the Maya node
  MFnDependencyNode dnodefn(obj);
  MStatus status;
  MPlug lifespan = dnodefn.findPlug("lifespan", &status);
  float ls = lifespan.asFloat();


  Hope that helps.

>>    I am wondering... is the way you export materials and treat them in
>> your engine incompatible with Maya2OSG exported GLSL shaders?
>
> Yes, we use our own shaders which do special things (for example, we use
> defines for number and types of lights, which allows us to do per-pixel
> lighting even on older cards). Also, we need to support various
> hardware, so we cannot guarantee that a given shader will always work
> for us, and so putting shaders in the .osg file directly is not a good
> idea for us.

  Yes, this is a difficult issue. Shaders are very system dependent.


  Regards.


-- 
Javier Taibo

Re: [Maya2osg-users] Discussion of next changes

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

Hi Javier,

>    Hope that helps.

Definitely! Thanks! I'll try to put something together in the next few 
days to show what I suggest.

>    Yes, this is a difficult issue. Shaders are very system dependent.

Agreed.

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 Fri, May 27, 2011 at 6:57 PM, Jean-Sébastien Guay
<jea...@cm...> wrote:
> I've added code to get the notes string from Maya nodes and put it as a
> description on the corresponding OSG node. I've also started writing
> code to export the custom attributes. It would be more general if I
> could export all types of custom attributes (within reason), but I can't
> find a way in the MPlug class to find out the type of the attribute
> (other than trying asString(), if that fails try asFloat(), if that
> fails ...). Do you know of a way?

  I don't know a way of querying the type of an attribute, sorry.

  However, I don't think that exporting all extra attributes is a good
idea. There are utilities that generate lots of attributes. I would
focus on the attributes defined by the exporter, maybe naming them
with a prefix to identify them (tough we can remove the prefix when
creating the OSG descriptions).

> Also, I see that the notes appear in the API as a custom attribute (and
> in the Maya UI when there's something in the Notes field it also shows
> up under "Extra Attributes", and disappears if you remove the text in
> the Notes field). I think I'll just export them all that way, as custom
> attributes, each attribute in a separate description string, with its
> name on the first line. That way, the notes will appear too and we'll
> have an easy way of knowing that this description contains whatever was
> in the Notes field. Any objections?

  I don't know if I am understanding you correctly. Is exporting all
"Extra attributes" what you are proposing? How do you identify what
attributes are "extra attributes", btw?

  About the "notes" field, yes I would export it like the other custom
attributes.


  Regards,

-- 
Javier Taibo

Re: [Maya2osg-users] Discussion of next changes

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

Hi Javier,

>    You can create the attributes editable or visible as you need. This
> avoid users to touch them, even see them (though seeing them should be
> useful for debugging, and artists still can't break anything)

OK, I'll have a look. Can you give me an example of how to create an 
attribute? Through scripting I assume... And then in Maya where will I 
see this attribute? And in the C++ plugin code?

>    I am wondering... is the way you export materials and treat them in
> your engine incompatible with Maya2OSG exported GLSL shaders?

Yes, we use our own shaders which do special things (for example, we use 
defines for number and types of lights, which allows us to do per-pixel 
lighting even on older cards). Also, we need to support various 
hardware, so we cannot guarantee that a given shader will always work 
for us, and so putting shaders in the .osg file directly is not a good 
idea for us.

So at load time, depending on the hardware on which the program runs, we 
will load the correct shaders, plus any additional textures needed 
(normal maps, specular maps, etc.)

Putting GLSL shaders in the exported .osg file might be fine for a 
certain pipeline, but it is not a general way of doing things, because 
shaders are very pipeline-specific. So if it works for you that's ok, 
but putting material parameters in descriptions will allow people who 
have a different pipeline to do things their way too.

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

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

Hi Javier,

I've added code to get the notes string from Maya nodes and put it as a 
description on the corresponding OSG node. I've also started writing 
code to export the custom attributes. It would be more general if I 
could export all types of custom attributes (within reason), but I can't 
find a way in the MPlug class to find out the type of the attribute 
(other than trying asString(), if that fails try asFloat(), if that 
fails ...). Do you know of a way?

Also, I see that the notes appear in the API as a custom attribute (and 
in the Maya UI when there's something in the Notes field it also shows 
up under "Extra Attributes", and disappears if you remove the text in 
the Notes field). I think I'll just export them all that way, as custom 
attributes, each attribute in a separate description string, with its 
name on the first line. That way, the notes will appear too and we'll 
have an easy way of knowing that this description contains whatever was 
in the Notes field. Any objections?

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

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

Hi Javier,

>    I don't know a way of querying the type of an attribute, sorry.

OK, I'll do it the hard way, it doesn't matter that much because it's 
not performance-critical code but I would have throught there was a 
way... It feels like I'm doing a series of dynamic_casts to find out the 
true concrete type of an object...

>    However, I don't think that exporting all extra attributes is a good
> idea. There are utilities that generate lots of attributes. I would
> focus on the attributes defined by the exporter, maybe naming them
> with a prefix to identify them (tough we can remove the prefix when
> creating the OSG descriptions).

A prefix is a good idea. I just don't want to have to hard-code 
attribute names in the plugin. But if I export any attribute that starts 
with say "maya2osg_" that would be ok, is that ok for you?

>    I don't know if I am understanding you correctly. Is exporting all
> "Extra attributes" what you are proposing? How do you identify what
> attributes are "extra attributes", btw?

 From an MFnDependencyNode, I can do:

unsigned int count = dnodefn.attributeCount();
for (unsigned int i = 0; i < count; ++i)
{
     MObject attr = dnodefn.attribute(i);
     MAttrClass attrClass = dnodefn.attributeClass(attr);
     if (attrClass == MFnDependencyNode::kLocalDynamicAttr)
     {
         // This is a custom attribute (i.e. not part of the normal list
         // of attributes for this type of node).
         // Also the notes attribute is one of these.
     }
}

So the MFnDependencyNode::MAttrClass enum gives the type of an attribute 
when iterating through all attributes of a node. kLocalDynamicAttr is 
documented as "Dynamically added, applies to this specific node." and I 
verified that when iterating through attributes of a node in a maya 
scene being exported, this was the class returned for custom attributes 
(added by addAttr or the Attributes menu) as well as the notes. Other 
attributes (there were almost 200 on the node I checked) did not have 
this class.

>    About the "notes" field, yes I would export it like the other custom
> attributes.

Great. 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 Sun, May 29, 2011 at 5:15 AM, Jean-Sébastien Guay
<jea...@cm...> wrote:
>
> OK, I'll do it the hard way, it doesn't matter that much because it's
> not performance-critical code but I would have throught there was a
> way... It feels like I'm doing a series of dynamic_casts to find out the
> true concrete type of an object...

  It *should* be a way. Maybe it is. But I don't know it.

>>    However, I don't think that exporting all extra attributes is a good
>> idea. There are utilities that generate lots of attributes. I would
>> focus on the attributes defined by the exporter, maybe naming them
>> with a prefix to identify them (tough we can remove the prefix when
>> creating the OSG descriptions).
>
> A prefix is a good idea. I just don't want to have to hard-code
> attribute names in the plugin. But if I export any attribute that starts
> with say "maya2osg_" that would be ok, is that ok for you?

  Perfect!

>>    I don't know if I am understanding you correctly. Is exporting all
>> "Extra attributes" what you are proposing? How do you identify what
>> attributes are "extra attributes", btw?
>
>  From an MFnDependencyNode, I can do:
>
> unsigned int count = dnodefn.attributeCount();
> for (unsigned int i = 0; i < count; ++i)
> {
>     MObject attr = dnodefn.attribute(i);
>     MAttrClass attrClass = dnodefn.attributeClass(attr);
>     if (attrClass == MFnDependencyNode::kLocalDynamicAttr)
>     {
>         // This is a custom attribute (i.e. not part of the normal list
>         // of attributes for this type of node).
>         // Also the notes attribute is one of these.
>     }
> }
>
> So the MFnDependencyNode::MAttrClass enum gives the type of an attribute
> when iterating through all attributes of a node. kLocalDynamicAttr is
> documented as "Dynamically added, applies to this specific node." and I
> verified that when iterating through attributes of a node in a maya
> scene being exported, this was the class returned for custom attributes
> (added by addAttr or the Attributes menu) as well as the notes. Other
> attributes (there were almost 200 on the node I checked) did not have
> this class.

  Interesting. I didn't know that. Quite useful.


  Regards,

-- 
Javier Taibo