maya2osg-users — Maya2OSG mailing list

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 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] Customized GLSL shaders

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

  Hi Peter,

On Fri, May 27, 2011 at 9:25 PM, Peter Wrobel <pp...@cg...> wrote:
>>    What are you editing CMake for?
>>
>
> I added a mel script called maya2osg_utility mel, and want to make sure
> that it gets installed like the other scripts.

  Don't worry then. Just throw it in the "scripts· directory where the
other mel scripts lie and as long as it has ".mel" extension it will
be installed.

> Cool, fist thing I will do in my holidays is learning the wiki, there is
> a lot of information that I am still not aware of. Its well enoght
> explained, and a cool concept. Do you still plan to give the option of
> completetly overwriting a shader ?

  I never said that. If you want to completely replace the shader,
then you should follow the J-S approach. What I said was to override
parts of the shader because the new code is added after the default
one. That means that if you assign a value to a variable that is
already assigned, this last value is what will remain.

> I really should write something about the polygon export too ...

  Nice. It's first on my to-do list to take a look at it and begin
with blend shapes export, but I didn't have time yet. Maybe next week,
but I don't know, it's going to be a bit intense.


  Regards,

-- 
Javier Taibo

Re: [Maya2osg-users] Customized GLSL shaders

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

Hi Javier,
>    If you didn't change it in revision 202, then svn is lying  :)


Yeeees, caught in the act, I was lying big time :-) nope, sorry, serach 
and replace was my doom ! Will fix it right away.

>
>    What are you editing CMake for?
>

I added a mel script called maya2osg_utility mel, and want to make sure 
that it gets installed like the other scripts.
But if CMake is so sensitive it might be better to ask you for these 
things.

>    Careful! Some of these are CMake scripts and others are generated by
> CMake (you can delete it without problem, and they are not in svn).
> Probably you only would need to edit the CMakeLists.txt file in the
> Maya2OSG root directory. Some of these files are for the Windows
> installer contributed by Ryan Pavlik in the osg-users mailing list.
> See this page:
>
>    https://sourceforge.net/apps/mediawiki/maya2osg/index.php?title=Windows_installer


Hm, for that purpose I downloaded the svn in a new  folder and searched 
all the files for entry of the maya2osg_scripts.
I read the wiki but still not sure what I need to edit. Could you tell 
me once so I know for feature please ?

>    Right, I tried to explain it in this page:
>
>    https://sourceforge.net/apps/mediawiki/maya2osg/index.php?title=Shading_Networks#Custom_GLSL_code
>
>    If you don't find it clear or want to add something, feel free to edit it.

Cool, fist thing I will do in my holidays is learning the wiki, there is 
a lot of information that I am still not aware of. Its well enoght 
explained, and a cool concept. Do you still plan to give the option of 
completetly overwriting a shader ?
I really should write something about the polygon export too ...

>> In an earlier mail you mentioned that the injection happens if ALL the
>> textfields do specify a file, is this correct ?
>> Is there in no case, where one wants to just overwrite the Fragment
>> color, without the need for any other ( Declare / Compute ) requirement ?
>    No, no, no... I didn't say anything like that. Once you enable the
> "custom code" check box, then the fields that have any valid content
> will be used, the others will be simply ignored. If you don't pass any
> of these options to Maya2OSG, it just ignores the corresponding piece
> of code (doesn't remember the last value as other options).
>

Missunderstood you here, but this is the behaviour I would expect.

Cheers, PP

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] Customized GLSL shaders

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

  Hi Peter

On Fri, May 27, 2011 at 9:07 AM, Peter Wrobel <pp...@cg...> wrote:
>>> The shader code does not end up in the osg file. Don't know what I'm
>>> doing wrong.
>>    You're passing the wrong options to the plug-in. Unless you have
>> renamed them in osgwrite.cpp and not committed the changes.
>
>
> Till now I only changed UI element names and envVars, but I kept the
> flags that are send to the plug-in untouched, so this shouldn't be the
> issue.

  See this code snippet:

	if ( `optionVar -query "maya2osg_custom_shader_code"` ) {
		if ( `optionVar -query "maya2osg_glsl_vert_declare"` != "" ) {
			$command += " -additionalVertexdeclare \"" + `optionVar -query
"maya2osg_glsl_vert_declare"` + "\"\n";
		}
		if ( `optionVar -query "maya2osg_glsl_vert_compute"` != "" ) {
			$command += " -additionalVertexCode \"" + `optionVar -query
"maya2osg_glsl_vert_compute"` + "\"\n";
		}
		if ( `optionVar -query "maya2osg_glsl_frag_declare"` != "" ) {
			$command += " -additionalFragmentdeclare \"" + `optionVar -query
"maya2osg_glsl_frag_declare"` + "\"\n";
		}
		if ( `optionVar -query "maya2osg_glsl_frag_compute"` != "" ) {
			$command += " -additionalFragmentCode \"" + `optionVar -query
"maya2osg_glsl_frag_compute"` + "\"\n";
		}
	}

  The parameters -additionalVertexCode and -additionalFragmentCode are
right (in fact they are working), but -additionalVertexdeclare and
-additionalFragmentdeclare are wrong. This is the reason for this code
not appearing in the shaders.

  If you didn't change it in revision 202, then svn is lying  :)

>>    I'm OK with it. You're right in that I left these names inconsistent
>> (in some places I said "compute" and others "code"). I think compute
>> is more adequate, as the declarations are also code, after all.
>>
>
> O.K., I will change the flags in the plugin to the suggested ones
>>    One other thing, Apart from the options being wrong, I tried it and
>> the scripts are not loading the plug-in as always. I had to manually
>> load it to be able to export a scene. I saw you changed a lot of code
>> but I didn't take a deep look at it. I think I wouldn't have too much
>> time these days.
>>
>>
> Will look into this, should be fixed today.
>
> Some more stuff from my side, I will start editing the cmake files as
> well, but need some assitance in the begining.

  What are you editing CMake for?

> The maya2osg_utility.mel needs to be installed properly. I found 2 files
> to edit and 2 deprecated VS files:
> configure_installer.cmake
> maya2osg-maininstaller.iss
> maya2osg.vcxproject
> maya2osg.vcxproject.filters

  Careful! Some of these are CMake scripts and others are generated by
CMake (you can delete it without problem, and they are not in svn).
Probably you only would need to edit the CMakeLists.txt file in the
Maya2OSG root directory. Some of these files are for the Windows
installer contributed by Ryan Pavlik in the osg-users mailing list.
See this page:

  https://sourceforge.net/apps/mediawiki/maya2osg/index.php?title=Windows_installer

> I will edit all 4 files ( with allmighty copy and paste tool :-) ),
> please to confirm.

  Just be careful to know exactly what you are doing.

> For my understanding, about the new textfields, and to be able to test
> functionality:
> Vertex / Fragment Declare are injected into GLSL code after the existing
> declaration block and before any procedure definition.
> Vertex / Fragment Compute are injected at the end of the GLSL code, so
> in the main procedure befor the closing braces.
> Is this right ?

  Right, I tried to explain it in this page:

  https://sourceforge.net/apps/mediawiki/maya2osg/index.php?title=Shading_Networks#Custom_GLSL_code

  If you don't find it clear or want to add something, feel free to edit it.

> In an earlier mail you mentioned that the injection happens if ALL the
> textfields do specify a file, is this correct ?
> Is there in no case, where one wants to just overwrite the Fragment
> color, without the need for any other ( Declare / Compute ) requirement ?

  No, no, no... I didn't say anything like that. Once you enable the
"custom code" check box, then the fields that have any valid content
will be used, the others will be simply ignored. If you don't pass any
of these options to Maya2OSG, it just ignores the corresponding piece
of code (doesn't remember the last value as other options).


  Regards,


-- 
Javier Taibo

Re: [Maya2osg-users] Customized GLSL shaders

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

Hi Javier,

>> The shader code does not end up in the osg file. Don't know what I'm
>> doing wrong.
>    You're passing the wrong options to the plug-in. Unless you have
> renamed them in osgwrite.cpp and not committed the changes.


Till now I only changed UI element names and envVars, but I kept the 
flags that are send to the plug-in untouched, so this shouldn't be the 
issue.



>    I'm OK with it. You're right in that I left these names inconsistent
> (in some places I said "compute" and others "code"). I think compute
> is more adequate, as the declarations are also code, after all.
>

O.K., I will change the flags in the plugin to the suggested ones
>    One other thing, Apart from the options being wrong, I tried it and
> the scripts are not loading the plug-in as always. I had to manually
> load it to be able to export a scene. I saw you changed a lot of code
> but I didn't take a deep look at it. I think I wouldn't have too much
> time these days.
>
>
Will look into this, should be fixed today.

Some more stuff from my side, I will start editing the cmake files as 
well, but need some assitance in the begining.
The maya2osg_utility.mel needs to be installed properly. I found 2 files 
to edit and 2 deprecated VS files:
configure_installer.cmake
maya2osg-maininstaller.iss
maya2osg.vcxproject
maya2osg.vcxproject.filters

I will edit all 4 files ( with allmighty copy and paste tool :-) ), 
please to confirm.

For my understanding, about the new textfields, and to be able to test 
functionality:
Vertex / Fragment Declare are injected into GLSL code after the existing 
declaration block and before any procedure definition.
Vertex / Fragment Compute are injected at the end of the GLSL code, so 
in the main procedure befor the closing braces.
Is this right ?

In an earlier mail you mentioned that the injection happens if ALL the 
textfields do specify a file, is this correct ?
Is there in no case, where one wants to just overwrite the Fragment 
color, without the need for any other ( Declare / Compute ) requirement ?

Cheers, PP

Re: [Maya2osg-users] Customized GLSL shaders

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

  Hi Peter,

On Fri, May 27, 2011 at 12:16 AM, Peter Wrobel <pp...@cg...> wrote:
>
> I added the required functionality to the textfields.

  Nice!

> The shader code does not end up in the osg file. Don't know what I'm
> doing wrong.

  You're passing the wrong options to the plug-in. Unless you have
renamed them in osgwrite.cpp and not committed the changes.

> I also shortened the envVars a little, and the lables of  Textfields,
> they did not fit into the UI, but they are still self explanatory.
>
> I'm also suggesting different names for the maya2osg option Flags, to
> keep it all consistent.
>
> -glslVertDeclare    instead of -additionalVertexdeclare
> -glslVertCompute instead of -additionalVertexCode
>
> -glslFragDeclare    instead of -additionalFragmentdeclare
>
> -glslFragCompute instead of -additionalFragmentCode

  I'm OK with it. You're right in that I left these names inconsistent
(in some places I said "compute" and others "code"). I think compute
is more adequate, as the declarations are also code, after all.

  One other thing, Apart from the options being wrong, I tried it and
the scripts are not loading the plug-in as always. I had to manually
load it to be able to export a scene. I saw you changed a lot of code
but I didn't take a deep look at it. I think I wouldn't have too much
time these days.


  Regards,


-- 
Javier Taibo

Re: [Maya2osg-users] Customized GLSL shaders

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

Hi Javier,

I added the required functionality to the textfields.
>   
>    The test shaders I am using do not work in a standard OSG viewer,
> unless you load it in the proper 3D engine you won't see anything. But
> for testing purposes any scene can do. Just add a fragment code like
> this:
>
>    gl_FragData[0] = vec4(0.0, 1.0, 0.0, 1.0);
>
>    And you'll test if it is working.
>
>    Anyway, if you modify the UI let me know and I will test it also.

The shader code does not end up in the osg file. Don't know what I'm 
doing wrong.

I also shortened the envVars a little, and the lables of  Textfields, 
they did not fit into the UI, but they are still self explanatory.

I'm also suggesting different names for the maya2osg option Flags, to 
keep it all consistent.

-glslVertDeclare    instead of -additionalVertexdeclare
-glslVertCompute instead of -additionalVertexCode

-glslFragDeclare    instead of -additionalFragmentdeclare

-glslFragCompute instead of -additionalFragmentCode



Cheers, PP

Re: [Maya2osg-users] osgpreview, UI and flags

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

  Hi Peter,

On Wed, May 25, 2011 at 10:15 PM, Peter Wrobel <pp...@cg...> wrote:
> Hi Javier,
>>    What I mean is: when you start Maya, the procs in these files are
>> not available. When you call for example the "maya2osg_export" proc,
>> as there is still not available, Maya looks for a
>> "maya2osg_export.mel" file in the scripts directories. When Maya
>> founds it and loads it, the procedure is available and executed. From
>> this moment, as the file is already loaded, all global procs in this
>> file are available, but they were not if you haven't called
>> "maya2osg_export" first.
>>
>
> Ah, I see. So for this there is the userSetup.mel, I guess you didn't
> get in touch with it till now. It gets executed at startup, and is, as
> the name says, a way to customize maya.
> This file doesn't exist by default, but only if one requires it. If it
> exists, user settings should be appended to the command s which are
> there already.
> In our case, we could source all the scripts with it. A more elegant way
> is to create a maya2osg_setup.mel ( will commit it soon ) and add the
> command source maya2osg_setup.mel to userSetup.mel. Within
> maya2osg_setup, we can source all the scripts, and maybe do some other
> setup stuff if requied. With this the preview command would available.

  I don't want to force the user to edit/create its userSetup.mel if
we can avoid it. Maybe it could be automatically done by the
installation process, but I prefer the other option, one file for
every "entry point" or procedure directly called by the user and they
can source other "utility files" with the procs needed by them.

> I must admit, that I like the fact that there is now a seperated
> osgFileExportOptions.mel, which is sourced by Maya at plugin load. I
> would like to keep this seperated, as there might be additional edits. A
> preview field does not make sens, but the pre and post export commands do.

  I don't understand what you mean here.

> Fine, unfortunatelly again not so much time for committing, as preaseure
> is going on again. But its not so horrible like the last week any more.
> I try to get all the discussed stuff checked in comming weekend. I will
> also add more options to the polygon exporter. Btw, now that custom glsl
> is supported, are you aware, that we can "paint" VertexAttributes with
> Maya VertexColor tool ?

  I didn't realized that. Cool.


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

>    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] Small changes for Maya 2012 x64

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

Hi Javier,

>    I took a look at Linux Maya installation and it's the same naming as
> in Windows, with the -x64 postfix. I already fixed it in svn/trunk. As
> I said, I cannot test, but it seems to install everything in the right
> place.

Great, as you said when someone wants to use it on Linux we'll know for 
sure.

>    AFAIK, there is no Maya 32 bit Linux version.

Interesting, good to know.

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

[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

[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] Small changes for Maya 2012 x64

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

  Hi J-S,

On Thu, May 26, 2011 at 2:17 AM, Jean-Sébastien Guay
<jea...@cm...> wrote:
>>    Thanks for the changes. I don't have a Maya license in Linux, I have
>> installed just to test that it compiles, but I can't launch it  :)
>
> Did you verify that the scripts get dropped in the right place, for both
> 32 and 64 bit builds on Linux? Do they use a similar scheme of adding
> "-x64" for  the user dir when it's the 64 bit version of Maya?

  I took a look at Linux Maya installation and it's the same naming as
in Windows, with the -x64 postfix. I already fixed it in svn/trunk. As
I said, I cannot test, but it seems to install everything in the right
place.

  AFAIK, there is no Maya 32 bit Linux version.


-- 
Javier Taibo

Re: [Maya2osg-users] Small changes for Maya 2012 x64

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

Hi Javier,

>    Thanks for the changes. I don't have a Maya license in Linux, I have
> installed just to test that it compiles, but I can't launch it  :)

Did you verify that the scripts get dropped in the right place, for both 
32 and 64 bit builds on Linux? Do they use a similar scheme of adding 
"-x64" for  the user dir when it's the 64 bit version of Maya?

My changes don't change anything to compilation, only installation of 
the scripts and icons (whatever goes into the user dir).

>    Anyway, I'll let it as it is now. It is committed to svn trunk. If
> someone tries it in Linux and doesn't work, we can change it easily.

Great, thanks!

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

Re: [Maya2osg-users] Small changes for Maya 2012 x64

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

  Hi J-S,

  Thanks for the changes. I don't have a Maya license in Linux, I have
installed just to test that it compiles, but I can't launch it  :)

  Anyway, I'll let it as it is now. It is committed to svn trunk. If
someone tries it in Linux and doesn't work, we can change it easily.


  Regards,


On Wed, May 25, 2011 at 10:15 PM, Jean-Sébastien Guay
<jea...@cm...> wrote:
> Hi Javier,
>
> I've installed Maya 2012 x64 at home (I was on Maya 2011 x86 at work, but
> will be using 2012 x64 soon there too) and I had to make a small
> modification to make the install phase install to the right place. Seems
> Maya 2012 x64 appends "-x64" to the user directory name, i.e. it's
>
> ...MyDocuments/maya/2012-x64
>
> instead of
>
> ...MyDocuments/maya/2012
>
> I wonder if the Linux version does the same, and for that fact if the 2011
> x64 version does it also... I have only access to 2011 x86 and 2012 x64,
> both on Windows, so I could only compare those two. For now I've put the
> added code inside the IF(WIN32) block, and kept the Linux behavior the same
> as it was before. Maybe you could test on 2011 x64 on Windows if you have
> access to that?
>
> Thanks,
>
> J-S
> --
> ______________________________________________________
> Jean-Sebastien Guay    jea...@cm...
>                               http://www.cm-labs.com/
>                    http://whitestar02.dyndns-web.com/
>
> ------------------------------------------------------------------------------
> vRanger cuts backup time in half-while increasing security.
> With the market-leading solution for virtual backup and recovery,
> you get blazing-fast, flexible, and affordable data protection.
> Download your free trial now.
> http://p.sf.net/sfu/quest-d2dcopy1
> _______________________________________________
> Maya2osg-users mailing list
> May...@li...
> https://lists.sourceforge.net/lists/listinfo/maya2osg-users
>
>



-- 
Javier Taibo

[Maya2osg-users] Small changes for Maya 2012 x64

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

Hi Javier,

I've installed Maya 2012 x64 at home (I was on Maya 2011 x86 at work, 
but will be using 2012 x64 soon there too) and I had to make a small 
modification to make the install phase install to the right place. Seems 
Maya 2012 x64 appends "-x64" to the user directory name, i.e. it's

...MyDocuments/maya/2012-x64

instead of

...MyDocuments/maya/2012

I wonder if the Linux version does the same, and for that fact if the 
2011 x64 version does it also... I have only access to 2011 x86 and 2012 
x64, both on Windows, so I could only compare those two. For now I've 
put the added code inside the IF(WIN32) block, and kept the Linux 
behavior the same as it was before. Maybe you could test on 2011 x64 on 
Windows if you have access to that?

Thanks,

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

Re: [Maya2osg-users] osgpreview, UI and flags

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

Hi Javier,
>    What I mean is: when you start Maya, the procs in these files are
> not available. When you call for example the "maya2osg_export" proc,
> as there is still not available, Maya looks for a
> "maya2osg_export.mel" file in the scripts directories. When Maya
> founds it and loads it, the procedure is available and executed. From
> this moment, as the file is already loaded, all global procs in this
> file are available, but they were not if you haven't called
> "maya2osg_export" first.
>

Ah, I see. So for this there is the userSetup.mel, I guess you didn't 
get in touch with it till now. It gets executed at startup, and is, as 
the name says, a way to customize maya.
This file doesn't exist by default, but only if one requires it. If it 
exists, user settings should be appended to the command s which are 
there already.
In our case, we could source all the scripts with it. A more elegant way 
is to create a maya2osg_setup.mel ( will commit it soon ) and add the 
command source maya2osg_setup.mel to userSetup.mel. Within 
maya2osg_setup, we can source all the scripts, and maybe do some other 
setup stuff if requied. With this the preview command would available.

I must admit, that I like the fact that there is now a seperated 
osgFileExportOptions.mel, which is sourced by Maya at plugin load. I 
would like to keep this seperated, as there might be additional edits. A 
preview field does not make sens, but the pre and post export commands do.


>    What have you merged? maya2osg_export and maya2osg_preview? If there
> are not the two files, then try to call (just after starting Maya,
> before calling anything else) the proc that has no file with its name
> and see if it is executed. I think it will not.
>

Yes, see above. It works in my case, because I added a source 
m20_export.mel into any shelf icon which requires the sourcing of the 
script. This makes sens for development, so I was not aware that there 
is an issue.



>> The only case is, when the whole system is installed, and no envVars are
>> created, so we can catch this case, and generate the default ones.
>    I think I am not understanding you. It's not about envVars, its
> about MEL procs.
>

Here I assumed, that all scripts do run, but I noticed issues, errors 
hen envVars were not setup properly.
Point is that the preview command can and should use the envVars, which 
means that the export and preview and the quick preview in the shelf 
should basically be the same commands.

>    OK. Commit it then and let's try it. If it works, it's OK. I just
> thought it wouldn't work, but I am not a Maya expert anyway  :)
>

Fine, unfortunatelly again not so much time for committing, as preaseure 
is going on again. But its not so horrible like the last week any more. 
I try to get all the discussed stuff checked in comming weekend. I will 
also add more options to the polygon exporter. Btw, now that custom glsl 
is supported, are you aware, that we can "paint" VertexAttributes with 
Maya VertexColor tool ?

Cheers, PP

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] osgpreview, UI and flags

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

  Hi Peter,

On Tue, May 24, 2011 at 12:32 AM, Peter Wrobel <pp...@cg...> wrote:
>>    Now we have to add the features we need to preview animations. Btw,
>> I hope to start next week with blend shapes export.
>>
>
> Cool, I will try add the skining module. To be honest, I hope I can
> overtake the blend shape stuff, as all regarding characters and rigging
> ( this includes best possible and fatest meshes export ) are my major
> field of interst.

  Don't worry, if you're with the skinning part, its OK. Let me do the
blend shape part and I'll ask you for help if I found any problem.

> If you know about corrective BlendShapes, I might be writing my Bachelor
> Thesis about a certain extension to this system which would yield
> perfect results at joints with more than one degree of freedom.

  I only know the very basic theory about blend shapes, I don't know
what corrective blend shapes are.

> But we should talk about the curent mesh export mechanism, as there are
> some traps waiting :-) see new thread.

  OK. I'll let you know what I found in my way...

>>    OK. All what you suggest is interesting. What about creating a new
>> section "Previewing" or "Previsualization" or something similar in the
>> export options window?
>>
>
> That can be done, but currently its only one TextField, does it really
> make sense for now ?

  Of course not. I thought you were talking about some new options
related to preview, that's why I said that. If there is only one,
there is no sense in making a new section.

>>    I don't understand completely what you are proposing. Just two notes:
>>
>>    1. maya2osg_export and maya2osg_preview procs must be in two
>> independent files with these same names to be automatically loaded the
>> first time they are called. This is the same reason I created the
>> "osgFileExportOptions.mel" file (otherwise the Maya Export option
>> failed if you haven't called maya2osg_export before).
>
> Now I think I can't follow you, neither  can reproduce the case you are
> talking about.

  What I mean is: when you start Maya, the procs in these files are
not available. When you call for example the "maya2osg_export" proc,
as there is still not available, Maya looks for a
"maya2osg_export.mel" file in the scripts directories. When Maya
founds it and loads it, the procedure is available and executed. From
this moment, as the file is already loaded, all global procs in this
file are available, but they were not if you haven't called
"maya2osg_export" first.

> I have merged the function already, but just not commited, and it works
> as expected.

  What have you merged? maya2osg_export and maya2osg_preview? If there
are not the two files, then try to call (just after starting Maya,
before calling anything else) the proc that has no file with its name
and see if it is executed. I think it will not.

> Before evaluating a global proc, the file where it is defined needs to
> be sourced, that's it. And as all settings are stored in environment
> variables, the UI does not have to be opened or executed, you can
> directly use the osg_preview command.

  But who is loading this file when Maya starts?

> The only case is, when the whole system is installed, and no envVars are
> created, so we can catch this case, and generate the default ones.

  I think I am not understanding you. It's not about envVars, its
about MEL procs.

>>    2. The maya2osg_preview command is meant to be a "quick preview" and
>> so it has no GUI. It just uses the last options that were set on the
>> plug-in and creates the output files in the temp directory and deletes
>> them after closing the preview window.
>
> As said, all that can be done without the UI opened, or the preview
> command existing in a seperate file.

  OK. Commit it then and let's try it. If it works, it's OK. I just
thought it wouldn't work, but I am not a Maya expert anyway  :)

> Btw, I like it very much, that it is a Maya window :-) do you remember
> the discussion about having a direct connection between Maya and a osg
> Window ? :-)

  Yes, we only have to add now the animation preview features and it
will be great!


-- 
Javier Taibo

Re: [Maya2osg-users] Blend Shapes and Geometry Export

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

  Hi Peter,

  Thank you very much for this information. It is very valuable to me
as I am just beginning to work on exporting blend shapes. I'm just
taking a look at osgAnimation (never used it before) to see what it
supports and how. Then I'll try to integrate the blend shape export in
your code into Maya2OSG. I'll let you know how it's going.

  I appreciate very much all the effort you have done here.


  Cheers!


On Tue, May 24, 2011 at 1:41 AM, Peter Wrobel <pp...@cg...> wrote:
> Hi all,
>
> wanna give some information about the current geometry export and the
> required steps to implement deformers like skinClusters and blendShapes.
> We should also implement normal Maya Clusters, as they are a fast and
> usefull Character utility.
>
> The current mesh exporter converts maya poly mesh into a VBO. Only
> osg::DrawElementsUByte( osg::PrimitiveSet::TRIANGLES ) are supported
> right now, all non triangle meshes get triangulated internally.
> In this proces, Vertices with multiple Normals ( Hard Edges ) or
> multiple UVs are duplicated, so the osg vertex count and IDs and don't
> correspond to the Maya vertex count and IDs in most of the cases. All
> Vertex Attributes are stored inside a Vertex Structure, and it has a
> field for the original Maya Vertex ID, which I will use for skinning.
> One Issue here is, that the Shape Orig of a Maya deformation chain does
> not have a shader attached, and does not necessarily need to have the
> same UVs or Normals as the resulting Mesh. The same is true for all the
> BlendShape Targets. The only attributes that are considered are
> VertexPositions and Normals ( there is a flag in
> osgAnimatin::MorphGeometry whether to morph Normals as well ).
>
> This means, that when exporting a deforming Mesh, the ShapeOrig, the
> resulting Shape and in the case of BlendShapes the Blend Targets should
> be exported simultaneously.
> Now the Vertex Atributes Structure is handy, as when all the
> osg::VertexArrays of the resulting mesh are generated, the required ones
> ( Position and Normals ) can be duplicated, and the corresponding Values
> can be accessed through the originla VertexID Attribute in the Vertex
> Structure, or even more confortable in the mVertexToVBOIndices variable,
> which is a std::Vector ( corresponding to Maya IDs ) of std::Vectors (
> the VBO IDs that refer Maya ID ).
>
> One more Issue. Now, it is possible to have shaders per Face attached,
> the exporter will capture all faces attached to one shader into one
> osg::Geometry, as to my understanding this is the lowest possible option
> to attach a osg::StateSet. This means one Maya Mesh can get Split up
> into multiple osg::Geometries. If this Mesh is a BlendShape, then we
> need to export as many MorphGeometries as Shaders are attached, and this
> leads to a new overhead of managing and connecting ( or duplicating ? )
> animations.
>
> That's it for now I guess.
>
> Cheers, PP
>
> ------------------------------------------------------------------------------
> vRanger cuts backup time in half-while increasing security.
> With the market-leading solution for virtual backup and recovery,
> you get blazing-fast, flexible, and affordable data protection.
> Download your free trial now.
> http://p.sf.net/sfu/quest-d2dcopy1
> _______________________________________________
> Maya2osg-users mailing list
> May...@li...
> https://lists.sourceforge.net/lists/listinfo/maya2osg-users
>



-- 
Javier Taibo