I don't think you're correct. The gl code receives quads. It's arbitrary what happens to the quads once opengl gets them.
The modifier will enforce correctness. On Wed, Nov 14, 2012 at 1:10 PM, CoDEmanX <codem...@gmx.de> wrote: > OBJ exporter offers a "Triangulate Faces" option. If enabled, it won't > export quads, but take the tessfaces and turn quads into tris by using > vert 0,1,2 for one tris, and 2,3,0 for another. This way, you get what > you see in viewport, non-destructive and without extra calculations. > > Search for "f_v_iter": > > https://svn.blender.org/svnroot/bf-extensions/trunk/py/scripts/addons/io_scene_obj/export_obj.py > > Am 14.11.2012 21:31, schrieb Morten Mikkelsen: > > The important thing is that any proposed solution will work with export > too. > > If the obj exporter is still exporting quads and beyond then this is not > a > > solution. > > The modifier solution will make sure the exporter when exporting the dm > > exports the same > > triangulation. If what you are proposing does that then it's probably > fine. > > > > > > > > > > On Tue, Nov 13, 2012 at 4:07 PM, Brecht Van Lommel < > > brechtvanlom...@pandora.be> wrote: > > > >> Tessfaces contain both quads and triangles. The render engine can > >> store quads natively (uses less memory) and has its own splitting > >> algorithm which is different than what OpenGL does. Perhaps it would > >> not be a bad thing to add an option to Mesh datablocks to disable that > >> smart render engine splitting and have it the same as the viewport, > >> and enable it by default even. > >> > >> I don't know how important the smarter splitting it is in practice, in > >> Cycles I intentionally did not add it because it can pop in animation > >> and be inconsistent with the viewport, did not see complaints about it > >> so far. > >> > >> Brecht. > >> > >> On Wed, Nov 14, 2012 at 1:00 AM, CoDEmanX <codem...@gmx.de> wrote: > >>> Alright, maybe what i had on mind isn't possible in your case. > >>> > >>> As Blender has a tessface cache, I thought it should be used throughout > >>> the application for everything that requires tessellated mesh geometry. > >>> Polygon and tessface data can be accessed at the same time, so this is > >>> basically non-destructive as well. What is missing IMO is a checkbox to > >>> toggle display of tessfaces (we already see tesselated faces, but they > >>> aren't outlined etc.) > >>> > >>> A modifier might offer an extra ability of editing the triangulated > mesh > >>> non-destructively, not sure if possible, but if so, it would be great > to > >>> be able to adjust triangulation in certain spaces (tessfaces don't make > >>> up "nice" triangles) > >>> > >>> > >>> Am 14.11.2012 00:25, schrieb metalliandy: > >>>> The point of the modifier is not how it is triangulated, it is that > the > >>>> triangulation is non destructive and can be visibly toggled on and off > >>>> by the user at will and without the need for undo steps :) > >>>> > >>>> Also that quote you was from me, not Morten and I was 100% accurate. > >>>> > >>>> Morten replied and said in his reply to me > >>>> > >>>>> This is not exactly the issue. Let me clarify. > >>>>> The mikktspace part is done at quad level if there are quads and will > >>>>> always give the same > >>>>> tangent spaces at vertex level no matter what the order of vertices > or > >>>>> faces is. > >>>>> This is its very strong advantage which other tangent space > calculators > >>>>> can't do. > >>>>> > >>>>> After mikktspace has already run the problem occurs at a later stage > >>>>> because before rendering/baking triangulation has to have been > >> performed. > >>>>> So the issue is eventhough the tangent spaces at the vertices aren't > >>>>> impacted by how quads are triangulated (since triangulation happens > >> later) > >>>>> the interpolated tangent space is heavily impacted by which diagonal > is > >>>>> picked. Similar to how Gouraud shading is heavily impacted by which > >>>>> diagonal is picked. So eventhough tangent space is consistent at the > >>>>> vertices you get problems if baker and render don't pick the same > >>>>> triangulation > >>>>> due to differences in the interpolated tangent space. > >>>>> > >>>>> I should mention I am using "render triangulation" loosely here since > >> it > >>>>> can happen in a lot of places though for a game it would typically > >> happen > >>>>> somewhere in the engine's tools pipeline. Anyway the advantage to > this > >>>>> modifier is it enforces a consistent triangulation which will be > >> received > >>>>> by both baker and renderer (incl. Blender's renderer). Further, this > is > >>>>> achieved without causing permanent triangulation. > >>>>> It's a sensible practice which is already used by artists in other > >> modeling > >>>>> products. > >>>>> > >>>>> Morten M. > >>>> > >>>> I hope that clears everything up :) > >>>> > >>>> -Andy > >>>> > >>>> On 13/11/2012 23:12, CoDEmanX wrote: > >>>>> Sounds to me like there is an inconsistency somewhere in Blender, > which > >>>>> causes the difference in mesh geometry between what baker uses and > the > >>>>> stored/exported data... Shouldn't everything in Blender use > tessfaces, > >>>>> if triangles are required? > >>>>> > >>>>> "When baking with an all quad mesh, the triangulation that is done > >>>>> internally in Morten's TS might not match the manual triangulation > that > >>>>> the user applies on export [...]" - Morten Mikkelsen > >>>>> > >>>>> There shouldn't be "manual triangulation", as export scripts can use > >>>>> tessfaces to get triangulated geometry. Maybe here's the > inconsistency? > >>>>> The "Triangulate Faces" operator (former Quads to Tris) might create > >>>>> triangles different from the tessfaces. I wonder how Morten's TS does > >>>>> triangulation, hm, maybe I missed your point! (sorry if so) > >>>>> > >>>>> > >>>>> Am 10.11.2012 19:32, schrieb Antony Riakiotakis: > >>>>>> Exactly, the point is not display, but data availability for > baking. A > >>>>>> {0,1,2} {2,1,3} scheme is also being considered for the modifier. > >>>>>> _______________________________________________ > >>>>>> Bf-committers mailing list > >>>>>> Bf-committers@blender.org > >>>>>> http://lists.blender.org/mailman/listinfo/bf-committers > >>>>>> > >>>>> _______________________________________________ > >>>>> Bf-committers mailing list > >>>>> Bf-committers@blender.org > >>>>> http://lists.blender.org/mailman/listinfo/bf-committers > >>>>> > >>>> > >>>> _______________________________________________ > >>>> Bf-committers mailing list > >>>> Bf-committers@blender.org > >>>> http://lists.blender.org/mailman/listinfo/bf-committers > >>>> > >>> _______________________________________________ > >>> Bf-committers mailing list > >>> Bf-committers@blender.org > >>> http://lists.blender.org/mailman/listinfo/bf-committers > >> _______________________________________________ > >> Bf-committers mailing list > >> Bf-committers@blender.org > >> http://lists.blender.org/mailman/listinfo/bf-committers > >> > > _______________________________________________ > > Bf-committers mailing list > > Bf-committers@blender.org > > http://lists.blender.org/mailman/listinfo/bf-committers > > > _______________________________________________ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers