maya2osg-users — Maya2OSG mailing list

Re: [Maya2osg-users] LOD

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

Hi Javier,

>    I didn't even know that there are LOD groups in Maya. That's the main
> reason they are not exported  :)

Yeah, you select a node then you go to Edit - LOD - group.

The only bad thing is that each LOD group is independent. There's no 
"this child between 0 and 5, this one from 5 to 20, this one from 20 to 
100, etc." node.

>    I had no plans to export LOD groups by now (there are too many things
> in my to-do list), but contributions are welcome ;)

OK, I'll work on it. I hope it doesn't conflict with Peter's current work.

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

Re: [Maya2osg-users] Winding again!

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

On Tue, Oct 18, 2011 at 6:26 PM, Jean-Sébastien Guay <
jea...@cm...> wrote:

> Hi guys,
>
> I think I found the case where winding will affect surfaces.
>
> An object scaled by -1 will have its normals inverted and winding will
> be inverted too. Maya sets the "opposite" mode on this. It makes it look
> OK in Maya. If, in the plugin, I set "flip normals if surface mode is
> opposite", then the plugin will invert the normals (* -1) but the
> winding will still be wrong, so they will be culled by CULL_FACE even
> though lighting is correct.
>

  I don't remember why is this "flip normals if surface mode is opposite"
option required. Probably Peter explained it to me some time ago, but I
don't remember. It was supposed to work automatically in FFP as well as in
GLSL mode.

  Peter can you throw some light here?


-- 
Javier Taibo

Re: [Maya2osg-users] LOD

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

On Tue, Oct 18, 2011 at 9:06 PM, Jean-Sébastien Guay <
jea...@cm...> wrote:

> Hi guys,
>
> I've been experimenting with LOD groups in Maya, and the plugin exports
> these as normal transforms. Are there any plans any of you will
> implement LOD groups --> osg::LOD nodes in the near future, or should I
> start working on that right away if I need it? :-)
>

  I didn't even know that there are LOD groups in Maya. That's the main
reason they are not exported  :)

  I had no plans to export LOD groups by now (there are too many things in
my to-do list), but contributions are welcome ;)


  Regards,

-- 
Javier Taibo

Re: [Maya2osg-users] Patch for units

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

On Tue, Oct 18, 2011 at 8:54 PM, Jean-Sébastien Guay <
jea...@cm...> wrote:

> Hi Javier,
>
> >    Isn't this enough to apply this scale to the top matrix (where the
> > Z-up/Y-up conversion is made)?
> >
> >    I don't know what is exactly down the scene graph, but I thought it
> > should do... if you scale the scene as a whole, that's it, aint't it?
> > maybe I'm missing something...
>
> It's enough if all you do is display the scene graph.
>
> We develop a physics engine, and for that, we need the actual geometry
> to be in the right scale, and the transforms' translations too. And it's
> more convenient if everything is in the right scale everywhere in the
> graph. Plus, apart from the code that gets the units setting, it's a 2
> line change.
>

  OK.


-- 
Javier Taibo

[Maya2osg-users] LOD

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

Hi guys,

I've been experimenting with LOD groups in Maya, and the plugin exports 
these as normal transforms. Are there any plans any of you will 
implement LOD groups --> osg::LOD nodes in the near future, or should I 
start working on that right away if I need it? :-)

Thanks in advance,

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

Re: [Maya2osg-users] Patch for units

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

Hi Javier,

>    Isn't this enough to apply this scale to the top matrix (where the
> Z-up/Y-up conversion is made)?
>
>    I don't know what is exactly down the scene graph, but I thought it
> should do... if you scale the scene as a whole, that's it, aint't it?
> maybe I'm missing something...

It's enough if all you do is display the scene graph.

We develop a physics engine, and for that, we need the actual geometry 
to be in the right scale, and the transforms' translations too. And it's 
more convenient if everything is in the right scale everywhere in the 
graph. Plus, apart from the code that gets the units setting, it's a 2 
line change.

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

Re: [Maya2osg-users] Patch for units

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

  Isn't this enough to apply this scale to the top matrix (where the
Z-up/Y-up conversion is made)?

  I don't know what is exactly down the scene graph, but I thought it should
do... if you scale the scene as a whole, that's it, aint't it? maybe I'm
missing something...


On Tue, Oct 18, 2011 at 5:08 PM, PP CG <pp...@cg...> wrote:

> Hi J-S,
> > I didn't think of skinning (I know you're working on this so you think
> > of it all the time :-) )
> >
> > It should be the same I think... It shouldn't affect other parts of
> > matrices, other than translation. Unless I'm missing something.
>
> There are inverse matrices involved in skinning process, I hope that the
> same is true for them. Additionally we must also multiply all
> Translation Keyframes with it. In any case we will give a setting if
> this recalculation should take place at all. Lets wait for Javiers opinion.
>
> Cheers, PP
>
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2d-oct
> _______________________________________________
> Maya2osg-users mailing list
> May...@li...
> https://lists.sourceforge.net/lists/listinfo/maya2osg-users
>



-- 
Javier Taibo

[Maya2osg-users] Winding again!

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

Hi guys,

I think I found the case where winding will affect surfaces.

An object scaled by -1 will have its normals inverted and winding will 
be inverted too. Maya sets the "opposite" mode on this. It makes it look 
OK in Maya. If, in the plugin, I set "flip normals if surface mode is 
opposite", then the plugin will invert the normals (* -1) but the 
winding will still be wrong, so they will be culled by CULL_FACE even 
though lighting is correct.

If I reverse the normals in Maya, my guess is that Maya also reverses 
winding, because then all is OK.

So I think the plugin should warn when the surface mode is set to 
opposite AND single sided, as that will not work unless triangle winding 
is reversed (which is maybe too complex for an export plugin to do). At 
least with a warning artists can see there is a problem and fix it on 
the affected surfaces. If the data is wrong, fix the data! :-)

Thanks,

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

Re: [Maya2osg-users] Patch for units

[PP CG <pp...@cg...>]

Hi J-S,
> I didn't think of skinning (I know you're working on this so you think
> of it all the time :-) )
>
> It should be the same I think... It shouldn't affect other parts of
> matrices, other than translation. Unless I'm missing something.

There are inverse matrices involved in skinning process, I hope that the 
same is true for them. Additionally we must also multiply all 
Translation Keyframes with it. In any case we will give a setting if 
this recalculation should take place at all. Lets wait for Javiers opinion.

Cheers, PP

Re: [Maya2osg-users] Patch for units

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

Hi Peter,

> Hi J-S, just right now I wanted to send you how to get the Units in the
> Maya API :-)

Heh I found it :-)

> anyway, there will be problem with characters and skinning, as its not
> so trivial to just multiply some values. Hope we will find a good
> solution for this as well.

I didn't think of skinning (I know you're working on this so you think 
of it all the time :-) )

It should be the same I think... It shouldn't affect other parts of 
matrices, other than translation. Unless I'm missing something.

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

Re: [Maya2osg-users] Patch for units

[PP CG <pp...@cg...>]

Hi J-S, just right now I wanted to send you how to get the Units in the 
Maya API :-)

anyway, there will be problem with characters and skinning, as its not 
so trivial to just multiply some values. Hope we will find a good 
solution for this as well.

Cheers, PP
> Hi guys,
>
> I found out how to query what units were set in the Maya UI, so I made 
> a small modification to export using the correct units.
>
> Quick recap of the problem: Vertices and translations are always 
> returned in centimeters when using the Maya C++ API, no matter what 
> was set in the units settings in the Maya UI.
>
> That means that if we set the Maya UI to meters, and modeled a 1x1x1 
> cube, when exporting, we would get a 100x100x100 cube. (100 centimeters)
>
> This modification will query what unit is set in the Maya UI, and 
> multiply vertex positions and translations to be in the correct units.
>
> Note that I have tested this on a relatively old version of maya2osg, 
> which is why I provide a patch - if I provided modified files they 
> would not match anyways, so it's clearer if you only see the changes 
> and can apply them. It's nothing complicated anyways.
>
> Thanks,
>
> J-S
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2d-oct
>
>
> _______________________________________________
> Maya2osg-users mailing list
> May...@li...
> https://lists.sourceforge.net/lists/listinfo/maya2osg-users

[Maya2osg-users] Patch for units

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

Hi guys,

I found out how to query what units were set in the Maya UI, so I made a 
small modification to export using the correct units.

Quick recap of the problem: Vertices and translations are always 
returned in centimeters when using the Maya C++ API, no matter what was 
set in the units settings in the Maya UI.

That means that if we set the Maya UI to meters, and modeled a 1x1x1 
cube, when exporting, we would get a 100x100x100 cube. (100 centimeters)

This modification will query what unit is set in the Maya UI, and 
multiply vertex positions and translations to be in the correct units.

Note that I have tested this on a relatively old version of maya2osg, 
which is why I provide a patch - if I provided modified files they would 
not match anyways, so it's clearer if you only see the changes and can 
apply them. It's nothing complicated anyways.

Thanks,

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

Re: [Maya2osg-users] Triangle winding question (maya usage)

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

Hi Peter,

> That makes sense, we just should mention it somewhere. I think I'll add
> it to a help annotation of the Surface Mode.

Actually perhaps your own shader is OK. Remember, I replace your shaders 
by my own. So the only thing I can say with certainty is that my own 
shaders have a bug with negative bump value, you'll have to test to see 
if your shaders are affected!

Sorry I wasn't clearer in my message...

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

Re: [Maya2osg-users] Matrix exported does not obey units set in Maya

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

Hi guys,

I come back to this question, because it's pretty important to us...

I would like to implement a way, when export starts, to set a global 
multiplier that would scale things correctly (vertex arrays, transforms 
mostly).

The problem is, in the C++ API, I have no idea how to get the current 
units of the file / maya instance. In scripting I can do "currentUnit 
-query -linear" and I get "m" or "cm" so I know what to do, but in the 
C++ API I have no idea. I could add a setting in the GUI, but since this 
information should already be available from maya, I'd prefer not to.

Can someone help with this? It would be cool if in the Mel command 
reference there was a link to find the equivalent command in the C++ API...

Thanks,

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

Re: [Maya2osg-users] Empty groups / transforms

[PP CG <pp...@cg...>]

Hi J-S,

> I'm not suggesting that you replicate the UI completely, in fact I 
> like the UI you have for the Maya exporter. But look at the options 
> under "Optimize" in that dialog, it can give you some ideas. 

So I added the same options to our Optimizer Section. They are reachable 
as the Camel Case version of the option names in the UI,
in case of "Share Dup. States"
use Config::instance() -> getArgBool( "-shareDuplicateStates" ) ;

> The one I would add is the great optimization INDEX_MESH | 
> VERTEX_POSTTRANSFORM | VERTEX_PRETRANSFORM which basically uniformises 
> and merges all primitive sets in a geometry. In combination with 
> MERGE_GEODES AND MERGE_GEOMETRY, it's a great way to reduce the number 
> of draw calls, which are a major bottleneck of ours. If you wanna try 
> creating the ui on your own, its very easy :-)

Not familiar with the optimizer, and not sure if I'll have time to look 
into it. But if you need assistance to get other UI settings into the 
Plug-In I can help.

Cheers, PP

Re: [Maya2osg-users] Triangle winding question (maya usage)

[PP CG <pp...@cg...>]

Hi Javier,

>   Yes, if the shader is overrided and it does not take care of the 
> normal direction, it could fail, but it would behave different from 
> FFP either. Shaders should take care of this or at least the pipeline 
> responsible should enforce that no normals are reversed by the Maya 
> "opposite" parameter.
>
>   My opinion  is: if a shader behaves the opposite way than FFP, 
> something is wrong with this shader.

That makes sense, we just should mention it somewhere. I think I'll add 
it to a help annotation of the Surface Mode.

Cheers, PP

>
>
> On Mon, Oct 17, 2011 at 7:26 PM, PP CG <pp...@cg... 
> <mailto:pp...@cg...>> wrote:
>
>     Hi Javier,
>
>     >   We treat normals and backface culling taking into account the
>     > "double sided" and "opposite" options in the Maya mesh. And they
>     > should behave the same in FFP and GLSL. If they don't it is a bug.
>     > Moreover, we have a test model for this backface culling and
>     lighting
>     > issues. I'll take a look as soon as I can, but I think last time I
>     > checked that it worked OK.
>
>     I don't remember it fully, but I think we had a case with
>     reversing the
>     normals in the normal array, and that later on this was required for
>     only one case, think the case when using glsl, but not sure. Could
>     this
>     result in a problem, if the shaders produced by maya2osg do
>     reverse the
>     normals, but when somebody overrides this shaders, he might not
>     reverse
>     the normals and see unexpected behavior ?
>     I was talking about such a case, but really just guessing.
>
>     Cheers, PP
>
>
>     ------------------------------------------------------------------------------
>     All the data continuously generated in your IT infrastructure
>     contains a
>     definitive record of customers, application performance, security
>     threats, fraudulent activity and more. Splunk takes this data and
>     makes
>     sense of it. Business sense. IT sense. Common sense.
>     http://p.sf.net/sfu/splunk-d2d-oct
>     _______________________________________________
>     Maya2osg-users mailing list
>     May...@li...
>     <mailto:May...@li...>
>     https://lists.sourceforge.net/lists/listinfo/maya2osg-users
>
>
>
>
> -- 
> Javier Taibo
>
>
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2d-oct
>
>
> _______________________________________________
> Maya2osg-users mailing list
> May...@li...
> https://lists.sourceforge.net/lists/listinfo/maya2osg-users

Re: [Maya2osg-users] Triangle winding question (maya usage)

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

Hi all,

>> But to be honest I don't think that the winding is your problem here,
>> see above, but of course I will consider it and look into it.
>
> I'll try to get a simple model that exhibits the problems I see.

I found the source of the problem and you were right Javier, it was not 
the triangle winding.

Our artist had used a negative value for the "bump amount" in order to 
get holes instead of bumps. In the end, in our shader, this meant that 
all normals for this object (with that material) were reversed. That's 
why it was hard to track down, it happened only in the shader so I was 
left guessing what could possibly cause that problem... :-)

So, false alert, sorry for that!

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

Re: [Maya2osg-users] Empty groups / transforms

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

Hi Peter,

> J-S if you have a patch for the transform, could you send me the patch
> I'll add it to my WIP. The same has happened already with the mesh.cpp
> you sent me, but have just not submitted. Currently the code is not
> workable, but it should be done this week.

It's just to remove this whole block:

	// 3. If there are no children, the node is ignored
	if( osggroup->getNumChildren() == 0 ){

         /// ...

	}

in group.cpp.

> Do you have time to dig into the optimizer ? I think you sent me a
> picture of the max ui once, if you could resend I can adopt the ui into
> our ui.

Maybe I sent it before, I can't remember, but I can't send it to you 
right now because Max doesn't start anymore (grrr)

You can see the export dialog for the Max exporter here:

http://sourceforge.net/apps/mediawiki/osgmaxexp/index.php?title=Documentation#Export_options

I'm not suggesting that you replicate the UI completely, in fact I like 
the UI you have for the Maya exporter. But look at the options under 
"Optimize" in that dialog, it can give you some ideas.

The one I would add is the great optimization INDEX_MESH | 
VERTEX_POSTTRANSFORM | VERTEX_PRETRANSFORM which basically uniformises 
and merges all primitive sets in a geometry. In combination with 
MERGE_GEODES AND MERGE_GEOMETRY, it's a great way to reduce the number 
of draw calls, which are a major bottleneck of ours.

If you wanna try creating the ui on your own, its very easy :-)
> check out this wiki:
> http://sourceforge.net/apps/mediawiki/maya2osg/index.php?title=How_to_add_new_UI_Controls_and_Arguments_to_the_Maya_export_UI_that_will_be_passed_to_the_PlugIn

I may help with this if time permits later, for now I'm just trying to 
get a first version of a working content pipeline set up... :-)

Thanks,

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

Re: [Maya2osg-users] Triangle winding question (maya usage)

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

  Yes, if the shader is overrided and it does not take care of the normal
direction, it could fail, but it would behave different from FFP either.
Shaders should take care of this or at least the pipeline responsible should
enforce that no normals are reversed by the Maya "opposite" parameter.

  My opinion  is: if a shader behaves the opposite way than FFP, something
is wrong with this shader.


On Mon, Oct 17, 2011 at 7:26 PM, PP CG <pp...@cg...> wrote:

> Hi Javier,
>
> >   We treat normals and backface culling taking into account the
> > "double sided" and "opposite" options in the Maya mesh. And they
> > should behave the same in FFP and GLSL. If they don't it is a bug.
> > Moreover, we have a test model for this backface culling and lighting
> > issues. I'll take a look as soon as I can, but I think last time I
> > checked that it worked OK.
>
> I don't remember it fully, but I think we had a case with reversing the
> normals in the normal array, and that later on this was required for
> only one case, think the case when using glsl, but not sure. Could this
> result in a problem, if the shaders produced by maya2osg do reverse the
> normals, but when somebody overrides this shaders, he might not reverse
> the normals and see unexpected behavior ?
> I was talking about such a case, but really just guessing.
>
> Cheers, PP
>
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2d-oct
> _______________________________________________
> Maya2osg-users mailing list
> May...@li...
> https://lists.sourceforge.net/lists/listinfo/maya2osg-users
>



-- 
Javier Taibo

Re: [Maya2osg-users] Triangle winding question (maya usage)

[PP CG <pp...@cg...>]

Hi Javier,

>   We treat normals and backface culling taking into account the 
> "double sided" and "opposite" options in the Maya mesh. And they 
> should behave the same in FFP and GLSL. If they don't it is a bug. 
> Moreover, we have a test model for this backface culling and lighting 
> issues. I'll take a look as soon as I can, but I think last time I 
> checked that it worked OK.

I don't remember it fully, but I think we had a case with reversing the 
normals in the normal array, and that later on this was required for 
only one case, think the case when using glsl, but not sure. Could this 
result in a problem, if the shaders produced by maya2osg do reverse the 
normals, but when somebody overrides this shaders, he might not reverse 
the normals and see unexpected behavior ?
I was talking about such a case, but really just guessing.

Cheers, PP

Re: [Maya2osg-users] Empty groups / transforms

[PP CG <pp...@cg...>]

Hi guys,

J-S if you have a patch for the transform, could you send me the patch 
I'll add it to my WIP. The same has happened already with the mesh.cpp 
you sent me, but have just not submitted. Currently the code is not 
workable, but it should be done this week.

Do you have time to dig into the optimizer ? I think you sent me a 
picture of the max ui once, if you could resend I can adopt the ui into 
our ui. If you wanna try creating the ui on your own, its very easy :-) 
check out this wiki:
http://sourceforge.net/apps/mediawiki/maya2osg/index.php?title=How_to_add_new_UI_Controls_and_Arguments_to_the_Maya_export_UI_that_will_be_passed_to_the_PlugIn

In any case, for now I can help with the ui, but am sucked in skinning, 
and after that most probably combining skinning and morphing.

Cheers, PP

> Hi Javier,
>
>>     I see no problem in removing this code.
> Great, thanks.
>
>>     Actually it would be nice to add the optimizer pass as an option to
>> the exporter and even set the different optimizer options in the GUI. I
>> currently had no time to deal with this, but it is on the to-do list.
> OK, great. This is what is done in osgExp (the Max exporter) so it would
> be nice to have this option for maya2osg too (and have it run both when
> exporting and when previewing optionally).
>
> Thanks,
>
> J-S

Re: [Maya2osg-users] Empty groups / transforms

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

Hi Javier,

>    I see no problem in removing this code.

Great, thanks.

>    Actually it would be nice to add the optimizer pass as an option to
> the exporter and even set the different optimizer options in the GUI. I
> currently had no time to deal with this, but it is on the to-do list.

OK, great. This is what is done in osgExp (the Max exporter) so it would 
be nice to have this option for maya2osg too (and have it run both when 
exporting and when previewing optionally).

Thanks,

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

Re: [Maya2osg-users] Empty groups / transforms

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

  Hi J-S,

  I see no problem in removing this code.

  Actually it would be nice to add the optimizer pass as an option to the
exporter and even set the different optimizer options in the GUI. I
currently had no time to deal with this, but it is on the to-do list.

  Meanwhile, feel free to remove it. It was not much saving anyway... :)


  Regards,


On Mon, Oct 17, 2011 at 6:20 PM, Jean-Sébastien Guay <
jea...@cm...> wrote:

> Hi all,
>
> Me again, sorry to bug you so much lately. I'm putting the finishing
> touches on our content pipeline, glad to see artists finally using it,
> but it raises issues like crazy... :-)
>
> The exporter doesn't export empty groups unless there is animation on
> them, see group.cpp:
>
>        // 3. If there are no children, the node is ignored
>        if( osggroup->getNumChildren() == 0 ){
>                // Buuuuuuut, if there is an animation, it is saved to disk
>                // because it can be a useful camera animation
>                osg::AnimationPathCallback *cb = dynamic_cast<
> osg::AnimationPathCallback * >(osggroup->getUpdateCallback());
>                if(cb){
>                        MFnDependencyNode dn(node);
>                        std::cout << "EXPORTING CAMERA ANIMATION: " <<
> dn.name().asChar() <<
> std::endl;
>             CameraAnimation::save(cb->getAnimationPath(),
> Config::instance()->getSceneFilePath().getDirectory() + "/" +
> Config::instance()->getSceneFilePath().getFileBaseName() + "_" +
> std::string(dn.name().asChar()) + ".path" );
>                }
>                return NULL;
>        }
>
> However, we use groups (actually transforms, previously when we used
> Creator and .flt files we used DOF nodes) to attach things, and these
> may not have any geometry under them. So we need these empty groups.
>
> Could this be made an option, or just removed (i.e. all groups are
> exported) ? You can rely on the osgUtil::Optimizer to remove redundant
> nodes, it's in its default settings unless the ~REMOVE_REDUNDANT_NODES
> option is set in OSG_OPTIMIZER env var.
>
> Thanks,
>
> J-S
> --
> ______________________________________________________
> Jean-Sébastien Guay    jea...@cm...
>                                http://www.cm-labs.com/
>                     http://whitestar02.dyndns-web.com/
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2d-oct
> _______________________________________________
> Maya2osg-users mailing list
> May...@li...
> https://lists.sourceforge.net/lists/listinfo/maya2osg-users
>



-- 
Javier Taibo

[Maya2osg-users] Empty groups / transforms

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

Hi all,

Me again, sorry to bug you so much lately. I'm putting the finishing 
touches on our content pipeline, glad to see artists finally using it, 
but it raises issues like crazy... :-)

The exporter doesn't export empty groups unless there is animation on 
them, see group.cpp:

	// 3. If there are no children, the node is ignored
	if( osggroup->getNumChildren() == 0 ){
		// Buuuuuuut, if there is an animation, it is saved to disk
		// because it can be a useful camera animation
		osg::AnimationPathCallback *cb = dynamic_cast< 
osg::AnimationPathCallback * >(osggroup->getUpdateCallback());
		if(cb){
			MFnDependencyNode dn(node);
			std::cout << "EXPORTING CAMERA ANIMATION: " << dn.name().asChar() << 
std::endl;
             CameraAnimation::save(cb->getAnimationPath(), 
Config::instance()->getSceneFilePath().getDirectory() + "/" + 
Config::instance()->getSceneFilePath().getFileBaseName() + "_" + 
std::string(dn.name().asChar()) + ".path" );
		}
		return NULL;
	}

However, we use groups (actually transforms, previously when we used 
Creator and .flt files we used DOF nodes) to attach things, and these 
may not have any geometry under them. So we need these empty groups.

Could this be made an option, or just removed (i.e. all groups are 
exported) ? You can rely on the osgUtil::Optimizer to remove redundant 
nodes, it's in its default settings unless the ~REMOVE_REDUNDANT_NODES 
option is set in OSG_OPTIMIZER env var.

Thanks,

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

Re: [Maya2osg-users] Preview command and pre-export command

[PP CG <pp...@cg...>]

Hi J-S,

the lines ( in maya2osg_command.mel, line 72 and 84 )
maya2osg_fileUtil( "event,pre" ) ;
maya2osg_fileUtil( "event,post" ) ;

were meant to do this, but I don't remember if I just forgot to 
uncomment them, or if there was some issue. I submitted the changes now, 
so please just update and comment any found issue, thx.

Cheers, PP

> Hi all,
>
> I noticed that the "preview" button doesn't execute pre- and post-export
> scripts, and in fact in maya2osg_export.mel there is this comment:
>
> // NOTE: If we do really "Export and Preview" (i.e., writing to the
> specified file path not to a temporary one)
> // then we should call pre- and post-export scripts.
> // REMOVE THIS COMMENT WHEN FIXED!
>
> I need the preview to run pre-export scripts so that the preview really
> corresponds to what will be exported. So I tried to fix this. I just added
>
> if ( `optionVar -query "maya2osg_preExportEnable"` )
>     eval ( `optionVar -query "maya2osg_preExportCommand"` );
>
> where there was "// PRE EXPORT COMMAND" comment, and the analogous code
> for post-export where there was "// POST EXPORT COMMAND" comment.
>
> This seems to work. Is that all that's needed?
>
> I noticed I'm pretty out of date compared to the current trunk of
> maya2osg... The maya2osg_export.mel has changed a lot and I can't find
> where to make this change in the current version. Has this already been
> fixed?
>
> Thanks,
>
> J-S