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