Folks,

With the release of v3.7 nearing the team is looking at the content of
the standard distribution, in particular the sample scene files.

So far the standard scenes are pretty much unchanged (in terms of
content) from past releases. Some of the scene files are in fact over
20 years old; this doesn't mean there's anything wrong with them of
course, however it seems that it may be prudent to sort through them
and determine, for each, if it's suitable as a standard scene for
today's POV-Ray.

Mostly this applies, I think, to samples in the advanced folder,
rather than the demos of various features.

One thing we have decided to do is to add the template scenes included
in Friedrich Lohmüller's extended insert menu for POVWIN. Friedrich is
also helping us with creating a HTML-based index and preview of all
the scene files.

In addition to considering what we might want to remove, we need to
consider what we might add. I don't think it's as critical to keep the
install as small as it can be (as was the case years ago when modems
were the common means of getting POV). So I think we have some scope
to add extra megabytes if required.

The additions can be in the form of macros, include files, demo files,
and sample scenes (either stand-alone or templates). Any additions we
do make need to be licensed under the CC or AGPL3, or more openly
(such as BSD or public domain).

I've been in contact with Gilles Tran and he's happy for us to include
anything he has posted on his site; he uses the Creative Commons
license already, so that's a great start. However there's lots of
other work out there that may be suitable if the author is willing to
allow it.

So, we're asking for user feedback and recommendations for things to
remove and things to add. Please followup to this thread ... thanks!

-- Chris

Post a reply to this message

This is great news!

Rather than including thousands of scenes, why not to think about a "Life"
feature which allows to download from a special online folder sample scenes,
sorted by subject (keyword)?

Example: the user has downloaded and installed a comfortably small POV-Ray, and
did already some renders with the included samples. But then, weeks later,
skills having gone up, (s)he wants to write a scene but find out that there is a
need for some more, specific samples (provided by the glorious POV-team or even
other users), and uses the Life feature of the new P7 to get a list of
additional sample scenes containing the desired keyword.

1
In fact, this could be possible even with all the scens currently
posted/published on this server. The server just needs a script to check each
functioning, finished uploaded scene for any keyword it contains. With a
database that stores that information, P7's LIFE feature could list all scenes
and even code excerpts around that specific keyword within each scene.

2
Otherwise, with the help of all interested users and a jury, thousands of
additional, highly specialized sample scenes could be created just for the Life
feature of the new P7.

Just an idea.

Post a reply to this message

Am 20.02.2013 06:09, schrieb Sven Littkowski:

> Rather than including thousands of scenes, why not to think about a "Life"
> feature which allows to download from a special online folder sample scenes,
> sorted by subject (keyword)?

Let's get real. We're talking about the 3.7.0 release package here, and 
we're long past feature freeze for the code.

That aside, there are other reasons not to implement such a thing. For 
one, such a feature would require a proper front-end; the command-line 
won't really cut it, so it won't fly for the Linux version. And then 
there's the problem that someone would have to implement it. Someone 
with, you know, a bit of time on their hands and no higher-priority 
ideas of what to implement next.

Let's see... integrate a bunch of features that have accumulated during 
3.7.0 feature freeze; redesign radiosity pretrace to work with 
distributed rendering; contribute to re-writing the parser from scratch 
and maybe re-invent the whole SDL; weed out the remaining C-style data 
structures from the C++ code; add support for color profiles; add 
support for post-processing like lens flares and stuff; write patches 
for stochastic rendering, spectral rendering, and polarized light; add 
performance improvements for SSLT; rewrite the radiosity tutorial; 
implement mesh subdivision; implement direct import of .obj files; add a 
feature to dump arbitrary scene elements back to an SDL file; add a 
feature to convert arbitrary objects to meshes; implement direct export 
of meshes to .obj files; implement NURBS support; write a patch to 
implement Metropolis Light Transport; take a DEEP breath and look around 
to see what else has cropped up in the world of rendering by then... ah 
yes, and let's not forget to weed out the legion of issues found by 
Coverity and other statical code analysis tools...

... well, no - not me, I'm afraid; I'm booked out till June next life as 
it seems.

Post a reply to this message

On 02/20/2013 06:32 AM, clipka wrote:
> Am 20.02.2013 06:09, schrieb Sven Littkowski:
>
>> Rather than including thousands of scenes, why not to think about a
>> "Life"
>> feature which allows to download from a special online folder sample
>> scenes,
>> sorted by subject (keyword)?
>
> Let's get real. We're talking about the 3.7.0 release package here, and
> we're long past feature freeze for the code.
>
> That aside, there are other reasons not to implement such a thing. For
> one, such a feature would require a proper front-end; the command-line
> won't really cut it, so it won't fly for the Linux version. And then
> there's the problem that someone would have to implement it. Someone
> with, you know, a bit of time on their hands and no higher-priority
> ideas of what to implement next.
>
> Let's see... integrate a bunch of features that have accumulated during
> 3.7.0 feature freeze; redesign radiosity pretrace to work with
> distributed rendering; contribute to re-writing the parser from scratch
> and maybe re-invent the whole SDL; weed out the remaining C-style data
> structures from the C++ code; add support for color profiles; add
> support for post-processing like lens flares and stuff; write patches
> for stochastic rendering, spectral rendering, and polarized light; add
> performance improvements for SSLT; rewrite the radiosity tutorial;
> implement mesh subdivision; implement direct import of .obj files; add a
> feature to dump arbitrary scene elements back to an SDL file; add a
> feature to convert arbitrary objects to meshes; implement direct export
> of meshes to .obj files; implement NURBS support; write a patch to
> implement Metropolis Light Transport; take a DEEP breath and look around
> to see what else has cropped up in the world of rendering by then... ah
> yes, and let's not forget to weed out the legion of issues found by
> Coverity and other statical code analysis tools...
>
> ... well, no - not me, I'm afraid; I'm booked out till June next life as
> it seems.
>
LOL ... you mean you /didn't/ know the job was dangerous when you took 
it ;-)

Post a reply to this message

Am 20.02.2013 18:10, schrieb James Holsenback:
> On 02/20/2013 06:32 AM, clipka wrote:
>>
>> ... well, no - not me, I'm afraid; I'm booked out till June next life as
>> it seems.
>>
> LOL ... you mean you /didn't/ know the job was dangerous when you took
> it ;-)

Quoth myself on 2008-12-20:

----------------------------------------------------
Uh-oh - I guess I'm going to regret this... well, anyway...

*(takes deep breath)*

So I want radiosity fully working ASAP in the 3.7 SMP, someone said 
there's already a suggestion how to do it but there's a lack of manpower 
to do it, and my secret identity happens to be that of a software 
developer with some C/C++ skills...

..... so what's the deal to get myself involved in this one?

[...]
----------------------------------------------------

So yes, I /did/ expect something like this to happen ;-)

Post a reply to this message

What is a life feature?  What is P7?

Post a reply to this message

Chris Cason <del### [at] deletethistoopovrayorg> wrote:
>
> In addition to considering what we might want to remove, we need to
> consider what we might add...
>
> The additions can be in the form of macros, include files, demo files,
> and sample scenes (either stand-alone or templates).

I would suggest Rune's ILLUSION.INC include file (with some minor changes.) I
don't know whether that's 'available' or what his license terms are, though.

It's essentially a different mapping type for image_maps--'camera projection' or
'camera mapping.' There's nothing like it in POV-Ray at present, AFAIK (and is a
feature available in many high-end CG programs.) I don't know if Rune is
actively engaged in updating his file; if not, I would certainly be willing to
help improve it with some slight changes (though necessary ones, IMO.) I've
already done that for my own use.

In lieu of that, maybe a (*gulp!*) feature request along the same lines:
possibly as the so-far-unused map_type 4. Rune's code *seems* to be an SDL
method for simply eliminating/reversing part of the 'transform' that POV-Ray
internally applies to an image_map to project it onto objects in
space--'eliminating' the z-distance/perspective pixel transformation. (Turning
it back into solely an affine transform? Sorry, my knowledge of this is
sketchy.) ANYWAY, just an idea.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:

>
> Let's see... integrate a bunch of features that have accumulated during
> 3.7.0 feature freeze; redesign radiosity pretrace to work with
> distributed rendering; contribute to...

Great! Shouldn't be too hard! Keep working those late hours, the deadline's
approaching! We'll supply the coffee and doughnuts!  ;-) ;-)

Post a reply to this message

Am 21.02.2013 08:14, schrieb Kenneth:

> In lieu of that, maybe a (*gulp!*) feature request along the same lines:
> possibly as the so-far-unused map_type 4. Rune's code *seems* to be an SDL
> method for simply eliminating/reversing part of the 'transform' that POV-Ray
> internally applies to an image_map to project it onto objects in
> space--'eliminating' the z-distance/perspective pixel transformation. (Turning
> it back into solely an affine transform? Sorry, my knowledge of this is
> sketchy.) ANYWAY, just an idea.

Ah yes, forgot to mention that on my list:

"... add support for all camera types as map types, ..."

Would be fun if you could just use

     #declare MyCam = camera { ... }
     image_map { png "foo.png" map_type MyCam }

or something along those lines.

Post a reply to this message

> In addition to considering what we might want to remove, we need to
> consider what we might add. I don't think it's as critical to keep the
> install as small as it can be (as was the case years ago when modems
> were the common means of getting POV). So I think we have some scope
> to add extra megabytes if required.

I would suggest landscape and cities generators (as well as planets 
generators).
The idea of an on-line repository is interesting, but I've always 
appreciated the off-line examples included in the setup package (even 
the off-line help): the network is not always available everywhere.
Thank you for your work,
    Paolo

Post a reply to this message

On 21-2-2013 10:01, Paolo Gibellini wrote:
> I would suggest landscape and cities generators (as well as planets
> generators).

That's a thought indeed. Comes to my mind: John Van Sickle's 
height_field mosaic macro for instance.

> The idea of an on-line repository is interesting, but I've always
> appreciated the off-line examples included in the setup package (even
> the off-line help): the network is not always available everywhere.

Better a good off-line than an unreliable online ;-)

> Thank you for your work,

I second that indeed.

Thomas

Post a reply to this message

>Thomas de Groot  on date 21/02/2013 13.11 wrote:
> On 21-2-2013 10:01, Paolo Gibellini wrote:
>> I would suggest landscape and cities generators (as well as planets
>> generators).
>
> That's a thought indeed. Comes to my mind: John Van Sickle's
> height_field mosaic macro for instance.
>
Or a Gancaloon cityscape generator ;-)
Paolo

Post a reply to this message

On 21-2-2013 15:15, Paolo Gibellini wrote:
> Or a Gancaloon cityscape generator ;-)

Lol! That means digitizing my brain ;-)

Thomas

Post a reply to this message

>Thomas de Groot  on date 21/02/2013 15.22 wrote:
> On 21-2-2013 15:15, Paolo Gibellini wrote:
>> Or a Gancaloon cityscape generator ;-)
>
> Lol! That means digitizing my brain ;-)
Mmm. How much disk space is estimated for an off-line version of such a 
data?
:-P
Paolo

Post a reply to this message

Am 21.02.2013 15:27, schrieb Paolo Gibellini:
>  >Thomas de Groot  on date 21/02/2013 15.22 wrote:
>> On 21-2-2013 15:15, Paolo Gibellini wrote:
>>> Or a Gancaloon cityscape generator ;-)
>>
>> Lol! That means digitizing my brain ;-)
> Mmm. How much disk space is estimated for an off-line version of such a
> data?

Well, it can't be /that/ much...

(ducks & runs)

Post a reply to this message

On 21-2-2013 19:21, clipka wrote:
> Am 21.02.2013 15:27, schrieb Paolo Gibellini:
>>  >Thomas de Groot  on date 21/02/2013 15.22 wrote:
>>> On 21-2-2013 15:15, Paolo Gibellini wrote:
>>>> Or a Gancaloon cityscape generator ;-)
>>>
>>> Lol! That means digitizing my brain ;-)
>> Mmm. How much disk space is estimated for an off-line version of such a
>> data?
>
> Well, it can't be /that/ much...
>
> (ducks & runs)
>

Right. I shall keep the floppy disk to myself...

Thomas

Post a reply to this message

Chris Cason <del### [at] deletethistoopovrayorg> wrote:

> ...it seems that it may be prudent to sort through them
> and determine, for each, if it's suitable as a standard scene for
> today's POV-Ray.
>
> Mostly this applies, I think, to samples in the advanced folder,
> rather than the demos of various features.
>

I've just methodically rendered all the demo scenes in the advanced folder (only
in v3.62, sorry) and, honestly, I think all of them are still 'useful' in one
way or another, if only for coding examples. Maybe CATS (povcatray.pov) looks a
bit out of date visually (an understatement!); but even that might have nuggets
of code that beginners would still find useful.

The DRUMS2 scene has some extraneous old text that could be removed.

The only scene that seems to have an actual problem is DESK. It's an animation
file, but I can't get it to animate using only the included desk.ini file (which
contains the animation parameters.) Perhaps I'm doing something wrong; someone
else needs to give that scene a try.

A more 'global' thing concerning the various scenes is that they have different
assumed_gamma settings (or none at all.) No doubt a result of their age; but
that might be a source of confusion with v3.7. Of course, that's the way they
were set up, so I wouldn't know what to recommend (if anything.)

Also, some of the scenes have an explicit #version 3.5 directive. Just wondering
if those should be changed to at least 3.6.

The day before Chris posted this message, I also happened to go through all of
the  various 'cameras' in the SCENES/CAMERA folder, and found a few minor things
that need attention. In many of the files, there is a 'boilerplate' text
section...

"don't forget to render this with the image ratio equal to 1 (height = width),
or, instead of being framed in a half-circle, the upper part of the image will
be "squished" into a half-ellipse."

In more than a few cases this is wrong, on two counts: The 'fisheye' and
omnimax' cameras need a 4:3-ratio render, not 1:1; and the stuff about being
"squished into a half-elipse" is a mystery altogether. (I can't honestly say if
this text section is right *or* wrong in the four 'cylinder' cameras, but it's
there too.) BTW, the text section in the 'spherical' camera is correct AFAIK.

Post a reply to this message

Am 22.02.2013 09:09, schrieb Kenneth:
> I've just methodically rendered all the demo scenes in the advanced folder (only
> in v3.62, sorry) and, honestly, I think all of them are still 'useful' in one
> way or another, if only for coding examples. Maybe CATS (povcatray.pov) looks a
> bit out of date visually (an understatement!); but even that might have nuggets
> of code that beginners would still find useful.
cats/povcatray.pov looks really "a bit out of date"!
But I also agree with your "but even".
Ingo Janssen did much more attractive things like grenadine.pov !

> The DRUMS2 scene has some extraneous old text that could be removed.
That text descripes how Dan Farmer in 1992 (20 years ago!) made
the background image with FRACTINT, an old fractal program.
I think this text should stay there by "historical reasons".

> The only scene that seems to have an actual problem is DESK. It's an animation
> file, but I can't get it to animate using only the included desk.ini file (which
> contains the animation parameters.) Perhaps I'm doing something wrong; someone
> else needs to give that scene a try.
This file needs:
1. Output_File_Type=N  (for png) //no command line like +fj ...
2. remove any output path  ( ;Output_File_Name="..." )
    that the rendered images come in the directory of desk.pov
    and desk.ini,
or move both in your output path for run.
The file desk.ini runs desk.pov 4 times to produce the effect of
  "an image in an image in an image ... "
Interesting method, it but needs an additional instruction.

> A more 'global' thing concerning the various scenes is that they have different
> assumed_gamma settings (or none at all.) No doubt a result of their age; but
> that might be a source of confusion with v3.7. Of course, that's the way they
> were set up, so I wouldn't know what to recommend (if anything.)
I'll try to add assumed_gamma in global_settings, where this is missing.

> Also, some of the scenes have an explicit #version 3.5 directive. Just wondering
> if those should be changed to at least 3.6.
Yes, I think so too!

> The day before Chris posted this message, I also happened to go through all of
> the  various 'cameras' in the SCENES/CAMERA folder, and found a few minor things
> that need attention. In many of the files, there is a 'boilerplate' text
> section...
>
> "don't forget to render this with the image ratio equal to 1 (height = width),
> or, instead of being framed in a half-circle, the upper part of the image will
> be "squished" into a half-ellipse."
>
> In more than a few cases this is wrong, on two counts: The 'fisheye' and
> omnimax' cameras need a 4:3-ratio render, not 1:1; and the stuff about being
> "squished into a half-elipse" is a mystery altogether. (I can't honestly say if
> this text section is right *or* wrong in the four 'cylinder' cameras, but it's
> there too.) BTW, the text section in the 'spherical' camera is correct AFAIK.
Good hints! Thank you!
I want also add (where it's missing) a
"right  x*image_width/image_height" to keep propotions of the results
with any aspect ratio. This avoids the effect that people think that
the image looks distorted, when they render the files without reading
the instructions about the resolutions.

Post a reply to this message

in news:5127c70a@news.povray.org Friedrich Lohmueller wrote:

> Am 22.02.2013 09:09, schrieb Kenneth:
> cats/povcatray.pov looks really "a bit out of date"!
> But I also agree with your "but even".
> Ingo Janssen did much more attractive things like grenadine.pov !
> 

Throw the cats out, they looked outdated the they I renderd them the first 
time :) They started out as an excersize in generating smooth shapes with 
just CSG.

If they are still usfull and there's interest in them, feel free to use my 
mesh generation macro's.
http://code.google.com/p/mmgm/ (documentation and demo's are in the zip-
archive)

ingo

Post a reply to this message

ingo <ing### [at] tagpovrayorg> wrote:
> in news:5127c70a@news.povray.org Friedrich Lohmueller wrote:

>
> Throw the cats out

Ha!

>
> ...feel free to use my mesh generation macro's.
> http://code.google.com/p/mmgm/ (documentation and demo's are in the zip-
> archive)

That would be a very nice addition--especially the one that uses splines to
create a 3D surface.

Another idea:

Chris Colefax's Compressed Mesh Macro file, found here (the only link I could
find):

http://www.reocities.com/SiliconValley/Lakes/1434/pcm.html

Post a reply to this message

>Thomas de Groot  on date 22/02/2013 8.59 wrote:
> On 21-2-2013 19:21, clipka wrote:
>> Am 21.02.2013 15:27, schrieb Paolo Gibellini:
>>>  >Thomas de Groot  on date 21/02/2013 15.22 wrote:
>>>> On 21-2-2013 15:15, Paolo Gibellini wrote:
>>>>> Or a Gancaloon cityscape generator ;-)
>>>>
>>>> Lol! That means digitizing my brain ;-)
>>> Mmm. How much disk space is estimated for an off-line version of such a
>>> data?
>>
>> Well, it can't be /that/ much...
>>
>> (ducks & runs)
>>
>
> Right. I shall keep the floppy disk to myself...
>
> Thomas
>
Ok. It _should_ be included in next release!
Provided with the comments obviously.
Paolo

Post a reply to this message

On 25-2-2013 9:58, Paolo Gibellini wrote:
> Ok. It _should_ be included in next release!
> Provided with the comments obviously.
> Paolo

See image in p.b.i.

Thomas

Post a reply to this message

Here's something else I thought to mention (but sorry for the delay) concerning
the camera statements in the various demo scenes.

The cameras are all constructed differently--some radically so. It isn't so much
that they *are* different (since they all 'work') but rather, it's difficult to
get a sense of what is the 'correct' way to state a camera block. (And this
affects how the basic <x,y,z> scene axes are interpreted.)  This could really
confuse a beginner, for various reasons. Granted, the POV-Ray documentation
explains the various camera parameters (and the pitfalls of using
a 'right-hand' coordinate system vs. a left-hand one); but the demo scenes are
probably where new users go first, to get that all-important first taste of the
program, by seeing an actual render and playing around with the code.

Some cameras use old methods, like 'direction' for zooming instead of 'angle.'
And the "benchmark" scene, as well as some others, uses a truly non-standard
set-up-- up z and direction y.

Here's a different example, from DIFFRACT.POV (posted verbatim)...

camera {  //  Camera StdCam
  angle 90
  location  <3.50, -15.00, 3.00>
  direction <0.0,     0.0,  1.6542>
  sky       <0.0,     0.0,  1.0>  // Use right handed-system!
  up        <0.0,     0.0,  1.0>  // Where Z is up
  right     <1.3333,  0.0,  0.0>
  look_at   <0.000, 0.000, -2.7500>
}

In the docs about CAMERA (at "Placing the Camera"), there's a nice diagram which
shows that 'direction' and 'up' are at right-angles to each other--as they
normally should be. Here, they are not.  As the docs about "Up and Right
Vectors" say:

"Note: that the up, right, and direction vectors should always remain
perpendicular to each other or the image will be distorted."

Also, 'up' (and 'sky') are in the z-direction, as well as 'direction.' So that's
not a right-handed coordinate system *according to POV-Ray*. In the docs about
"Handedness" it says:

"To use a right-handed coordinate system...Your thumb still points up in the
+y-direction...."

All of this might sound like nit-picking, but here's why I think it matters:
When I first started learning the program, I picked a demo scene at random to
render and work with...knowing nothing at all about POV-Ray or it's coordinate
axes. The scene happened to be FISH13. Lucky for me, it had an 'understandable'
camera statement, more or less--where the scene's <x,y,z> directions/axes meant
<right,up,into the scene>. Easily grasped, if only from a simple mathematical
standpoint. So if I wanted to change/experiment with something--like translating
one of the objects in +y--then the render actually showed it moving in +y. But
with a few of these demo scenes, that's not at all what will happen in the
render. Trying to learn even the basics of POV-Ray with a non-standard camera
could turn off a new user--there are just too many fundamental details to
comprehend, all at once.

Of course, to fix this situation would mean re-coding some of the scenes
themselves, if they are still to render as originally intended  (a lot of work!)
But an easier solution might be a simple statement, something like "This scene
uses a non-standard camera set-up. (See CAMERA in the included documentation for
details.) If you are new to POV-Ray, you might want to try a different demo
scene."

Post a reply to this message

On 28-2-2013 4:22, Kenneth wrote:
> Here's something else I thought to mention (but sorry for the delay) concerning
> the camera statements in the various demo scenes.

I fully agree with you!

> camera {  //  Camera StdCam
>    angle 90
>    location  <3.50, -15.00, 3.00>
>    direction <0.0,     0.0,  1.6542>
>    sky       <0.0,     0.0,  1.0>  // Use right handed-system!
>    up        <0.0,     0.0,  1.0>  // Where Z is up
>    right     <1.3333,  0.0,  0.0>
>    look_at   <0.000, 0.000, -2.7500>
> }

I think that this set up was originally made in Moray, which used a 
'different' right-handedness.

Thomas

Post a reply to this message

Am 28.02.2013 04:22, schrieb Kenneth:
> Here's something else I thought to mention (but sorry for the delay) concerning
> the camera statements in the various demo scenes.
I had this feeling too!

> ...    In the docs about
> "Handedness" it says:
>
> "To use a right-handed coordinate system...Your thumb still points up in the
> +y-direction...."
'right-handed' or 'left-handed' does not necessarily mean y=up or z=up
  (or may be also x = up ! - Why not ?? ).
It only means, that to detect the used sense of rotation, we can help
us by looking at our right or left hand!
(This has specially repercussions also on the way, how the rotation and
  the cross product works!)

The docs are here a bit incomplete!

> Of course, to fix this situation would mean re-coding some of the scenes
> themselves, if they are still to render as originally intended  (a lot of work!)
> But an easier solution might be a simple statement, something like "This scene
> uses a non-standard camera set-up. (See CAMERA in the included documentation for
> details.) If you are new to POV-Ray, you might want to try a different demo
> scene."
I'll try to integrate something like this in as many files as possible.
Re-coding all is not possible and also not the best way!
It's also a good thing, that the bundle of demo scene files shows
the variety of the ways, how to use the 'camera'.

  'right-handed' is just a convention, often used math teachers,
to make it easier to talk about how axes are orientated and how
angles turn. (later they tell us, that electrons are left-handed :-))
POV-Ray is able to do also very inconventional things.
That's very good!

Friedrich

Post a reply to this message

Friedrich Lohmueller <Fri### [at] t-onlinede> wrote:

> 'right-handed' or 'left-handed' does not necessarily mean y=up or z=up
>   (or may be also x = up ! - Why not ?? ).
> It only means, that to detect the used sense of rotation, we can help
> us by looking at our right or left hand!

Yes, that's true of course. But using an 'unconventional' handedness system
would cause trouble later IMO, because *everything* in POV-Ray is set up for the
left-handed way (or maybe its *own* left-handed way.) It seems to me that even
an experienced user would have to change over to the 'POV-Ray way' of doing
things at some point, if the coding of scenes is going to make any sense. I
can't even imagine the constant mental re-orientation that would be required
otherwise! ;-)  Perhaps some people CAN do that; but it sounds like a lot of
extra work, conceptually.

> I'll try to integrate something like this in as many files as possible.
> Re-coding all is not possible and also not the best way!
> It's also a good thing, that the bundle of demo scene files shows
> the variety of the ways, how to use the 'camera'...
> POV-Ray is able to do also very inconventional things.
> That's very good!

Yes, I do agree. When I was thinking about all of this, it occurred to me that
the 'unconventional' cameras do show that almost anything is possible in
POV-Ray!

Everything should be OK, with just a little 'warning' to new users.

Post a reply to this message

Le 2013-02-28 08:24, Friedrich Lohmueller a écrit :

>   'right-handed' is just a convention, often used math teachers,
> to make it easier to talk about how axes are orientated and how
> angles turn. (later they tell us, that electrons are left-handed :-))
> POV-Ray is able to do also very inconventional things.
> That's very good!
>
> Friedrich
>
>
>
>

In my math classes when looking at geometry, we only used the 
left-handed coordinate and rotation system. Also, Y was always UP and Z 
forward, NEVER relative to the paper's surface.

It was the same in my physics courses.

The right-handed system is mostly used by architecs, and, as most early 
modeling applications where made for architecs, it stuck. It's also why 
we have the infamous Z for the up direction. Architecs use the X and Y 
axis along the ground and on paper where +X is right and +Y is the top 
of the paper.

Post a reply to this message

Am 01.03.2013 04:14, schrieb Alain:
> Le 2013-02-28 08:24, Friedrich Lohmueller a écrit :
>
> In my math classes when looking at geometry, we only used the
> left-handed coordinate and rotation system. Also, Y was always UP and Z
> forward, NEVER relative to the paper's surface.
>
> It was the same in my physics courses.

What? For us it was /always/ right-handed, for both maths and physics. I 
can't believe it's different across the world in such disciplines.

... unless of course you use a different scheme to assign axes to the 
fingers. We used thumb=X, index=Y, and middle=Z.

> The right-handed system is mostly used by architecs, and, as most early
> modeling applications where made for architecs, it stuck. It's also why
> we have the infamous Z for the up direction. Architecs use the X and Y
> axis along the ground and on paper where +X is right and +Y is the top
> of the paper.

If you put a proper math-style 2D coordinate system (X axis right, Y 
axis "top") onto paper, and then add +Z as height above ground, that's a 
left-handed system to me.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:

>
> If you put a proper math-style 2D coordinate system (X axis right, Y
> axis "top") onto paper, and then add +Z as height above ground, that's a
> left-handed system to me.

Egads, then +Z becomes -Z in POV-Ray!  :-O

But you're right, of course.

My own concept of the axes (putting aside what I learned in school) is kind of
an odd one--or maybe not so odd?  I've been sketching things all my life
(mechanical stuff mostly, in semi-perspective views), and 'right' is +x
naturally, but z is *mostly* INTO the page, and y is *mostly* up, but kind of
sticking OUT of the page a little. (Similar to an isometric view when drafting,
but not as extreme.) Maybe this is why POV's left-handed system was such an easy
learn for me.

Post a reply to this message

Am 01.03.2013 07:08, schrieb Kenneth:
> My own concept of the axes (putting aside what I learned in school) is kind of
> an odd one--or maybe not so odd?  I've been sketching things all my life
> (mechanical stuff mostly, in semi-perspective views), and 'right' is +x
> naturally, but z is *mostly* INTO the page, and y is *mostly* up, but kind of
> sticking OUT of the page a little. (Similar to an isometric view when drafting,
> but not as extreme.) Maybe this is why POV's left-handed system was such an easy
> learn for me.
Well, that depends on how we start a plan and how we continue.
Starting with the front view:
   x right, y up. The house behind the front goes to +z = left-handed.
Starting with the top view on ground plan:
  x right front line, y = depth, so z = up seems okay! = right-handed.

Interesting the different positions in the last 4 contributions here!
So all positions are justified - except those, who want to
declare a type of system as 'natural' and 'absolutely correct'!

Her in Germany, some regions, by 'orders from above', have decided that
their teachers at school must use a right-handed system.
And teachers, who use POV-Ray at school, are often confronted with
big resistances, because 'it is using a wrong system of coordinates'.
The students themselves do not have so much trouble with it.
  :-)

Friedrich

Post a reply to this message

Le 2013-02-28 23:41, clipka a écrit :
> Am 01.03.2013 04:14, schrieb Alain:
>> Le 2013-02-28 08:24, Friedrich Lohmueller a écrit :
>>
>> In my math classes when looking at geometry, we only used the
>> left-handed coordinate and rotation system. Also, Y was always UP and Z
>> forward, NEVER relative to the paper's surface.
>>
>> It was the same in my physics courses.
>
> What? For us it was /always/ right-handed, for both maths and physics. I
> can't believe it's different across the world in such disciplines.
>
> ... unless of course you use a different scheme to assign axes to the
> fingers. We used thumb=X, index=Y, and middle=Z.

Using the right hand, it require you to twist your arm to have the thumb 
point toward +X, then the index point to +Z

In my courses, with the left hand, it was: thumb = +Y, index= +Z, 
middle= +X with the index pointing forward and the thumb up.
Very easy to hold, and you can still have a pen in your right hand...
Maybe just a coincidence, but it's the same thing that is used to get 
the direction of the force exerced on a conductor in a magnetic field. 
The index is in the direction of the current (positive), the thumb in 
the direction of the magnetic field (north pole), and the middle finger 
in the direction of the force.
For the rotations, you point the thumb toward the + side of an axis, and 
the fingers curl in the direction of the positive rotation.

That's why, for me, ther was no learning curve to use the POV-Ray 
coordinate system. It's exactly the same I always used in school.

>
>> The right-handed system is mostly used by architecs, and, as most early
>> modeling applications where made for architecs, it stuck. It's also why
>> we have the infamous Z for the up direction. Architecs use the X and Y
>> axis along the ground and on paper where +X is right and +Y is the top
>> of the paper.
>
> If you put a proper math-style 2D coordinate system (X axis right, Y
> axis "top") onto paper, and then add +Z as height above ground, that's a
> left-handed system to me.
>
That's exactly how architecs work. And that's right handed.



Alain

Post a reply to this message

Am 01.03.2013 22:42, schrieb Alain:
> Le 2013-02-28 23:41, clipka a écrit :
>> Am 01.03.2013 04:14, schrieb Alain:
>>> Le 2013-02-28 08:24, Friedrich Lohmueller a écrit :
>>>
>>> In my math classes when looking at geometry, we only used the
>>> left-handed coordinate and rotation system. Also, Y was always UP and Z
>>> forward, NEVER relative to the paper's surface.
>>>
>>> It was the same in my physics courses.
>>
>> What? For us it was /always/ right-handed, for both maths and physics. I
>> can't believe it's different across the world in such disciplines.
>>
>> ... unless of course you use a different scheme to assign axes to the
>> fingers. We used thumb=X, index=Y, and middle=Z.
>
> Using the right hand, it require you to twist your arm to have the thumb
> point toward +X, then the index point to +Z
>
> In my courses, with the left hand, it was: thumb = +Y, index= +Z,
> middle= +X with the index pointing forward and the thumb up.
> Very easy to hold, and you can still have a pen in your right hand...

That's a left-handed system indeed, but I doubt it's the standard used 
in professional mathematics and physics. (Then again, in professional 
mathematics the handedness of the world is just abstracted away anyway. 
That leaves physics though.)


> Maybe just a coincidence, but it's the same thing that is used to get
> the direction of the force exerced on a conductor in a magnetic field.
> The index is in the direction of the current (positive), the thumb in
> the direction of the magnetic field (north pole), and the middle finger
> in the direction of the force.

If you swap any of the two components, you can do the same stunt with 
the right hand.

But here are two stunts you can't do left-handed:

Make a "thumbs-up" sign with your right hand. Point your thumb in the 
direction of current in a wire. The fingers will curl in the direction 
of the magnetic field around the wire.

Make a "thumbs-up" sign with your right hand. Hold your hand so that the 
fingers curl in the direction of current flowing in a coil. The thumb 
will point in the direction of the magnetic field inside the coil.


> For the rotations, you point the thumb toward the + side of an axis, and
> the fingers curl in the direction of the positive rotation.

That's true in both left- and right-handed coordinate systems, simply 
due to the way positive rotation is defined. (In other words, in a 
left-handed coordinate system positive rotation is defined just the 
other way round as in a right-handed one.)


> That's why, for me, ther was no learning curve to use the POV-Ray
> coordinate system. It's exactly the same I always used in school.

It might be a UK-schools special, which would explain why POV-Ray uses 
it. (Then again, you are not from the UK, are you?)


>> If you put a proper math-style 2D coordinate system (X axis right, Y
>> axis "top") onto paper, and then add +Z as height above ground, that's a
>> left-handed system to me.
>>
> That's exactly how architecs work. And that's right handed.

Doing the gymnastics again, yes - it is indeed.

Post a reply to this message

Le 2013-03-01 22:32, clipka a écrit :
> Am 01.03.2013 22:42, schrieb Alain:
>> Le 2013-02-28 23:41, clipka a écrit :
>>> Am 01.03.2013 04:14, schrieb Alain:
>>>> Le 2013-02-28 08:24, Friedrich Lohmueller a écrit :
>>>>
>>>> In my math classes when looking at geometry, we only used the
>>>> left-handed coordinate and rotation system. Also, Y was always UP and Z
>>>> forward, NEVER relative to the paper's surface.
>>>>
>>>> It was the same in my physics courses.
>>>
>>> What? For us it was /always/ right-handed, for both maths and physics. I
>>> can't believe it's different across the world in such disciplines.
>>>
>>> ... unless of course you use a different scheme to assign axes to the
>>> fingers. We used thumb=X, index=Y, and middle=Z.
>>
>> Using the right hand, it require you to twist your arm to have the thumb
>> point toward +X, then the index point to +Z
>>
>> In my courses, with the left hand, it was: thumb = +Y, index= +Z,
>> middle= +X with the index pointing forward and the thumb up.
>> Very easy to hold, and you can still have a pen in your right hand...
>
> That's a left-handed system indeed, but I doubt it's the standard used
> in professional mathematics and physics. (Then again, in professional
> mathematics the handedness of the world is just abstracted away anyway.
> That leaves physics though.)
>
>
>> Maybe just a coincidence, but it's the same thing that is used to get
>> the direction of the force exerced on a conductor in a magnetic field.
>> The index is in the direction of the current (positive), the thumb in
>> the direction of the magnetic field (north pole), and the middle finger
>> in the direction of the force.
>
> If you swap any of the two components, you can do the same stunt with
> the right hand.
>
> But here are two stunts you can't do left-handed:
>
> Make a "thumbs-up" sign with your right hand. Point your thumb in the
> direction of current in a wire. The fingers will curl in the direction
> of the magnetic field around the wire.
>
> Make a "thumbs-up" sign with your right hand. Hold your hand so that the
> fingers curl in the direction of current flowing in a coil. The thumb
> will point in the direction of the magnetic field inside the coil.
>
>
>> For the rotations, you point the thumb toward the + side of an axis, and
>> the fingers curl in the direction of the positive rotation.
>
> That's true in both left- and right-handed coordinate systems, simply
> due to the way positive rotation is defined. (In other words, in a
> left-handed coordinate system positive rotation is defined just the
> other way round as in a right-handed one.)
>
>
>> That's why, for me, ther was no learning curve to use the POV-Ray
>> coordinate system. It's exactly the same I always used in school.
>
> It might be a UK-schools special, which would explain why POV-Ray uses
> it. (Then again, you are not from the UK, are you?)
No. Canada.
>
>
>>> If you put a proper math-style 2D coordinate system (X axis right, Y
>>> axis "top") onto paper, and then add +Z as height above ground, that's a
>>> left-handed system to me.
>>>
>> That's exactly how architecs work. And that's right handed.
>
> Doing the gymnastics again, yes - it is indeed.
>

Post a reply to this message

On 1-3-2013 22:42, Alain wrote:
> Using the right hand, it require you to twist your arm to have the thumb
> point toward +X, then the index point to +Z
>

Just as an info: The modeller Silo uses the following right-handed 
system coordinate:

X to the right (thumb)
Y up (index)
Z towards viewer/out of screen (middle)

Moray, on the other hand (no pun intended), was right-handed as follows:

X to the right (thumb)
Y towards screen (index)
Z up (middle)

Thomas

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:

>
> Just as an info: The modeller Silo uses the following right-handed
> system coordinate:
>
> X to the right (thumb)
> Y up (index)
> Z towards viewer/out of screen (middle)
>
> Moray, on the other hand (no pun intended), was right-handed as follows:
>
> X to the right (thumb)
> Y towards screen (index)
> Z up (middle)
>

What a mess! :-P

Well, there seems to be at least ONE 'standard' that everyone/every system
agrees on: +x is to the right. Hooray! It's good to know that there's one little
'island of stability' in a chaotic world. ;-)

Post a reply to this message

On 6-3-2013 9:15, Kenneth wrote:
> What a mess! :-P
>
> Well, there seems to be at least ONE 'standard' that everyone/every system
> agrees on: +x is to the right. Hooray! It's good to know that there's one little
> 'island of stability' in a chaotic world. ;-)

In fact, once you get used to manipulating the different systems at the 
same time, you know exactly what to expect and how to merge everything 
harmoniously into POV-Ray.

So, for Moray, I always had two lines of code ready whenever I imported 
a Moray object into a POV scene:

scale <1,1,-1>
rotate <90,0,0>

Except of course, when I used complete Moray scenes. I suppose that the 
/new/ future Moray version is going to be left-handed by the way ;-)

Using Silo, I model as if the object were left-handed, export it as 
left-handed through Poseray, and then just rotate it by 180*y whence in 
POV-Ray.

Little tricks, but becoming automatic.

Thomas

Post a reply to this message

Am 06.03.2013 09:15, schrieb Kenneth:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>
>>
>> Just as an info: The modeller Silo uses the following right-handed
>> system coordinate:
>>
>> X to the right (thumb)
>> Y up (index)
>> Z towards viewer/out of screen (middle)
>>
>> Moray, on the other hand (no pun intended), was right-handed as follows:
>>
>> X to the right (thumb)
>> Y towards screen (index)
>> Z up (middle)
>>
>
> What a mess! :-P
>
> Well, there seems to be at least ONE 'standard' that everyone/every system
> agrees on: +x is to the right. Hooray! It's good to know that there's one little
> 'island of stability' in a chaotic world. ;-)
>
I don't want not spoil your joy :-)
but "+x is right" is not always right!
Sometimes it's also left!
Take a look at http://www.f-lohmueller.de/pov_anim/ani_3920d.htm

Post a reply to this message

Friedrich Lohmueller <Fri### [at] t-onlinede> wrote:

> >
> I don't want not spoil your joy :-)
> but "+x is right" is not always right!
> Sometimes it's also left!
> Take a look at http://www.f-lohmueller.de/pov_anim/ani_3920d.htm

Oh no!  TOTAL chaos now! (heh heh)

BTW, that's a really nice animation. I had not seen that particular page; thanks
for posting the link. (I need to revisit your website--LOTS of fascinating and
useful stuff there. Over the years, I've learned *many* POV-Ray tips and tricks
from all of it.)

Post a reply to this message

Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> So, we're asking for user feedback and recommendations for things to
> remove and things to add. Please followup to this thread ... thanks!

A few years ago, CLipka posted some well-annotated SDL code for dispersion to
the TINA-CHeP forums:

   http://tinachepforum.forumup.co.uk/about8-tinachepforum.html

If he is willing, I'd love to see that as a standard include file.

Post a reply to this message

Am 08.03.2013 03:03, schrieb Cousin Ricky:
> Chris Cason <del### [at] deletethistoopovrayorg> wrote:
>> So, we're asking for user feedback and recommendations for things to
>> remove and things to add. Please followup to this thread ... thanks!
>
> A few years ago, CLipka posted some well-annotated SDL code for dispersion to
> the TINA-CHeP forums:
>
>     http://tinachepforum.forumup.co.uk/about8-tinachepforum.html
>
> If he is willing, I'd love to see that as a standard include file.

You might want to have a look at your POV-Ray 3.7 standard include 
directory - keep your eyes peeled for "ior.inc" ;-)

Post a reply to this message

Le 2013-03-08 02:02, clipka a écrit :
> Am 08.03.2013 03:03, schrieb Cousin Ricky:
>> Chris Cason <del### [at] deletethistoopovrayorg> wrote:
>>> So, we're asking for user feedback and recommendations for things to
>>> remove and things to add. Please followup to this thread ... thanks!
>>
>> A few years ago, CLipka posted some well-annotated SDL code for
>> dispersion to
>> the TINA-CHeP forums:
>>
>>     http://tinachepforum.forumup.co.uk/about8-tinachepforum.html
>>
>> If he is willing, I'd love to see that as a standard include file.
>
> You might want to have a look at your POV-Ray 3.7 standard include
> directory - keep your eyes peeled for "ior.inc" ;-)
>

I think that it will become one of my favourite includes.

Post a reply to this message

Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> Folks,
>
> With the release of v3.7 nearing the team is looking at the content of
> the standard distribution, in particular the sample scene files.
>
> The additions can be in the form of macros, include files, demo files,
> and sample scenes (either stand-alone or templates). Any additions we
> do make need to be licensed under the CC or AGPL3, or more openly
> (such as BSD or public domain).
>

I do not think this has been forgotten yet. Damn procrastination.

http://news.povray.org/povray.binaries.images/thread/%3C4d3ed424@news.povray.org%3E/?ttop=357771

link doesn't works? try search "spline-based highway macro"

B. Gimeno

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> You might want to have a look at your POV-Ray 3.7 standard include
> directory - keep your eyes peeled for "ior.inc" ;-)

Typical.  I come up with an idea, and someone else has already thought of it.
:-P

That is the only file added since version 3.5 (so far), although the byte counts
on some of the .inc files have changed.

Post a reply to this message

On 9-3-2013 17:51, Cousin Ricky wrote:
> That is the only file added since version 3.5 (so far), although the byte counts
> on some of the .inc files have changed.

Not really /new/: "last updated: 2010.12.12"  ;-)

Thomas

Post a reply to this message

Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> So, we're asking for user feedback and recommendations for things to
> remove and things to add. Please followup to this thread ... thanks!

How about adding this line to consts.inc:

  #declare tau = 2 * pi;

In 4.0, this can be replaced with a built-in variable.

Post a reply to this message

Le 23/03/2013 13:59, Cousin Ricky a écrit :
> Chris Cason <del### [at] deletethistoopovrayorg> wrote:
>> So, we're asking for user feedback and recommendations for things to
>> remove and things to add. Please followup to this thread ... thanks!
> 
> How about adding this line to consts.inc:
> 
>   #declare tau = 2 * pi;
> 
> In 4.0, this can be replaced with a built-in variable.
> 
> 
> 
this does not seem yet to be an universal value:

http://en.wikipedia.org/wiki/Tau

there is 2*pi, but also the golden ratio [ (1+sqrt(5))/2 ]

What's wrong so far with 2*pi ?

-- 
Just because nobody complains does not mean all parachutes are perfect.

Post a reply to this message

On 25/03/2013 7:50 AM, Le_Forgeron wrote:
> What's wrong so far with 2*pi ?

You couldn't make it up.

http://www.bbc.co.uk/news/science-environment-13906169

-- 
Regards
     Stephen

Post a reply to this message