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