[vtkusers] vtkTriangleStrip and empty vtkSTLWriter output

[Bill Lorensen]

I just submitted a merge request to add triangle strips to the writer.
https://gitlab.kitware.com/vtk/vtk/merge_requests/777

Dave C., I did not see your name as a reviewer on the gitlab site.

Bill

On Thu, Oct 15, 2015 at 1:17 PM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
> I looked at the STLWriter code:
>
> 1) It reports an error if a polygon is not a triangle.
> 2) It reports nothing if there are triangle strips.
>
> At a minimum I think it should handle triangle strips. No need to run
> triangle filter, I'll decompose the strips on the fly.
>
> Working on a patch and a unit test.
>
> Bill
>
> On Thu, Oct 15, 2015 at 9:45 AM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
>> I think the writer should handle triangle strips. I'll take a stab at adding
>> that functionality.
>>
>> On Oct 15, 2015 9:13 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
>
>
>
> --
> Unpaid intern in BillsBasement at noware dot com



-- 
Unpaid intern in BillsBasement at noware dot com