maya2osg-users — Maya2OSG mailing list

Re: [Maya2osg-users] Customized GLSL shaders

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

  Hi,

On Tue, May 24, 2011 at 9:06 AM, Peter Wrobel <pp...@cg...> wrote:

>>    There is an UI option to enable the custom code feature and four
>> corresponding to the four code blocks above mentioned. And here,
>> Peter, I'm going to ask for your skills on Maya UI creation. I created
>> 5 new optionVars and the UI for them (basically copy&  paste of your
>> code :). Please, review it when you have time, just in case I have
>> done some nonsens. I also put "Browse" buttons after the text boxes,
>> but I don't know what is the most adequate way to make it work and the
>> script is growing dangerously, so I don't want to complicate it
>> further. Can you take a look at it, please? It would be nice also to
>> enable/disable the four text box / browse buttons depending on the
>> checkbox "Custom GLSL code".
>
> Working on that. Would be nice, if you could provide me some test scene
> and shader.

  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.

> You're right with the growing, thing should split it up somehow, but
> then there are lot of local functions which are needed almost
> everywhere. Will look into this.

  I am OK with it, I let you its organization, I just didn't want to
add more complexity nor to change the way to organize things. It is on
your hands.

> I would require motionvectors too, could you tell me how you are
> approaching this within one shader ?
> Thought one needs the same mesh from two different time stamps to get
> the position differences, but have not figured out the most efficient
> way store position mesh mesh data in a additional array. I tried to get
> Transfor Feedback to work, but I don't understand osgs extension
> mechanism well enough. So, how do you do it ?

  It is explained in the paper I am presenting next month in
Vancouver. I'll send you the information.


  Regards,

-- 
Javier Taibo

Re: [Maya2osg-users] Customized GLSL shaders

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

Hi Javie,

>
>
>    There is an UI option to enable the custom code feature and four
> corresponding to the four code blocks above mentioned. And here,
> Peter, I'm going to ask for your skills on Maya UI creation. I created
> 5 new optionVars and the UI for them (basically copy&  paste of your
> code :). Please, review it when you have time, just in case I have
> done some nonsens. I also put "Browse" buttons after the text boxes,
> but I don't know what is the most adequate way to make it work and the
> script is growing dangerously, so I don't want to complicate it
> further. Can you take a look at it, please? It would be nice also to
> enable/disable the four text box / browse buttons depending on the
> checkbox "Custom GLSL code".
>

Working on that. Would be nice, if you could provide me some test scene 
and shader.

You're right with the growing, thing should split it up somehow, but 
then there are lot of local functions which are needed almost 
everywhere. Will look into this.


>    Also, the fragment shaders are now writing to gl_FragData[0] instead
> of gl_FragColor, to allow the use of multiple render targets. In fact,
> the additional code is especially useful to add the code that computes
> the value of output in these other render targets (e.g. motion vectors
> in my case).

I would require motionvectors too, could you tell me how you are 
approaching this within one shader ?
Thought one needs the same mesh from two different time stamps to get 
the position differences, but have not figured out the most efficient 
way store position mesh mesh data in a additional array. I tried to get 
Transfor Feedback to work, but I don't understand osgs extension 
mechanism well enough. So, how do you do it ?

Cheers, PP

[Maya2osg-users] Blend Shapes and Geometry Export

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

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

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

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

Hi Javier,

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

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


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


>    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.
I have merged the function already, but just not commited, and it works 
as expected.

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

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

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

Cheers, PP

[Maya2osg-users] Customized GLSL shaders

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

  Hi,

  I have added four new options to the exporter that allow to append
custom GLSL code to the shaders exported.

  -additionalVertexDeclarations <file>
  -additionalVertexCode <file>
  -additionalFragmentDeclarations <file>
  -additionalFragmentCode <file>

  This way custom declarations can be appended at the end of the
shader (vertex or fragment) declarations (i.e. uniforms, varyings,
etc.) and custom computations can be added at the end of the shader
main() function. It is important to note that they are at the end
because this way users can override computations of the default
shader, i.e. the custom code has higher precedence.

  What the user specifies in these command line parameters is the path
of a file containing the GLSL code (not the code itself). If any of
these options is not supplied, no custom code in this part of this
shader is added (unlike most of the other parameters, these don't keep
the value of the last invocation).

  There is an UI option to enable the custom code feature and four
corresponding to the four code blocks above mentioned. And here,
Peter, I'm going to ask for your skills on Maya UI creation. I created
5 new optionVars and the UI for them (basically copy & paste of your
code :). Please, review it when you have time, just in case I have
done some nonsens. I also put "Browse" buttons after the text boxes,
but I don't know what is the most adequate way to make it work and the
script is growing dangerously, so I don't want to complicate it
further. Can you take a look at it, please? It would be nice also to
enable/disable the four text box / browse buttons depending on the
checkbox "Custom GLSL code".

  Also, the fragment shaders are now writing to gl_FragData[0] instead
of gl_FragColor, to allow the use of multiple render targets. In fact,
the additional code is especially useful to add the code that computes
the value of output in these other render targets (e.g. motion vectors
in my case).

  Btw, Peter, the "reloading" bug of the plug-in is fixed. The new
command was not unregistered when unloading the plug-in and this was
the reason it failed to load the plug-in again. My mistake!


  Regards,


-- 
Javier Taibo

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

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

On Sat, May 21, 2011 at 1:43 PM, Peter Wrobel <pp...@cg...> wrote:
> Hi all,
>
> first its nice to have the osgpreview as maya command :-)

  Now we have to add the features we need to preview animations. Btw,
I hope to start next week with blend shapes export.

> I would like to add some stuff to it. I'm using 2 Monitors and would
> like to preview on one of them in full screen, this is perfectly
> possible with the osgpreview flags, but there's no way to pass them from
> the ui.

  OK. All what you suggest is interesting. What about creating a new
section "Previewing" or "Previsualization" or something similar in the
export options window?

> Moreover, Javier, I would like to either merge the maya2osg_preview
> script with maya2osg_export script, or reorganize in both of the
> scripts, in one UI script and one export commands script, what do you
> think ?

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

  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.


-- 
Javier Taibo

[Maya2osg-users] osgpreview, UI and flags

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

Hi all,

first its nice to have the osgpreview as maya command :-)

I would like to add some stuff to it. I'm using 2 Monitors and would 
like to preview on one of them in full screen, this is perfectly 
possible with the osgpreview flags, but there's no way to pass them from 
the ui.

I would like to add an optionMenu to the preview command textfield, 
which changes the behavior of the command field, with these options:

Mel:
current behaviour

Pyth:
corresponding Python script

Exec:
which would take an os command ( like "osgviewer --flags file" ) without 
the need of "exec" infront of it

Flag:
this would call osgpreview with flags entered inside the textfield, 
overriding those hardcoded in the export script

Edit: ( maybe )
this would pop up a bigger window for editing text, in the case one of 
the above needs more space


Moreover, Javier, I would like to either merge the maya2osg_preview 
script with maya2osg_export script, or reorganize in both of the 
scripts, in one UI script and one export commands script, what do you 
think ?

Cheers, PP

Re: [Maya2osg-users] Discussion of next changes

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

Hi,

all Issues fixed, detailed notes in Repo Log.

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

Re: [Maya2osg-users] Discussion of next changes

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

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] About the UI

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

Hi,
>    Why? I liked very much when you added all the OptionVars because I
> can store my last export options from one Maya execution to other. I
> think it is very useful. Please, don't disable now this feature  :)
>
>

no, no, that's not what I meant. I created already a lot of variables 
and one of them got useless right now, which is "maya2osg_uiType". I'm 
sure that few more will follow, but once created, this variable will 
stay forever unless one deletes it manually. That is the intention of 
the procedure, cleaning up optionVar mess. In any case, if opening the 
UI the really necessary variables will be recreated. Its more like a reset.

Cheers, PP

Re: [Maya2osg-users] Blend shapes

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

Hi Javier,

>   one questin, how urgent is it at all ?
>    Nothing in the plug-in is more important to you than your exams now.
> Just focus on them and we'll talk about blend shapes, skinning,
> osgAnimation and everything after them.
>
>    Btw, good luck!
>
>    Or maybe I must say... justice! ;)
>
>

Wow, I wish that I'll be working in a company with a boss like you :-)
and thanks, justice is the only thing I'm missing right now ;-)

Cheers, PP

Re: [Maya2osg-users] Blend shapes

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

  Hi Peter,

On Thu, May 19, 2011 at 8:29 PM, Peter Wrobel <pp...@cg...> wrote:
> Hi Javier, and thanks for understanding.
>
> Just one questin, how urgent is it at all ?

  Nothing in the plug-in is more important to you than your exams now.
Just focus on them and we'll talk about blend shapes, skinning,
osgAnimation and everything after them.

  Btw, good luck!

  Or maybe I must say... justice! ;)


-- 
Javier Taibo

Re: [Maya2osg-users] Blend shapes

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

Hi Javier, and thanks for understanding.

Just one questin, how urgent is it at all ?

Cheers, PP


>    Hi Peter,
>
> On Thu, May 19, 2011 at 10:50 AM, Peter Wrobel<pp...@cg...>  wrote:
>> Hi Javier,
>>
>> fast answer, but details on mondy.
>    OK. Don't worry just ignore the messages if you're busy. We'll
> follow the thread next week.
>
>>>     I'm going to export a 3D character with skeleton animation and blend
>>> shapes, so I will at last test the osgAnimation export  :)
>> I wasn't able to add Skinning Code till now, so all yo can export is
>> transform animation. My osgMaya exporter has skinning implemented, but
>> the merging will take some time, so I don't know how fast I'll get to this.
>    OK. Maybe I can help with it. I'll take a look at it when I had some time.
>
>>>     Are blend shapes supported in Maya2OSG? Is there any development? Or
>>> may I have to start from scratch?
>> I started to write the export for that. I stopped as I was a little
>> frustrated that you cannot't "chain" the skining and morphing in an osg
>> file. Cedric showed me how to do this through code. But now I already
>> know more about osg, and I have an Idea what has to be done.
>> Datails after monday
>    OK. We'll follow the discussion next week.
>
>>>     And about how to prepare the model, it is a pseudo-humanoid
>>> character (biped) that will have blend shapes applied only to the
>>> face. The artist is asking me whether she should cut out the head to
>>> create the blend shapes only there or keep the body geometry as a
>>> whole. Is it a problem to rejoin the blend-shaped head later with the
>>> rest of the body? Have you ever done it?
>> This is the "normal" way people do it in the industry. So for the
>> begining it would be cool if she would keep the whole body mesh
>> attached. Later we should add this functionality, but I don't know how
>> far osgANimation needs to support this. Basically in normal morphing you
>> blend the position of a point to the position of another point. You
>> identify both points with their id. If you screw up point numbering in
>> one of the meshes ( by deliting one Vertex somwhere ) you scre up the
>> morphing. We would require a map between target and source ids. That we
>> can do in the plug in, but can osgAnimation use such a map ? Not shure,
>> but I don't think so.
>    Yes, I know the blend shape theory. I didn't know however how much
> is it supported in osgAnimation.
>
>>>     In case of having the "blend-shaped head" and the body in separate
>>> geometries, both affected by the skeleton animation, as long as the
>>> vertices in the joint edges are not affected by blend shapes and have
>>> assigned the exact same weights in skinning, should it be a problem?
>>> Do you think it would produce visible cracks in this part of the
>>> geometry?
>> No, the way you normally di it is, cut the hayd off, but dont' morph the
>> border edges. With this you guarantee continuity.
>    Yes, that's exactly what I meant. My doubt was, being the geometry
> split in two pieces, even though the vertices are in the same place if
> there are any problems of edge cracks. I hope not.
>
>

Re: [Maya2osg-users] Discussion of next changes

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

Hi J-S,

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

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

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

Cheers, PP

Re: [Maya2osg-users] Discussion of next changes

[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

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

Hi Peter,

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

If you can, thanks.

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

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

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

I find that weird.

Thanks,

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

Re: [Maya2osg-users] Discussion of next changes

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

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

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

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


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


> Sorry for my MEL newb-ness...

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

Cheers, PP

Re: [Maya2osg-users] Discussion of next changes

[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

[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] About the UI

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

  Hi Peter,

On Thu, May 19, 2011 at 10:28 AM, Peter Wrobel <pp...@cg...> wrote:
> Hi Javier and all, have exams this week, so this will be very short.
> Will turn more to maya2osg after monday

  OK. Just delay the answer to this message until next week. I'm
writing it now, because otherwise I will forget :)

> Yes, the normal fileTranslator functionality is doing this. When you
> don't add a file extension, the fileTranslator chooses the first which
> is assotiated with ... oh I can't check any more, notice now, that all

  Yes, this is the normal (and desirable) behavior, but the problem is
that when you explicitly define an extension, it still chooses the
default one. There is no way to specify other than the default. I
tried for a while, but I didn't find a way to solve it  :?

  But don't worry, anyway, our export command works pretty well  :)

>>    OK. After some use, you discover that the straight way to use this
>> part of the UI is going directly to the Browse button in the Filename
>> and there you can select at once file path, file name and file type.
>> Well. Then clearly the first textfield file path and especially its
>> Browse button are redundant.
>
> Not really, as sometimes you might want to keep filename, filetype, but
> just change the path.
> On my to do list is also something like "exportSelectedMeshAsGeode". Now
> suppose, you want to organize all what you export in different pathes.
> What's very handey for this is also the recently used paths Popup, when
> you press right mouse button over the path field. Tried that alreafy ?

  :-)   I didn't tried that. Cool!

> Yes, same reason as above, when you wanna do the Testing, tweaking,
> testing, tweaking Thingie, its unconfortable to reaopen the dialog
> again. Same solution idea, either one more button "export and close" or
> give a Option, "Close After Export"

  Personally I prefer the option better than the button. This way you
select it once and forget it exists. With the button you have to
choose always between all the buttons.

> So I submit now minor changes, making the text field for filename
> editable again, and the UI opening with optionMenu by default.
> Moreover, there is a global proc "maya2osg_removeOptionVars" actually
> deletes all the optionVars. This means that when reopening the UI, they
> will be regenarted with default settings.

  Why? I liked very much when you added all the OptionVars because I
can store my last export options from one Maya execution to other. I
think it is very useful. Please, don't disable now this feature  :)


  Regards,

-- 
Javier Taibo

Re: [Maya2osg-users] Blend shapes

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

  Hi Peter,

On Thu, May 19, 2011 at 10:50 AM, Peter Wrobel <pp...@cg...> wrote:
> Hi Javier,
>
> fast answer, but details on mondy.

  OK. Don't worry just ignore the messages if you're busy. We'll
follow the thread next week.

>>    I'm going to export a 3D character with skeleton animation and blend
>> shapes, so I will at last test the osgAnimation export  :)
>
> I wasn't able to add Skinning Code till now, so all yo can export is
> transform animation. My osgMaya exporter has skinning implemented, but
> the merging will take some time, so I don't know how fast I'll get to this.

  OK. Maybe I can help with it. I'll take a look at it when I had some time.

>>    Are blend shapes supported in Maya2OSG? Is there any development? Or
>> may I have to start from scratch?
>
> I started to write the export for that. I stopped as I was a little
> frustrated that you cannot't "chain" the skining and morphing in an osg
> file. Cedric showed me how to do this through code. But now I already
> know more about osg, and I have an Idea what has to be done.
> Datails after monday

  OK. We'll follow the discussion next week.

>>    And about how to prepare the model, it is a pseudo-humanoid
>> character (biped) that will have blend shapes applied only to the
>> face. The artist is asking me whether she should cut out the head to
>> create the blend shapes only there or keep the body geometry as a
>> whole. Is it a problem to rejoin the blend-shaped head later with the
>> rest of the body? Have you ever done it?
>
> This is the "normal" way people do it in the industry. So for the
> begining it would be cool if she would keep the whole body mesh
> attached. Later we should add this functionality, but I don't know how
> far osgANimation needs to support this. Basically in normal morphing you
> blend the position of a point to the position of another point. You
> identify both points with their id. If you screw up point numbering in
> one of the meshes ( by deliting one Vertex somwhere ) you scre up the
> morphing. We would require a map between target and source ids. That we
> can do in the plug in, but can osgAnimation use such a map ? Not shure,
> but I don't think so.

  Yes, I know the blend shape theory. I didn't know however how much
is it supported in osgAnimation.

>>    In case of having the "blend-shaped head" and the body in separate
>> geometries, both affected by the skeleton animation, as long as the
>> vertices in the joint edges are not affected by blend shapes and have
>> assigned the exact same weights in skinning, should it be a problem?
>> Do you think it would produce visible cracks in this part of the
>> geometry?
>
> No, the way you normally di it is, cut the hayd off, but dont' morph the
> border edges. With this you guarantee continuity.

  Yes, that's exactly what I meant. My doubt was, being the geometry
split in two pieces, even though the vertices are in the same place if
there are any problems of edge cracks. I hope not.


-- 
Javier Taibo

Re: [Maya2osg-users] Discussion of next changes

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

Hi Javier,

Great, thanks for the info!

J-S


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


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

Re: [Maya2osg-users] Discussion of next changes

[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