[vtkusers] vtkTriangleStrip and empty vtkSTLWriter output

Cory Quammen cory.quammen at kitware.com
Thu Oct 15 09:32:28 EDT 2015


In the case of the STL writer, I could anticipate a future email to this
list along the lines of "my poly data has only quads, but when I write it
to an STL file and load it in XYZ viewer it has been turned into triangles.
Why is this happening?" Or for the normals calculation, "I'm implementing a
cutting-edge new vis algorithm with wacky normals and they are getting
overwritten with plain old boring normals. Why is this happening?"

I think a warning/error is definitely needed to explain what is going on in
the STL writer, and Ben has provided that. That's not as clear for me in
the case of autogenerating normals. Should splitting be on? What feature
angle? etc.

Cory


On Thu, Oct 15, 2015 at 9:12 AM, Ben Boeckel <ben.boeckel at kitware.com>
wrote:

> On Wed, Oct 14, 2015 at 22:34:25 -0400, David Cole via vtkusers wrote:
> > Shouldn't the STL writer detect that its input contains non-triangles,
> and
> > **automatically** insert a triangle filter to produce correct output? Or,
> > at the very least, spit out an error message saying "here, insert this
> code
> > before calling Update/Write, and it will work like you want it to" ... ?
>
> Well, it used to drop vertices past the third on the floor (silently),
> but now it should be erroring out about non-triangles at least:
>
>     commit 9a00db82900bd15442cc471143c4e5dd1ac09a2d
>     Author: Ben Boeckel <ben.boeckel at kitware.com>
>     Date:   Tue Feb 25 17:16:58 2014 -0500
>
>         STLWriter: Raise an error for non-triangles
>
>         The STL format only supports triangles and previously, it just
>         truncated polygons silently. Cause an error to occur when this
>         happens so that users know.
>
>         Change-Id: I9c2f96d887074943130a8442d6796cb0c2ce1bbf
>
> The commit is in VTK 6.2.0.
>
> > (Similarly for rendering crappy polydata using the polydata mapper: it
> > requires up-to-date normals to render with proper lighting and shading,
> and
> > seems like the perfect candidate for **automatically** inserting a
> polydata
> > normals filter. This might be harder to detect that the normals are not
> up
> > to date, but sure would have saved my team some time recently...)
>
> It should error out like the STL writer for bad input at the least.
>
> > Would these types of improvements be welcome additions to VTK, or am I
> > missing some case where you would NOT want this type of behavior?
>
> As long as it lets you know that your data is bad and that (and how) it
> is being fixed is warned about, I don't see any reason why such an
> auto-fixer filter couldn't exist (whether it is named vtkSTLWriter or
> something else is a different question I don't have enough feel too
> strongly about).
>
> --Ben
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the VTK FAQ at:
> http://www.vtk.org/Wiki/VTK_FAQ
>
> Search the list archives at: http://markmail.org/search/?q=vtkusers
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtkusers
>



-- 
Cory Quammen
R&D Engineer
Kitware, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtkusers/attachments/20151015/9c296df9/attachment.html>


More information about the vtkusers mailing list