Hello,

I'm starting a new thread for the v3.7 example scenes project as this is a 
side topic that came from the povray.ini thread and dosen't seem to really 
belong there anymore.

Jim

Post a reply to this message

Jim Holsenback <jho### [at] hotmailcom> wrote:
> I'm starting a new thread for the v3.7 example scenes project as this is a 
> side topic that came from the povray.ini thread and dosen't seem to really 
> belong there anymore.

  It would be nice if there would be a set of cool scenes showcasing all the
new features of POV-Ray 3.7. Preferably scenes which are nigh impossible (or
very laborious) to get with v3.6

  Of course there aren't that many new (visible) features in 3.7, but the
few that are (eg. HDRI and area highlights) should be showcased prominently.

-- 
                                                          - Warp

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message 
news:48876e92@news.povray.org...
>  It would be nice if there would be a set of cool scenes showcasing all 
> the
> new features of POV-Ray 3.7. Preferably scenes which are nigh impossible 
> (or
> very laborious) to get with v3.6
>
>  Of course there aren't that many new (visible) features in 3.7, but the
> few that are (eg. HDRI and area highlights) should be showcased 
> prominently.
>
> -- 
>                                                          - Warp

good idea .... now all that's left is to line up some contributors. at this 
point i've not thought much about this aspect of the effort. i would say 
that some sort of selection criteria is in order. i'm not to interested in 
this becomming (for lack of a better word) a contest where judging is 
involved .... hmmmm not sure of a way around this. i'm for kicking this 
around some ....

Jim

Post a reply to this message

"Jim Holsenback" <jho### [at] hotmailcom> wrote in message 
news:48876483@news.povray.org...
> I'm starting a new thread for the v3.7 example scenes project as this is a 
> side topic that came from the povray.ini thread and dosen't seem to really 
> belong there anymore.

i've got the latest beta downloaded and installed. the biscuit scene renders 
fine. i did notice that the examples scenes didn't come with this setup. i 
know it's bad etiquette but a while back i may have stepped on more than one 
or two of the scene files that came with v3.6 install. that brings to mind 
how can we be sure that we are all working from the same files? is there a 
place to go get (ftp) just the example files or am i just going to have to 
get them from the last stable install?

finally .... i have "ksh" and perl on my windows machine (a win nt to unix 
migration tool) and i could very easily produce a manifest of all the 
example files. that might help in trying to figure out how to carve this up 
into who's working on what.

Jim

Post a reply to this message

"Jim Holsenback" <jho### [at] hotmailcom> wrote in message 
news:48877ccc@news.povray.org...
> i did notice that the examples scenes didn't come with this setup.

doh! i see them in the application data folder .... my bad

Post a reply to this message

At least one example scene showcasing the area highlights could be based
on this test render of mine:
  http://warp.povusers.org/images/arealighttest3.jpg

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Jim Holsenback <jho### [at] hotmailcom> wrote:
>> I'm starting a new thread for the v3.7 example scenes project as this is a 
>> side topic that came from the povray.ini thread and dosen't seem to really 
>> belong there anymore.
> 
>   It would be nice if there would be a set of cool scenes showcasing all the
> new features of POV-Ray 3.7. Preferably scenes which are nigh impossible (or
> very laborious) to get with v3.6
> 
>   Of course there aren't that many new (visible) features in 3.7, but the
> few that are (eg. HDRI and area highlights) should be showcased prominently.

Apart from that it would be nice to get some fresh air into the advanced
scenes subdir (or create a new sub-section called 'samples' or something).
basically to get some more 'real' sample scenes into the distribution;
there's surely a lot of nice work out there, perhaps some authors would be
willing to contribute some nice scenes (either on a derivative-work-ok or
possibly a no-derivatives basis).

While I still think examples such as fish13 are interesting, they do smell
a little of mothballs :-)

-- Chris

Post a reply to this message

Jim Holsenback wrote:
> good idea .... now all that's left is to line up some contributors. at this 
> point i've not thought much about this aspect of the effort. i would say 
> that some sort of selection criteria is in order. i'm not to interested in 
> this becomming (for lack of a better word) a contest where judging is 
> involved .... hmmmm not sure of a way around this. i'm for kicking this 
> around some ....

sounds like a good topic for the first or second round of the new IRTC ...

-- Chris

Post a reply to this message

Jim Holsenback wrote:
> "Jim Holsenback" <jho### [at] hotmailcom> wrote in message 
> news:48877ccc@news.povray.org...
>> i did notice that the examples scenes didn't come with this setup.
> 
> doh! i see them in the application data folder .... my bad 

I should probably put a README in the program files/scenes folder to remind
folks where they've moved to.

-- Chris

Post a reply to this message

Jim Holsenback wrote:
> how can we be sure that we are all working from the same files? is there a 
> place to go get (ftp) just the example files or am i just going to have to 
> get them from the last stable install?

please use the files that came with the latest beta.

if you need an FTP dir for uploading the results please let me know.

-- Chris

Post a reply to this message

Another thing that's occurred to me that would be nice if it can be done is
a HTML page containing thumbnails and a short description of most of the
sample scenes. This could be included in the docs and the distro ... from
an end-users point of view, if I was installing POV for the first time, the
sample scenes would be the first thing I'd head for, and being able to see
what each one looks like in advance would be neat.

-- Chris

Post a reply to this message

Jim Holsenback wrote:
> Hello,
> 
> I'm starting a new thread for the v3.7 example scenes project as this is a 
> side topic that came from the povray.ini thread and dosen't seem to really 
> belong there anymore.
> 
> Jim
> 
>

I'm reinstalling povray, and reading through all the beta notes. Once 
I'm awake and have my head wrapped around what I need to do, I'll start 
comparing a few images to make sure I understand it.

Post a reply to this message

Chris Cason schrieb:

> Another thing that's occurred to me that would be nice if it can be done is
> a HTML page containing thumbnails and a short description of most of the
> sample scenes. This could be included in the docs and the distro ... from
> an end-users point of view, if I was installing POV for the first time, the
> sample scenes would be the first thing I'd head for, and being able to see
> what each one looks like in advance would be neat.

For MegaPOV i made a script that builds such a page based on the header 
comments in the scene file - a somewhat extended version of what comes 
with the POV-Ray 3.6 Unix version.  The result:

http://megapov.inetart.net/samples.html

-- Christoph

Post a reply to this message

"Chris Cason" <del### [at] deletethistoopovrayorg> wrote in 
message news:4887b7bb$1@news.povray.org...
> sounds like a good topic for the first or second round of the new IRTC ...
>
> -- Chris

yes .... i think thtas a great idea

Jim

Post a reply to this message

"Chris Cason" <del### [at] deletethistoopovrayorg> wrote in 
message news:4887b8f1$1@news.povray.org...
> Another thing that's occurred to me that would be nice if it can be done 
> is
> a HTML page containing thumbnails and a short description of most of the
> sample scenes. This could be included in the docs and the distro ... from
> an end-users point of view, if I was installing POV for the first time, 
> the
> sample scenes would be the first thing I'd head for, and being able to see
> what each one looks like in advance would be neat.
>
> -- Chris

it's seems like an easy enough thing to do .... should there be any 
agreement on image size and format (jpg, png, bmp)
How about 1024x768 jpg?

Jim

Post a reply to this message

"Christoph Hormann" <chr### [at] gmxde> wrote in message 
news:48881dd1$1@news.povray.org...
> For MegaPOV i made a script that builds such a page based on the header 
> comments in the scene file - a somewhat extended version of what comes 
> with the POV-Ray 3.6 Unix version.  The result:
>
> http://megapov.inetart.net/samples.html
>
> -- Christoph

that's a nice clean format .... how did you do it? a html template file and 
awk, sed, perl?

Jim

Post a reply to this message

"Jim Holsenback" <jho### [at] hotmailcom> wrote in message 
news:48876483@news.povray.org...
> Hello,
>
> I'm starting a new thread for the v3.7 example scenes project as this is a
> side topic that came from the povray.ini thread and dosen't seem to really
> belong there anymore.

I've completed a file manifest .... we have 365 pov files. I didn't count 
includes, ini or image files.

I've attached the breakdown.

Jim

Post a reply to this message

Attachments:
Download 'file-list.txt' (18 KB)

Christoph Hormann <chr### [at] gmxde> wrote:
> For MegaPOV i made a script that builds such a page based on the header 
> comments in the scene file - a somewhat extended version of what comes 
> with the POV-Ray 3.6 Unix version.  The result:

> http://megapov.inetart.net/samples.html

  Does it take into account that not all scene files have an aspect ratio
of 4:3?

  (Personally I feel nothing more irritating than automatically rendered
images which use the wrong aspect ratio, squeezing the image horribly.)

-- 
                                                          - Warp

Post a reply to this message

Jim Holsenback <jho### [at] hotmailcom> wrote:
> it's seems like an easy enough thing to do .... should there be any 
> agreement on image size and format (jpg, png, bmp)
> How about 1024x768 jpg?

  Take into account that not all the scene files use an aspect ratio of 4:3.
Those which don't have to be rendered with the proper resolution.

  Probably the width of the rendered images could be fixed, while the
height depends on the aspect ratio.

-- 
                                                          - Warp

Post a reply to this message

Jim Holsenback schrieb:
> 
> that's a nice clean format .... how did you do it? a html template file and 
> awk, sed, perl?

it's a shell script analyzing the header comment of the scene files and 
rendering the scene and generating the list accordingly.

I will try to have a look at it during the weekend.

-- Christoph

Post a reply to this message

Warp schrieb:
> 
>   Does it take into account that not all scene files have an aspect ratio
> of 4:3?

The render options are specified as a scene comment as it is already 
done in most of the 3.6 sample scenes.

-- Christoph

Post a reply to this message

"Jim Holsenback" <jho### [at] hotmailcom> wrote:
> I'm starting a new thread for the v3.7 example scenes project ...
Ok, I've reinstalled POV-Ray 3.7.0.beta27.
I'll go step by step in case my method needs fixing.
As my first victim, scenes\qtvr\qtvrpanorama.pov from 3.7
File states:
#version 3.5;
global_settings{ assumed_gamma 1.0}
//-w384 -h1284 (command line recomended)

1)I run the scene with POV-Ray 3.5
2)I run the scene with POV-Ray 3.7(new output file name)
3)I run the scene with POV-Ray 3.7, removing version and gamma(new output file
name)

I compare 1 and 2, PaintShopPro/Arithmetic/difference. The resulting image is
not blank.
I compare 1 and 3, PaintShopPro/Arithmetic/difference. The resulting image is
not blank.

qtvrpanorama.pov does not render the same.
Yikes, now what?

Include the updated scene anyways? If it needs fixing, this will be beyond me.

Post a reply to this message

StephenS wrote:
> "Jim Holsenback" <jho### [at] hotmailcom> wrote:
>> I'm starting a new thread for the v3.7 example scenes project ...
> Ok, I've reinstalled POV-Ray 3.7.0.beta27.
> I'll go step by step in case my method needs fixing.
> As my first victim, scenes\qtvr\qtvrpanorama.pov from 3.7
> File states:
> #version 3.5;
> global_settings{ assumed_gamma 1.0}
> //-w384 -h1284 (command line recomended)
> 
> 1)I run the scene with POV-Ray 3.5
> 2)I run the scene with POV-Ray 3.7(new output file name)
> 3)I run the scene with POV-Ray 3.7, removing version and gamma(new output file
> name)
> 
> I compare 1 and 2, PaintShopPro/Arithmetic/difference. The resulting image is
> not blank.
> I compare 1 and 3, PaintShopPro/Arithmetic/difference. The resulting image is
> not blank.
> 
> qtvrpanorama.pov does not render the same.
> Yikes, now what?
> 
> Include the updated scene anyways? If it needs fixing, this will be beyond me.
> 
> 

Next is talking about what changes are visible, and figuring out what to 
change to "fix" it. Some differences will be easy, others might not. As 
a group, though, we should be able to get a good many of them.

Post a reply to this message

"Sabrina Kilian" <"ykgp at vtSPAM.edu"> wrote in message 
news:488a6e58@news.povray.org...
> StephenS wrote:
>> "Jim Holsenback" <jho### [at] hotmailcom> wrote:
>>> I'm starting a new thread for the v3.7 example scenes project ...
>> Ok, I've reinstalled POV-Ray 3.7.0.beta27.
>> I'll go step by step in case my method needs fixing.
>> As my first victim, scenes\qtvr\qtvrpanorama.pov from 3.7
>> File states:
>> #version 3.5;
>> global_settings{ assumed_gamma 1.0}
>> //-w384 -h1284 (command line recomended)
>>
>> 1)I run the scene with POV-Ray 3.5
>> 2)I run the scene with POV-Ray 3.7(new output file name)
>> 3)I run the scene with POV-Ray 3.7, removing version and gamma(new output 
>> file
>> name)
>>
>> I compare 1 and 2, PaintShopPro/Arithmetic/difference. The resulting 
>> image is
>> not blank.
>> I compare 1 and 3, PaintShopPro/Arithmetic/difference. The resulting 
>> image is
>> not blank.
>>
>> qtvrpanorama.pov does not render the same.
>> Yikes, now what?
>>
>> Include the updated scene anyways? If it needs fixing, this will be 
>> beyond me.
>>
>>
>
> Next is talking about what changes are visible, and figuring out what to 
> change to "fix" it. Some differences will be easy, others might not. As a 
> group, though, we should be able to get a good many of them.

i think before we get to far ahead of ourselves we should divide up the 
examples so we can work without stepping on each others toes. if there are 
no objections i'll use the manifest list to evenly divide up those scenes 
into managable chunks. i think a good first pass would be to try to render 
the scenes and see what goes without any changes. fails/warnings/problems 
lets just make notes and move on to the next scene. i think this will pare 
down the list and help use identify the problem scenes. as for debugging i 
agree with Sabrina that we should be able work through most problems amoung 
ourselves. if not, i'm sure that others in the users community will be able 
to bail us out. i'll wait a bit for any comments before proceeding in case 
either of you have a better idea how to go forward.

Jim

Post a reply to this message

"Jim Holsenback" <jho### [at] hotmailcom> wrote:
....
>if there are
> no objections i'll use the manifest list to evenly divide up those scenes
> into managable chunks...
Good idea. Use more chunks than people so new people can easly join, or another
chunk can be taken if one is easy(or time permits).

Post a reply to this message

"StephenS" <nomail@nomail> wrote:
....
> qtvrpanorama.pov does not render the same.
....
Just for my own curiosity:
~changing the noise generator had little effect
~The scene uses crackle, turbulence is already listed first.

The difference in the 3.7 and 3.5 pictures is from the use of crackle.
Any other suggestions?

Post a reply to this message

Jim Holsenback wrote:
> "Sabrina Kilian" <"ykgp at vtSPAM.edu"> wrote in message 
> news:488a6e58@news.povray.org...
>> StephenS wrote:
>>> "Jim Holsenback" <jho### [at] hotmailcom> wrote:
>>>> I'm starting a new thread for the v3.7 example scenes project ...
>>> Ok, I've reinstalled POV-Ray 3.7.0.beta27.
>>> I'll go step by step in case my method needs fixing.
>>> As my first victim, scenes\qtvr\qtvrpanorama.pov from 3.7
>>> File states:
>>> #version 3.5;
>>> global_settings{ assumed_gamma 1.0}
>>> //-w384 -h1284 (command line recomended)
>>>
>>> 1)I run the scene with POV-Ray 3.5
>>> 2)I run the scene with POV-Ray 3.7(new output file name)
>>> 3)I run the scene with POV-Ray 3.7, removing version and gamma(new output 
>>> file
>>> name)
>>>
>>> I compare 1 and 2, PaintShopPro/Arithmetic/difference. The resulting 
>>> image is
>>> not blank.
>>> I compare 1 and 3, PaintShopPro/Arithmetic/difference. The resulting 
>>> image is
>>> not blank.
>>>
>>> qtvrpanorama.pov does not render the same.
>>> Yikes, now what?
>>>
>>> Include the updated scene anyways? If it needs fixing, this will be 
>>> beyond me.
>>>
>>>
>> Next is talking about what changes are visible, and figuring out what to 
>> change to "fix" it. Some differences will be easy, others might not. As a 
>> group, though, we should be able to get a good many of them.
> 
> i think before we get to far ahead of ourselves we should divide up the 
> examples so we can work without stepping on each others toes. 

I didn't mean it was the next immediate step, just the next thing to do 
for that single image.

>if there are 
> no objections i'll use the manifest list to evenly divide up those scenes 
> into managable chunks. i think a good first pass would be to try to render 
> the scenes and see what goes without any changes. fails/warnings/problems 
> lets just make notes and move on to the next scene.

That sounds like a good idea to me. I can think of one possible issue. 
Certain files in the demo scenes tend to take a lot longer to render. If 
memory serves me right, the radiosity ones take more time, in general, 
and should be split over multiple chunks.

> i think this will pare 
> down the list and help use identify the problem scenes. as for debugging i 
> agree with Sabrina that we should be able work through most problems amoung 
> ourselves. if not, i'm sure that others in the users community will be able 
> to bail us out. i'll wait a bit for any comments before proceeding in case 
> either of you have a better idea how to go forward.
> 
> Jim 
> 
> 

The last thing we need to agree on might be an ideal image format to 
test with. I'm not familiar with the technical differences between Targa 
and PNG, could anyone else chime in if we might notice certain 
differences that appear in one or the other, or at certain bit depths?

Post a reply to this message

StephenS wrote:
> qtvrpanorama.pov does not render the same.

It doesn't need to be identical, however we need to evaluate for each image
the reason for the difference. If it's a bug or unimplemented feature, then
please let me know (even if it's a known issue - it will help to have a new
list based on all the sample scenes being tested). If it's simply due to a
difference in the way 3.7 works, we need to evaluate whether or not it
makes the scene no longer relevant.

NB the next beta (out in the next few days) has some improvements which you
may want to be using. I can upload a binary for you (EXE only, I am still
working on the installer) if you want to have access to it immediately.
Please email me if so.

-- Chris

Post a reply to this message

Christoph Hormann wrote:
> For MegaPOV i made a script that builds such a page based on the header 
> comments in the scene file - a somewhat extended version of what comes 
> with the POV-Ray 3.6 Unix version.  The result:
> 
> http://megapov.inetart.net/samples.html

I think this is a very useful start.

-- Chris

Post a reply to this message

Jim Holsenback wrote:
> How about 1024x768 jpg?

Keep in mind all of the images need to go into the distro; it would depend
on the filesize of the combined images as to whether or not we could use
that size. we might want to include smaller images to start off with, and
have an alternate version of the HTML files that link to larger versions
online. Or just include the thumbnails (presuming we use a reasonable size
for these; e.g. 320 width) and always have the large version linked online.

One thing I think would be nice is if we use a smaller thumbnail (e.g. 160
width), and have a larger (e.g. 320 or even 512 pixel width) one become
visible upon mouse hover. Full-size images would all be online in that case.

(Also, if we have an online version, it might be nice to link to it from
the scene source file - if we do that I might add HTML link recognition to
the POVWIN editor).

-- Chris

Post a reply to this message

Sabrina Kilian wrote:
> The last thing we need to agree on might be an ideal image format to 
> test with. I'm not familiar with the technical differences between Targa 
> and PNG, could anyone else chime in if we might notice certain 
> differences that appear in one or the other, or at certain bit depths?

Either is OK, as both are lossless formats (ie, they should result in 
the exact same image).

...Chambers

Post a reply to this message

Hola,

I've completed a review of the v3.7 example scenes. A picture is worth a 
1000 words so I've attached a pie chart showing the breakdown.
I also wrote a quick shell script to help target potential resourse 
bottlenecks. I just produced this stuff so I've not had much time to think 
about how to divide it up yet. Any thoughts? Finally I'm wondering if there 
is a need to restate what it is we are going to be doing, image file 
formats, what AA to use, etc and include it in a single document that we can 
all read comment on and agree to before digging in. I'd hate to be halfway 
through and find out that "Hey!!!! that's not what we agreed on!"

If I'm not stepping on any toes I'll commit to pulling togeather a mission 
statement. I think this is may be the final piece before proceeding. Shout 
if you don't agree!

This are the strings I looked for:
isosurface {
scattering {
radiosity {

These files have isosurfaces:

./advanced/abyss.pov
./advanced/benchmark.pov
./advanced/biscuit.pov
./advanced/isocacti.pov
./advanced/landscape.pov
./advanced/optics.pov
./incdemo/i_internal.pov
./language/trace2.pov
./objects/isosurfaces.pov
./portfolio/allobjects.pov
./portfolio/allpat1iso.pov
./portfolio/allpat2iso.pov
./textures/patterns/crackle2.pov
./textures/patterns/crackle3.pov
./textures/patterns/crackle_form.pov

These files have scattering media:

./advanced/abyss.pov
./advanced/benchmark.pov
./advanced/mediasky.pov
./advanced/optics.pov
./interior/media/galaxy.pov
./interior/media/media1.pov
./interior/media/media2.pov
./interior/media/media3.pov

The files have radiosity:

./advanced/benchmark.pov
./advanced/gaussianblob.pov
./advanced/object_pattern.pov
./animations/raddem/raddem.pov
./radiosity/patio-radio.pov
./radiosity/radiosity.pov
./radiosity/radiosity2.pov
./radiosity/radiosity3.pov
./radiosity/rad_def_test.pov

Cheers Jim

Post a reply to this message

Attachments:
Download 'scene-files.jpg' (138 KB)

Preview of image 'scene-files.jpg'

Chris Cason wrote:
> Jim Holsenback wrote:
>> How about 1024x768 jpg?
> 
> Keep in mind all of the images need to go into the distro; it would depend
> on the filesize of the combined images as to whether or not we could use
> that size. we might want to include smaller images to start off with, and
> have an alternate version of the HTML files that link to larger versions
> online. Or just include the thumbnails (presuming we use a reasonable size
> for these; e.g. 320 width) and always have the large version linked
> online.
> 
> One thing I think would be nice is if we use a smaller thumbnail (e.g. 160
> width), and have a larger (e.g. 320 or even 512 pixel width) one become
> visible upon mouse hover. Full-size images would all be online in that
> case.

Do the same as for the Insert menu. Put small images in the package and have
an automatic way to re-render them at a bigger size.

Post a reply to this message

Nicolas Alvarez wrote:
> Do the same as for the Insert menu. Put small images in the package and have
> an automatic way to re-render them at a bigger size.

I could, but I suspect that 99% of people wouldn't bother (and/or wouldn't
know). Most would, I feel, rather just point and click, even if that
involves pulling down the images from the internet. (We could provide a
downloadable set of the large images at the same site).

-- Chris

Post a reply to this message

Nice work!

Post a reply to this message

Jim Holsenback wrote:

> This are the strings I looked for:
> isosurface {
> scattering {
> radiosity {

I think you place too much trust in consistent coding
style here ;) e.g., in 3.6, the following scenes use
"radiosity{" without a space:

advanced\balcony\balcony.pov(67)
advanced\blocks\stackerday.pov(40)
advanced\blocks\stackernight.pov(41)
radiosity\cornell.pov

and there may be more using the prettier way (troll troll)
of opening the curly brace on the next line ;)

Post a reply to this message

Chambers nous illumina en ce 2008-07-26 15:47 -->
> Sabrina Kilian wrote:
>> The last thing we need to agree on might be an ideal image format to 
>> test with. I'm not familiar with the technical differences between 
>> Targa and PNG, could anyone else chime in if we might notice certain 
>> differences that appear in one or the other, or at certain bit depths?
> 
> Either is OK, as both are lossless formats (ie, they should result in 
> the exact same image).
> 
> ...Chambers
The main difference between TGA and PNG, is that TGA is normaly not compressed 
while PNG is a lossless compressed format.

-- 
Alain
-------------------------------------------------
I bet exercise equipment would be a lot more expensive if we had evolved from 
starfish.

Post a reply to this message

Chris Cason wrote:
> Nicolas Alvarez wrote:
>> Do the same as for the Insert menu. Put small images in the package and
>> have an automatic way to re-render them at a bigger size.
> 
> I could, but I suspect that 99% of people wouldn't bother (and/or wouldn't
> know). Most would, I feel, rather just point and click, even if that
> involves pulling down the images from the internet. (We could provide a
> downloadable set of the large images at the same site).

What if it renders from the last in the list, downloads from the first in
the list, and calls it done when they meet in the middle? That way it'd
fully use both network and CPU resources :)

Bonus points for ordering the list by render time : file size ratio
(download the slowest to render, render the slow to download).

Post a reply to this message

"Chris Cason" <del### [at] deletethistoopovrayorg> wrote in 
message news:488f0949@news.povray.org...
> Nice work!

Thanks .....

I've also had a poke around some of the examples and I have some questions.

It seems the biggest issue is going to be the assumed_gamma handling change 
in v3.7. If I'm understanding correctly if the parser sees the inclusion of 
that keyword it basically spits out a warning and handles gamma correction 
based on what you have in resolution.ini. Is that correct? So there's no way 
to compare a before and after image. I used isocacti as a test case and saw 
no visual difference in the image with assumed_gamma and with it commented 
out.

Another thing I looked at was some of the animation examples. Some examples 
had ini files and started clocking through and produced a series of images. 
Do we want to run through the entire animation, and produce a mov. I have QT 
pro to do that if that's the case. (I'm sure there are other apps for this) 
but QT is what I'm comfortable with.

I've reread through this thread and it still seems that there is no 
consensus on image file format and size. Whats the best approach here? 
Produce a full sized image and just scale for the thumbnails, or two 
separate runs.

What kind of timeframe are we working against here ..... by the end of the 
beta cycle and before v3.7 final release?

I'm sure there are one or two more issues that I've not hit upon. 
Stephen/Sabrina .... you guys have been mostly silent. What kind of initial 
issues have you seen? I really think it's important to get as many of the 
issues as we can out in the open before formulating a test plan. If I'm off 
base on this please speak up. I'm flexible and have no problem being pointed 
in the right direction.

Jim

Post a reply to this message

"Christian Froeschlin" <chr### [at] chrfrde> wrote in message 
news:488f283f@news.povray.org...
> Jim Holsenback wrote:
>
>> This are the strings I looked for:
>> isosurface {
>> scattering {
>> radiosity {
>
> I think you place too much trust in consistent coding
> style here ;) e.g., in 3.6, the following scenes use
> "radiosity{" without a space:
>

oooo .... good point. perhaps just looking for the keyword (no brace) would 
be better.

> advanced\balcony\balcony.pov(67)
> advanced\blocks\stackerday.pov(40)
> advanced\blocks\stackernight.pov(41)
> radiosity\cornell.pov

easy enough to change the script I used to hunt for these occurances. i'll 
see if the count changes by much. maybe I should be looking for photons 
keyword as well.
>
> and there may be more using the prettier way (troll troll)
> of opening the curly brace on the next line ;)

i think omitting the brace might give a better snapshot of whats out there 
..... a ballpark estime anyway

Jim

Post a reply to this message

"Jim Holsenback" <jho### [at] hotmailcom> wrote:
....
> I'm sure there are one or two more issues that I've not hit upon.
> Stephen/Sabrina .... you guys have been mostly silent. What kind of initial
> issues have you seen? I really think it's important to get as many of the
> issues as we can out in the open before formulating a test plan. If I'm off
> base on this please speak up. I'm flexible and have no problem being pointed
> in the right direction.
My current understanding is:
~Stage one: Identify included content that no longer produces the same result in
3.7 as the version it was made for. Update files to reflect; removal of #version
if possible, and removal of version 3.5/3.6 in comments.
~Stage two: Update/remove/new content and the way it's presented to the end
user.
 Stage one is the level I signed up for, Stage two is interesting but only as an
observer.
If you could group the files into managable chunks, I'll start reporting back my
findings;)

Post a reply to this message

"StephenS" <nomail@nomail> wrote in message 
news:web.4890749415676239b586e7830@news.povray.org...
> My current understanding is:
> ~Stage one: Identify included content that no longer produces the same 
> result in
> 3.7 as the version it was made for. Update files to reflect; removal of 
> #version
> if possible, and removal of version 3.5/3.6 in comments.
> ~Stage two: Update/remove/new content and the way it's presented to the 
> end
> user.
> Stage one is the level I signed up for, Stage two is interesting but only 
> as an
> observer.
> If you could group the files into managable chunks, I'll start reporting 
> back my
> findings;)

Last evening I reviewed about two dozen files from various locations. 
Without fail assumed_gamma was the prevailing issue. Several files had 
version 3.1 brands. There was one or two files that had noticeable blocks of 
code commented out. I also noticed that some but not all source files had 
ini files. I think this a great feature that we might use in the process of 
producing the final quality images for the distribution. Stephens comments 
and one other limiting factor for me (dial-up) leads me to believe that 
there may be a better way to approach this project. The whole thing depends 
on Chris having a machine that has enough free cycles to crank out the final 
product, so I will be brief.



Divide the source files into four chunks. Three for the review team, one 
left over for whoever gets done first. While that's going on there needs to 
be a decision made about final image quality, size, and format. Every source 
final gets an ini file with the agreed upon render options. See if we might 
be able to leverage off what Christoph did with the MegaPov examples. The 
testing on our end will just involve branding a version if necessary, making 
sure any parser warnings are resolved, and seeing that the image does indeed 
render. No worries about quality and size as the images will just be 
discarded. Upload the cleaned up source and ini files, and batch them up for 
processing.

Cheers
Jim

Post a reply to this message

Jim Holsenback wrote:
> It seems the biggest issue is going to be the assumed_gamma handling change 
> in v3.7. If I'm understanding correctly if the parser sees the inclusion of 
> that keyword it basically spits out a warning and handles gamma correction 
> based on what you have in resolution.ini. Is that correct? So there's no way 

It's a little more complicated than that: best to read the release notes
regarding that (I'll paste the relevant section in a followup to this message).

> Another thing I looked at was some of the animation examples. Some examples 
> had ini files and started clocking through and produced a series of images. 
> Do we want to run through the entire animation, and produce a mov. I have QT 

I don't think this is necessary, just a single still would do.

> I've reread through this thread and it still seems that there is no 
> consensus on image file format and size. Whats the best approach here? 
> Produce a full sized image and just scale for the thumbnails, or two 
> separate runs.

Scaling to thumbnails is fairly easy, so I'd recommend that. For full-size
images you could render at a width of, say, 768, with the height being
whatever that scales to with the aspect ratio taken into account.

> What kind of timeframe are we working against here ..... by the end of the 
> beta cycle and before v3.7 final release?

No specific time other than that obviously we have to get it done before we
release :). It would be nice to have the updated scenes in the betas sooner
than later.

One other suggestion: when leaving a #version in the scene file, it might
be good to add a comment above it that says e.g. "minimum POV-Ray version
needed to render this scene", or something like that.

thanks,

-- Chris

Post a reply to this message

Here's the relevant portions of the notes:

>   The way POV-Ray 3.7 handles the 'assumed_gamma' keyword has changed.
>   Previously the presence of this keyword in global_settings caused a
>   'possible error' warning and its presence was ignored. In addition
>   no gamma correction was available in previous betas. Starting with
>   beta.10 however, gamma correction is performed on both the display and
>   file output, subject to the following criteria:
> 
>     o If the scene language version is set to 3.7 (or not set at all), then
>       gamma correction will default to ON, with the value used being set by
>       the 'display_gamma' INI file setting. Note that in previous versions of
>       POV-Ray gamma correction was OFF by default but otherwise this is the
>       same.
> 
>     o If the scene language version is set to earlier than 3.7, then gamma
>       will be OFF by default.
> 
>     o Notwithstanding the above, if the keyword 'assumed_gamma' is present
>       in the scene's global_settings, then POV will take one of the following
>       actions:
> 
>         a) if "assumed_gamma 2.2" is present, gamma correction will be turned
>            OFF and a warning issued. the same thing will happen if the value
>            specified is not 2.2 but happens to be the default for the platform
>            setting given to POV-Ray when it was compiled (e.g. Windows is 2.2).
> 
>         b) if "assumed_gamma 1.0" is present, gamma correction will be turned
>            ON (if it's not already on) and in any case a warning will be issued.
> 
>         c) if a value other than the above is specified, it is ignored and a
>            'possible error' message is issued.
> 
>       You will note from the above that therefore it is no longer possible to
>       adjust the amount of gamma correction from a scene file. This is as
>       designed since scene files should be as much as possible be platform
>       independent, and the gamma of particular display hardware does not belong
>       in the scene file. If you really need to specify 'assumed_gamma' you can
>       do so in an INI file or on the command-line; however in those cases you
>       may as well just use 'display_gamma' in its place.
> 
>       When writing file formats that support gamma specification, the inverse
>       of the assumed_gamma value will be embedded in the file headers, so that
>       an appropriately equipped display program can 'undo' the gamma correction
>       if it is so desired. This is as per previous versions of POV-Ray.
> 
>   Frontend and Backend
>   --------------------
>       
>   Note that POV-Ray uses a logical separation of frontend and backend. The
>   'frontend' is that part which deals with the user-interface, locating files,
>   parsing command-line options, reading INI files, and so forth. The 'backend'
>   deals with parsing the scene file and doing the actual render. These two parts
>   of POV-Ray communicate via a message-passing interface, even when linked into
>   the one executable program.
>   
>   Whilst currently not supported, it is entirely possible to separate the front
>   and back ends via for example a network interface, and have the render done
>   on one machine while the user interface (and display) is on another. Knowing
>   this may make it easier to understand why, for example, we are moving away
>   from allowing things such as gamma correction to be specified in the scene
>   file; there is no reason to assume the scene file is on the same machine as
>   the image will be displayed upon, and as such the specification of gamma
>   should be done in the frontend via INI or command-line options.
> 
>   There will be more changes along these lines as we prepare for the future
>   transition to a fully network-capable renderer. The POV-Team will attempt
>   to ease the change to the new system by doing things such as the assumed_gamma
>   interpretation above, where it is possible to do so.

-----------

>   gamma changes, revert to beta.10 behaviour with some tweaks for more 
>   extensive version checking.
>   
>   In particular, specifying -MV3.7 or later via an INI file or the 
>   command-line is taken at higher precedence than a #version 3.6 (or 
>   lower) in the scene file when it comes to assigning the default state of 
>   gamma correction (on/off, not its actual value if on). the value used 
>   when it is on is determined by either Display_Gamma (if given) or 
>   DEFAULT_DISPLAY_GAMMA otherwise. Similar steps are taken for the new 
>   File_Gamma option.
>   
>   The actual value of assumed_gamma is not passed on; this prevents its 
>   use for anything other than turning gamma on or off (which is what the 
>   majority of scenes did with it). Those scenes that (mis)used 
>   assumed_gamma to adjust the scene appearance outside of the needs of the 
>   user's actual display gamma will need to either be altered to suit, or 
>   to be run with an adjusted Display_Gamma and File_Gamma.
>   
>   NB users are warned that assumed_gamma support will be removed entirely 
>   in a later 3.7 revision.

Post a reply to this message

"Chris Cason" <del### [at] deletethistoopovrayorg> wrote in 
message news:4891a171@news.povray.org...
> Jim Holsenback wrote:
>> It seems the biggest issue is going to be the assumed_gamma handling 
>> change
>> in v3.7. If I'm understanding correctly if the parser sees the inclusion 
>> of
>> that keyword it basically spits out a warning and handles gamma 
>> correction
>> based on what you have in resolution.ini. Is that correct? So there's no 
>> way
>
> It's a little more complicated than that: best to read the release notes
> regarding that (I'll paste the relevant section in a followup to this 
> message).

thanks .... I'm squared away on that now.

>> I've reread through this thread and it still seems that there is no
>> consensus on image file format and size. Whats the best approach here?
>> Produce a full sized image and just scale for the thumbnails, or two
>> separate runs.
>
> Scaling to thumbnails is fairly easy, so I'd recommend that. For full-size
> images you could render at a width of, say, 768, with the height being
> whatever that scales to with the aspect ratio taken into account.

ok that answers size .... what about format? png?

> One other suggestion: when leaving a #version in the scene file, it might
> be good to add a comment above it that says e.g. "minimum POV-Ray version
> needed to render this scene", or something like that.
>
> thanks,
> -- Chris

I've seen what I think perhaps catches all the cases we are likley to 
encounter that involve gamma correction and they are:
version <= 3.5 with  assumed_gamma = 2.2, 1.8, 1, or 0.8 in 244 of the 365 
scene files, or no version set at all for the rest.
It seems then that the 244 files with some mention of gamma correction have 
the version reference removed, so that by default gamma correction is on. 
the test file I was using sourced a couple of includes that had #version 3.5 
keyword. Does the pov source file inherent the version from a sourced 
include? If so I would be in favor of setting #version = 3.7 in those pov 
files. Maybe we need to up version the includes as well. The remaining files 
that have no mention of assumed_gamma should be set to 3.5 so to have gamma 
correction off.

here's the header of the test file i've been using and a pretty free form of 
what I'm thinking we ought to be doing:

// Persistence Of Vision raytracer version "what ever we decide" sample 
file.
//
// -w320 -h240
// -w800 -h600 +a0.3

#include "stdinc.inc"
#include "arrays.inc"

/* The following has been obsoleted due to the way gamma correction is now 
being handled.
Please refer to the release notes for additional information. Any version 
references should
be considered as a minimum requirement to render this scene. */

//#version 3.5;

global_settings {
 //assumed_gamma 1
}

Cheers
Jim

Post a reply to this message

"StephenS" <nomail@nomail> wrote in message 
news:web.488b08c815676239270b39b0@news.povray.org...
> "Jim Holsenback" <jho### [at] hotmailcom> wrote:
> ....
>>if there are
>> no objections i'll use the manifest list to evenly divide up those scenes
>> into managable chunks...
> Good idea. Use more chunks than people so new people can easly join, or 
> another
> chunk can be taken if one is easy(or time permits).

i think we are getting close to starting to work, however there are some 
pending issues to be nailed down yet.
here's a proposed breakdown:

advanced/animations (71)
camera/incdemo (74)
interior/language/lights/objectmods/qtvr/radiosity (69)
objects/portfolio (78)
textures (73)

Jim

Post a reply to this message

Jim Holsenback wrote:
> ok that answers size .... what about format? png?

Yes, I think so: it's lossless and easy to convert from that to another
format if it's needed.

> the version reference removed, so that by default gamma correction is on

> Does the pov source file inherent the version from a sourced 
> include? 

I think you'll find that the includes set it back to the old value at the
end (please check to make sure).

> Maybe we need to up version the includes as well.

There's probably no harm in doing so, and might even be a good idea overall.

> /* The following has been obsoleted due to the way gamma correction is now 
> being handled.
> Please refer to the release notes for additional information. Any version 
> references should
> be considered as a minimum requirement to render this scene. */
> 
> //#version 3.5;
> 
> global_settings {
>  //assumed_gamma 1
> }

In the above example I'd rather have the assumed_gamma removed, along with
the #version; thus the comment isn't necessary.

OTOH if there is no #version at all, and the scene doesn't render "right"
(i.e. gamma turns out wrong) when rendered in version 3.6 due to the
removal of the assumed_gamma, then we probably ought to place a #version
3.7 in the scene.

if you wanted to get fancy, you could leave the #version out and put a #if
around the assumed_gamma statement, where you check the version and only
apply the assumed_gamma for version 3.6 and earlier.

regards,

-- Chris

Post a reply to this message

Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> Jim Holsenback wrote:
....
> > /* The following has been obsoleted due to the way gamma correction is now
> > being handled.
> > Please refer to the release notes for additional information. Any version
> > references should
> > be considered as a minimum requirement to render this scene. */
> >
> > //#version 3.5;
> >
> > global_settings {
> >  //assumed_gamma 1
> > }
>
> In the above example I'd rather have the assumed_gamma removed, along with
> the #version; thus the comment isn't necessary.
....
If we go this route, then I would also use:
// Persistence Of Vision raytracer sample file.
in the top comments, with no mention of version.

Stephen S

Post a reply to this message

"StephenS" <nomail@nomail> wrote in message 
news:web.48948ff5156762395d26830d0@news.povray.org...
> Chris Cason <del### [at] deletethistoopovrayorg> wrote:
>> Jim Holsenback wrote:
> ....
>> > /* The following has been obsoleted due to the way gamma correction is 
>> > now
>> > being handled.
>> > Please refer to the release notes for additional information. Any 
>> > version
>> > references should
>> > be considered as a minimum requirement to render this scene. */
>> >
>> > //#version 3.5;
>> >
>> > global_settings {
>> >  //assumed_gamma 1
>> > }
>>
>> In the above example I'd rather have the assumed_gamma removed, along 
>> with
>> the #version; thus the comment isn't necessary.
> ....
> If we go this route, then I would also use:
> // Persistence Of Vision raytracer sample file.
> in the top comments, with no mention of version.
>
> Stephen S

good eye .... i noticed this but forgot to mention. In other words agreed!!

Jim

Post a reply to this message

"Chris Cason" <del### [at] deletethistoopovrayorg> wrote in 
message news:48948066@news.povray.org...
>> Does the pov source file inherent the version from a sourced
>> include?
>
> I think you'll find that the includes set it back to the old value at the
> end (please check to make sure).

ok ... i'll look to make sure.

>> Maybe we need to up version the includes as well.
>
> There's probably no harm in doing so, and might even be a good idea 
> overall.

good ... i'll have a look and see what's involved before I pull the trigger 
and do it.

>> /* The following has been obsoleted due to the way gamma correction is 
>> now
>> being handled.
>> Please refer to the release notes for additional information. Any version
>> references should
>> be considered as a minimum requirement to render this scene. */
>>
>> //#version 3.5;
>>
>> global_settings {
>>  //assumed_gamma 1
>> }
>
> In the above example I'd rather have the assumed_gamma removed, along with
> the #version; thus the comment isn't necessary.

i threw that in just to see if i could get any outside ideas .....

> OTOH if there is no #version at all, and the scene doesn't render "right"
> (i.e. gamma turns out wrong) when rendered in version 3.6 due to the
> removal of the assumed_gamma, then we probably ought to place a #version
> 3.7 in the scene.

another overlooked possibility ..... thanks!

> if you wanted to get fancy, you could leave the #version out and put a #if
> around the assumed_gamma statement, where you check the version and only
> apply the assumed_gamma for version 3.6 and earlier.

this is way more elegant and easy enough to do.

Cheers

Post a reply to this message