[Bf-gamedev] Triangulation Modifier changes, and feedback
Katsbits.com
info at katsbits.com
Sat Nov 2 00:06:19 CET 2013
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
****************************************
More information about the Bf-gamedev
mailing list