[Bf-committers] New mesh data type

[Matt Ebb]

--Apple-Mail-2-1069210494
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=ISO-8859-1;
	format=flowed

Just a few feature requests/considerations that are often mentioned by=20=

users. I don't know how feasible it is, but anyway if it's meant to be=20=

a long term solution, it'd help to keep these in mind.

Often requested are:
* > 4 sided polys (helps a lot when using edge loop modelling=20
techniques)
* Individual vertex/edge/face selection (i.e. not like the current=20
system where selecting 3 edges will select the whole face). I know=20
you're looking for something that contains separate edge data - can=20
face selection be derived from the edge selection (rather than vertex=20
selection, as it is now), in a way that doesn't have the same problems=20=

as the current mesh system?



On 18 Dec 2003, at 2:06 PM, Matthew H. Plough wrote:

> Hi all --
> =A0
> You probably don't remember what I'm talking about since I last wrote=20=

> about this on November 25, but I've been researching a new mesh data=20=

> structure because of a subdivision surface project I'm working on.=A0
> =A0
> First, the underlying reason for my mesh rewrite:
> I have been working on a modification to Blender's subdivision=20
> surfaces that allows semi-sharp subdivision to happen when the user=20
> marks certain edges as creases.=A0 I successfully implemented this =
code=20
> in Tuhopuu about a month ago, and today finished adding it to the=20
> official BF tree.=A0 However, Blender=A0does not store data about =
edges,=20
> so the current implementation only allows the user to modify the sharp=20=

> subdivision level of entire meshes.=A0 This is great for beveling, but=20=

> now that real beveling code has been added, my limited implementation=20=

> is rather useless.=A0
> =A0
> Second, information about the mesh rewrite:
> Therefore, I propose the addition of a mesh data type that can coexist=20=

> with the current implementation, as per Ton's recommendation.=A0 The =
new=20
> data type will need to store data about all edges in the mesh=20
> explicitly, so that the sharp subdivision level can be set on a=20
> per-edge basis.=A0
> =A0
> The most basic data structure that includes edges is a structure that=20=

> stores vertex geometry, and a face list and edge list that each=20
> references the vertex list.=A0 Although such a data structure is =
small,=20
> it does not have any benefit besides the ability to store information=20=

> about edges.=A0
> =A0
> Ton writes, however,
> The data representation type could be designed in two steps:
>
> 1. A compact & simple, preferable compressed, format to store in=20
> memory=A0
> and save in files. Preferably consisting out of as few data chunks as=A0=

> possible, and easily to parse for creating display lists and do=A0
> conversions.
> 2. A highly flexible and advanced 'editing format', for tools to=A0
> operate on. This fits within Blender's convention to have EditMode.
>
> By creating conversions to/from current Mesh data it can (eventually)=A0=

> become invisible for users, where internally this conversion just=A0
> happens automatically.
> This most basic data structure, then,=A0would be ideal for storage in =
a=20
> file or for storage outside of edit mode, as it would not include the=20=

> overhead of adjacency information.=A0 It would also be extremely easy =
to=20
> parse for display; the current display code could be reused verbatim.=A0=
=20
> Edge data would simply be ignored.=A0 The structure would also allow=20=

> easy parsing in the subsurf.c module, since the only addition would be=20=

> references to edge data.
> =A0
> A more advanced data structure would be needed in edit mode, and I=20
> have focused my research on determining what this structure should=20
> be.=A0 I immediately eliminated the winged edge, radial edge, and=20
> similar data structures as candidates for the new representation, as=20=

> they cannot represent open meshes or non-manifold meshes without heavy=20=

> modification.=A0 Two data structures of note have been designed to=20
> represent non-manifold or open meshes: the partial entity data=20
> structure, and the non-manifold indexed data structure with=20
> adjacencies (NMIA data structure).=A0 The NMIA data=A0structure is=20
> designed to scale with the degree of "non-manifoldness," a property=20
> that the partial entity structure does not possess.=A0
> =A0
> At first glance, then, the NMIA structure seemed ideal for the job.=A0=20=

> However, that structure does not encode data about alledges, a crucial=20=

> property.=A0 Although it would be smaller in memory than the partial=20=

> entity structure, the NMIA data structure cannot be used for the job!=A0=
=20
> I therefore decided that the partial entity structure should be used=20=

> instead; it does encode information about all edges, albeit at a=20
> higher memory cost.=A0 However, this cost is justified, as it will =
only=20
> be experienced while the user is editing a mesh.=A0
> =A0
> Ton, you'll be getting that email about how to write a new type=20
> shortly!
> =A0
> Please criticize this email as much as possible, since I'm designing=20=

> this for the long term.
> =A0
> Blend on!
> Matthew H. Plough

--Apple-Mail-2-1069210494
Content-Transfer-Encoding: quoted-printable
Content-Type: text/enriched;
	charset=ISO-8859-1

Just a few feature requests/considerations that are often mentioned by
users. I don't know how feasible it is, but anyway if it's meant to be
a long term solution, it'd help to keep these in mind.


Often requested are:

* > 4 sided polys (helps a lot when using edge loop modelling
techniques)

* Individual vertex/edge/face selection (i.e. not like the current
system where selecting 3 edges will select the whole face). I know
you're looking for something that contains separate edge data - can
face selection be derived from the edge selection (rather than vertex
selection, as it is now), in a way that doesn't have the same problems
as the current mesh system?




On 18 Dec 2003, at 2:06 PM, Matthew H. Plough wrote:


<excerpt><fontfamily><param>Arial</param><smaller>Hi all =
--</smaller></fontfamily>

=A0

<fontfamily><param>Arial</param><smaller>You probably don't remember
what I'm talking about since I last wrote about this on November 25,
but I've been researching a new mesh data structure because of a
subdivision surface project I'm working on.=A0</smaller></fontfamily>

=A0

<fontfamily><param>Arial</param><smaller>First, the underlying reason
for my mesh rewrite:</smaller></fontfamily>

<fontfamily><param>Arial</param><smaller>I have been working on a
modification to Blender's subdivision surfaces that allows semi-sharp
subdivision to happen when the user marks certain edges as creases.=A0 I
successfully implemented this code in Tuhopuu about a month ago, and
today finished adding it to the official BF tree.=A0 However,
Blender=A0does not store data about edges, so the current implementation
only allows the user to modify the sharp subdivision level of entire
meshes.=A0 This is great for beveling, but now that real beveling code
has been added, my limited implementation is rather =
useless.=A0</smaller></fontfamily>

=A0

<fontfamily><param>Arial</param><smaller>Second, information about the
mesh rewrite:</smaller></fontfamily>

<fontfamily><param>Arial</param><smaller>Therefore, I propose the
addition of a mesh data type that can coexist with the current
implementation, as per Ton's recommendation.=A0 The new data type will
need to store data about all edges in the mesh explicitly, so that the
sharp subdivision level can be set on a per-edge =
basis.=A0</smaller></fontfamily>

=A0

<fontfamily><param>Arial</param><smaller>The most basic data structure
that includes edges is a structure that stores vertex geometry, and a
face list and edge list that each references the vertex list.=A0
Although such a data structure is small, it does not have any benefit
besides the ability to store information about =
edges.=A0</smaller></fontfamily>

=A0

<fontfamily><param>Arial</param><smaller>Ton writes, =
however,</smaller></fontfamily>

The data representation type could be designed in two steps:


1. A compact & simple, preferable compressed, format to store in
memory=A0

and save in files. Preferably consisting out of as few data chunks as=A0=20=


possible, and easily to parse for creating display lists and do=A0=20

conversions.

2. A highly flexible and advanced 'editing format', for tools to=A0=20

operate on. This fits within Blender's convention to have EditMode.


By creating conversions to/from current Mesh data it can (eventually)=A0

become invisible for users, where internally this conversion just=A0=20

happens automatically.

<fontfamily><param>Arial</param><smaller>This most basic data
structure, then,=A0would be ideal for storage in a file or for storage
outside of edit mode, as it would not include the overhead of
adjacency information.=A0 It would also be extremely easy to parse for
display; the current display code could be reused verbatim.=A0 Edge data
would simply be ignored.=A0 The structure would also allow easy parsing
in the subsurf.c module, since the only addition would be references
to edge data.</smaller></fontfamily>

=A0

<fontfamily><param>Arial</param><smaller>A more advanced data
structure would be needed in edit mode, and I have focused my research
on determining what this structure should be.=A0 I immediately
eliminated the winged edge, radial edge, and similar data structures
as candidates for the new representation, as they cannot represent
open meshes or non-manifold meshes without heavy modification.=A0 Two
data structures of note have been designed to represent non-manifold
or open meshes: the partial entity data structure, and the
non-manifold indexed data structure with adjacencies (NMIA data
structure).=A0 The NMIA data=A0structure is designed to scale with the
degree of "non-manifoldness," a property that the partial entity
structure does not possess.=A0</smaller></fontfamily>

=A0

<fontfamily><param>Arial</param><smaller>At first glance, then, the
NMIA structure seemed ideal for the job.=A0 However, that structure does
not encode data about <italic>all</italic>edges, a crucial property.=A0
Although it would be smaller in memory than the partial entity
structure, the NMIA data structure cannot be used for the job!=A0 I
therefore decided that the partial entity structure should be used
instead; it does encode information about all edges, albeit at a
higher memory cost.=A0 However, this cost is justified, as it will only
be experienced while the user is editing a mesh.=A0</smaller></fontfamily>=


=A0

<fontfamily><param>Arial</param><smaller>Ton, you'll be getting that
email about how to write a new type shortly!</smaller></fontfamily>

=A0

<fontfamily><param>Arial</param><smaller>Please criticize this email
as much as possible, since I'm designing this for the long =
term.</smaller></fontfamily>

=A0

<fontfamily><param>Arial</param><smaller>Blend =
on!</smaller></fontfamily>

<fontfamily><param>Arial</param><smaller>Matthew H. =
Plough</smaller></fontfamily>

</excerpt>=

--Apple-Mail-2-1069210494--