"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

"Chris Cason" <del### [at] deletethistoopovrayorg> wrote in 
message news:48948066@news.povray.org...
> Jim Holsenback wrote:
>> 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).

yes they do that ..... all but two of them

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

with the code frag in the includes this could be considered a moot point. In 
the name of housekeeping this may not be a bad idea to do this anyway. there 
are only 35 include files .... 33 are branded version 3.5 and have the 
switching mechinism, two files (stdcam.inc and stage1.inc) have 3.1 mention 
in header comments and no switching code. easy enough to version them as 3.7 
and housekeeping seems like a good reason to proceed, but won't do that 
unless you (Chris) think I should do this.

Jim

Post a reply to this message

"Jim Holsenback" <jho### [at] hotmailcom> wrote:
....
> 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

If there are no objections I'll start to familiarise myself with the
'camera/incdemo' group.
When we seem to have agreed upon the requested changes, I'll start a new thread
for this group of files, so I can list my progress or problems.

Stephen S

Post a reply to this message

while having a look at the include files i think i may have come up with one 
more housekeeping issue that may be worthy of consideration.

the issue of the I_Glass warning .....

there are 14 scenes that call glass.inc (which calls glass_old.inc). my 
cleanup proposal involves making the textures in glass_old materials which 
would have the required inclusion of interior {I_Glass} and removing the 
I_Glass warning message in glass.inc .... oh and making a comment in 
glass_old header to call materials instead of textures.

I found at least one scene that calls the texture {T_Glass1} which is a 
glass_old texture, so it would appear there would be some changes to scene 
files as well.

comments welcome!

Jim

Post a reply to this message

"StephenS" <nomail@nomail> wrote in message 
news:web.489593a615676239d1f8364e0@news.povray.org...
> If there are no objections I'll start to familiarise myself with the
> 'camera/incdemo' group.
> When we seem to have agreed upon the requested changes, I'll start a new 
> thread
> for this group of files, so I can list my progress or problems.
>
> Stephen S
>
>
i'm cool wid dat

Post a reply to this message

I think we are close to wrapping up the review of v3.7 example scene files 
so I wanted to summarize and get our plan "blessed" before proceeding with 
the actual work.



Division of work: This is how the scenes have been divided up.

advanced/animations (71)
camera/incdemo (74)                (Stephen has already spoken up for this 
group)
interior/language/lights/objectmods/qtvr/radiosity (69)
objects/portfolio (78)
textures (73)



Image size and format: 768 x 576 (4:3 aspect ratio) PNG. Using the file 
advanced/grenadine as a test case I noticed a difference in the preview 
window image (to dark) and the final png image file (to light). This led me 
to believe that I hadn't set display_gamma correctly. After some empirical 
testing this is what I came up with for my quickres.ini file:



[768x576, AA 0.3]

Width=768

Height=576

Antialias=On

Antialias_Threshold=0.3

Display_Gamma=2.3



I'm going to post the image over in the images group. One last thing about 
image quality. The rim of the glass had jagged edges until I used +a0.1 
+r4 ... we DO want to resolve quality issues like that don't we?



Scene file edits: This is how assumed_gamma and source file versioning is 
handled.

This example (below) has an assumed_gamma setting, so in order to leverage 
off the 3.7 default behavior the #version 3.5 directive has been 
conditionally excluded, as well as the assumed_gamma setting in the global 
settings block. Additionally any mention of version in header comments have 
been deleted , and a date stamp with initials was added. Example files that 
don't have assumed_gamma in global settings block should be (if not already) 
branded #version 3.5 as the default behavior is gamma correction off.



---begin scene file frag

// Persistence of Vision Ray Tracer Scene Description File

// File: grenadine.pov

// Desc: Glass with liquid

// Date: 1999/06/04

// Auth: Ingo Janssen

//

// -w320 -h240

// -w800 -h600 +a0.3



// Updated: 04Aug2008(jh) for v3.7 distribution



#if (version < 3.6)

  #version 3.5

#end



#include "glass.inc"

#include "lemon.inc"



global_settings {

   // conditionally comply with gamma correction handling

   #if (version < 3.6)

        assumed_gamma 1.0

   #end

   max_trace_level 5

   photons {

      spacing 0.01  // higher value 'lower' quality, faster parsing.

      autostop 0

      jitter 0.5

      max_trace_level 15

  }

}

--- end scene file frag



Notice from the scene frag above that it calls and include "lemon.inc" which 
is an include in scenes/advanced. It had the #version directive in the body 
of that include. I used the following common version preservation method 
used in the application includes.



--- begin code frag

// Added to comply with common version preservation scheme

// 04Aug2008 (jh)

#ifndef(Lemon_Inc_Temp)

#declare Lemon_Inc_Temp=version;

#version 3.5;



#ifdef(View_POV_Include_Stack)

    #debug "including lemon.inc\n"

#end



// code body goes here



// Added to comply with common version preservation scheme

// 04Aug2008 (jh)

#version Lemon_Inc_Temp;

#end

--- end code frag



Include files review:

The include files have been reviewed and  since they have a scheme that 
keeps the calling source file from inheriting it's #version branding it's 
been suggested that this is a moot point to change the #version branding for 
now. In other words it's purely a housekeeping issue for now. Since we're on 
the topic of includes, I've heard no reply on my proposal to change the 
textures in glass_old.inc to materials, and remove the I_Glass warning in 
glass.inc. The above scene file frag calls glass.inc so a minor mod to the 
scene file was in order. The scene file rendered fine. I don't want to do 
this because silence implies agreement. Someone yea or nay this change 
please!



Have I forgotten anything?



Jim

Post a reply to this message

Jim Holsenback wrote:
> advanced/grenadine as a test case I noticed a difference in the preview 
> window image (to dark) and the final png image file (to light). This led me 

Please be aware that the PNG output images have the inverse gamma
written into the file header and will appear differently between
viewers that do and don't support using this value.

> I'm going to post the image over in the images group. One last thing about 
> image quality. The rim of the glass had jagged edges until I used +a0.1 
> +r4 ... we DO want to resolve quality issues like that don't we?

I suspect so, if it doesn't involve too much work.

> #if (version < 3.6)

Should that be < 3.6 or < 3.7 ?

> the topic of includes, I've heard no reply on my proposal to change the 
> textures in glass_old.inc to materials, and remove the I_Glass warning in 
> glass.inc. The above scene file frag calls glass.inc so a minor mod to the 
> scene file was in order. The scene file rendered fine. I don't want to do 
> this because silence implies agreement. Someone yea or nay this change 
> please!

I haven't read it in detail (during weekdays I don't get a lot of
time) but as long as it doesn't break any existing third-party scenes
I'm OK with the change.

thanks,

-- Chris

Post a reply to this message

"Chris Cason" <del### [at] deletethistoopovrayorg> wrote in 
message news:489a8737$1@news.povray.org...
> Jim Holsenback wrote:
>> advanced/grenadine as a test case I noticed a difference in the preview
>> window image (to dark) and the final png image file (to light). This led 
>> me
>
> Please be aware that the PNG output images have the inverse gamma
> written into the file header and will appear differently between
> viewers that do and don't support using this value.

yes .... i was using GIMP

>> I'm going to post the image over in the images group. One last thing 
>> about
>> image quality. The rim of the glass had jagged edges until I used +a0.1
>> +r4 ... we DO want to resolve quality issues like that don't we?
>
> I suspect so, if it doesn't involve too much work.
>
>> #if (version < 3.6)
>
> Should that be < 3.6 or < 3.7 ?

i defer to you .... i'll reread the doc and see if i can figure out what led 
me to believe that the default behavior for gamma correction has been around 
since 3.6.1

>
>> the topic of includes, I've heard no reply on my proposal to change the
>> textures in glass_old.inc to materials, and remove the I_Glass warning in
>> glass.inc. The above scene file frag calls glass.inc so a minor mod to 
>> the
>> scene file was in order. The scene file rendered fine. I don't want to do
>> this because silence implies agreement. Someone yea or nay this change
>> please!
>
> I haven't read it in detail (during weekdays I don't get a lot of
> time) but as long as it doesn't break any existing third-party scenes
> I'm OK with the change.

these scene files have glass.inc but MAY not call glass_old textures. i'll 
take ownership for making those changes.

./advanced/desk.pov
./advanced/grenadine.pov
./advanced/wineglass.pov
./advanced/woodbox.pov
./advanced/blocks/stackertransp.pov
./advanced/fish13/fish13.pov
./animations/boing/glsbng.pov
./incdemo/glasses/glass.pov
./incdemo/glasses/samp_demo.pov
./interior/ballbox1.pov
./interior/iortest.pov
./interior/magglass.pov
./lights/glassthing.pov
./lights/phot_met_glass.pov

Stephen I owe you two files as you're already working on the incdemo files. 
I'm going to speak up for the advanced/animations group of files. I will 
deal with the remaining files when someone speaks up for the groups that 
they are in. I will also post the revised glass/glass_old.inc files so both 
of you  (Stephen/Sabrina) can pick those up. Zip format OK? Give me a couple 
of days to get this done as I'm juggling several things (feast or famine) 
right now.

Jim

Post a reply to this message

"Jim Holsenback" <jho### [at] hotmailcom> wrote in message 
news:489ac9a9@news.povray.org...
> these scene files have glass.inc but MAY not call glass_old textures. i'll 
> take ownership for making those changes.
>
> ./advanced/desk.pov
> ./advanced/grenadine.pov
> ./advanced/wineglass.pov
> ./advanced/woodbox.pov
> ./advanced/blocks/stackertransp.pov
> ./advanced/fish13/fish13.pov
> ./animations/boing/glsbng.pov
> ./incdemo/glasses/glass.pov
> ./incdemo/glasses/samp_demo.pov
> ./interior/ballbox1.pov
> ./interior/iortest.pov
> ./interior/magglass.pov
> ./lights/glassthing.pov
> ./lights/phot_met_glass.pov

i posted these scene files as well as glass.inc and glass_old.inc are in a 
zip file over in the text.scene-files group

jim

Post a reply to this message

"Jim Holsenback" <jho### [at] hotmailcom> wrote in message 
news:489d58bf$1@news.povray.org...
>
> "Jim Holsenback" <jho### [at] hotmailcom> wrote in message 
> news:489ac9a9@news.povray.org...
>> these scene files have glass.inc but MAY not call glass_old textures. 
>> i'll take ownership for making those changes.
>>
>> ./advanced/desk.pov
>> ./advanced/grenadine.pov
>> ./advanced/wineglass.pov
>> ./advanced/woodbox.pov
>> ./advanced/blocks/stackertransp.pov
>> ./advanced/fish13/fish13.pov
>> ./animations/boing/glsbng.pov
>> ./incdemo/glasses/glass.pov
>> ./incdemo/glasses/samp_demo.pov
>> ./interior/ballbox1.pov
>> ./interior/iortest.pov
>> ./interior/magglass.pov
>> ./lights/glassthing.pov
>> ./lights/phot_met_glass.pov
>
> i posted these scene files as well as glass.inc and glass_old.inc are in a 
> zip file over in the text.scene-files group

i discovered a typo in comments that's been corrected ..... NEW zip file 
posted

Jim

Post a reply to this message

"Jim Holsenback" <jho### [at] hotmailcom> wrote in message 
news:489ac9a9@news.povray.org...
> I'm going to speak up for the advanced/animations group of files.

i'm done with edits of this section, and i've taking a different approach on 
my work flow. i'm going to just do edits for now as the render portion is 
going to be a bottleneck on my machine. most images rendered fairly quickly 
however some took > 1 hr at that rate i ought to finish up sometime before 
next summer ;-)

i'm going to start edits on this group:
interior/language/lights/objectmods/qtvr/radiosity

Jim

Post a reply to this message

Jim Holsenback wrote:
> "Jim Holsenback" <jho### [at] hotmailcom> wrote in message 
> news:489ac9a9@news.povray.org...
>> I'm going to speak up for the advanced/animations group of files.
> 
> i'm done with edits of this section, and i've taking a different approach on 
> my work flow. i'm going to just do edits for now as the render portion is 
> going to be a bottleneck on my machine. most images rendered fairly quickly 
> however some took > 1 hr at that rate i ought to finish up sometime before 
> next summer ;-)
> 
> i'm going to start edits on this group:
> interior/language/lights/objectmods/qtvr/radiosity
> 
> Jim 
> 
> 

I'll jump in and take the objects/portfolio set to render. And I'll see 
about getting/keeping access to an animation lab, and running it there 
as well.

Post a reply to this message

"Jim Holsenback" <jho### [at] hotmailcom> wrote in message 
news:489dcf22@news.povray.org...
> i'm going to start edits on this group:
> interior/language/lights/objectmods/qtvr/radiosity

done with those .... i'll start on textures.

Cheers

Post a reply to this message

Stephen & Sabrina: I'm done with all my edits and have rendered all the 
files in the textures directory.

Chris: do you have some disc space that we can start putting the scene 
source files and images?

Jim

Post a reply to this message

Jim Holsenback wrote:
> Stephen & Sabrina: I'm done with all my edits and have rendered all the 
> files in the textures directory.
> 

I've gotten the objects folder rendered, but the portfolio is taking 
longer as I'm not too talented at scripting, so I am running each pass 
by the GUI and Sel-Run.

The biggest issue I've seen so far is the wood include and 
objects/pawns.pov. The wood textures look completely different without 
the assumed gamma statements, and pawns seems to have some graphical 
issue. I'm thinking it might be coincident surfaces, but I've not looked 
at it too close yet.

Post a reply to this message

"Sabrina Kilian" <"ykgp at vtSPAM.edu"> wrote in message 
news:48a3573c$1@news.povray.org...
> The biggest issue I've seen so far is the wood include and 
> objects/pawns.pov. The wood textures look completely different without the 
> assumed gamma statements, and pawns seems to have some graphical issue. 
> I'm thinking it might be coincident surfaces, but I've not looked at it 
> too close yet.

hmmmm .... the only thing that slowed me down was that some of the images in 
advanced had different aspect ratio's (other than 4:3). The stuff in 
textures went by super fast once I got past my "Doh" moment using the file 
queue feature. The file queue feature was appealling to me because I wanted 
to have the renders go unattended. I inspected the headers and camera 
statements and found nothing unusual so I thought they looked like an ideal 
candidate for batch processing.

I'm wondering if you had a particular file in mind that you were seeing the 
wood.inc problem, or should I just have a look at anything that sources 
wood.inc ..... mind you it's not that I don't believe you, I'm just curious 
and want to have a look. I'm going to slow things down abit until I hear 
back from Chris on disc space.

Jim

Post a reply to this message

"Sabrina Kilian" <"ykgp at vtSPAM.edu"> wrote in message 
news:48a3573c$1@news.povray.org...
> The wood textures look completely different without the assumed gamma 
> statements, and pawns seems to have some graphical issue. I'm thinking it 
> might be coincident surfaces, but I've not looked at it too close yet.

pawns problem is indeed coincident surfaces ..... checkout where the author 
finally builds the chessboard. The calls to the object "Eights" could use a 
bit of +y ..... i used 0.000001 and it looks fine now. BTW: the wood 
textures in this file look ok to me.

Jim

Post a reply to this message

Jim Holsenback wrote:
> "Sabrina Kilian" <"ykgp at vtSPAM.edu"> wrote in message 
> news:48a3573c$1@news.povray.org...
>> The biggest issue I've seen so far is the wood include and 
>> objects/pawns.pov. The wood textures look completely different without the 
>> assumed gamma statements, and pawns seems to have some graphical issue. 
>> I'm thinking it might be coincident surfaces, but I've not looked at it 
>> too close yet.
> 
> hmmmm .... the only thing that slowed me down was that some of the images in 
> advanced had different aspect ratio's (other than 4:3). The stuff in 
> textures went by super fast once I got past my "Doh" moment using the file 
> queue feature. The file queue feature was appealling to me because I wanted 
> to have the renders go unattended. I inspected the headers and camera 
> statements and found nothing unusual so I thought they looked like an ideal 
> candidate for batch processing.
> 
> I'm wondering if you had a particular file in mind that you were seeing the 
> wood.inc problem, or should I just have a look at anything that sources 
> wood.inc ..... mind you it's not that I don't believe you, I'm just curious 
> and want to have a look. I'm going to slow things down abit until I hear 
> back from Chris on disc space.
> 
> Jim 
> 
> 

Yeah, the file queue worked great for objects, I set it to run in both 
3.6 and 3.7, turned on an MMO, and by the time the evening was over they 
were both done. The portfolio requires rendering with an .ini unique to 
each .pov file, and so eats up a bit more time as I'm not comfortable 
with scripting windows to do it for me.

On to wood.inc: In the display window while it's running and rendering, 
the images looked a lot different for the same file. Brighter or darker, 
the colors seemed more saturated. Checking the image after it's been 
saved to disk, I don't see the huge difference any longer.

I looked at t_woods6.png, it looks like it has some minor color 
differences in the dark area, but that could just be me. I'll check it 
in Gimp and difference the two images to see if it's just where I have 
the pictures on the screen.

Post a reply to this message

"Sabrina Kilian" <"ykgp at vtSPAM.edu"> wrote in message 
news:48a4db21$1@news.povray.org...
> On to wood.inc: In the display window while it's running and rendering, 
> the images looked a lot different for the same file. Brighter or darker, 
> the colors seemed more saturated. Checking the image after it's been saved 
> to disk, I don't see the huge difference any longer.

i saw this too and thought that tweeking the Display_Gamma entries in 
quickres.ini would help ...... it did.

Jim

Post a reply to this message

"Jim Holsenback" <jho### [at] hotmailcom> wrote:
> Stephen & Sabrina: I'm done with all my edits and have rendered all the
> files in the textures directory.
>
> Chris: do you have some disc space that we can start putting the scene
> source files and images?
>
> Jim

I've gone thought my first edits with v3.7, some things i've seen:

Two files have warnings, this is just the way the file is constructed, I see no
problem with leaving them as is.
String.pov, warning no objects
Screen.pov, warning more than one camera

Web link, and still working, will it always?
Sundial.pov

Some files are set up to use animations, I_internal.pov, but some need to be
manualy edited to get the full benefit, Transform.pov. I'll leave this for
posible future edits. I prefer the animation setup.

I like the idea of using the comments to add the assumed_gamma settings
// -w768 -h576 +a0.3 display_gamma=1.8
or what ever is needed for the file.

comments welcome.

Stephen S

Post a reply to this message

Jim Holsenback wrote:
> Stephen & Sabrina: I'm done with all my edits and have rendered all the 
> files in the textures directory.
> 
> Chris: do you have some disc space that we can start putting the scene 
> source files and images?

Sorry, only just now catching up with group: yes, I'll set something up.

-- Chris

Post a reply to this message

"Jim Holsenback" <jho### [at] hotmailcom> wrote in message 
news:48a2b9c9@news.povray.org...
> Stephen & Sabrina: I'm done with all my edits and have rendered all the 
> files in the textures directory.

I'm all done with these sections (edits & renders) ....

advanced/animations (71)
interior/language/lights/objectmods/qtvr/radiosity (69)
textures (73)

1. there were less than half dozen files that required differnt aspect ratio 
other than 4:3

2. a couple of files were order dependant (error because it was looking for 
a image file that hadn't been rendered yet)

3. advanced/fish13/fish.inc and stem1.inc had #version 1.0 set. I left 
fih.inc at #version 1.0 (comma's between vector coords?) upgraded stem1.inc 
to #version 3.5 and replaced alpha with filter. left world12.inc alone as it 
had no #version.

4. modified glass.inc and glass_old.inc (textures-> materials)

5. assumed_gamma handling was by far the dominate issue.

Jim

Post a reply to this message

Stephen,

I've set up a FTP account for the scenes but don't have your email
address handy ATM. Please drop me an email and I'll pass on the login
details.

-- Chris

Post a reply to this message

"Jim Holsenback" <jho### [at] hotmailcom> wrote:
....
Sorry for taking so long, I have been struggling a bit, but seem to be going
fine now. This post by Jim has helped.
> [768x576, AA 0.3]
>
> Width=768
>
> Height=576
>
> Antialias=On
>
> Antialias_Threshold=0.3
>
> Display_Gamma=2.3
....
I'm using this in quickres.ini to help:

[768x576, AA 0.3, png]
Width=768
Height=576
Antialias=On
Antialias_Threshold=0.3
Output_File_Type = n

> // Updated: 04Aug2008(jh) for v3.7 distribution
>
>
>
> #if (version < 3.6)
>
>   #version 3.5
>
> #end
>
>
>
> #include "glass.inc"
>
> #include "lemon.inc"
>
>
>
> global_settings {
>
>    // conditionally comply with gamma correction handling
>
>    #if (version < 3.6)
>
>         assumed_gamma 1.0
>
>    #end
>
....
I'm using a version of this in the scene file:

// Updated: Aug2008(sjs) for version and gamma
// -w768 -h576 +a0.3 Output_File_Type=n Display_Gamma=1
#if (version < 3.7)
  #version 3.6;
  global_settings { assumed_gamma 2.2 }
#end

Stephen S

Post a reply to this message