Problem with face orientation on STL file

[Daniel Scott Matthews]

I grabbed the skull from here,
http://www.thingiverse.com/download:1967
(http://www.thingiverse.com/thing:827) but when I used the STL mesh
reader I found that some of the faces, such as in the eye sockets, are
reversed. SDS and CatmullClark created a nasty mess of it too.

Is this an invalid STL file, or is the read breaking things?

BTW there are all sorts of interesting "free" bits of geometry on
thingiverse.com check it out.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[Timothy M. Shead]

Daniel Scott Matthews wrote:
> I grabbed the skull from here,
> http://www.thingiverse.com/download:1967
> (http://www.thingiverse.com/thing:827) but when I used the STL mesh
> reader I found that some of the faces, such as in the eye sockets, are
> reversed. SDS and CatmullClark created a nasty mess of it too.
>
> Is this an invalid STL file, or is the read breaking things?

My first assumption is that that's the way the data is organized.
Whether that makes it a valid STL file or not is an open question - I
don't know what guarantees (if any) STL makes about polygon orientation.
   Bart?

Cheers,
Tim


[tshead.vcf]

---

begin:vcard
fn:Timothy Shead
n:Shead;Timothy
org:www.k-3d.org
email;internet:tshead@...
title:Founder
x-mozilla-html:FALSE
version:2.1
end:vcard

---

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[bART Janssens-2]

On Sat, Aug 15, 2009 at 5:19 PM, Timothy M. Shead<tshead@...> wrote:
> My first assumption is that that's the way the data is organized. Whether
> that makes it a valid STL file or not is an open question - I don't know
> what guarantees (if any) STL makes about polygon orientation.  Bart?

I've been looking at this today. My first guess was that the problem
was that the  STL reader ignores normal data, but taking this into
account did not help, so the file appears to be wrong here. It should
be possible to fix this automatically, I'll start experimenting with a
new plugin for this.

Cheers,

--
Bart

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[Timothy M. Shead]

Bart Janssens wrote:

> On Sat, Aug 15, 2009 at 5:19 PM, Timothy M. Shead<tshead@...> wrote:
>> My first assumption is that that's the way the data is organized. Whether
>> that makes it a valid STL file or not is an open question - I don't know
>> what guarantees (if any) STL makes about polygon orientation.  Bart?
>
> I've been looking at this today. My first guess was that the problem
> was that the  STL reader ignores normal data, but taking this into
> account did not help, so the file appears to be wrong here. It should
> be possible to fix this automatically, I'll start experimenting with a
> new plugin for this.

Having a modifier do this is the right thing, but getting the behavior
correct will be tricky, since it needs (as always) to be deterministic.
  How do you plan to decide which orientation is "right"?

Cheers,
Tim


[tshead.vcf]

---

begin:vcard
fn:Timothy Shead
n:Shead;Timothy
org:www.k-3d.org
email;internet:tshead@...
title:Founder
x-mozilla-html:FALSE
version:2.1
end:vcard

---

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[bART Janssens-2]

On Sat, Aug 15, 2009 at 6:02 PM, Timothy M. Shead<tshead@...> wrote:
> Having a modifier do this is the right thing, but getting the behavior
> correct will be tricky, since it needs (as always) to be deterministic.  How
> do you plan to decide which orientation is "right"?

The outline of the mechanism I had in mind was:
- Choose a face F with the right orientation
- Using companions, follow along the shell until you reach a boundary
- On the boundary, check if there are identical edges (i.e. edges with
the same start and end) belonging to a different face
- If such edges exist, expand from their face using companions and
flip the orientations of these faces

The method to choose the face with the right orientation could be a
property, or it could always be face 0, and if this happens to be
wrong the user has to apply FlipOrientation afterwards.
We could also start from all selected faces, which is more
user-friendly and more robust in case the mesh has multiple shells,
but problematic in case a right and a wrong face on the same shell are
selected.

Cheers,

--
Bart

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[Timothy M. Shead]

Bart Janssens wrote:

> On Sat, Aug 15, 2009 at 6:02 PM, Timothy M. Shead<tshead@...> wrote:
>> Having a modifier do this is the right thing, but getting the behavior
>> correct will be tricky, since it needs (as always) to be deterministic.  How
>> do you plan to decide which orientation is "right"?
>
> The outline of the mechanism I had in mind was:
> - Choose a face F with the right orientation
> - Using companions, follow along the shell until you reach a boundary
> - On the boundary, check if there are identical edges (i.e. edges with
> the same start and end) belonging to a different face
> - If such edges exist, expand from their face using companions and
> flip the orientations of these faces
>
> The method to choose the face with the right orientation could be a
> property, or it could always be face 0, and if this happens to be
> wrong the user has to apply FlipOrientation afterwards.
> We could also start from all selected faces, which is more
> user-friendly and more robust in case the mesh has multiple shells,
> but problematic in case a right and a wrong face on the same shell are
> selected.

I agree that using selection to explicitly designate correctly oriented
faces is the way to go.  If the user picks conflicting sides, the right
thing to do is bail-out with error messages.

As an aside, keep in mind that you wouldn't have to have separate shells
to have disconnected components in a polyhedron - create a PolyGrid and
delete a row of faces down the middle - you now have to separate sets of
faces, in a single shell.

It's also worth mentioning that this is a type of breadth first search.

Cheers,
Tim

[tshead.vcf]

---

begin:vcard
fn:Timothy Shead
n:Shead;Timothy
org:www.k-3d.org
email;internet:tshead@...
title:Founder
x-mozilla-html:FALSE
version:2.1
end:vcard

---

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[bART Janssens-2]

On Sun, Aug 16, 2009 at 2:14 AM, Timothy M. Shead<tshead@...> wrote:
> I agree that using selection to explicitly designate correctly oriented
> faces is the way to go.  If the user picks conflicting sides, the right
> thing to do is bail-out with error messages.

OK, the plugin is in my repository now. I have further simplified it,
and now all it does is flip the orientation of "shells" that don't
have any selected faces. A "shell" in this context is any connected
set of faces, regardless of shells definitions in the mesh structure.
As it turns out, the skull is badly connected, and applying the
original algorithm did not work. I wonder if instead of this
FixOrientation plugin, it would be better to have an
ExpandFaceSelectionToShell plugin (similar to GrowSelection - not sure
if it does exactly the same). The workflow would then be:
- Select a correctly-oriented face
- Apply ExpandFaceSelectionToShell
- Invert the selection
- Apply FlipOrientation (which is converted to the new structure in my
repository)

> It's also worth mentioning that this is a type of breadth first search.
I used a recursive function for this, I hope that scales to millions
of edges... If not, I'll re-implement it as a loop.

Cheers,

--
Bart

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[Daniel Scott Matthews]

On Tue, Aug 18, 2009 at 7:33 AM, Bart Janssens<bart.janssens@...> wrote:

> On Sun, Aug 16, 2009 at 2:14 AM, Timothy M. Shead<tshead@...> wrote:
>> I agree that using selection to explicitly designate correctly oriented
>> faces is the way to go.  If the user picks conflicting sides, the right
>> thing to do is bail-out with error messages.
>
> OK, the plugin is in my repository now. I have further simplified it,
> and now all it does is flip the orientation of "shells" that don't
> have any selected faces. A "shell" in this context is any connected
> set of faces, regardless of shells definitions in the mesh structure.
> As it turns out, the skull is badly connected, and applying the
> original algorithm did not work. I wonder if instead of this
> FixOrientation plugin, it would be better to have an
> ExpandFaceSelectionToShell plugin (similar to GrowSelection - not sure
> if it does exactly the same). The workflow would then be:
> - Select a correctly-oriented face
> - Apply ExpandFaceSelectionToShell
> - Invert the selection
> - Apply FlipOrientation (which is converted to the new structure in my
> repository)
>
>> It's also worth mentioning that this is a type of breadth first search.
> I used a recursive function for this, I hope that scales to millions
> of edges... If not, I'll re-implement it as a loop.
>

Thanks Bart that is going to be a big help. Your workflow gave me an
idea, could you have a python script that is called
from a menu (and has an icon) which can make a text message hover over
the cursor that says "select a correctly oriented face" then once the
user clicks on the face the workflow is applied to the shell that the
face belongs to?

This guiding-macro approach would take K-3D to another level in terms of HCI.

Perhaps there should be a new menu called "Production Methods"?

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[Timothy M. Shead]

Bart Janssens wrote:
> On Sun, Aug 16, 2009 at 2:14 AM, Timothy M. Shead<tshead@...> wrote:
>> I agree that using selection to explicitly designate correctly oriented
>> faces is the way to go.  If the user picks conflicting sides, the right
>> thing to do is bail-out with error messages.
>
> OK, the plugin is in my repository now. I have further simplified it,
> and now all it does is flip the orientation of "shells" that don't
> have any selected faces. A "shell" in this context is any connected
> set of faces, regardless of shells definitions in the mesh structure.

Not trying to be annoying here, but it's my nature so it comes out that
way - you can't overload "shell" to mean whatever you want.  Shells have
a specific definition, see

http://www.cs.mtu.edu/~shene/COURSES/cs3621/NOTES/model/euler.html

Could you please update your implementation so we're using consistent
terminology to avoid future confusion?  I suggest "connected faces" or
(more generally) "connected components" ... see

http://en.wikipedia.org/wiki/Connected_component_(graph_theory)

for the connection to graph theory.

> As it turns out, the skull is badly connected, and applying the
> original algorithm did not work. I wonder if instead of this
> FixOrientation plugin, it would be better to have an
> ExpandFaceSelectionToShell plugin (similar to GrowSelection - not sure
> if it does exactly the same). The workflow would then be:

GrowSelection expands the selection outward by one "hop".  What you want
in this case doesn't exist in K-3D, which would be "select connected
components" (graphs again).

Cheers,
Tim


[tshead.vcf]

---

begin:vcard
fn:Timothy Shead
n:Shead;Timothy
org:www.k-3d.org
email;internet:tshead@...
title:Founder
x-mozilla-html:FALSE
version:2.1
end:vcard

---

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[Timothy M. Shead]

Daniel Scott Matthews wrote:

> Thanks Bart that is going to be a big help. Your workflow gave me an
> idea, could you have a python script that is called
> from a menu (and has an icon) which can make a text message hover over
> the cursor that says "select a correctly oriented face" then once the
> user clicks on the face the workflow is applied to the shell that the
> face belongs to?

This wouldn't work today, because the UI event loop is stopped while the
script is executing.  FWIW, this is the same technical hurdle faced by
any "scripted tool".  It's definitely something we want to address in 0.9.

Cheers,
Tim

[tshead.vcf]

---

begin:vcard
fn:Timothy Shead
n:Shead;Timothy
org:www.k-3d.org
email;internet:tshead@...
title:Founder
x-mozilla-html:FALSE
version:2.1
end:vcard

---

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[bART Janssens-2]

On Tue, Aug 18, 2009 at 4:33 AM, Timothy M. Shead<tshead@...> wrote:
> Not trying to be annoying here, but it's my nature so it comes out that way
> - you can't overload "shell" to mean whatever you want.

OK, no problem, I'll change the terminology. I will note, however,
that shell as used in the polyhedron primitive doesn't adhere to the
definition, either (and I'm still not convinced we need explicit
shells at all in the polyhedron structure, but that's another story
and not really important right now).

As for the FixOrientation plugin, I'm leaning towards removing it in
favor of a SelectConnectedComponents plugin. This will allow any
operation on a set of connected components, including flipping its
normals.

Cheers,

--
Bart

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[bART Janssens-2]

On Tue, Aug 18, 2009 at 12:15 AM, Daniel Scott
Matthews<dsmatthews@...> wrote:
> idea, could you have a python script that is called
> from a menu (and has an icon) which can make a text message hover over
> the cursor that says "select a correctly oriented face" then once the
> user clicks on the face the workflow is applied to the shell that the
> face belongs to?

As Tim has planned, the UI will be tackled in 0.9. I expect that part
of this will include the possibility for plugins to define what sort
of manipulators they need in the viewport, and the hovering text you
mention could be such a manipulator.

Cheers,

--
Bart

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[Timothy M. Shead]

Bart Janssens wrote:
> On Tue, Aug 18, 2009 at 4:33 AM, Timothy M. Shead<tshead@...> wrote:
>> Not trying to be annoying here, but it's my nature so it comes out that way
>> - you can't overload "shell" to mean whatever you want.
>
> OK, no problem, I'll change the terminology. I will note, however,
> that shell as used in the polyhedron primitive doesn't adhere to the
> definition, either (and I'm still not convinced we need explicit
> shells at all in the polyhedron structure, but that's another story
> and not really important right now).

Can you show me where?  I admit that we don't actually have any
documentation stating the definition of a shell, but I don't know of any
(current) code that doesn't fit the current definition.  MergeMesh and
the ArrayFOO plugins prior to generic primitive refactoring would fit in
that category.

As an aside, we now have wiki pages for every primitive type, so I will
start adding to

http://www.k-3d.org/wiki/Polyhedron_Primitive

> As for the FixOrientation plugin, I'm leaning towards removing it in
> favor of a SelectConnectedComponents plugin. This will allow any
> operation on a set of connected components, including flipping its
> normals.

Sounds good!

Cheers,
Tim

[tshead.vcf]

---

begin:vcard
fn:Timothy Shead
n:Shead;Timothy
org:www.k-3d.org
email;internet:tshead@...
title:Founder
x-mozilla-html:FALSE
version:2.1
end:vcard

---

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[bART Janssens-2]

On Wed, Aug 19, 2009 at 7:49 AM, Timothy M. Shead<tshead@...> wrote:
> Can you show me where?  I admit that we don't actually have any
> documentation stating the definition of a shell, but I don't know of any
> (current) code that doesn't fit the current definition.  MergeMesh and the
> ArrayFOO plugins prior to generic primitive refactoring would fit in that
> category.

Well, the fact that a shel should enclose a solid is not enforced
anywhere. Any mesh with a boundary, such as the PolyGrid, does not fit
the definition, it seems to me.

>> As for the FixOrientation plugin, I'm leaning towards removing it in
>> favor of a SelectConnectedComponents plugin. This will allow any
>> operation on a set of connected components, including flipping its
>> normals.

This is in my repository now. I've also converted GrowSelection to the
new mesh structure. The skull.stl file is very bad, however. For
starters, it contains every face three times, so I've updated the
STLMeshReader to skip duplicate faces. Tinkering with it further, I
believe it is not 2-manifold, and SelectConnectedComponents does not
work very well as a consequence.

Cheers,

--
Bart

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[Timothy M. Shead]

Bart Janssens wrote:

> On Wed, Aug 19, 2009 at 7:49 AM, Timothy M. Shead<tshead@...> wrote:
>> Can you show me where?  I admit that we don't actually have any
>> documentation stating the definition of a shell, but I don't know of any
>> (current) code that doesn't fit the current definition.  MergeMesh and the
>> ArrayFOO plugins prior to generic primitive refactoring would fit in that
>> category.
>
> Well, the fact that a shel should enclose a solid is not enforced
> anywhere. Any mesh with a boundary, such as the PolyGrid, does not fit
> the definition, it seems to me.

If you look at my definition in

http://www.k-3d.org/wiki/Polyhedron_Primitive

I've already reflected this.  Also to be fair, you could make the same
statement about loops - nothing enforces the fact that they must enclose
the outer boundary of a face.

>>> As for the FixOrientation plugin, I'm leaning towards removing it in
>>> favor of a SelectConnectedComponents plugin. This will allow any
>>> operation on a set of connected components, including flipping its
>>> normals.
>
> This is in my repository now. I've also converted GrowSelection to the
> new mesh structure. The skull.stl file is very bad, however. For
> starters, it contains every face three times, so I've updated the
> STLMeshReader to skip duplicate faces. Tinkering with it further, I
> believe it is not 2-manifold, and SelectConnectedComponents does not
> work very well as a consequence.

Merged into the main repo, but I don't think that STLMeshReader should
have to do this - shouldn't "RemoveDuplicateFaces" be a filter of its own?

Cheers,
Tim


[tshead.vcf]

---

begin:vcard
fn:Timothy Shead
n:Shead;Timothy
org:www.k-3d.org
email;internet:tshead@...
title:Founder
x-mozilla-html:FALSE
version:2.1
end:vcard

---

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[Daniel Scott Matthews]

On Mon, Aug 24, 2009 at 3:38 AM, Timothy M. Shead<tshead@...> wrote:
> Merged into the main repo, but I don't think that STLMeshReader should have
> to do this - shouldn't "RemoveDuplicateFaces" be a filter of its own?

Both are good, mesh importers should provide the best data that is
possible but it is also good to have a user accessible set of mesh
cleaning tools. Perhaps one CleanMesh node with different "filters"
that can be tweaked and toggled?

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[Timothy M. Shead]

Daniel Scott Matthews wrote:
> On Mon, Aug 24, 2009 at 3:38 AM, Timothy M. Shead<tshead@...> wrote:
>> Merged into the main repo, but I don't think that STLMeshReader should have
>> to do this - shouldn't "RemoveDuplicateFaces" be a filter of its own?
>
> Both are good, mesh importers should provide the best data that is
> possible but it is also good to have a user accessible set of mesh
> cleaning tools. Perhaps one CleanMesh node with different "filters"
> that can be tweaked and toggled?

I would nuance this as follows :)

* Mesh readers need to do the minimum amount of processing necessary to
produce a valid K-3D data structure.  Beyond that, it's up to the user.

* I will always be repetitive about this: instead of one big node,
multiple nodes.

* Loading meshes needs to be driven by a "wizard" that hooks up the
(hypothetical) pipeline, so that users interact with a familiar "File >
Open" type interface.  This abstracts away the distinction between
importers and readers at a UI level (which is a big source of support
requests), and can provide a friendly UI: "I see that your mesh contains
duplicate polygons, Dave ... would you like me to eliminate them?", etc.

Cheers,
Tim

[tshead.vcf]

---

begin:vcard
fn:Timothy Shead
n:Shead;Timothy
org:www.k-3d.org
email;internet:tshead@...
title:Founder
x-mozilla-html:FALSE
version:2.1
end:vcard

---

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[bART Janssens-2]

> If you look at my definition in
>
> http://www.k-3d.org/wiki/Polyhedron_Primitive
>
> I've already reflected this.  Also to be fair, you could make the same
> statement about loops - nothing enforces the fact that they must enclose the
> outer boundary of a face.

OK, that definition is good, but since you've been doing a lot of work
on the primitives again, I think we should discuss the usefulness of
shells again. This was last discussed in January (see
http://sourceforge.net/mailarchive/message.php?msg_name=cf05e15e0901241558u5fcf5ad5kbed714fc5d46e894%40mail.gmail.com)
but we never reached a conclusion.

As far as I know, none of our plugins currently take advantage of
shells, so removing them from the structure seems like a reasonable
simplification.

Cheers,

--
Bart

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[bART Janssens-2]

On Mon, Aug 24, 2009 at 6:19 AM, Timothy M. Shead<tshead@...> wrote:
> * I will always be repetitive about this: instead of one big node, multiple
> nodes.
>
> * Loading meshes needs to be driven by a "wizard" that hooks up the
> (hypothetical) pipeline, so that users interact with a familiar "File >
> Open" type interface.  This abstracts away the distinction between importers
> and readers at a UI level (which is a big source of support requests), and
> can provide a friendly UI: "I see that your mesh contains duplicate
> polygons, Dave ... would you like me to eliminate them?", etc.

OK, I agree this is the best way forward. I'll let this rest now
though, to concentrate on the painters.

Cheers,

--
Bart

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[Timothy M. Shead]

Bart Janssens wrote:

>> If you look at my definition in
>>
>> http://www.k-3d.org/wiki/Polyhedron_Primitive
>>
>> I've already reflected this.  Also to be fair, you could make the same
>> statement about loops - nothing enforces the fact that they must enclose the
>> outer boundary of a face.
>
> OK, that definition is good, but since you've been doing a lot of work
> on the primitives again, I think we should discuss the usefulness of
> shells again. This was last discussed in January (see
> http://sourceforge.net/mailarchive/message.php?msg_name=cf05e15e0901241558u5fcf5ad5kbed714fc5d46e894%40mail.gmail.com)
> but we never reached a conclusion.
>
> As far as I know, none of our plugins currently take advantage of
> shells, so removing them from the structure seems like a reasonable
> simplification.

There's a certain circularity to this argument - if you remove shells,
they definitely won't get used.  Remember that most modifiers can (and
already do) trivially work with shells, since they're volume-unaware,
and were already written for a world in which a single mesh contains
multiple polyhedra.  Codes that care about volumes, including CSG and
scientific visualization, will benefit from them in the long run.

FWIW, I used to have similar feelings about face holes - what was the
point of storing them explicitly, particularly when a face with a hole
as can be represented using a single polygon?  See

http://www.k-3d.org/k3d_wiki/images/a/a9/Holes_or_Not.svg)

Answer: the latter approach is too low-level.  Yes, it is simpler and
can be rendered, but it is a false simplicity: it causes significant
headaches for modeling operations because many operations (think
BevelEdges) will produce incorrect results.  Consider a simple use-case
in a world without shells: calculating the volume of a mesh (this isn't
a made-up example, GTSMeshVolume already exists to do this).  Without
shells, how will you know which parts of the volume are voids?

The moral: explicit is better (and truly simpler) than implicit.

Cheers,
Tim

[tshead.vcf]

---

begin:vcard
fn:Timothy Shead
n:Shead;Timothy
org:www.k-3d.org
email;internet:tshead@...
title:Founder
x-mozilla-html:FALSE
version:2.1
end:vcard

---

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development