 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] san rrcom> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris B wrote:
> 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.
We can do pretty much whatever we need. If it can be done then for the time
being please just assume it would be possible on the server. If it's
something that ends up being a problem (e.g. too much CPU time), we'd still
centralize it on the server but split the processing out to other machines.
-- Chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Florian Brucker wrote:
> Ah, and of course Sample images (not too small, i.e. at least 320x240)
> are a must-have :)
I'd go further and say a large image should be submitted (it will be made
into a thumbnail of an appropriate size on the server), and that in addition
to this, a thumbnail-sized animated GIF should be supplied giving an
appropriate set of views. For an object, perhaps a fly-around; for a tree
macro, perhaps an example of growth, for a texture, perhaps various objects
using it, and so forth.
-- Chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> When I did this sort of thing, I allowed "keywords" and "topics".
> "Topics" were chosen from a list the administrators created, while
I'd go with both too. The main criteria however is that a good search
function enables users to find what they want more or less instantly, and
that would require good keyword selection. Inevitably there will be the need
for some admin work to clean up/add keywords and arrange categories.
-- Chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Randall Sawyer wrote:
> What if the contents of each include file be strictly limited to ONE
> macro/object or ONE class of macros/objects/textures/etc? Furthermore,
[snip]
I'm inclined to go along with this, at least for macros/objects.
If the macro/object requires any other includes, they would be listed as
dependencies. If it doesn't want to depend on another include for some other
macro that the author already has but doesn't want to go to the trouble of
releasing separately, then that macro (or declarations, or whatever) must be
local to the file and not visible from outside, so as to not pollute the
namespace and potentially cause collisions.
-- Chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Charles C wrote:
> 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
My ten cents: things are downloadable separately. Perhaps in groups as well.
The site could be smart enough to provide you links to dependencies of
something you download, too, and possibly (if we hook it up to the POV-Ray
user registration system) keep track of what you download and only offer the
downloads of dependencies you don't already have.
If this collection gets to be quite useful we need to consider the
possibility that at some point, integration with some POV platform user
interfaces could happen; for that, it definitely needs to support retrieval
of individual files.
-- Chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris, thank you for your enthusiastic support for the idea. I think indeed
exciting bright times are ahead for povray and the povray community! :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Cason wrote:
> If the macro/object requires any other includes, they would be listed as
> dependencies. If it doesn't want to depend on another include for some other
Come to think of it, tracking dependencies would probably be important for
versioning too - e.g. if 'abc.inc' only works with version 1.1 of 'def.inc'
then we either need to provide links to the older version of 'def.inc', mark
'abc.inc' as broken, or attempt to have some sort of backward-compatibility
standard.
Personally, I feel that apart from the case of bug fixes, if an include file
in the standard portion of the library needs to be changed in such a way that
it would adversely affect other files that use it (where such use is done
according to the documented interface), there should be some attempt made to
keep the old behaviour and provide the new behaviour only to files that
expect it (i.e. have been written to use the new feature).
-- Chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Randall Sawyer <sra### [at] yahoocom> wrote:
> What if the contents of each include file be strictly limited to ONE
> macro/object or ONE class of macros/objects/textures/etc?
I would say that if the feature is prominent and quite stand-alone
(such as eg. a lens-flare effect) then it should be in its own file,
but some files can contain a collection of similar features (math.inc
and functions.inc are good examples of this).
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
in news:456ec72e@news.povray.org Chris Cason wrote:
> Randall Sawyer wrote:
>> What if the contents of each include file be strictly limited to ONE
>> macro/object or ONE class of macros/objects/textures/etc?
>> Furthermore,
> [snip]
>
> I'm inclined to go along with this, at least for macros/objects.
I think it will be restrictive quite soon when working on complex
includes.
>[...] If it doesn't want to depend on another include for
> some other macro that the author already has but doesn't want to go
> to the trouble of releasing separately, then that macro (or
> declarations, or whatever) must be local to the file and not visible
> from outside, so as to not pollute the namespace and potentially
> cause collisions.
how about the possibility of including 'packages' of includefiles. Think
for example of Jaime's lightsys. It consists of several files and lots
of macros and data. Now if we could just '#include lightsys' and in one
go include all files in the directory /lightsys and put them all in the
lightsys namespace, the potential of collisions gets a lot less. I'm not
good at explaining this so maybe have a look at how Python deals with
standard and third party libraries and namespaces. It's done very user
friendly.
#include MMMM (a library (directory) consisting of 7 includefile
sharing a lot of code)
object {
MMMM.Parametric (
function(u,v){R*sin(v)*cos(u)},
function(u,v){R*cos(v)},
function(u,v){R*sin(v)*sin(u)}
<0, FromV(0)>, <pi, 2*pi>,
20, 10, ""
)
pigment {rgb 1}
finish{specular 0.3}
}
Ingo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
ingo <ing### [at] tagpovrayorg> wrote:
> #include MMMM (a library (directory) consisting of 7 includefile
> sharing a lot of code)
>
> object {
> MMMM.Parametric (
> function(u,v){R*sin(v)*cos(u)},
> function(u,v){R*cos(v)},
> function(u,v){R*sin(v)*sin(u)}
> <0, FromV(0)>, <pi, 2*pi>,
> 20, 10, ""
> )
> pigment {rgb 1}
> finish{specular 0.3}
> }
oh! I'd certainly love proper foo.bar style of accessing containers member
rather than the one in my proposed alias:
#include "foo.inc" #as MMM
object { MMM_Parametric(...) }...
Except i feel the latter should be simpler to implement in the povray parser
with a few rewriting rules...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
This thread contained quite a diverse range of ideas and has been quite
difficult to summarize. This is a first attempt to summarize it, so feel
free to chip in if you think I've overlooked something or made mistakes.
I've tried to incorporate the ideas raised into a description of how the
collection could potentially work (a sort of specification). It's a bit
long, so I've tried to break it up to enable you to focus in on the bits
that most interest you.
Please comment on whether you think the following scenarios seem reasonable:
The Plan is to create a collection of objects, textures and include files
contributed by the POV-Ray community on povray.org.
Organisation
-------------
The site would be split into two main parts with (1) an 'ad-hoc' area for
new submissions and (2) a 'standard' area where contributions adhere to
certain standards and to a common licensing structure. There would be no
visible hard-wired hierarchy of directories within these areas, but there
would be (potentially multiple) logical categorisations available alongside
indexing information (Keywords) supplied by the contributor. One form of
categorisation could potentially cover topics like 'Space Hardware' and
'Landscapes' whereas an alternative form of categorisation could cover
contribution types, such as 'Component', 'Finished Object', 'Texture',
'Utility Macro' etc.
The povray.org server may use an internal directory structure to manage
versioning or other aspects of the collection, but this structure would not
be visible to users and would not be present on the user's local machine
once the files have been downloaded.
Submitting Contributions
------------------------
Contribution Name - To submit a contribution through the povray.org web
site, you would first enter a name or a unique ID for your contribution.
Povray.org would search its index for that identifier.
If it's a new submission and the name is already being used, you will need
to pick a different one.
If you intend to supersede an existing contribution you will need confirm
that and will need to 'version' your contribution - See 'Provenance' below.
Keywords - You will need to associate keywords with the contribution so that
people can find it through the search facility. You could be given the
option of either submitting a file containing keywords or typing them into a
list on the submission page, in which case the server would create the file.
In both cases povray.org would incorporate the keywords into a machine
readable index for use by the search facility.
Categories - You will be prompted to select one or more categories for the
contribution. For example, a chair object could go into the Topic-based
categories 'Household Objects' and 'Business Furnishings' and into the
'Completed Objects' category within the Contribution-Type-based categories.
Standards Compliance - You would also indicate whether you believe your
contribution conforms to the standards necessary to become eligible for
promotion into the 'standard' area.
Dependencies - If the contribution has dependencies (is dependant upon
another contribution already in the collection), you will also needs to
identify those dependencies. As was alluded to earlier in this thread, if we
build large lists of dependencies it becomes difficult to keep them up to
date and to retain forward and backward compatibility as new versions of a
contribution are added. If you write a macro that works with your objects,
it may be safer to bundle it all together in a single contribution and
accept that if someone wants to use it elsewhere that they'll copy it. I
think this is one of those issues we can most appropriately handle in a
'best-practices' tutorial once we see how this all works out.
Pre-Requisites - If your contribution has any pre-requisites you'll need to
describe them, for example, if the contribution requires a certain version
of POV-Ray or if there are operating system or other software dependencies
(e.g. Use of Windows bmp format, Perl scripts, Modellers).
Description/Comments - For new contributions, you should provide a brief
description of the contribution. If updating the contribution, you could
optionally modify the existing description and potentially add update notes.
Server-Side Checks - The server would check that all of the file names in a
submission are prefixed with the contribution name or some form of
standardised prefix.
The server checks that any required files are present and accepts the
submission, adding indexing and category information into the search
facility and storing the files in the 'ad-hoc' area. A submission may be
required to include a rendered image of the object at a standard size,
documentation etc. but we'll cover that in detail in the standards thread.
The server may perform tasks such as generating a thumbnail image from the
submission, either from the larger image or using some sort of standard for
rendering the contribution.
Collaborative Developments
----------------------------
Although many of the contributions could be objects contributed by a single
author, it is also possible to foresee more collaborative developments where
many people are updating a set of files. I think that groups working on such
projects will need to coordinate themselves and to establish who will manage
releases of the contribution into the collection. Such projects could
involve development using a check-out/check-in strategy, but this would be
managed outside of the collection using a code repository such as CVS, a
service such as Sourceforge or some other mechanism selected by that team.
Provenance (Origin)
------------
The intention is to encourage the evolution of contributions by future
contributors, so we need a way of accepting new versions of a contribution.
However, we run into an issue of divergency, where two separate modification
streams could be taking place at the same time.
I would suggest that the easiest way of dealing with this is to incorporate
the a contributor prefix (the authors initials or tag) into the version
number and have a place on the submissions page where the contributor can
indicate the version that the changes are based on. If the contributor is
registered and logged in they can use their ID in the version number. If the
contributor is not logged in they would need to add a number each time to
make their tag unique.
If contribution hierarchies get overly complex for a contribution then
someone would need to sort it out. This is most likely to occur with a
contribution where many people from the POV-Ray community have shown an
interest, so hopefully, getting someone to put in the time to sort it out
should be a viable option.
Finding and Downloading Contributions
----------------------------------------
The collection would be available to anyone with an Internet connection
using a standard browser by accessing the appropriate page on the povray.org
web site. If you have chosen to register as a POV-Ray community member you
could have the option of logging in, which will enable the povray.org server
to provide you with a couple of extra features (previous download lists
etc).
Searching - You would be able to search for contributions by some
combination of contribution name, author name, one or more category
structures or by keyword. Multiple versions of a contribution could
potentially be present in the collection. The most recent version would
normally be displayed, but you could go into a 'detail' page that would list
the version hierarchy and enable you to select an alternative version of the
contribution.
Standards Compliance - Some means will be used to indicate whether a given
version has been accepted into the 'standard' area. If it hasn't, the server
could indicate whether the contributor considered that it conforms to the
standards and has accepted the common license. Otherwise the server could
indicate that it's an 'ad-hoc' contribution. Maybe we could use a sort of
'traffic lights' type system.
Dependencies - An indication will be given to show dependencies on other
contributions within the collection and an option could be provided to
either link through to those items, or some mechanism could be provided to
follow dependency chains and add the contribution and all of its
dependencies to the 'download list' (see next paragraph).
Download Lists - When you find a contribution you like, you can either
download it from the list or add it to a 'download list' similar to a
shopping basket concept for online shops. A button on the page would enable
you to add all items from the current selection to your 'download list'. If
building a 'download list' you could go to your list and remove items. Once
happy with your list you can download a zipped archive containing the files
selected.
Value Added Features - If you register with povray.org and choose to log-in,
the server may be smart enough to keep track of what you have previously
downloaded so that it can indicate which contributions you already have and
could list any contributions that have been updated since you last
downloaded them (would require some hooks into the POV-Ray registration
system).
Future enhancements could include downloadable indexes that could be used to
link into platform specific user interfaces to support retrieval from the
editor (e.g. from the 'insert' menu).
Promotion into the 'standard' area
----------------------------------
If the contributor has accepted the common licensing terms and has complied
with the required standards, their work will be eligible for inclusion in
the 'standard' area.
Depending upon the complexity of the standards agreed upon, it may be
possible to automatically verify that some or all of the standards are
satisfied. For more complex standards or for more complex contributions it
may be necessary for a group of volunteers to go through and verify
conformance to the required standards before registering the contributions
for inclusion in the 'standard' area. I think we're agreed that we would
like to keep manual maintenance tasks to a minimum.
Once a contribution has been accepted into the 'standard' area, users will
be able to identify that fact when they come across that contribution in the
collection (a special icon or something).
Other Stuff
-----------
There was a discussion on the subject of whether we have one file per
object/macro or whether we support more sophisticated bundles/packages. I
believe the conclusion was that prominent and quite stand-alone items should
be in their own file, collections of similar features could be in a single
file and more complex packages of files could be bundled together. Imposing
some over restrictive rule on this could reduce the potential for the
collection.
My view is that supporting archives of files that work together would be a
good thing. Given the licensing conditions the exchange of ideas could go
both ways. Someone could take individual contributions and build them into a
package using a standardised scale, standardised parameters and consistent
documentation etc. Someone else could picking macros and other pieces out of
packages and create more generic, standalone utilities out of them. I would
foresee a smaller number of the larger packages, so it might be possible for
those to be expanded into separate directories on the user's machine without
hitting the 20 library path limit mentioned in the help (Charles indicated
25, is this OS dependant?). This could maybe permit naming conventions
within the archive to be relaxed avoiding large amounts of rework on
existing packages.
There was a discussion about automatic renaming of contributions. I
personally use some animation features to build the names of include files
dynamically and I'm not sure whether we could do anything that could
reliably update everyone's file references without risking breaking them
beyond repair.
'Value-Added' features like "most downloaded", ratings, etc. could be added
as time permits.
We could also implement the features described above in two phases, getting
started with the 'ad-hoc' area and initially relying on contributors to
assess their own contributions. We could potentially introduce the more
formal 'standard' mark of approval at a later stage, once we can assess how
much work/interest is generated.
Ben suggested the following categories as a starting point for a 'type'
based categorisation:
- Textures
o Pigments
o Finishes
o Normals
- Interiors
o Media
- Shapes
o Solid (CSG-able)
o Non-solid (Non-CSG-able)
- Functions
o Isosurface
o Positioning
o Other
I'll propose the following starting point for a 'topic' based
categorisation:
- Household/Office Objects
- Buildings
- Landscapes
- Vehicles
- Space
- Organic Forms
- Abstract Forms
Regards,
Chris B.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Chris B" <c_b### [at] btconnectcomnospam> a écrit dans le message de news:
457d907f@news.povray.org...
> Ben suggested the following categories as a starting point for a 'type'
> based categorisation:
> - Textures
(These threads are long so please ignore the following if already discussed)
IMHO it should be possible to add resource materials that are not made of
POV-Ray SDL.
Bitmaps textures (simple or HDRI) are the more obvious case - bitmaps are
often part of packaged scenes or objects -, but other stuff could go there
too, including non-SDL models (think Wings or Blender models), packaged
tutorials, BVH files, little software utilities etc. I realise that this
opens another can of worms, but this is done in other 3D communities, and
lots of people have non-SDL material to offer.
The fact that non-SDL goodies could be used by users of other software may
be a good thing (more public exposure for POV-Ray and its community) or not
(extra server load, more potential license troubles since non-SDL goodies
are likely to have a higher commercial value than SDL ones).
G.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Gilles Tran" <tra### [at] inapgfr> wrote in message
news:457da098$1@news.povray.org...
> "Chris B" <c_b### [at] btconnectcomnospam> a écrit dans le message de
> news: 457d907f@news.povray.org...
>
>> Ben suggested the following categories as a starting point for a 'type'
>> based categorisation:
>> - Textures
>
> (These threads are long so please ignore the following if already
> discussed)
>
> IMHO it should be possible to add resource materials that are not made of
> POV-Ray SDL.
>
I don't think this has been specifically discussed yet, but it's not
necessarily a problem with the solution that has been discussed. So long as
the files are prefixed with the appropriate contribution ID, then I don't
see a problem with having any variety of files and file types as you need to
make a contribution work. The application code on the server managing the
download would create an archive incorporating the entire contribution.
> Bitmaps textures (simple or HDRI) are the more obvious case - bitmaps are
> often part of packaged scenes or objects -, but other stuff could go there
> too, including non-SDL models (think Wings or Blender models), packaged
> tutorials, BVH files, little software utilities etc. I realise that this
> opens another can of worms, but this is done in other 3D communities, and
> lots of people have non-SDL material to offer.
>
One of the things that was discussed was also the possibility of
incorporating more sophisticated contributions which I've suggested could
enable the contents of the archive to evade some of the file naming
conventions. I'm a bit biased on this as I would like to contribute a
complex set of files which incorporates a variety of BVH files, converter
utilities, model sources and sets of pose files, clothing files etc. and I'd
prefer not to have to rename them all.
> The fact that non-SDL goodies could be used by users of other software may
> be a good thing (more public exposure for POV-Ray and its community) or
> not (extra server load, more potential license troubles since non-SDL
> goodies are likely to have a higher commercial value than SDL ones).
>
> G.
>
Regards,
Chris B.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Two quick issues to pick apart. I just got done with exams so I haven't
had enough time to go through everything yet.
Chris B wrote:
> Organisation
> -------------
> The site would be split into two main parts with (1) an 'ad-hoc' area for
> new submissions and (2) a 'standard' area where contributions adhere to
> certain standards and to a common licensing structure. There would be no
> visible hard-wired hierarchy of directories within these areas, but there
> would be (potentially multiple) logical categorisations available alongside
> indexing information (Keywords) supplied by the contributor. One form of
> categorisation could potentially cover topics like 'Space Hardware' and
> 'Landscapes' whereas an alternative form of categorisation could cover
> contribution types, such as 'Component', 'Finished Object', 'Texture',
> 'Utility Macro' etc.
>
> The povray.org server may use an internal directory structure to manage
> versioning or other aspects of the collection, but this structure would not
> be visible to users and would not be present on the user's local machine
> once the files have been downloaded.
>
Even the ad-hoc should have to be under a compatible license. If it is
not licensed for redistribution, then someone could complain that the
server was giving it away with permission. That may sound strange, but
it would be safer if we knew we had permission to redistribute the
files. Secondly, it allows others to patch a file to make it standards
compliant.
If we want to allow non-similar licensed files in the library, then the
traffic light indicator you mentioned could be useful. Stop for
privately licensed, read the files carefully. Slow/caution for standard
license but not prefixed or checked, and go for checked over and should
work with the current version of POV-Ray.
> Submitting Contributions
> ------------------------
> Contribution Name - To submit a contribution through the povray.org web
> site, you would first enter a name or a unique ID for your contribution.
> Povray.org would search its index for that identifier.
> If it's a new submission and the name is already being used, you will need
> to pick a different one.
> If you intend to supersede an existing contribution you will need confirm
> that and will need to 'version' your contribution - See 'Provenance' below.
>
Just for everyone to think about, who's name should go on a file that
was patched? If I fix a bug, or typo or what ever, in someone elses
library, the most I'm going to do is add a comment saying I fixed
something and why, and add one to the patch version level. If the server
is appending a prefix based on the uploader's name, then we could end up
with two files doing the exact same thing.
The solutions I could come up with follow:
1)Server allows uploading over established files. I could see this being
really bad, but it would solve this single issue.
2)Allow only the contributor to over write their file, and make sure
that all patches are sent to them. This could pose a problem if the
contributor doesn't want to update or just can't be found.
3)Only designated people can overwrite files. There could be many ways
of determining this. Only head folks in the Library Team, a specific
patch manager, everyone with a patch that has been downloaded 100 times.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Chris B" <c_b### [at] btconnectcomnospam> a écrit dans le message de news:
457dc4d2$1@news.povray.org...
> I don't think this has been specifically discussed yet, but it's not
> necessarily a problem with the solution that has been discussed.
Thanks for the answer. I just wanted to make sure that the option was
mentioned somewhere. Note that the license should also cover these kinds of
materials (not just SDL).
G.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Sabrina Kilian" <ykg### [at] vtedu> wrote in message
news:457dd079@news.povray.org...
> Two quick issues to pick apart. I just got done with exams so I haven't
> had enough time to go through everything yet.
>
> Chris B wrote:
>> Organisation
>> -------------
>> The site would be split into two main parts with (1) an 'ad-hoc' area for
>> new submissions and (2) a 'standard' area where contributions adhere to
>> certain standards and to a common licensing structure.
>
> Even the ad-hoc should have to be under a compatible license. If it is
> not licensed for redistribution, then someone could complain that the
> server was giving it away with permission. That may sound strange, but
> it would be safer if we knew we had permission to redistribute the
> files. Secondly, it allows others to patch a file to make it standards
> compliant.
>
I think I missed a bit out in my summary. I think the idea proposed by Chris
Cason was that the contributor would still need a fairly liberal license,
but they may elect to require 'Attribution', so his suggestion was that they
would be required to include something like the following trap in their SDL
to prevent people from using their contribution unwittingly.
#ifndef (Attributed_Includes_OK)
#error "This include file requires attribution"
#end
I'm fairly impartial on this because I can see that it might help encourage
more contributions, but I think it does add a layer of complexity and I'm
pretty confident that a lot of people will be happy to contribute without
requiring attribution, just as a sort of give-back gesture.
>> Submitting Contributions
>> ------------------------
>> If you intend to supersede an existing contribution you will need confirm
>> that and will need to 'version' your contribution - See 'Provenance'
>> below.
>
> Just for everyone to think about, who's name should go on a file that
> was patched? If I fix a bug, or typo or what ever, in someone elses
> library, the most I'm going to do is add a comment saying I fixed
> something and why, and add one to the patch version level. If the server
> is appending a prefix based on the uploader's name, then we could end up
> with two files doing the exact same thing.
>
I would suggest that we don't routinely delete any version although there
may be special circumstances where an administrator would go in and make
deletions (e.g. if one or more contributions is intentionally corrupted or
if older versions are not downloaded for a year or so and no other
contributions depend on them).
I see the versioning as being largely internal to the server, so that you
only get one entry for a contribution coming up on a search, but when you
look at the entry you can see that multiple versions have existed and can
select the one you want. Normally you'd go for the latest. I think the files
you download would not be prefixed with a version number or contributor ID,
because this would interfere with anything you've written to use them. There
could be an auto-generated 'version' file containing the version number in
the name - e.g. 'TennisBall_SK_V2.3.ver' that contains information about the
provenance of this version.
If you fix a bug, you would upload a new version of the whole contribution
having tested it as a complete unit. You wouldn't change the name of the
original author as registered on the server if it's just a little fix, but
would merely add a comment to say what you'd done. This contribution would
have your initials or tag against it in the versioning information and
people would be able to select either your newer version or the original
version if they prefer. Dependencies in other contributions may still need
to point to the older version of this contribution.
If the original author subsequently applies the same fix to the same bug,
then yes, you end up with two virtually identical files on the server, but
hopefully the comments will cast some light on that.
Regards,
Chris B.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
It all looks good so far, of course I only gave it a quick read :)
There are two things I'd like to further suggest, however:
1) All contributions should be required to submit to a particular
(non-exclusive) license, similar to what the IRTC does. Ie, "I agree to
the standard license, and allow anyone with access to this repository to
use my contribution for any purpose whatsoever, including making changes
and submitting patches to the repository." Or something like that. The
point is, if I access something from the repository, I don't want to
have to read over the license for it to determine whether or not I
should use it.
2) In the vein of "value-added features", I'd recommend allowing users
to rate the individual files according to several criteria, such as
Completeness, Usability, Realism, Uniqueness, etc (those are just
examples), as well as add comments / reviews about them. If a
submission has multiple versions, allow the viewing of aggregate reviews
(for all versions combined), or for a single version.
...Chambers
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
First, thanks for all your thought & effort Chris. Supposing this thing
gets off the ground it'll be in no small part thanks your efforts in
getting everybody together in discussing it.
"Chris B" <c_b### [at] btconnectcomnospam> wrote:
> foresee a smaller number of the larger packages, so it might be possible for
> those to be expanded into separate directories on the user's machine without
> hitting the 20 library path limit mentioned in the help (Charles indicated
> 25, is this OS dependant?). This could maybe permit naming conventions
If I'm not mistaken I'm reading this as a standard limit for all platforms:
http://www.povray.org/documentation/view/3.6.1/56/
Where did you find 20?
Charles
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Charles C" <nomail@nomail> wrote in message
news:web.457e46ca6bf4081b9926319c0@news.povray.org...
> First, thanks for all your thought & effort Chris. Supposing this thing
> gets off the ground it'll be in no small part thanks your efforts in
> getting everybody together in discussing it.
>
> "Chris B" <c_b### [at] btconnectcomnospam> wrote:
>> foresee a smaller number of the larger packages, so it might be possible
>> for
>> those to be expanded into separate directories on the user's machine
>> without
>> hitting the 20 library path limit mentioned in the help (Charles
>> indicated
>> 25, is this OS dependant?). This could maybe permit naming conventions
>
> If I'm not mistaken I'm reading this as a standard limit for all
> platforms:
>
> http://www.povray.org/documentation/view/3.6.1/56/
>
> Where did you find 20?
>
> Charles
>
Hmm. I see.
I was looking at 2.1.2.5.4 Library Paths where it says "Up to twenty unique
paths may be specified".
http://www.povray.org/documentation/view/3.6.1/220/
Regards,
Chris B.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Ben Chambers" <ben### [at] pacificwebguycom> wrote in message
news:457e3915$1@news.povray.org...
> It all looks good so far, of course I only gave it a quick read :)
>
> There are two things I'd like to further suggest, however:
>
> 1) All contributions should be required to submit to a particular
> (non-exclusive) license, similar to what the IRTC does. Ie, "I agree to
> the standard license, and allow anyone with access to this repository to
> use my contribution for any purpose whatsoever, including making changes
> and submitting patches to the repository." Or something like that. The
> point is, if I access something from the repository, I don't want to have
> to read over the license for it to determine whether or not I should use
> it.
>
Sabrina made the same point. I can see both sides. One aspect of it that I
don't think was yet discussed is that if someone creates something based on
another Open Source license, then they may not be able to comply with our
license terms without breaking the terms of that other license. I guess the
answer is that they can still publish on their own web site and add a link
into the povray links collection or promote it on these newsgroups.
Two ways forward on this question spring to mind. We could have a vote on it
or we could start by requiring a common license and ease up if it seems to
be causing a problem.
> 2) In the vein of "value-added features", I'd recommend allowing users to
> rate the individual files according to several criteria, such as
> Completeness, Usability, Realism, Uniqueness, etc (those are just
> examples), as well as add comments / reviews about them. If a submission
> has multiple versions, allow the viewing of aggregate reviews (for all
> versions combined), or for a single version.
>
> ...Chambers
I like this idea.
Regards,
Chris B.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
