Thread: [Maya2osg-users] Triangle winding question (maya usage)
Status: Alpha
Brought to you by:
jtaibo
|
From: Jean-Sébastien G. <jea...@cm...> - 2011-10-14 17:13:35
|
Hi guys,
This is a Maya usage question... Hope you don't mind.
Our modelers often create symmetric pieces by first creating half, then
duplicating that half, scaling it by -1, reversing the normals and then
freezing the transforms.
This seems to work fine, at least in Maya, except that I notice now that
triangle winding (vertex order) is still inversed when they do that.
This manifests itself in two ways in our realtime app: Lighting
considers the wrong side of a face (light seems to come from the
opposite side) and backface culling is reversed (faces are culled when
looking from the outside instead of from the inside).
I wonder, is there a way in Maya to reverse the triangle winding? I can
write a script (or search the net for one), but is there something built-in?
I was thinking of writing a script that would go through all polygons of
a model and compare the "implicit normal" (calculate a normal using the
vertex order in the triangle) to the saved normal (in the normal array)
and if it doesn't point in roughly the same direction, reverse the
vertex order. This assumes that the artist has made his normals all
point in the correct direction, so the normals are used as reference to
correct the triangle winding. I could then put this script on preExport
in the plugin.
My question is really, do I have to do this myself or is there something
already there I can use?
Thanks in advance,
J-S
--
______________________________________________________
Jean-Sébastien Guay jea...@cm...
http://www.cm-labs.com/
http://whitestar02.dyndns-web.com/
|
|
From: Javier T. <jav...@gm...> - 2011-10-14 17:19:49
|
Hi J-S, Just a quick answer, without thinking too much... O:) Take a look at: Mesh > Cleanup (especially the "Nonmanifold geometry" option in "Remove Geometry" section) Normals > Conform I don't know if any of this is going to solve your problem, but these are the first places I would look. Just my two cents... good luck! Regards, On Fri, Oct 14, 2011 at 7:13 PM, Jean-Sébastien Guay < jea...@cm...> wrote: > Hi guys, > > This is a Maya usage question... Hope you don't mind. > > Our modelers often create symmetric pieces by first creating half, then > duplicating that half, scaling it by -1, reversing the normals and then > freezing the transforms. > > This seems to work fine, at least in Maya, except that I notice now that > triangle winding (vertex order) is still inversed when they do that. > This manifests itself in two ways in our realtime app: Lighting > considers the wrong side of a face (light seems to come from the > opposite side) and backface culling is reversed (faces are culled when > looking from the outside instead of from the inside). > > I wonder, is there a way in Maya to reverse the triangle winding? I can > write a script (or search the net for one), but is there something > built-in? > > I was thinking of writing a script that would go through all polygons of > a model and compare the "implicit normal" (calculate a normal using the > vertex order in the triangle) to the saved normal (in the normal array) > and if it doesn't point in roughly the same direction, reverse the > vertex order. This assumes that the artist has made his normals all > point in the correct direction, so the normals are used as reference to > correct the triangle winding. I could then put this script on preExport > in the plugin. > > My question is really, do I have to do this myself or is there something > already there I can use? > > Thanks in advance, > > 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 |
|
From: Peter W. <pp...@cg...> - 2011-10-14 18:59:16
|
Hi J-S > Our modelers often create symmetric pieces by first creating half, then > duplicating that half, scaling it by -1, reversing the normals and then > freezing the transforms. At this point, if the two pieces are supposed to be one piece, the modelers should combine the pieces, and merge the vertices. I think this should fix the winding as well, but need to confirm. > This seems to work fine, at least in Maya, except that I notice now that > triangle winding (vertex order) is still inversed when they do that. > This manifests itself in two ways in our realtime app: Lighting > considers the wrong side of a face (light seems to come from the > opposite side) and backface culling is reversed (faces are culled when > looking from the outside instead of from the inside). If the two pieces are not combined, scaling by minus one and freezing tansform does set the oposite attribute of the shape to true. Maya2osg does consider this attribute, and it might be that this is the reason for the culling. Even in the lightning case this can true, as sometimes we do reverse the normals inside the plugin due to settings and the usage of GLSL shading. The GLSL Shaders do reverse the normals too, if the oposite flag is set, so we can't inverse the normals. @Javier, think we should unify this so that FFP and GLSL allways get the same normals, let's put this on the to do list. > I wonder, is there a way in Maya to reverse the triangle winding? I can > write a script (or search the net for one), but is there something built-in? Here I agree with Javier. This is also the answer to your other mail about the optimization of models. I will take some more timeto reply to that mail later :-) 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 was thinking of writing a script that would go through all polygons of > a model and compare the "implicit normal" (calculate a normal using the > vertex order in the triangle) to the saved normal (in the normal array) > and if it doesn't point in roughly the same direction, reverse the > vertex order. This assumes that the artist has made his normals all > point in the correct direction, so the normals are used as reference to > correct the triangle winding. I could then put this script on preExport > in the plugin. This sounds really tricky to do with a script, and slow as well. I will take a look into the api, maybe I can find something. But here is one idea that might help. What about an external Triangle Stripifier. Doesn't matter if you use the strips at all, but the Triangles would be alligned with the right winding. From the resulting data it should be easy to built triangle lists with right winding. In some article ( don't know which one, sorry ) I read once that there is an optimazation in osg that reorders the vertices of a triangle list, so that vertices of adjecent triangles are as close as possible in the vertex arrays, to optimize GPU vertex caching. This one should give you as well the right winding. > My question is really, do I have to do this myself or is there something > already there I can use? AFAIK, there's nothing to tweak, fix or optimize triangle winding directly. Cheers, PP |
|
From: Javier T. <jav...@gm...> - 2011-10-14 20:32:15
|
On Fri, Oct 14, 2011 at 8:59 PM, Peter Wrobel <pp...@cg...> wrote: > Hi J-S > > Our modelers often create symmetric pieces by first creating half, then > > duplicating that half, scaling it by -1, reversing the normals and then > > freezing the transforms. > > At this point, if the two pieces are supposed to be one piece, the > modelers should combine the pieces, and merge the vertices. I think this > should fix the winding as well, but need to confirm. > I assumed that the geometry is in one shell, otherwise, what I say in last message has no sense. > > This seems to work fine, at least in Maya, except that I notice now that > > triangle winding (vertex order) is still inversed when they do that. > > This manifests itself in two ways in our realtime app: Lighting > > considers the wrong side of a face (light seems to come from the > > opposite side) and backface culling is reversed (faces are culled when > > looking from the outside instead of from the inside). > > If the two pieces are not combined, scaling by minus one and freezing > tansform does set the oposite attribute of the shape to true. Maya2osg > does consider this attribute, and it might be that this is the reason > for the culling. Even in the lightning case this can true, as sometimes > we do reverse the normals inside the plugin due to settings and the > usage of GLSL shading. The GLSL Shaders do reverse the normals too, if > the oposite flag is set, so we can't inverse the normals. @Javier, think > we should unify this so that FFP and GLSL allways get the same normals, > let's put this on the to do list. > 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 wonder, is there a way in Maya to reverse the triangle winding? I can > > write a script (or search the net for one), but is there something > built-in? > > Here I agree with Javier. This is also the answer to your other mail > about the optimization of models. I will take some more timeto reply to > that mail later :-) > 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 was thinking of writing a script that would go through all polygons of > > a model and compare the "implicit normal" (calculate a normal using the > > vertex order in the triangle) to the saved normal (in the normal array) > > and if it doesn't point in roughly the same direction, reverse the > > vertex order. This assumes that the artist has made his normals all > > point in the correct direction, so the normals are used as reference to > > correct the triangle winding. I could then put this script on preExport > > in the plugin. > > This sounds really tricky to do with a script, and slow as well. I will > take a look into the api, maybe I can find something. But here is one > idea that might help. > What about an external Triangle Stripifier. Doesn't matter if you use > the strips at all, but the Triangles would be alligned with the right > winding. From the resulting data it should be easy to built triangle > lists with right winding. > In some article ( don't know which one, sorry ) I read once that there > is an optimazation in osg that reorders the vertices of a triangle list, > so that vertices of adjecent triangles are as close as possible in the > vertex arrays, to optimize GPU vertex caching. This one should give you > as well the right winding. > Cool! If you find this reference, please share it. It's interesting. Regards, -- Javier Taibo |
|
From: Jean-Sébastien G. <jea...@cm...> - 2011-10-14 21:06:01
|
Hi Peter,
I have to see how the modeler got the result I see exactly... :-)
> 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.
> In some article ( don't know which one, sorry ) I read once that there
> is an optimazation in osg that reorders the vertices of a triangle list,
> so that vertices of adjecent triangles are as close as possible in the
> vertex arrays, to optimize GPU vertex caching. This one should give you
> as well the right winding.
That would be the combination of INDEX_MESH | VERTEX_POSTTRANSFORM |
VERTEX_PRETRANSFORM in the osgUtil::Optimizer. I've seen it work
wonders, yes. So I may consider running the Optimizer with some flags
including these on any exported file. I'll see.
Thanks,
J-S
--
______________________________________________________
Jean-Sébastien Guay jea...@cm...
http://www.cm-labs.com/
http://whitestar02.dyndns-web.com/
|
|
From: Jean-Sébastien G. <jea...@cm...> - 2011-10-17 18:44:38
|
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/
|
|
From: PP CG <pp...@cg...> - 2011-10-17 17:26:50
|
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 |
|
From: Javier T. <jav...@gm...> - 2011-10-17 18:20:01
|
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 |
|
From: PP CG <pp...@cg...> - 2011-10-17 19:33:01
|
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 |
|
From: Jean-Sébastien G. <jea...@cm...> - 2011-10-17 20:56:43
|
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/
|