I have a question concerning the polyhedra objects I have recently been
amassing. Silly me, I haven't been creating the include files with the object
collection in mind, and there are A LOT of include files.

I have organised the polyhedra into groups (Platonic, Archimedean etc). Each
group has a main include file, which has a list of everything defined in that
group and another set of includes. Each polyhedron then has its own separate
include file, which defines three macros and a global vertex array. In this
way, one can include individual shapes without having to include the whole lot,
or a whole group without having to manually list the whole lot. I've been
putting the groups into separate directories for convenience, although this
needn't be compulsory. The macros and arrays are all prefixed by the shape name
and an underscore (e.g., tetrahedron_faces(), tetrahedron_edges() etc), and each
include file is named for this prefix.

My question is, therefore (and eventually!), is this layout sufficient for
inclusion in the object library? It feels sensible to submit each group as a
separate item, but the prefixes are per shape-include, not per group. Also, as
there are so many files per group (92 shapes for the Johnson solids, for
example) it might be better to submit a .zip file - is this supported by the
submission system?

Any advice..? :-)

Bill


(I'm also happy to host them on my own site, but this of course defeats the
purpose of the object collection...)

Post a reply to this message

IMO you should group the objects into a smaller amount of include files
rather than having every single one in its own file (unless the files are
very large, which I think is not the case with such simple objects). While
parsing an include file with dozens of objects might take slightly longer,
it's not that bad (as long as you don't go overboard). Just group all the
polyhedra into logical categories, and create one include file for each
such category. Then maybe an include file which just includes all those
separate include files.

  Also, if you haven't done so, I think all the polyhedra should be scaled
to fit the same space, for consistency. For example, they could be scaled
so that they all fit perfectly inside a box from <-1, -1, -1> to <1, 1, 1>.
This way it's easy for the user to scale any polyhedron to the size he needs.

  Also, I don't know how you have thought about defining the objects, but
you could do two things:

  1) #define each polyhedron as its own identifier, named logically and
consistently.

  2) For each category, create an array with all the polyhedra of that
category, ordered in some logical way.

  This way the user can use either the name of the polyhedron directly,
or index that array, as needed.

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
>   Also, if you haven't done so, I think all the polyhedra should be scaled
> to fit the same space, for consistency. For example, they could be scaled
> so that they all fit perfectly inside a box from <-1, -1, -1> to <1, 1, 1>.
> This way it's easy for the user to scale any polyhedron to the size he needs.

.... or not. There's also reason to scale them so all edges are 1 unit in length
(which however gives rise to the question whether they should be seated on the
y=0 plane, or centered around <0,0,0>), or - in case of regular polyhedra - so
that all vertices are at 1 unit distance from the center.

Interesting question, btw: Is there a way to access the individual vertex
coordinates?

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> IMO you should group the objects into a smaller amount of include files
> rather than having every single one in its own file (unless the files are
> very large, which I think is not the case with such simple objects).

Many of them are very simple, but the larger ones can be quite complex. Each
include file contains the vertices in a global array (for the advanced user)
and three macros for instantiating the shape; most of the stellar icosahedra
includes are 1200+ lines.

> Just group all the
> polyhedra into logical categories, and create one include file for each
> such category. Then maybe an include file which just includes all those
> separate include files.

That'll probably work. There are some logical sub-groups in the Johnsons, but
the stellar icosahedra don't really have any sub-groups. If I put them all
together it could be several MB for the include... not too bad compared to a
big converted mesh2 I suppose.

>   Also, if you haven't done so, I think all the polyhedra should be scaled
> to fit the same space, for consistency. For example, they could be scaled
> so that they all fit perfectly inside a box from <-1, -1, -1> to <1, 1, 1>.
> This way it's easy for the user to scale any polyhedron to the size he needs.

I can add this with no problems, I think. Most of them are already approximately
scaled like this anyway.

>   1) #define each polyhedron as its own identifier, named logically and
> consistently.

I have three macros per shape. Faces (taking texture identifiers for polygon
types by number of sides), faces (no textures) and edges (textures and radii
for the edge cylinders and vertex spheres). Each macro also takes a yes/no for
sitting the shape on the x-z plane (it is centred on the origin otherwise). I
thought I could leave it to the user to combine faces and edges for themselves.

>   2) For each category, create an array with all the polyhedra of that
> category, ordered in some logical way.

This is something I already thought of - invaluable for rendering them in
groups, as I have been doing.

What about the prefixes though? Even if I put them together in one file, there's
a lot of renaming to do for perfect library standards compliance...!

Post a reply to this message

Firstly: thank you for your efforts and generosity in sharing the files!

Why don't you just post what you have got so far somewhere - whereever - 
just not yet in the object collection. Maybe on rapidshare, if you fear for 
the traffic it might generate.You might drop a link here.

Then we all could have a closer look at the sources, since I do not have the 
faintest idea how large or small, how complex or how trivial (in case of a 
tetraeder, cube etc. ;-) the files and data may be. So everybody interested 
in the discussion could have a look and make some comments based on facts 
instead of guesswork how the actual files do look.

Then you could consider all the arguments and decide what to do.

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> Warp <war### [at] tagpovrayorg> wrote:
> >   Also, if you haven't done so, I think all the polyhedra should be scaled
> > to fit the same space, for consistency. For example, they could be scaled
> > so that they all fit perfectly inside a box from <-1, -1, -1> to <1, 1, 1>.
> > This way it's easy for the user to scale any polyhedron to the size he needs.
>
> .... or not. There's also reason to scale them so all edges are 1 unit in
> length

I thought about it, but it seemed overkill. Also, this wouldn't apply to the
stellar forms, since many of them are composed of highly irregular polygons.

> (which however gives rise to the question whether they should be seated on the
> y=0 plane, or centered around <0,0,0>)

Taken care of - see my reply to Warp.

> or - in case of regular polyhedra - so
> that all vertices are at 1 unit distance from the center.

I could be wrong, but I think that only applies to the Platonics.

> Interesting question, btw: Is there a way to access the individual vertex
> coordinates?

Yes - see my reply to Warp.

Many of your suggestions become possible by having access to the vertices, of
course!

:-)

Post a reply to this message

"Bill Pragnell" <bil### [at] hotmailcom> wrote in message 
news:web.4a66345af9355cc2d5649c20@news.povray.org...
>I have a question concerning the polyhedra objects I have recently been
> amassing. Silly me, I haven't been creating the include files with the 
> object
> collection in mind, and there are A LOT of include files.
>
> I have organised the polyhedra into groups (Platonic, Archimedean etc). 
> Each
> group has a main include file, which has a list of everything defined in 
> that
> group and another set of includes. Each polyhedron then has its own 
> separate
> include file, which defines three macros and a global vertex array. In 
> this
> way, one can include individual shapes without having to include the whole 
> lot,
> or a whole group without having to manually list the whole lot. I've been
> putting the groups into separate directories for convenience, although 
> this
> needn't be compulsory. The macros and arrays are all prefixed by the shape 
> name
> and an underscore (e.g., tetrahedron_faces(), tetrahedron_edges() etc), 
> and each
> include file is named for this prefix.
>
> My question is, therefore (and eventually!), is this layout sufficient for
> inclusion in the object library? It feels sensible to submit each group as 
> a
> separate item, but the prefixes are per shape-include, not per group. 
> Also, as
> there are so many files per group (92 shapes for the Johnson solids, for
> example) it might be better to submit a .zip file - is this supported by 
> the
> submission system?
>

These objects would be a great addition to the collection.
To answer your technical questions about the site:


File Names:
The upload scripts check that all files start with either the name of the 
submission (e.g. "Polyhedra"), or a prefix that you can define (e.g. 'P'). 
This would mean that a file called 'tetrahedron.inc' would need to be 
renamed 'p_tetrahedron.inc' or 'polyhedra_tetrahedron.inc', otherwise the 
upload screen will raise an error.

SubDirectories:
Web browsers don't allow you to select a folder in the file upload screen 
associated with a file field on a web page (or at least none of the web 
browsers I've ever come across). The submission screen doesn't currently 
provide any functionality to create subfolders within a single entry. OTOH, 
if memory serves me correctly, I coded the server-side code to support 
sub-directories. So if it makes most sense to organize them that way, I can 
probably upload the directory structure for you (I'd need to do some testing 
first to verify that this works ok).

ZIP Files:
The upload scripts don't accept 'zip' files, only files with extensions 
'BMP, CSS, CSV, GIF, HTM, HTML, INC, INI, JPEG, JPG, JS, MAC, MCR, MDL, PGM, 
PNG, POV, PPM, TGA, TIF, TIFF, TXT'. This is intended to reduce the risk of 
harmful content being uploaded.

Identifier Names:
Variable and Macro names are less critical. The scripts do allow you to 
upload files containing non-standard identifiers. The aim of the standards 
is to avoid naming collisions for people using the files. It would therefore 
be preferable to rename them, for example 'P_tetrahedron_faces()'. In any 
case it is a POV-Ray convention to start identifier names with an uppercase 
letter as I believe that names starting with lowercase letters are all 
reserved for future versions of POV-Ray.


If you'd like help renaming files and variables for this impressive 
collection of shapes, then I'd like to offer you my assistance. I'm quite 
adept with editors and editor/OS scripts, so it's likely that I could do 
that quite quickly. Also, if there is a large number of files it can get a 
bit tedious selecting them one by one on the submission screen. I've done 
this with about 30 files in one go and I would say that this is probably 
about the practical limit. I do have access to the file system though, so if 
you need a large number of files uploading for a single entry, I can easily 
do the bulk of that for you.


Best Regards,
Chris B.

Post a reply to this message

Okay, so regarding filenames and directories, this may not be such an issue if I
follow Warp's advice and combine the separate files into a single include per
group.

> ZIP Files:
> The upload scripts don't accept 'zip' files, only files with extensions
> 'BMP, CSS, CSV, GIF, HTM, HTML, INC, INI, JPEG, JPG, JS, MAC, MCR, MDL, PGM,
> PNG, POV, PPM, TGA, TIF, TIFF, TXT'. This is intended to reduce the risk of
> harmful content being uploaded.

Of course. If I end up with many files, I'll let you know and put a temporary
..zip on my site that you can upload for me.

> Identifier Names:

By the sounds of it, this won't be too much of a problem either. The Johnson
solids and stellar icosahedra are all prefixed by J23, S48 and so on because of
their unwieldy nomenclature. The others are not sufficiently numerous to stop me
renaming them manually.

> If you'd like help renaming files and variables for this impressive
> collection of shapes, then I'd like to offer you my assistance.

If I hit any serious bottlenecks I'll let you know - thanks for the offer!

Bill

Post a reply to this message

Bill Pragnell wrote:
> Many of them are very simple, but the larger ones can be quite complex. Each
> include file contains the vertices in a global array (for the advanced user)
> and three macros for instantiating the shape; most of the stellar icosahedra
> includes are 1200+ lines.


Why are you storing the individual vertices instead of generating them 
using an equation?

-Mike

Post a reply to this message

SharkD <mik### [at] gmailcom> wrote:
> Bill Pragnell wrote:
> > Many of them are very simple, but the larger ones can be quite complex. Each
> > include file contains the vertices in a global array (for the advanced user)
> > and three macros for instantiating the shape; most of the stellar icosahedra
> > includes are 1200+ lines.
>
>
> Why are you storing the individual vertices instead of generating them
> using an equation?

Quite simply, because I don't know how! (Well, except the simpler cases like the
platonic/archimedean solids).

I am converting the polyhedra from a library of meshes - someone has already
done the necessary calculations to generate them; I simply want to play with
the shapes and make them available to other users. The meshes are not big, so
there's no advantage to a native SDL polyhedron generator beyond elegance and
the joy of the challenge.

I've been distracted from this by RL recently, but they will make it to the
object library sometime soon, promise!

Bill

Post a reply to this message