"Bald Eagle" <cre### [at] netscapenet> wrote:

> Hopefully this afternoon I'll expand upon that idea to suggest a format and a
> few guiding principles.

I'm just going to disgorge a few ideas off the top of my head to add to the
list.

Something that would be helpful would be what Jim Henderson seems to have a
talent for - searching all 30 years of the POV-Ray forum, and compiling an
ordered list of some of the most-asked questions.  After all, one of the
fundamental goals (in my mind) for the Insert Menu is preempting the most basic
and most-asked calls for help in coding, keyword syntax, or feature use.
A simple task like making a scene that renders an image with a transparent
background ought to be just that - simple.   Click, drag-down, click, done.

I'm sure that there are things that we all struggle with.  Functions, gamma,
data structures, vector math, matrices, making a pot of coffee without having
had a cup of coffee yet, etc.  Very often, the presence or absence of a quick
and easy way to reference some key bit of code can make or break a project, or
turn what should have been the straightforward coding of a scene into a weekend
long odyssey of searching directories and forums, and backups for critical bits
of code to make something work.  So having a pre-written snippet of code that
performs some task that's a barrier to completing a scene is likely to make a
lot more projects come to fruition.

I have a lot of bits of things stored here and there, and I suppose I'll just
list a few here to see what interests people and solicit comments.

I have lot of things that I've written over the years to help myself and new
users lay out scenes and overcome the usual difficulties experienced when
scaling and rotating things, placing light sources, and positioning or orienting
objects.   Friedrich Lohmueller wrote similar things, and jr even did a whole
rewrite of the grid system to assist in placing objects in a scene.

I have a bounding box macro that I improved to make the lines fully visible
regardless of how far away from the camera it is.

Calculation of matrix determinants.  This is useful for things like vector cross
products for calculating surface normals, incenters of tetrahedra, and likely
other things of which I'm currently blissfully unaware.

A whole system to graph equations - basically a graphing calculator for POV-Ray.
 Pretty useful for debugging functions, developing ne functions, or placing a
graph of a function in a render where you're trying to illustrate the effect of
a function.

The big Hexagonal Color Histogram project which analyzes images and provides
graphical and color_map data for replicating or creating derivative works from
images.  Useful for getting all of those colors right in a pigment, texture, or
material.

A macro that calculates the intersection point of two 3D lines.

A macro that calculates what the minimum visible radius for a sphere or cylinder
is - how big one pixel is at any given distance from the camera location.

A macro that determines what octant a given point is in

A macro that calculates the intersection line of two planes

A macro that calculates the shortest distance of a point from a line.
Essentially the point on a line where one can draw a perpendicular line to
intersect that other point.

a sphere-cylinder sweep

A file that makes spheres starting from regular polyhedra by subdividing
triangles

The analytical tangents between circles project

A macro that generates a hardwood floor

Code that shows numerical values in pigment patterns

Somewhere I have one good implementation of a catenary curve - amidst a lot of
bad ones

Code to calculate the radius of a circle given the width and depth of the secant
 part of a circle's sector


..... and likely more.




> For example: I had a project going to provide a working code example for every
> single keyword:

This was instructive, because I needed compact, versatile code for creating the
basic scene elements for a variety of keyword types.  Sometimes I needed to
display an object, other times I needed to graph a function.  Sometimes I wanted
a perspective camera, other times orthographic.  Sometimes I needed a Cartesian
graph, other times I needed a polar graph.
So I made a fairly small include file to handle all of those tasks for
everything I needed.

I'd say that a good submission for something like this would be a full
standalone scene that made use of a core include file, and made proper use of
the usual include stack and version wrappers.  Then, a simple, stripped-down
code snippet with proper indentation and a minimum of extraneous text or
exceedingly common modifiers (translate, scale, rotate, ...).   I use things
like phase, octaves, turbulence, etc infrequently enough that it would probably
be helpful to have those included in the snippet.


Every project has its contributors and detractors.

I think that serious work on this would give us many components necessary for
efficiently working on the sample scenes for future distributions.

The sample scene stuff has some clever code in (IIRC) an ini file for scanning a
..pov file for the presence of preferred rendering resolution/image size, and
that would be a handy bit of code for the insert menu (I believe we have zero
Insert menu items for writing .ini files).

I was also thinking about Sergey's desire for animations, and thought a neat
idea would be to have a similar mechanism to TdG's eval_pigment scene which
checks for the existence of a file, writes data to disk and then skips that part
and renders on the second rendering.
The thought here is to have a .pov file check for an .ini file, if it doesn't
exist, write one, and render the first fram of the animation (why not), and then
have the resulting .ini file be ready to render all of the frames of the
animation starting from the second.  (or of course, one can just skip rendering
with an error message instructing the new user to run the resulting .ini file
instead - or just rerender the first frame along with all others from the ini
file.)

- BW

Post a reply to this message