[Bf-gamedev] Triangulation Modifier changes, and feedback

Sat Nov 2 13:45:32 CET 2013

This might be a little off-topic to the discussed areas of the triangule
modifier, but I still think it is somewhat relevant to this discussion.
Would it be possible to add a triangle counter to the triangulate modifier?
The reason for me wanting this is that if I want to count the triangles for
a specific mesh I have to add both a triangulate and decimate modifier
which is (imo) one step too many and takes up too much space and clutters
the modifier stack for what is used for (in this case, just triangle
counting). It is in my opinion a very relevant location for a triangle
counter as it is a modifier that will be used (presumably) mostly by game
artists on most/all assets anyway.

I've attached a mock-up that illustrates the problem and proposes a
solution.

It might also be worth mentioning that the Decimator does not count the
number of triangles as long as you're using a ratio of 1.0 regardless of if
you've checked the Triangulate box. What this results in is that the
Decimator by itself can never give a 100% correct triangle count. This
might just be a bug and should probably be reported to the bugtracker (I
reported it once but my report was kind of bad/cluttered), but for reasons
stated above I would desire a triangle counter in the triangulate modifier
even if this bug/oversight were to be fixed.

On Sat, Nov 2, 2013 at 12:06 AM, Katsbits.com <info at katsbits.com> wrote:

> The problem presented by triangulation tends to crop up on lower poly
> meshes
> (usually larger models with fewer triangles [cf. in addition to
> metalliandy's points]), and often needs to be corrected by manually turning
> an edge; it's unavoidable in some instances and can't be 'assumptively'
> fixed by automation. So far as I've been able to ascertain, it is possible
> to fix a quads orientation by splitting, rotating then reverting to quads
> again as a means to avoid having to tessellate a mesh for baking et-al
> (upon
> export the modified orientations appear to be kept). Not sure additional
> layers of AddOns and modifiers to fix the issue is wholly pragmatic unless
> it means adding some form of simple, quick mark-up of faces for inverse(?)
> treatment (split the opposite way) during render?.
>
> kat
> KatsBits | http://www.katsbits.com/
>
> -----Original Message-----
> From: bf-gamedev-request at blender.org
> Sent: Friday, November 01, 2013 10:30 PM
> To: bf-gamedev at blender.org
> Subject: Bf-gamedev Digest, Vol 3, Issue 3
>
> Send Bf-gamedev mailing list submissions to
> bf-gamedev at blender.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.blender.org/mailman/listinfo/bf-gamedev
> or, via email, send a message with subject or body 'help' to
> bf-gamedev-request at blender.org
>
> You can reach the person managing the list at
> bf-gamedev-owner at blender.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Bf-gamedev digest..."
>
>
> Today's Topics:
>
>    1. Re: New loop normals/tspace needs testing (Piotr Adamowicz)
>    2. Re: New Bullet version and Featherstone (Arnaud Degroote)
>    3. Triangulation Modifier changes, and feedback (Dalai Felinto)
>    4. Re: Triangulation Modifier changes, and feedback (metalliandy)
>    5. Re: New loop normals/tspace needs testing (Simon Broggi)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 1 Nov 2013 20:09:47 +0100
> From: Piotr Adamowicz <padamowicz at gmail.com>
> Subject: Re: [Bf-gamedev] New loop normals/tspace needs testing
> To: bf-gamedev at blender.org
> Message-ID:
> <CAGqzbHFoo03cOzhk4sBiWA3AFmoo3TcA3dBLiZjvSZ1VGH_+2w at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Custom normals are used mainly for two things. One of them is foliage
> you already know about. The other is correcting shading errors on low
> poly geometry when you want or need to avoid split edges. This other
> use is actually much more common.
>
> For example, with averaged normals, on a smooth-shaded cube with a
> small single-segment bevel, there's very noticeable artefacting along
> the surfaces of the large faces. You use custom normals to correct
> this manually, to make the large faces' vertex normals point exactly
> along the face normals. That way the large surfaces appear flat, but
> the small beveled edges of the cube still appear rounded.
>
> Other than that you might want to use custom normals for baking, to
> point rays in a particular direction and, say, avoid waviness at the
> edges of cylindrical shapes. This only applies if you're not using a
> cage for baking, so assuming that cages are implemented at some point,
> this usage isn't very important.
>
> And one more use that is not usually game-related is importing,
> rendering and baking from CAD models that have normals calculated
> based on the underlying mathematical solid shapes. For this it's just
> important to be able to keep the normals as is without wrecking them
> with simple things like entering edit mode.
>
> That's it I think, if there are other use cases I don't know about them.
>
> I'd really like to see option II implemented, but I understand this is
> a tall order. For correcting normals a modifier-based approach might
> be ok. A modifier that calculates the vertex normals by taking the
> relative surface areas of the adjoining faces into account
> (face-weighted normals) would do most of the job. Such a modifier
> should also have an optional threshold below which the larger face
> 'wins' and the vertex in question is pointed directly along the face
> normal. This would probably cover 80% of cases. For the other 20%, the
> trouble is that this threshold might be different for different parts
> of the low poly mesh, so controlling it with a vertex group (this
> would probably be very user-unfriendly), and/or a way to manually tag
> faces 'flat' would be in order.
>
>
> On Fri, Nov 1, 2013 at 7:06 PM, Bastien Montagne <montagne29 at wanadoo.fr>
> wrote:
> > Hey guys,
> >
> > Further tweaked the code, patch is available here (for review as well).
> > Still more a draft than final, trunk-ready code, but I would avoid
> > spending
> > more time on it before having it reviewed and global design validated.
> >
> > https://codereview.appspot.com/20790043/
> >
> > From that point, we can have two different goals:
> > I) Simply add import of normals (from FBX and co) as a "frozen" loop
> > normal
> > layer, which just stays as-is even if you edit the mesh (probably on a
> > vertex- or loop-based flag, so that someone can choose to go back to
> > auto-computed ones for some parts of the mesh), and add some modifiers to
> > get procedural loop normals editing (e.g. to use other geometry's
> normals,
> > the "trees" example).
> > II) Aim to a full support of custom normals.
> >
> > I) is relatively easy to do, could be mostly finished and working in a
> few
> > weeks. However, it is not fully featured and powerful (you can't say "I
> > want
> > this normal to point this way"), and support for geometry deformations
> and
> > editing would be *very* poor (in other words, normals computation should
> > happen as late as possible in the modifier stack).
> >
> > II) would allow to do virtually everything with normals. However, it is
> > much
> > more involved (most likely months of work):
> > * Have to add loop normals handling in BMesh.
> > * Will need some UI new stuff (maybe a new Loop select mode, similar to
> > current vertex/edge/face ones in Edit mode, perhaps even new editing
> > widgets
> > in viewport, etc.).
> > * Implies to store custom normals as some kind of diff (in tspace-like
> > coordinates) format, relative to auto-computed ones. This would allow to
> > keep meaningful (to some extend!) custom normals even in heavy geometry
> > changes.
> >
> > So I'd really like to get feedback from expert gamedevs, ideally with
> > example of workflow involving custom normals (the only real one I found
> so
> > far is the "tree" one, which is very easy to implement as a modifier). I
> > need to know whether solution II) (which covers 100% of the editing needs
> > in
> > this area) is worth the work involved, or if solution I) (covering maybe
> > 90%
> > of needs) could be enough?
> >
> > PS: Don't think I'll make builds, this has proved to be rather painful
> and
> > time consuming in the past (Blender uses many libs, hard to static-link
> > all
> > that together), and building Blender is now very easy on every OS!
>
>
>
> --
> Piotr "MadMinstrel" Adamowicz
> padamowicz at gmail.com
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 1 Nov 2013 20:20:42 +0100
> From: Arnaud Degroote <arnaud.degroote at laas.fr>
> Subject: Re: [Bf-gamedev] New Bullet version and Featherstone
> To: bf-gamedev at blender.org
> Message-ID: <20131101192042.GA13379 at bugfree>
> Content-Type: text/plain; charset="us-ascii"
>
> On 01/Nov - 09:53, Jacob Merrill wrote:
> > Featherstone allows for Inverse kinematics for 6dof chains in real time.
> > Allowing animation using objects that physically interact, or for
> robotics
> > control/ emulation
> > On Nov 1, 2013 9:50 AM, "Jacob Merrill" <blueprintrandom1 at gmail.com>
> > wrote:
> >
> > > I have been using 6dof solvers to animate, and it works amazing but
> it's
> > > rather resource intensive, but is dynamic and can be pushed, yanked
> etc.
> > >
> > > http://www.youtube.com/watch?v=s57ipxhXBS4
> > > On Nov 1, 2013 9:41 AM, "Mitchell Stokes" <mogurijin at gmail.com> wrote:
> > >
> > >> Solving 6dof joint constraints is not a bottleneck (at least in any
> BGE
> > >> game I've looked at). So, it's not currently worth our time to spend
> > >> development resources speeding it up. That being said, you (or anyone
> > >> else)
> > >> are more than welcome to create a patch.
> > >>
>
> Just to add we develop a robotic simulator using blender / game engine
> (morse.openrobots.org) and we will be really interested by this feature
> to simulate in a smarter way complex armature.
>
> Best regards,
>
> --
> Arnaud Degroote
> Postdoc
> RIA LAAS - CNRS
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: application/pgp-signature
> Size: 490 bytes
> Desc: Digital signature
> Url :
>
> http://lists.blender.org/pipermail/bf-gamedev/attachments/20131101/6348cb42/attachment-0001.pgp
>
> ------------------------------
>
> Message: 3
> Date: Fri, 1 Nov 2013 17:27:38 -0200
> From: Dalai Felinto <dfelinto at gmail.com>
> Subject: [Bf-gamedev] Triangulation Modifier changes, and feedback
> To: bf-gamedev at blender.org
> Message-ID:
> <CAGjvzG2uqPnfv4bhZa5jRhJFPVa5dscwNRkESNx3X3_UuE7ksw at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi,
>
> I recently committed some changes to the Triangulation Modifier [1]:
>
> 1) Quads Split Method: Shortest Diagonal (default), Beauty, Fixed, Fixed
> Alternate
> 2) Ngons Split Method: Scanfill, Beauty
>
> There is a remaining issue though. Users seem to care about non-destructive
> workflows and at the same time, fine-tuning control over the triangulation.
>
> For that the easiest solution would be to have the user triangulating the
> quads that need to be tweaked. The downside of this is that you loose
> things such as edge-loop/rings selection.
>
> Another solution would be changing the code to flag some edges/quads as
> 'flip-rotation'. This is complicated to implement, leads to a messy design
> for the user, and honestly it may not be worth the time to do it.
>
> As a compromise/3rd option one can use an addon to 'rotate' the vertices
> indices of a face, and use it with the Fixed or Fixed Alternate quad
> methods.
> I even implemented that in C, but it should be doable in Py as well [2].
> The downside of this is that it would not work with the "Shortest
> Diagonal", which seems to be a popular method.
>
> I would like to hear from some real-world pipelines how important it is to
> have all-quads meshes, and/or if the current implementation/solutions are
> enough.
>
> [1]  -
>
> http://wiki.blender.org/index.php/Doc:2.6/Manual/Modifiers/Generate/Triangulate
> [2] - https://github.com/dfelinto/blender-svn/pull/16/files
>
> Many thanks,
> Dalai
>
> --
> blendernetwork.org/dalai-felinto
> www.dalaifelinto.com
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
>
> http://lists.blender.org/pipermail/bf-gamedev/attachments/20131101/59fd80d8/attachment-0001.htm
>
> ------------------------------
>
> Message: 4
> Date: Fri, 01 Nov 2013 20:07:54 +0000
> From: metalliandy <metalliandy666 at googlemail.com>
> Subject: Re: [Bf-gamedev] Triangulation Modifier changes, and feedback
> To: bf-gamedev at blender.org
> Message-ID: <52740A1A.2040005 at googlemail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi Dalai,
>
> Awesome! I can't wait to see the changes in a build!
>
> Triangulation is very important to ensure consistently correct baking
> (anyone who says different either doesn't care or doesn't know any
> better ;) ) but it is also very important to ensure that it is as
> non-destructive as possible to allow the flexibility of having to go
> back and adjust geometry without having to convert to quads which can be
> error prone and time consuming.
>
> Quads are not needed for game ready meshes as they are converted to tris
> anyway on import but the important thing is that the triangulation is
> performed before baking and the same triangulation is used on the game
> mesh. As we can't guarantee which method of triangulation is used in any
> other program it is down to the artist to ensure that it remains
> consistent throughout the pipeline. However, in Blender triangles
> restrict the ability of the artist to edit a mesh in a fast and
> efficient manner so it isn't really a good idea to work on a
> triangulated mesh in this way.
>
> The method of triangulation doesn't really matter from a rendering
> perspective  as GPUs can brute force pretty much anything with relative
> ease (aside from very long thin triangles) and we don't do things like
> tri-stripping any more because it's just not worth the effort for the
> extremely minimal impact of performance.
>
> That said, shortest diagonal is the most consistent way of applications
> triangulating a mesh as the mesh will always have the same results vs
> other perhaps more involved triangulation algorithms. So having it as
> default makes sense I think.
>
> The ability to rotate edges would be great but not at the expense of
> changing the triangulation algorithm from shortest diagonal so unless
> there is a way to do this I would prefer to do any edge rotating after
> the fact once the modifier has been applied before export.
>
> Cheers,
>
> -Andy
>
> On 01/11/2013 19:27, Dalai Felinto wrote:
> > Hi,
> >
> > I recently committed some changes to the Triangulation Modifier [1]:
> >
> > 1) Quads Split Method: Shortest Diagonal (default), Beauty, Fixed,
> > Fixed Alternate
> > 2) Ngons Split Method: Scanfill, Beauty
> >
> > There is a remaining issue though. Users seem to care about
> > non-destructive workflows and at the same time, fine-tuning control
> > over the triangulation.
> >
> > For that the easiest solution would be to have the user triangulating
> > the quads that need to be tweaked. The downside of this is that you
> > loose things such as edge-loop/rings selection.
> >
> > Another solution would be changing the code to flag some edges/quads
> > as 'flip-rotation'. This is complicated to implement, leads to a messy
> > design for the user, and honestly it may not be worth the time to do it.
> >
> > As a compromise/3rd option one can use an addon to 'rotate' the
> > vertices indices of a face, and use it with the Fixed or Fixed
> > Alternate quad methods.
> > I even implemented that in C, but it should be doable in Py as well
> > [2]. The downside of this is that it would not work with the "Shortest
> > Diagonal", which seems to be a popular method.
> >
> > I would like to hear from some real-world pipelines how important it
> > is to have all-quads meshes, and/or if the current
> > implementation/solutions are enough.
> >
> > [1]  -
> >
> http://wiki.blender.org/index.php/Doc:2.6/Manual/Modifiers/Generate/Triangulate
> > [2] - https://github.com/dfelinto/blender-svn/pull/16/files
> >
> > Many thanks,
> > Dalai
> >
> > --
> > blendernetwork.org/dalai-felinto <
> http://blendernetwork.org/dalai-felinto>
> > www.dalaifelinto.com <http://www.dalaifelinto.com>
> >
> >
> > _______________________________________________
> > Bf-gamedev mailing list
> > Bf-gamedev at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-gamedev
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
>
> http://lists.blender.org/pipermail/bf-gamedev/attachments/20131101/ca917aea/attachment-0001.htm
>
> ------------------------------
>
> Message: 5
> Date: Fri, 1 Nov 2013 23:29:56 +0100
> From: Simon Broggi <simon.broggi at gmail.com>
> Subject: Re: [Bf-gamedev] New loop normals/tspace needs testing
> To: bf-gamedev at blender.org
> Message-ID:
> <CAKXpPRzH9W4bOh3KwNHu-KsijGw2PvUKu9W4Y=6=wja_9DfNHg at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> I totally agree with Piotr Adamowicz.
> Here's a video of how I currently achieve smooth low poly models in
> blender.
> http://vimeo.com/78378752
> Biggest downside is that I have to apply the edge split modifier.
>
> On Fri, Nov 1, 2013 at 8:09 PM, Piotr Adamowicz <padamowicz at gmail.com
> >wrote:
>
> > Custom normals are used mainly for two things. One of them is foliage
> > you already know about. The other is correcting shading errors on low
> > poly geometry when you want or need to avoid split edges. This other
> > use is actually much more common.
> >
> > For example, with averaged normals, on a smooth-shaded cube with a
> > small single-segment bevel, there's very noticeable artefacting along
> > the surfaces of the large faces. You use custom normals to correct
> > this manually, to make the large faces' vertex normals point exactly
> > along the face normals. That way the large surfaces appear flat, but
> > the small beveled edges of the cube still appear rounded.
> >
> > Other than that you might want to use custom normals for baking, to
> > point rays in a particular direction and, say, avoid waviness at the
> > edges of cylindrical shapes. This only applies if you're not using a
> > cage for baking, so assuming that cages are implemented at some point,
> > this usage isn't very important.
> >
> > And one more use that is not usually game-related is importing,
> > rendering and baking from CAD models that have normals calculated
> > based on the underlying mathematical solid shapes. For this it's just
> > important to be able to keep the normals as is without wrecking them
> > with simple things like entering edit mode.
> >
> > That's it I think, if there are other use cases I don't know about them.
> >
> > I'd really like to see option II implemented, but I understand this is
> > a tall order. For correcting normals a modifier-based approach might
> > be ok. A modifier that calculates the vertex normals by taking the
> > relative surface areas of the adjoining faces into account
> > (face-weighted normals) would do most of the job. Such a modifier
> > should also have an optional threshold below which the larger face
> > 'wins' and the vertex in question is pointed directly along the face
> > normal. This would probably cover 80% of cases. For the other 20%, the
> > trouble is that this threshold might be different for different parts
> > of the low poly mesh, so controlling it with a vertex group (this
> > would probably be very user-unfriendly), and/or a way to manually tag
> > faces 'flat' would be in order.
> >
> >
> > On Fri, Nov 1, 2013 at 7:06 PM, Bastien Montagne <montagne29 at wanadoo.fr>
> > wrote:
> > > Hey guys,
> > >
> > > Further tweaked the code, patch is available here (for review as well).
> > > Still more a draft than final, trunk-ready code, but I would avoid
> > spending
> > > more time on it before having it reviewed and global design validated.
> > >
> > > https://codereview.appspot.com/20790043/
> > >
> > > From that point, we can have two different goals:
> > > I) Simply add import of normals (from FBX and co) as a "frozen" loop
> > normal
> > > layer, which just stays as-is even if you edit the mesh (probably on a
> > > vertex- or loop-based flag, so that someone can choose to go back to
> > > auto-computed ones for some parts of the mesh), and add some modifiers
> > > to
> > > get procedural loop normals editing (e.g. to use other geometry's
> > normals,
> > > the "trees" example).
> > > II) Aim to a full support of custom normals.
> > >
> > > I) is relatively easy to do, could be mostly finished and working in a
> > few
> > > weeks. However, it is not fully featured and powerful (you can't say "I
> > want
> > > this normal to point this way"), and support for geometry deformations
> > and
> > > editing would be *very* poor (in other words, normals computation
> should
> > > happen as late as possible in the modifier stack).
> > >
> > > II) would allow to do virtually everything with normals. However, it is
> > much
> > > more involved (most likely months of work):
> > > * Have to add loop normals handling in BMesh.
> > > * Will need some UI new stuff (maybe a new Loop select mode, similar to
> > > current vertex/edge/face ones in Edit mode, perhaps even new editing
> > widgets
> > > in viewport, etc.).
> > > * Implies to store custom normals as some kind of diff (in tspace-like
> > > coordinates) format, relative to auto-computed ones. This would allow
> to
> > > keep meaningful (to some extend!) custom normals even in heavy geometry
> > > changes.
> > >
> > > So I'd really like to get feedback from expert gamedevs, ideally with
> > > example of workflow involving custom normals (the only real one I found
> > so
> > > far is the "tree" one, which is very easy to implement as a modifier).
> I
> > > need to know whether solution II) (which covers 100% of the editing
> > needs in
> > > this area) is worth the work involved, or if solution I) (covering
> maybe
> > 90%
> > > of needs) could be enough?
> > >
> > > PS: Don't think I'll make builds, this has proved to be rather painful
> > and
> > > time consuming in the past (Blender uses many libs, hard to static-link
> > all
> > > that together), and building Blender is now very easy on every OS!
> >
> >
> >
> > --
> > Piotr "MadMinstrel" Adamowicz
> > padamowicz at gmail.com
> > _______________________________________________
> > Bf-gamedev mailing list
> > Bf-gamedev at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-gamedev
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
>
> http://lists.blender.org/pipermail/bf-gamedev/attachments/20131101/ae841d5b/attachment.htm
>
> ------------------------------
>
> _______________________________________________
> Bf-gamedev mailing list
> Bf-gamedev at blender.org
> http://lists.blender.org/mailman/listinfo/bf-gamedev
>
>
> End of Bf-gamedev Digest, Vol 3, Issue 3
> ****************************************
>
> _______________________________________________
> Bf-gamedev mailing list
> Bf-gamedev at blender.org
> http://lists.blender.org/mailman/listinfo/bf-gamedev
>

-- 
//Robin Karlsson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-gamedev/attachments/20131102/ec59caee/attachment-0001.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Triangulate_mod_prop.png
Type: image/png
Size: 44693 bytes
Desc: not available
Url : http://lists.blender.org/pipermail/bf-gamedev/attachments/20131102/ec59caee/attachment-0001.png 