 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Florian Brucker" <tor### [at] torfbold com> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris B wrote:
> 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.
When I did this sort of thing, I allowed "keywords" and "topics".
"Topics" were chosen from a list the administrators created, while
"keywords" could be anything. Since you could get a list of both, it was
expected that you'd pick keywords others had used if they fit.
(Otherwise, people would have trouble guessing your keywords, and your
stuff wouldn't get found.)
It worked out OK.
Since I was doing this sort of thing 12 years ago via pure CGI without a
database, I can't imagine it's particularly difficult to do now if you
have *any* sort of scripting capabilities available on the server.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I want to verify what we're doing here... What will be downloadable? I
thought we were laying the groundwork for a future single(yet
versionable/growable) package containing the entire library of things
people contribute. If I have that right, the website can/could be
relatively minimal: e.g. just another page and downloadable .zip on the
povray.org website along with some guidelines and way to submit items for
review. Pre-renderings & tutorials are icing on the cake.
The big thing on my mind regarding organization in general is how we should
organize the library itself once downloaded. I'll post my comments on this
under "standards"... (Or do I have that wrong - it'd be a web page with
many downloads?)
Charles
"Chris B" <c_b### [at] btconnectcomnospam> wrote:
> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Charles C" <nomail@nomail> wrote in message
news:web.456b83576bf4081b2869ae640@news.povray.org...
>I want to verify what we're doing here... What will be downloadable? I
> thought we were laying the groundwork for a future single(yet
> versionable/growable) package containing the entire library of things
> people contribute. If I have that right, the website can/could be
> relatively minimal: e.g. just another page and downloadable .zip on the
> povray.org website along with some guidelines and way to submit items for
> review. Pre-renderings & tutorials are icing on the cake.
>
That's one option.
I think the problem with that is that, if it's successful, it could grow
quite large and could change quite frequently.
If we only make it available as a single big zipped file then everyone who
wants access to a new addition would need to download the whole archive each
time and would need to take care not to overwrite any changes they'd made to
stuff they'd downloaded earlier.
Also, how would you know whether you want to bother with the new additions
if we don't list them with graphics to illustrate what you'd be getting.
>
> The big thing on my mind regarding organization in general is how we
> should
> organize the library itself once downloaded. I'll post my comments on this
> under "standards"... (Or do I have that wrong - it'd be a web page with
> many downloads?)
>
I think that's part of this discussion at the moment, whether it should be a
loose collection of objects or a highly structured heirarchical library with
categories and sub-categories. My view is that developing a deep multi-level
taxonomy would turn out to be something of a maintenance overhead, but that
grouping it all into just one archive would make it cumbersome and messy.
My preference would be for a small number of areas of interest with a main
directory for each, then a sub-directory for each contribution within that
category. So, if you're interested in buildings you could download an
archive that might include the cityscape generator, some models of buildings
and some furnishings and fittings. If you're interested in space you could
download an archive containing macros for building planets, utilities for
converting and mapping satelite images and utilities for generating
gallaxies. I'd also like to be able to download new contributions and
updates without having to refresh the entire archive.
Most of the contributors to the discussion so far seem more in favour of a
loose collection of include files where you could download one file at a
time or a selection of files chosen from a list or through a search.
Regards,
Chris B.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Well, some sort of CV type system (CVS, monotone, Subversion, etc) could
handle the browsing / downloads, with daily tarballs or zips available
for everyone who wants them.
As for directories / categories / whatever you want to call them, I'd
keep them extremely abstract and general. I'd also recommend forcing a
separation between various component types at the top level. So, the
directory tree might look something like this:
- Textures
-- Pigments
-- Finishes
-- Normals
- Interiors
-- Media
- Shapes
--Solid (CSG-able)
--Non-solid (Non-CSG-able)
- Functions
-- Isosurface
-- Positioning
-- Other
This system isn't meant to be browsed by hand; you'd search through it
via the server to find what you need. Since I'm spending quite a bit of
time these days trying to clean up my mp3 collection, I've got a few
thoughts about tags: everything would have a variable number of tags,
and the tags may be whatever the author wishes.
Rather than forcing an arbitrary categorization with set tags (with MP3s
these are Author, Album, Genre, etc), each tag would simply be a tag,
with no category. Tek's Sea would have the tags "Tek", "Sea", "Ocean",
"Isosurface", "Realistic" etc.
To find any files which might be useful, you'd run a search on the
server for the tags you want. It would be especially useful if POV-Ray
accepted URIs to files, and you wouldn't have to download them locally
to check them out... but that could open a whole new can of worms :)
...Chambers
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris B wrote:
> Any ideas?
The objects section should be divided at least into semi-primitive
objects, which do simple-but-common CSGs, and final objects, which
represent actual things like chairs, tables, and so forth.
For instance, I have a macro which builds a cylinder that is chopped in
half along the center axis, since this is an extremely common CSG in my
work. I also have a macro which takes a few parameters and builds a
window frame. Different levels of completeness here.
Regards,
John
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Chris B" <c_b### [at] btconnectcomnospam> wrote:
> That's one option.
> I think the problem with that is that, if it's successful, it could grow
> quite large and could change quite frequently.
> If we only make it available as a single big zipped file then everyone who
> wants access to a new addition would need to download the whole archive each
> time
I think Ben Chambers has a good point that it doesn't have to be one way or
another... Maybe we can do both. Browse by file, view sample images online
download the latest version of somebody's "woodfloor.inc" But then when
somebody adds or changes something, the server could create a new (for
example) POV_Community_Library_RevDate20061128.zip Some people might find
it easier to replace the whole library directory on their computer than look
to see if they've got the latest of each component.
>and would need to take care not to overwrite any changes they'd made to
> stuff they'd downloaded earlier.
I basically leave the POV-Ray INCLUDE directory alone for just this
reason...
> Also, how would you know whether you want to bother with the new additions
> if we don't list them with graphics to illustrate what you'd be getting.
Good point. I'm all for icing on that cake, and the gravy too! errrr ;-)
>
> >
> > The big thing on my mind regarding organization in general is how we
> > should
> > organize the library itself once downloaded. I'll post my comments on this
> > under "standards"... (Or do I have that wrong - it'd be a web page with
> > many downloads?)
> >
>
> I think that's part of this discussion at the moment, whether it should be a
> loose collection of objects or a highly structured heirarchical library with
> categories and sub-categories. My view is that developing a deep multi-level
> taxonomy would turn out to be something of a maintenance overhead, but that
> grouping it all into just one archive would make it cumbersome and messy.
>
> My preference would be for a small number of areas of interest with a main
> directory for each, then a sub-directory for each contribution within that
> category. So, if you're interested in buildings you could download an
I've checked now, and the limit for POV-Ray is 25 library_paths that you can
add to the main POVRAY.INI. Having a lot of sub directories containing 2
files kindof slows down browsing on one's own computer IMHO, so for some
things some sort of a general/tidbits directory might be nice. Nobody
seems to be talking about bigger "systems" which might have a dozen related
files, each with a dozen or more macros within them. I think those kinds of
things could definitely use their own directories. Then again, maybe
fitting in with one of appropriete categories is good enough. That leads
to another question which is, will one "system" or "project" still have to
be broken up & spread out in the library according to its components?
> archive that might include the cityscape generator, some models of buildings
> and some furnishings and fittings. If you're interested in space you could
> download an archive containing macros for building planets, utilities for
> converting and mapping satelite images and utilities for generating
> gallaxies. I'd also like to be able to download new contributions and
> updates without having to refresh the entire archive.
I think this would be good too. I do have a slow connection at home...
Charles
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
From: Chris B
> if it's successful, it could grow
> quite large and could change quite frequently.
a Version Control System like CVS or Subversion as seen in most colaborative
open-source projects is the correct way to handle it.
> how would you know whether you want to bother with the new additions
> if we don't list them with graphics to illustrate what you'd be getting.
should be nice to be handled by a script, which would see if there is a
sample image available and, if not, would render a small sample on-the-fly
and cache it. Hey, finally broadband users would get to feel like in the
90's 56K modems! ;)
> My view is that developing a deep multi-level
> taxonomy would turn out to be something of a maintenance overhead, but that
> grouping it all into just one archive would make it cumbersome and messy.
yes, indeed. some mid-level agreed upon standard would be required.
> My preference would be for a small number of areas of interest with a main
directory for each,
BTW, Ben Chambers take on this one below is also worth a look.
> Most of the contributors to the discussion so far seem more in favour of a
> loose collection of include files where you could download one file at a
> time or a selection of files chosen from a list or through a search.
more of the same way of doing pov things and not unlike most web
collections, rather than standard povray includes. But hosted at
povray.org itself! :)
From: Ben Chambers
> As for directories / categories / whatever you want to call them, I'd
> keep them extremely abstract and general.
you're suggesting just the hierarchy you layout below? While i agree it
would be very useful, it's only as part of a top-level hierarchy, much like
to the one described by Chris B, focused on few highlevel areas of interest,
each one branched like yours... perhaps i'm thinking too much in terms of OO
software programming, i dunno...
- Shapes
--Solid (CSG-able)
--Non-solid (Non-CSG-able)
this is good.
- Functions
-- Isosurface
hmm, i believe Isosurfaces (already defined by a function, possibly included
from here) should be under Shapes/Solids.
> This system isn't meant to be browsed by hand; you'd search through it
> via the server to find what you need.
A plain directory with many include files identified only by a prefix ID is
nice when it's on a server machine with searching capability. But imagine
such a collection in your own machine, with no advanced search and possibly
naming conflicts...
> It would be especially useful if POV-Ray
> accepted URIs to files, and you wouldn't have to download them locally
> to check them out... but that could open a whole new can of worms :)
yes, like when the server's down or people begin putting URIs to external
sites that go out of business... nothing like locality, or at least the
illusion of it. :)
From: John VanSickle
> The objects section should be divided at least into semi-primitive
> objects, which do simple-but-common CSGs
you mean, like "clippers" -- objects that clip others in differences or
clipped_by?
yeah, we coult get an abstract, utilities section...
From: Charles C
> Some people might find
> it easier to replace the whole library directory on their computer than look
> to see if they've got the latest of each component.
those are the broadband non-programmer guys who don't know the benefits of a
Version Control System, in which you just issue an update command and it
automagically downloads diffs from the repository and patches them in your
local copy. And it even generated nightly builds for those wanting a
single download.
> I've checked now, and the limit for POV-Ray is 25 library_paths that you can
> add to the main POVRAY.INI.
hmm, i begin to feel a need for Makefiles... :P
perhaps only include in POVRAY.INI the main branches and leave specifics to
the command-line?
> might have a dozen related
> files, each with a dozen or more macros within them.
it seems we're seeking for a one object per file standard.
> will one "system" or "project" still have to
> be broken up & spread out in the library according to its components?
you mean textures, shapes and the like? I believe that's desirable.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ben Chambers wrote:
> As for directories / categories / whatever you want to call them, I'd
> keep them extremely abstract and general. I'd also recommend forcing a
> separation between various component types at the top level. So, the
> directory tree might look something like this:
>
> - Textures
> -- Pigments
> -- Finishes
> -- Normals
> - Interiors
> -- Media
> - Shapes
> --Solid (CSG-able)
> --Non-solid (Non-CSG-able)
> - Functions
> -- Isosurface
> -- Positioning
> -- Other
"Charles C" wrote:
> I've checked now, and the limit for POV-Ray is 25 library_paths that you can
> add to the main POVRAY.INI. Having a lot of sub directories containing 2
> files kindof slows down browsing on one's own computer IMHO, so for some
> things some sort of a general/tidbits directory might be nice.
How about using file names with standardized multiple suffixes such as:
-- foo.texture.inc (or foo_texture.inc)
-- foo.pigment.inc (or foo_pigment.inc)
-- foo.finish.inc (or foo_finish.inc)
-- etc...
Or, if grouping *.inc files into the directory tree Ben Chambers proposes,
then within each one of these directories use standardized suffixes such
as:
-- foo.texture.skin.inc (or foo_texture_skin.inc)
-- foo.texture.stone.inc (or foo_texture_stone.inc)
-- foo.texture.wood.inc (or foo_texture_wood.inc)
-- etc...
This way, we could easily stay within the "25 library_paths" limit that
Charles C addresses.
Just thinking...
-Randall
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
