"jr" <cre### [at] gmailcom> wrote:

> www.povray.org/resources/ should be used for such (important) contributor's
> files imo, the site seems the "natural" place to look for stuff.

It would be a great place to look for _new_ stuff that has yet to be extensively
tested, [ab]used, and deemed ready for converting to C++.

At present, there's SO MUCH old stuff, that we'd need a library sciences major
to sift through it all, and make value judgments about what was important, what
were unfinished experiments, and what were spurious and mysterious posts.

If there's a way to automate an indexing of all the attachments and in-line code
posts, that would be a quick and easy start, as would some method for tracking
how many times a file has been viewed / downloaded.

> also, it is
> not good advertising for POV-Ray to see the out-of-date links collection.

True.  It would be nice to have a facelift for the site as well, and even
"advertising".   Part of my concern about the early part of the learning curve
is to make POV-Ray ever more accessible and immediately usable for people just
discovering it, so that we can start growing the user base.
It doesn't matter HOW great and perfect our favorite raytracer is - if no one is
using it.


> occurs to me that you could have a simple "meta" file with conditionals, one per
> ..inc (or grouped), and use a corresponding set of 'Declare's in an .ini file to
> activate the ones needed.  would that do?

Yes, that was my idea, though POV-Ray would still have to parse the entire
include file.
Which is why I was wondering about an #exit directive.
The only way I could see to minimize parsing would be to have an index include
file that then includes smaller targeted include files - which just multiplies
the detachable pieces part.   :(



> how about (mis)using the DF3 format?  if one could put that data to use in
> contexts other than an interior..


HMMM.    THAT, Sir, is a _very_ interesting idea.

I would still like to see a simple primitive that can be constructed simply and
easily inside of SDL and is easy for a new user to grasp.
But as a workaround for the present - that's a pretty cool idea.
But how do I [easily] index a single point in the df3?


Part of the experiment I wanted to run with that got even more interesting when
I recently discovered someone's post on naming cameras or array elements (I lost
the link, can't remember which, and it doesn't show up in any searches).
Check out:
http://wiki.povray.org/content/HowTo:Use_conditional_structures
and see "Using #switch with text values"
Then maybe we could name corners and edges and face centers and object centers
and not worry about keeping track of anything.
"I want the endpoint of this cylinder/cone arrow to be at the face of CubeA."
Done.  Because it _should_ be _that_ easy.


In the absence of a modeler, it would be useful to have some "meta" scene
rendering aids - screen.inc, an image plane grid, and and object locator
function that returns an <x, y, z> vector using a screen <u,v> coordinate and a
desired z-value.   Having them in source, you can't lose them, they're
"immutable" and therefore stable and common/constant, and they take a line or
two to invoke, rather then lots of lines of code.

Post a reply to this message