Just throwing these out there as I do periodically.

After working on some scenes and fielding user questions, I had "the thinks"
while trying to get some much-needed sleep, and much of it goes back to what a
newbie is presented with when first starting to use POV-Ray, and the
"command-line"/programming nature of POV-Ray vs a currently
functioning/supported GUI modeler.

I think that the learning curve for POV-Ray is a bit steep, and there are a lot
of moving and detached parts.

If some of the things that are currently in #include files could be implemented
in source, that would be great.   The first thing one learns about detachable
parts (like include files) is that they get lost.
[observe how often people are looking for a lost Colefax or other include file]

Following up on that, I've been mulling the idea of building a large include
file that will hold most everything I use, without having to remember the
filenames and use multiple include files.
This would require parsing the whole file, and I'd need a way to only store in
memory the parts that I wanted (#if ought to git 'er done)
With regard to the parsing, could something like #exit be implemented to abort
parsing an #include file early?   Sort of like #break?
(Also, is there a file type or structure that would allow
skipping/jumping/indexing a larger file?)


As a new user, working with trying to construct a scene in 3D, I think it is
natural to conceive of "drawing in 3D space" and defining and manipulating
_points_ seems intuitive and expected.

Just having a point{} object would be limited, but having a pointcloud{} object
would work very nicely, I think.
This would probably be/work exactly like an array, and just be a list of one or
more points that can take advantage of the brief and simple syntax of rotate,
translate, scale, etc.

This would allow a very accessible means to keep track of where certain
reference points are in the scene without requiring the need to learn the
keywords and syntax of all of the code to transform 3D vectors, as well as
making it possible to append "points" to an object in a union {}.  Those points
would them "follow" the shape around, and then be referenced to trivially
discover the new transformed position.
Super useful for cylinder (line segment) endpoints, box corners, centers, face
centers, edge centers or subdivisions, points on sphere surfaces (globes), etc.

It would also allow "glueing" and "rubber banding" which is popular and nearly
essential in most drawing / charting / CAD programs.

With regard to facilitating scene construction, in the absence of a GUI modeler,
and reigning back on the "but there's already a [detachable] macro for that" - I
think it would be nice to keep a running list of geometric functions (features)
that would be very nice to implement (in source) so as not to forget about them.
  Much like we have bug reports - but this would be a desired/requested feature
report.  Maybe even put a placeholder function in source with a warning message
- "feature not yet implemented" in case anyone tries to invoke it.

There are likely many questions that a [new] user needs the answer to, and
doesn't have the geometric / mathematical / programming knowledge to implement -
unlike a GUI where it's all point-and-click.
"What's the normal vector at <x,y,z>?"
"Where do these two "lines" intersect? (if anywhere)"
"What's the closest point on plane P to my point P?"
"What is the center and radius of the bounding sphere of these points?"

And likely a bunch of others.

And lastly, default values for some of the the primitives.
We have a default scene space, and default camera parameters, and a default
pigment - I think it would be useful for new users to be able to get a lot done
in terms of placing visible objects on the screen if things like
plane {default]
sphere {default}
axes {default}
box {default}

were fully valid directives.

Throw in a message to the #debug stream "try using sphere {<0, 0, 0>, 0.5
pigment {rgb 1}} when invoking "default" parameters, and it would avoid a lot of
new user frustration, act as a help/man command, and facilitate that first
"hello world" scene.


Just emptying my brain onto the forum for the record.

Post a reply to this message

Op 25/09/2019 om 02:45 schreef Bald Eagle:
> 
> Just throwing these out there as I do periodically.
> 

And thank you indeed for that. I believe this to be an important exercise.

I am not going to comment in detail; you have brought the points 
forwards and there is certainly more. I simply want to stress the 
frustration of 'disappearing' and 'lost' sites with useful #include, 
#macro, and other smart information over time. It is a natural 
phenomenon like evolution and it cannot be avoided, but regularly, 
useful developments are lost to the community and/or have to be 
re-invented several times. I do not have a specific example in mind at 
present but I have noticed this to happen on a regular basis over the 
past years. The closure of the 'Colefax' site is a prime example (or 
Uncle Tyler's for that matter) and I dread the possible future closure 
of sites like Friedrich Lohmüller's, Mike Williams', Jaime Vives 
Piqueres', or Gilles Tran's, just to cite a few examples. Fortunately, 
there are a couple of idiots about who 'collect' those things ;-) but at 
the end of the day it is not a sustainable way of doing things POV-Ray-wise.

> [snip]
> 
> 
> Just emptying my brain onto the forum for the record.
> 

and a good thing you did.

-- 
Thomas

Post a reply to this message

hi,

just a couple of thoughts.

"Bald Eagle" <cre### [at] netscapenet> wrote:
> ...
> If some of the things that are currently in #include files could be implemented
> in source, that would be great.   The first thing one learns about detachable
> parts (like include files) is that they get lost.
> [observe how often people are looking for a lost Colefax or other include file]

www.povray.org/resources/ should be used for such (important) contributor's
files imo, the site seems the "natural" place to look for stuff.  also, it is
not good advertising for POV-Ray to see the out-of-date links collection.


> Following up on that, I've been mulling the idea of building a large include
> file that will hold most everything I use, without having to remember the
> filenames and use multiple include files.
> This would require parsing the whole file, and I'd need a way to only store in
> memory the parts that I wanted (#if ought to git 'er done)
> With regard to the parsing, could something like #exit be implemented to abort
> parsing an #include file early?   Sort of like #break?
> (Also, is there a file type or structure that would allow
> skipping/jumping/indexing a larger file?)

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?

> ...
> Just having a point{} object would be limited, but having a pointcloud{} object
> would work very nicely, I think.
> This would probably be/work exactly like an array, and just be a list of one or
> more points that can take advantage of the brief and simple syntax of rotate,
> translate, scale, etc.

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

> ...
> Just emptying my brain onto the forum for the record.

concur with TdG, good you did.  :-)


regards, jr.

Post a reply to this message

"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

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "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++.

I was thinking .. archive(s).  ;-)


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

ah, I thought this was about things like the ccolefax .zip files and such.


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

what POV-Ray "needs" is a decent book or two written about it.  :-(


> > ... point{}...pointcloud{} ...
> > how about (mis)using the DF3 format?  if one could put that data to use in
> > contexts other than an interior..
> ...
> 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.

a macro to return (part of) a DF3 in an array[][][] should be doable.

if you decide to develop a 'pointcloud' type, have a look at the 'PointSet'
primitive in the VRML 2.0 spec which deals with that.
(I'll post an example of the "old friend" 'spiral.df3' converted in
p.t.scene-files)


> 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?

I have never (really) looked at the POV-Ray source but would think that there
are places where you could utilise the existing read/write functions for your
own ends.


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

write a pre-processor which translates "I want ..." to assorted primitives and
outputs scene code?  :-)


regards, jr.

Post a reply to this message

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


> I was thinking .. archive(s).  ;-)

Yes, indeed.   Though one thing I'd love to have is a zip of the entire server.
Maybe put it up on a Google Drive or other similar file hosting service.

> ah, I thought this was about things like the ccolefax .zip files and such.

It is, but those are just the "famous" ones.   There's tons of other really cool
stuff buried in the newsgroups.
I think a few of us have tried to archive the whole Lohmueller site - that's an
amazing resource that would make me CRY to lose.
I really have to make sure I have Mike Williams' stuff too.  I can hardly ever
go a month without checking his site for _something_.
There are surely at least a dozen others.

> > True.  It would be nice to have a facelift for the site as well,

And with regard to that, it would be cool to have a sort of slide-show on a
welcome page for the site - and there could be some of the HOF renders as well
as just some really cool renders that have been posted.  Change it up with some
of the holiday renders, etc based on date / season, etc.


> a macro to return (part of) a DF3 in an array[][][] should be doable.
>
> if you decide to develop a 'pointcloud' type, have a look at the 'PointSet'
> primitive in the VRML 2.0 spec which deals with that.
> (I'll post an example of the "old friend" 'spiral.df3' converted in
> p.t.scene-files)
>
>
> > 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?
>
> I have never (really) looked at the POV-Ray source but would think that there
> are places where you could utilise the existing read/write functions for your
> own ends.

Yes, but I think due to the nature of the source, it's probably 100x easier to
just make a special kind of array that can have the usual transforms applied to
it, compared to trying to emulate that in SDL.


> write a pre-processor which translates "I want ..." to assorted primitives and
> outputs scene code?  :-)

You smirk, but that of course is already in my *"notes".

*read as, "10,000 little pieces of paper with scribbles"    :D

Post a reply to this message

My 5 cents contribution:

There are two points here:

Archiving, or preserving, existing, handy utilities, include files, scattered
all over the internet.

Learning Povray.

The first one will be difficult. If, for instance, the Lohmuller site closes, a
lot of information will be gone. Of course there is archive.org, with its
wayback machine, but then you really have to know where to search.
If all this stuff could be centralized on the povray website, that would be easy
for the users. But of course a maintenance hell for the website people. And who
will decide what goes in, or not? And how to organize it?

The second one, learning Povray, goes for all software. If you see blender for
the first time, you don't have a clue. Moray, or kpovmodeler, if you see a
spreadsheet, or even a web-page for the first time, what do you do?
Povray comes with a good set of sample files, I think the documentation is quite
good, they really help you on your way. And of course, even people who have been
using povray since Napoleon times are sometimes puzzled how to do things.

Cheers
Ton.

Post a reply to this message

"Ton" <ton### [at] gmailcom> wrote:

> If all this stuff could be centralized on the povray website, that would be easy
> for the users. But of course a maintenance hell for the website people.

That depends on if it acts as just a mirror / backup / archive, or if it gets
something more done with it.

> And who
> will decide what goes in, or not? And how to organize it?

I'd probably suggest opening a few accounts of some sort and let a few of the
users admin their own versions.   That way there would be competition /
collaboration, and the people maintaining those lists could pick and choose what
they like.
They could also field requests from other users.   It has to be driven by some
sort of self-interest, otherwise it won't get done / maintained at all.

It would be nice if a few wiki accounts were opened up as well.


> The second one, learning Povray, goes for all software.

Indeed, and we're just bouncing ideas around about how to make learning our
favorite software easier and less frustrating.

Certainly your renders act as inspiration to want to know how to use POV-Ray and
do more with it.   :)

Post a reply to this message

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

> what POV-Ray "needs" is a decent book or two written about it.  :-(

I'd rather see a better editor, with a context-sensitive menu and a feature like
#alias.

I'm wondering if there's a word processor that uses macros which can be used to
start a POV-Ray render of the saved document file...

> write a pre-processor which translates "I want ..." to assorted primitives and
> outputs scene code?  :-)

Another thing along those lines was the idea of having a [semi] lockable data
format, to protect against inadvertent changes.

As a present alternative to that, I thought it would be interesting to have a
spreadsheet that could show the current value of any #declare[d] variables,
ranges, graphs, etc, would create SDL in a print area for saving to a .pov file,
and then the cells could be password protected.

And REALLY what I would love to see is a way to embed the SDL for a render into
the image file itself.  No more losing the code - or working version of the code
- that made the image.
I know there's a way to merge a zip or other archive file into things like jpg,
so that you can open the file like an archive and extract the files ----
but I distinctly recall someone posting an example of a file where it was a book
cover, and when you simply renamed the image file to .txt or .doc or .pdf or
whatever it was - then the OS (Windows) recognized it as _that_ and opened it in
the appropriate application.

Still working on hunting down how to do that...

Post a reply to this message

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > what POV-Ray "needs" is a decent book or two written about it.  :-(
> I'd rather see a better editor, with a context-sensitive menu and a feature like
> #alias.

never used the Windows version, so cannot comment.

> I'm wondering if there's a word processor that uses macros which can be used to
> start a POV-Ray render of the saved document file...

with the Vim editor you have both macros and the option to execute a program
with the current (by default) buffer containing the scene; check out the 'make'
command  option; worth noting that Vim also supports a number of scripting
languages directly.  you can also (ab)use 'Makefile's.

(word processors have the (nasty) habit of embedding control codes in the text)


> > write a pre-processor which translates "I want ..." to assorted primitives and
> > outputs scene code?  :-)
>
> Another thing along those lines was the idea of having a [semi] lockable data
> format, to protect against inadvertent changes.

you already have that, provided by the operating system.  you could use a shell
(or such) script which "locks" (ie marks read-only) or unlocks the
working/project directory.


> As a present alternative to that, I thought it would be interesting to have a
> spreadsheet that could show the current value of any #declare[d] variables,
> ranges, graphs, etc, would create SDL in a print area for saving to a .pov file,
> and then the cells could be password protected.

or a database!?


> And REALLY what I would love to see is a way to embed the SDL for a render into
> the image file itself.  No more losing the code - or working version of the code
> - that made the image.
> I know there's a way to merge a zip or other archive file into things like jpg,
> so that you can open the file like an archive and extract the files ----
> but I distinctly recall someone posting an example of a file where it was a book
> cover, and when you simply renamed the image file to .txt or .doc or .pdf or
> whatever it was - then the OS (Windows) recognized it as _that_ and opened it in
> the appropriate application.
>
> Still working on hunting down how to do that...

won't work like that on a Linux box though, the file extension is .. eye candy,
mostly.

thought your reply to Ton was interesting too, and concur that interested users
should be able to support web site "maintenance" and such.  it would be helpful
to get some input/feedback from the .. gods.


regards, jr.

Post a reply to this message