This is another follow-up to the thread "povray standard include files" to 
discuss the organisation and management of a proposed area on povray.org for 
storage and distribution of a collection of objects and other files, 
contributed by the POV-Ray community.

Because POV-Ray can be used to model anything that exists and quite a lot 
that doesn't, it could be difficult coming up with an intuitive way to 
organise such a collection.
We need some way of organising stuff that makes it easy to keep it up to 
date without requiring much administrative effort to keep it going.

My thought is that we could have a relatively small number of areas of 
interest - e.g. Landscapes, Buildings, Spacecraft, Sports, Automotive, 
Planets/Cosmology, Organic Forms etc. with a section (and maybe a section 
owner) for each. A file could be submitted into one or more areas. Possibly 
at regular intervals, each area could be automatically built into a 
compressed archive. Someone interested in a particular area could either 
browse the collection or download one of the compressed archives and explore 
its contents.

Each area of interest could include objects, textures, macros and anything 
else related to the subject.

Any ideas?

Regards
Chris B.

Post a reply to this message

Chris B wrote:
> Any ideas?

Perhaps a better way would be to have each submission include the 
include file, a sample scene, and a small render of the sample scene, 
along with a list of keywords describing the include file. (I'm not sure 
there's one directory where you would file a macro for a 
mandelbrot-driven crowd of chair-dancers.)

Add keyword search.

Later, add a link to create a zip file of the found items on demand.

-- 
   Darren New / San Diego, CA, USA (PST)
     Scruffitarianism - Where T-shirt, jeans,
     and a three-day beard are "Sunday Best."

Post a reply to this message

Chris B wrote:
> Any ideas?

For just distributing, an index of available functions, textures,
macros, etc and what they do and which specific include they are in.
Each developer could have one or more includes that contain their work,
divided how ever they like. Should a tree bark texture go in a texture
file or should it be added to the include with trees? I'd argue for
keeping textures separate from objects, but after seeing some of the
tricks in POV-Ray I'm not sure there really is such a distinction.

I think the bigger issue will be making sure that all of the includes
are usable together. Some sort of enforced use of #local in each
include, and only defining the things that are going to be used
externally if possible.

There would probably need to be some way of making sure that two
developers don't create items that have the same name as well. Some form
of unique ID might be needed. This could be anything, initials, some
developer ID number, anything that would prevent overlap.

Last thing I can think of would be some uniformity in naming. Even with
an index, it might be useful to know that ID23_My_Tree_Macro is actually
a macro and not a function. This might really creep in with objects that
can be part of CSGs and those that can't. Some form of Hungarian
notation might work*.


*I'll probably regret even joking about using that, since someone might
think it is a good idea.

Post a reply to this message

My 2 cents:

Like Darren I suggest using sets of key words instead of fixed
categories. IMHO such collections really depend on a good search
function, and categories are just hard to search through. Available
search options should include the needed POV version, key words and
perhaps the author.

I'm not sure about the points Sabrina mentions: On the one hand, having
a standard for sizes and names is nice, but on the other hand it makes
it less likely that someone put's his objects/textures/whatever in the
collection, because it's too much hassle. Personally I've never had any
problems with using include files from various authors, without any
standardization.

Of course the list of possible features is endless. If time permits it's
always nice to have things like "most downloaded", ratings, etc.

Ah, and of course Sample images (not too small, i.e. at least 320x240)
are a must-have :)


Regards,
Florian

Post a reply to this message

Standards / Frontend-Backend / Hypothetical scenario...

How about this?

What if the contents of each include file be strictly limited to ONE
macro/object or ONE class of macros/objects/textures/etc?  Furthermore,
let's establish a standardized scene - or scenes - ( camera, light_source,
objects with textures ).  That way, if a user were to copy-and-paste the
the new object/texture/light_source/camera from the include file into the
standardized scene ( replacing as necessary), and then render the test
image in a standardized render window, then the object/texture would make
immediate sense to the user.  This might entail a submittal-and-approval
process on the part of whomever maintains the collection.  Also, if one of
these specialized include files calls another include file, then the prior
include file must also be made available.

Second, how about having a backend for archiving (to be organized by
whomever maintains the collection) and a front-end for browsing and
searching.  For an example of what I mean, take a look at
http://kde-apps.org/.

Here's a scenario:
I am currently creating an array of 96 unions of objects, each representing
a text character (ascii 32 - 127).  In my current include file, I have
another array of floats which specify the width of each character and a
macro which accepts a string as a parameter and returns a union of the
correspondinding elements of the first array, each cumulatively translated
by the widths of the preceeding characters (so that I can easily "write"
words in my scene using my font).

In terms of what I propose then, the text-layout macro would be submitted by
itself (or with related macros) as a 'text-utility include file'.  The
object array and the float array would be submitted in a standardized
format as an 'object-font include file' (which makes use of the macro in
the first file).  That way, others could submit their own object-font
include files which also make use of the same text-utility file.

Then, when users browse the section called "Object Fonts" in the frontend,
they would see sample images of the povver's fonts, they could read a
description, they would see how large the include file is, they might be
able to read/submit comments, and they would be allerted to the fact that
the file is dependent upon text-utility file "object-font_layout.inc".

I hope this is helpful.

Yours,
Randall

Post a reply to this message

I'd like to try and limit this thread to discussions about how to best 
organise the web site. I've started another thread for the subject of 
Standards and I've tried to include a summary of contributions on that 
subject so far. It doesn't include Randalls comments as I only got them 
after starting the Standards thread.

Regards,
Chris B.

Post a reply to this message

"Darren New" <dne### [at] sanrrcom> wrote in message 
news:456b2d1c$1@news.povray.org...
> Chris B wrote:
>> Any ideas?
>
> Perhaps a better way would be to have each submission include the include 
> file, a sample scene, and a small render of the sample scene, along with a 
> list of keywords describing the include file.

This sounds a good start and maybe an optional HTML users guide

>
> (I'm not sure there's one directory where you would file a macro for a 
> mandelbrot-driven crowd of chair-dancers.)
>

That certainly conjures up some images in my mind.

Though I agree with the indexing, I still think there is something to be 
said for grouping stuff. For example, my POV-Person library includes a macro 
for positioning groups of people on a surface. Grouping it alongside a 
mandelbrot-driven macro for positioning crowds could help encourage someone 
to integrate the two. I've had my eye on Rune's lipsync macro for some time. 
If he could be persuaded to contribute it into the same category we might 
end up with a human model that can walk and talk. I've also got a Rexx 
text-to-speech script that could be bundled to add a spoken sound-track.

If we create categories based on areas of interest we may also be able to 
divide up any maintenance work a bit more.

>
> Add keyword search.
>
> Later, add a link to create a zip file of the found items on demand.
>

I like this idea, we could do a sort of catalogue. I've got a DHTML 
client-side catalogue that I could contribute that enables you to select 
items and add them to a list. It can then generate a list of links within 
the browser (IE or Mozilla/Netscape) to allow the user to download the files 
one at a time. To get the server to build the listed objects into a single 
zip file may be more technically challenging.

> -- 
>   Darren New / San Diego, CA, USA (PST)
>     Scruffitarianism - Where T-shirt, jeans,
>     and a three-day beard are "Sunday Best."

Post a reply to this message

"Sabrina Kilian" <ykg### [at] vtedu> wrote in message 
news:456b3dea@news.povray.org...
> Chris B wrote:
>> Any ideas?
>
> For just distributing, an index of available functions, textures,
> macros, etc and what they do and which specific include they are in.
> Each developer could have one or more includes that contain their work,
> divided how ever they like. Should a tree bark texture go in a texture
> file or should it be added to the include with trees? I'd argue for
> keeping textures separate from objects, but after seeing some of the
> tricks in POV-Ray I'm not sure there really is such a distinction.
>

I agree that an index of functions, textures and macros would be 
advantageous. We'd need a list of keywords, as Darren mentioned. This 
implies some sort of server-side processing to build the index. I'm not sure 
what options there might be on povray.org for implementing this.

In my includes I try to split out the textures and objects with varying 
degrees of success. I usually set a default texture in the object #include 
file so that I can do test renders without a scene file. I think this is 
probably an area where we should write up some best practices, but stop 
short of making it a standard.

Regards,
Chris B.

Post a reply to this message

"Florian Brucker" <tor### [at] torfboldcom> wrote in message 
news:456b4129$1@news.povray.org...
> My 2 cents:
>
> Like Darren I suggest using sets of key words instead of fixed
> categories. IMHO such collections really depend on a good search
> function, and categories are just hard to search through. Available
> search options should include the needed POV version, key words and
> perhaps the author.
>

I'm onside with the keyword search idea, though we'll need some way of 
getting good keywords, resolving typos etc. I guess we could have a machine 
readable keywords file with each submission that could be processed by a 
script on the server. I'd also quite like some categorisation for the 
reasons I've stated in response to Darren's post, but if I'm alone in this 
I'll drop it.

>
> Of course the list of possible features is endless. If time permits it's
> always nice to have things like "most downloaded", ratings, etc.
>

They do such statistics already on the links collection on povray.org, so 
that may not be too hard.

>
> Ah, and of course Sample images (not too small, i.e. at least 320x240)
> are a must-have :)
>

Just a thought, but if the include file itself or an accompanying scene file 
could be rendered with standard switches, then it may be possible to 
generate images automatically.
This could also be handy when new versions of POV-Ray are released as it 
would be possible to script the rendering of all of the submissions to 
rapidly establish which ones are compatible with the new release.

>
> Regards,
> Florian

Regards,
Chris.

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Perhaps a better way would be to have each submission include the
> include file, a sample scene, and a small render of the sample scene,
> along with a list of keywords describing the include file.

would it help to have a standard sample scene creation script handle it?
The script could use the object's (in the case of shapes) bounding box size
information to correctly place it and the relative camera...

BTW, if we're not going for standardized metrics, then at least i'd enjoy
seeing carefully tight bounding boxes for the library objects... :)

Post a reply to this message