"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

On 06/03/2023 15:12, Bald Eagle wrote:
> Certainly taking a mesh and placing it into a well-composed scene, predominately
> governed by the camera location, and giving it 3-point lighting, an HDRI
> lighting sphere, and good radiosity settings would be fairly easy to do and
> really provide instant guidance for even the newest of users.

I remembered another one domain where POV has advantages and where an
accurate lighting environment is important - jewelry.
A few scenes with gems, gold and silver will look very attractive, but
this is a challenging task for experienced POV-ers.

Here described very promising approach to jewelry rendering:
https://www.lilysoft.org/CGI/SR/Spectral%20Render.htm

Unfortunately I still have no time to try it.
--
YB

Post a reply to this message

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

> 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).

Crap.
It's a shell script...   but maybe someone has some ideas for using shellout
.....


C:\....\POV-Ray\v3.8-beta\scenes\38BetaSource\scripts

Post a reply to this message

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

> Others are invited to chime in on what additions they think would be useful.

Just something your thread made me think about and before I forget it again,
Supercollider has documentation integrated in its GUI. This gives the user the
possibility to run code samples straight from the docs.

ingo

Post a reply to this message

On 06/03/2023 22:41, yesbird wrote:
> Here described very promising approach to jewelry rendering:
> https://www.lilysoft.org/CGI/SR/Spectral%20Render.htm
> 
> Unfortunately I still have no time to try it.


I just downloaded the zip and render "Prism.pov".

This is what I get with E_Phillips_Mastercolor_3K
Nothing to do with the image on the web page

Is my version of povray buggy ?

Persistence of Vision(tm) Ray Tracer
Version 3.8.0-alpha.10013324.unofficial






-- 
Kurtz le pirate
Compagnie de la Banquise

Post a reply to this message

Attachments:
Download 'prism.png' (5 KB)

Preview of image 'prism.png'

On 07/03/2023 19:58, kurtz le pirate wrote:
> Is my version of povray buggy ?
Hi,
still didn't try it myself, but have you installed 'LightsysIV' as
required on this page ?

Also, I see you are using 'Version 3.8.0-alpha.10013324.unofficial', I'd
prefer to install stable 3.7, or maybe 3.8-beta2.
--
YB

Post a reply to this message

What I use the insert menu for mostly is to save me typing.
Once in awhile scan the menu for fun, to see what things I'm not using but
could.

I made my own folder with a lots of debug statements in it. One for each data
type. I also have few odds and ends store away there.

 After reading what other had to say. I see that the insert menu has a lot of
targets to hit. The newbe, the advanced, the more advance, the more advance....
There are plenty of topics to cover. From objects to skies. I can't see one
insert menu covering every bodies needs, without Gigs of data. Only part of
those gigs would help a particular person.
 What we probably need is a insert menu web site. Where you can pick and choose
what type of menu you need. From beginners, heavily documented to advance, type
saving menus.

Have fun!

Post a reply to this message

On 08/03/2023 01:18, Leroy wrote:
>   What we probably need is a insert menu web site. Where you can pick and choose
> what type of menu you need. From beginners, heavily documented to advance, type
> saving menus.
Probably, we could provide compact add-ons, of different kind, something
like plugins.
--
YB

Post a reply to this message

"Leroy" <whe### [at] gmailcom> wrote:
> What I use the insert menu for mostly is to save me typing.

> I made my own folder with a lots of debug statements in it. One for each data
> type. I also have few odds and ends store away there.

I predominately do the same.

>  After reading what other had to say. I see that the insert menu has a lot of
> targets to hit. The newbe, the advanced, the more advance, the more advance....
> There are plenty of topics to cover. From objects to skies. I can't see one
> insert menu covering every bodies needs, without Gigs of data.

I don't really think that's true.  The Insert Menu as it stands, is absolutely
packed with entries.  But I think that taking a look at what's there, assessing
it, cleaning it up a bit, and jusdiciously adding to it would help people be
more productive - especially new users trying to get a scene to render - it's
really important to have early sucesses.

The menu is hierarchical, and if you take a look at Special Shapes and
Transformations, there's 3 levels to those.  That leaves a lot of room to
compartmentalize things based on level of expertise and the amount of code and
commentary that gets pasted into a scene.

And aside from just the implementation, it's always a good idea to have people
throw out ideas and spur new ideas and projects.  What goes into the Insert Menu
vs into the include directory, vs what gets fleshed out into an entire scene or
animation.  Plus the existing code could probably use some editing to clean up
the code, update it to take advantage of new developments and trim deprecated
directives, and maybe add some bits of helpful code that are hard-won but easily
lost in thousands of (unsearchable) forum posts.

Plus, then it will be all freshly-edited and proofread before the next version.
;)

- BW

Post a reply to this message

So, I was just doodling away to play a bit with the Pi pavement pattern, and
that
a) reminded me about the (missing) dependencies in some of the code snippets
b) highlighted the presence of some unnecessary/deprecated dependencies
c) revealed some potential problems with the included shapes

There are a lot of stone/granite/metal etc textures in the menu, and it's
unclear what include file is necessary to make them work.  I think there was
also some discussion about srgb values in the colors, etc.

Some of the textures use things like pigment {White} which necessitates the
inclusion of colors.inc.  Totally avoidable.

I tried using the Dodecahedron and Icosahedron objects, and I'm getting some
strange pigmentation of parts of those.  Don't yet know if that's me, or the
structure of the object (union vs mesh), or some messed up triangle face normals
or what.

I likely won't have time to look over any of it until much later in the day, so
just bringing this up to document it, and perhaps if anyone is bored and looking
to fiddle, they could look into some of these things.

(I also noticed that when pasting the code snippets into my scene, that the
cursor hopped back up to the top of the code snippet rather than staying at the
bottom of the inserted text.   Neat trick, but unexpected - any ideas on how
that works / if it can be disabled?

- BW

Post a reply to this message

Attachments:
Download 'tilingtest.png' (1150 KB)

Preview of image 'tilingtest.png'