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

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