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

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