Re: [rp-ml] STL files

From: Caleb at Chinook Sailing Products <purchasing_at_chinooksailing.com>
Date: Thu Dec 07 2006 - 18:27:14 EET

  Regarding the PLY format: It was also used as the primary mesh data format for Cyberware 3D laser scanners & seemed to be quite robust. Just from a software users perspective the files size was roughly half what the identical file would be in the BINARY STL format. Also it would seem to be be pretty easy write I/O support, after a quick request to Robert McNeel Assoc, they had Rhino reading & writing PLY the next day.

  ---------------------

  ----- Original Message -----
  From: Wesley Brooks
  To: steve
  Cc: rp-ml@rapid.lpt.fi
  Sent: Thursday, December 07, 2006 12:52 AM
  Subject: Re: [rp-ml] STL files

  PLY? This file format is something that I've come across when using the open source "Visualisation Toolkit - VTK" supported by Kitware. This was a project developed for the Human Visualisation Project, which I'm afraid I know very little about. What I do know is that having a heavy emphasis on Medical applications, it deals with slices of solids alot, almost doing the exact reverse of what I want at times.

  Anyway, going back to the three rules;

  1. All triangles much conform to the right hand rule
  2. All exterior surfaces must be devoid of gaps
  3. Each triangle must share two of its vertices with each adjacent triangle

  Should point three be changed to; 'Each triangle must share at most two of its vertices with each of the adjacent triangles'? Consider the simplest 3D shape that can be represented by triangles, a triangular base pyramid. In this case the rule holds. Go to a square based pyramid and you get triangles which share only one point, the sharp end of the pyramid.

  I guess there are enough high up staff from RP machine manufactures on this mailing list, why not add the ability to read in a new format such as a points and IDs style format? Keep everything public domain open source and review the standard yearly, in a similar way to large open source projects such as python are managed. If the software for the machines are written well all it would take is a simple bit of code to read in the new format, which would be smaller, and more robust. Here's a set of rules which are an obvious development on the first three;

  1. All triangles much conform to the right hand rule.
  2. All exterior surfaces must be devoid of gaps.
  3. Each triangle must share at most two of its points with each of the adjacent triangles.
  4. Where a triangle shares two points with an adjacent triangle the order of the points must be a-b on one triangle ID list, and b-a, on the other.
  5. Each point must be shared with at least three triangles.
  6. Each edge must be, and only be common to two triangles.

  These rules said there should also be a addition where by if 'surface' is in the header then the triangular mesh can be open, relaxing rules 2, 5, and 6.

  I agree with keeping to a triangular mesh format file for the time being, but I do believe it's time we stopped talking about it and started to propose a new format. Perhaps develop (or limit) an existing format such as those in VTK ( www.kitware.com)?

  If the format (let's say *.orm, Open - Rapid - Manufacture file), is decided on I guess it wouldn't take much to politely ask the main CAD package manufactures to include outputs for it in there software too?

  Cheers,

  Wesley Brooks

  On 07/11/06, steve <sjbaker1@airmail.net> wrote:
    ...snip...

    What you are describing is exactly what PLY does - except
    that you can squish the file still further by using quads
    and higher order polygons as well as triangles - and you
    can specify which vertex attributes there are and at what
    precision they are represented. (So you can have colours
    and/or texture coordinates, etc)

    PLY can also store 'List of Edges' so you can get a better
    handle on the topology of the model when cracks and gaps
    are a problem.

    But at the basics, what you laid out there was almost
    exactly what a minimal PLY file looks like.
Received on Thu Dec 07 17:23:08 2006

This archive was generated by hypermail 2.1.8 : Tue Jul 21 2009 - 10:27:52 EEST