 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] yahoo com> 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
|
|
| |
| |
|
|
|
|
| |
