 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] deletethistoo povrayorg> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Chris Cason" <del### [at] deletethistoopovrayorg> wrote in
message news:48a7e19a@news.povray.org...
> 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
I'm all done .... source, ini and png files have been uploaded to ftp site.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Holsenback wrote:
> "Chris Cason" <del### [at] deletethistoopovrayorg> wrote in
> message news:48a7e19a@news.povray.org...
>> 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
>
> I'm all done .... source, ini and png files have been uploaded to ftp site.
>
> Jim
>
>
This weekend has turned awful, and extended till midweek. I've got the
edits, just need to find time to upload them.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Holsenback wrote:
> 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.
Jim,
About the change of glass textures to materials: we need some provision for
backward compatibility, otherwise lots of old scenes will be busted
(includes some in the distro; e.g. woodbox.pov).
Suggestions?
-- Chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Chris Cason" <del### [at] deletethistoopovrayorg> wrote in
message news:48d60e3d@news.povray.org...
> Jim Holsenback wrote:
>> 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.
>
> Jim,
>
> About the change of glass textures to materials: we need some provision
> for
> backward compatibility, otherwise lots of old scenes will be busted
> (includes some in the distro; e.g. woodbox.pov).
>
> Suggestions?
>
> -- Chris
I did change ALL distro scenes that called any glass textures the old way.
Are you talking about a personal scene that someone created with application
version less than 3.7? I thought that the error that the parser would throw
would eventually lead them to the glass.inc file where a notation was made
about the change was enough to ween everyone off the old way. If that's not
the case, how about something like we did with the assumed_gamma handling in
the globals block? Personally anytime I called glass.inc definitions I found
the parser warning annoying and copied the definition (with appropriate
I_Glass) into my scene and didn't bother even sourcing the glass.inc file at
all. As I was looking at distro scenes that had glass.inc some of the
authors had already done that. At any rate if you feel the needs a closer
look I'll do that. At first glance I'm thinking something like:
if (version < 3.7)
make them textures
issue I_Glass warning
else
make them materials
end
but haven't explored the gotcha's of this yet.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Holsenback wrote:
> I did change ALL distro scenes that called any glass textures the old way.
I think you missed woodbox.pov then:] (either that or I didn't update
it for some reason).
> Are you talking about a personal scene that someone created with application
> version less than 3.7? I thought that the error that the parser would throw
Basically any pre-existing scene. With upgrades to POV-Ray we've
always had a policy of not breaking pre-existing scenes except where
absolutely necessary. So we ought to provide backwards compatibility.
Technically there's probably no reason why both schemes can't live
alongside each other.
> if (version < 3.7)
> make them textures
> issue I_Glass warning
> else
> make them materials
> end
While I'd like to see a warning issued, the problem would be that
anyone with a pre-3.7 scene loading the include file (even if they
don't use the glass textures) would get the warning ... I expect some
scenes out there do include files that they don't use, and would thus
get this warning. Also, anyone running an old scene without a #version
set would get a parse failure on the missing textures.
I think we need to provide both for the meantime. Perhaps we also then
need something like the 'deprecated' warning that is available in
compilers; we can declare something deprecated (via SDL) and if it is
used in a scene the parser spits out a warning.
-- Chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Cason wrote:
> While I'd like to see a warning issued, the problem would be that
> anyone with a pre-3.7 scene loading the include file (even if they
> don't use the glass textures) would get the warning ...
Doesn't that already happen if you include glass.inc in 3.6? I get a warning
even if the scene doesn't use the old glass textures.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez wrote:
> Doesn't that already happen if you include glass.inc in 3.6? I get a warning
> even if the scene doesn't use the old glass textures.
Yes, and it's one of the things we are fixing in the updated files.
-- Chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Chris Cason" <del### [at] deletethistoopovrayorg> wrote in
message news:48d700f7@news.povray.org...
> Jim Holsenback wrote:
>> I did change ALL distro scenes that called any glass textures the old
>> way.
>
> I think you missed woodbox.pov then:] (either that or I didn't update
> it for some reason).
I still have modified scenes on my system and it (woodbox.pov) looks like
it's been done on my end. I connected to the ftp site and in
jim/scenes/advanced woodbox.pov has been changed as well.
> While I'd like to see a warning issued, the problem would be that
> anyone with a pre-3.7 scene loading the include file (even if they
> don't use the glass textures) would get the warning ... I expect some
> scenes out there do include files that they don't use, and would thus
> get this warning. Also, anyone running an old scene without a #version
> set would get a parse failure on the missing textures.
>
> I think we need to provide both for the meantime. Perhaps we also then
> need something like the 'deprecated' warning that is available in
> compilers; we can declare something deprecated (via SDL) and if it is
> used in a scene the parser spits out a warning.
>
> -- Chris
Perhaps I jumped the gun abit. Things were flying pretty fast and when I
floated the idea of addressing this issue it didn't seem that anyone had any
strong feelings one way or another, so I pulled the trigger. If I could have
a few days to think about how to address this to everyones satisfaction I'd
like to take ownership of putting this issue to rest. In the meantime if
there are anymore specific considerations I should be aware of ..... let 'em
fly!
Cheers
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Chris Cason" <del### [at] deletethistoopovrayorg> wrote in
message news:48d700f7@news.povray.org...
> I think you missed woodbox.pov then:] (either that or I didn't update
> it for some reason).
another thought .... woodbox.pov will still issue the I_Glass warning if the
modified glass.inc and glass_old.inc files are not in place. Those file are
on the ftp site in the jim/include directory.
Ciao
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Holsenback wrote:
> I still have modified scenes on my system and it (woodbox.pov) looks like
> it's been done on my end. I connected to the ftp site and in
> jim/scenes/advanced woodbox.pov has been changed as well.
You are correct; it appears the updated installer I made had the old
file in it for some reason. Apologies for getting it wrong.
> Perhaps I jumped the gun abit. Things were flying pretty fast and when I
> floated the idea of addressing this issue it didn't seem that anyone had any
> strong feelings one way or another, so I pulled the trigger. If I could have
> a few days to think about how to address this to everyones satisfaction I'd
Sure, feel free to think it over. I think we need to move forward on
stuff like this without the fear of being bound to the past, while at
the same time keeping in mind that one of the impediments to upgrading
any software is if a user's old files don't work (properly). Hence we
need to balance things and provide backwards compatibility where possible.
If (as it appears to be the case) the SDL as it stands doesn't provide
a clean way of deprecating existing constructs while still permitting
their use, then we need to enhance the SDL. I'm inclined to add such a
means. For example:
#declare I_Glass4=
deprecated once "... some message goes here ..."
interior {
ior 1.5
fade_distance 2.0
fade_power 1001
}
if we did it this way, for example, the #declared item is known by the
parser to be deprecated: this generates no warning during the parse of
the #declare itself (or even if the #declare is used in another
#declare), but if it is used in an actual object, the message
associated with it is displayed (if the 'once' keyword is present,
it's only displayed once per parse, otherwise it's displayed each time
it's used in an object).
I'm not saying it has to be done this way; it's just one thing that
comes to mind. It would require the parser to track the deprecated
status of each #declared item (passing up the state if a new declare
inherits a deprecated declare, and so forth), which isn't as clean as
I'd like it to be. The other option is to display the warning anytime
the declare is used (even if in another declare, which means we have
to ensure we don't use such declares as part of something else in the
same standard include file as this would trigger the warning even if
the end-user didn't use the #declared item).
-- Chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Cason wrote:
> It would require the parser to track the deprecated
> status of each #declared item (passing up the state if a new declare
> inherits a deprecated declare, and so forth), which isn't as clean as
> I'd like it to be.
If the SDL could be changed to allow calling parameterless macros
without parantheses, it might be possible to do something like
#declare I_Glass4_Deprecated =
interior {
ior 1.5
fade_distance 2.0
fade_power 1001
}
#macro I_Glass4()
#warning "I_Glass4 is deprecated"
I_Glass4_Deprecated
#end
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Chris Cason" <del### [at] deletethistoopovrayorg> wrote in
message news:48d874f9$1@news.povray.org...
> I think we need to move forward on
> stuff like this without the fear of being bound to the past, while at
> the same time keeping in mind that one of the impediments to upgrading
> any software is if a user's old files don't work (properly). Hence we
> need to balance things and provide backwards compatibility where possible.
cool .... we're on the same page then.
> If (as it appears to be the case) the SDL as it stands doesn't provide
> a clean way of deprecating existing constructs while still permitting
> their use, then we need to enhance the SDL. I'm inclined to add such a
> means. For example:
>
> #declare I_Glass4=
> deprecated once "... some message goes here ..."
> interior {
> ior 1.5
> fade_distance 2.0
> fade_power 1001
> }
> if we did it this way, for example, the #declared item is known by the
> parser to be deprecated: this generates no warning during the parse of
> the #declare itself (or even if the #declare is used in another
> #declare), but if it is used in an actual object, the message
> associated with it is displayed (if the 'once' keyword is present,
> it's only displayed once per parse, otherwise it's displayed each time
> it's used in an object).
How big of a deal to do this? Giving the parser the means to do this could
be useful for furture change issues as well right? This issue (I_Glass)
isn't the first time and I'm sure it wouldn't be the last, so I kind of like
this idea at first glance.
> I'm not saying it has to be done this way; it's just one thing that
> comes to mind. It would require the parser to track the deprecated
> status of each #declared item (passing up the state if a new declare
> inherits a deprecated declare, and so forth), which isn't as clean as
> I'd like it to be. The other option is to display the warning anytime
> the declare is used (even if in another declare, which means we have
> to ensure we don't use such declares as part of something else in the
> same standard include file as this would trigger the warning even if
> the end-user didn't use the #declared item).
>
> -- Chris
I've pseudo coded an idea but haven't had the time to see if it might lead
anywhere. Basically the idea would use a function to return the state of a
toggle so we could conditionally provide a warning, but your suggestion has
me thinking that my idea is more of a patch than a solution.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Holsenback wrote:
> How big of a deal to do this? Giving the parser the means to do this could
> be useful for furture change issues as well right? This issue (I_Glass)
> isn't the first time and I'm sure it wouldn't be the last, so I kind of like
> this idea at first glance.
Yes, it would be: this is the primary reason why I'm considering it.
I've prototyped this in the parser and it seems to be working OK so
most likely I'll include it in the next beta. I'll get an early copy
to you so you can add support for the keyword in the include files if
you like.
-- Chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Jim Holsenback" <jho### [at] hotmailcom> wrote in message
news:48a98a0d@news.povray.org...
>> Stephen & Sabrina: I'm done with all my edits and have rendered all the
>> files in the textures directory.
you guys have been silent for awhile ..... any status update?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Chris Cason" <del### [at] deletethistoopovrayorg> wrote in
message news:48db069d$1@news.povray.org...
> Jim Holsenback wrote:
>> How big of a deal to do this? Giving the parser the means to do this
>> could
>> be useful for furture change issues as well right? This issue (I_Glass)
>> isn't the first time and I'm sure it wouldn't be the last, so I kind of
>> like
>> this idea at first glance.
>
> Yes, it would be: this is the primary reason why I'm considering it.
> I've prototyped this in the parser and it seems to be working OK so
> most likely I'll include it in the next beta. I'll get an early copy
> to you so you can add support for the keyword in the include files if
> you like.
>
> -- Chris
thanks that would be great!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Holsenback wrote:
> thanks that would be great!
Ok, it's in the FTP dir (pvengine.zip). Note that this has some other
changes related to paths: you may need to copy your standard scenes,
include, ini, and insert menu files to 'My Documents\POV-Ray\v3.7'.
Syntax is as follows:
#declare deprecated Col_Glass_Old=color rgbf <0.8, 0.9, 0.85, 0.85>;
#declare deprecated once Col_Glass_Old=... etc
#declare deprecated "Some message" Col_Glass_Old=... etc
A deprecated identifier generates no message at the time it is declared: a
warning is only issued if it is used.
If the optional 'once' keyword is present it must immediately follow the
'deprecated' keyword and indicates that the warning should only be
displayed once per parse.
If the optional message string is present, it will be used as the warning
to be displayed if the identifier is used. Otherwise, a message of the form
"Identifier 'Col_Glass_Old' was declared deprecated." is used.
An identifier is considered 'used' if it is referenced anywhere (even if in
another #declare).
-- Chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Holsenback wrote:
> you guys have been silent for awhile ..... any status update?
NB I have files from all three of you now: I think the set is basically
complete.
thanks for the help folks!
-- Chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Chris Cason" <del### [at] deletethistoopovrayorg> wrote in
message news:48db9305@news.povray.org...
> Ok, it's in the FTP dir (pvengine.zip). Note that this has some other
> changes related to paths: you may need to copy your standard scenes,
> include, ini, and insert menu files to 'My Documents\POV-Ray\v3.7'.
Thanks Chris! I'm all set .... still have my old notes so I know what files
need to be looked at (14 scene files and 1 include). Barring diversions on
my end I should be able to wrap this up before the end of this weekend.
Cheers
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Chris Cason" <del### [at] deletethistoopovrayorg> wrote in
message news:48db9305@news.povray.org...
> Ok, it's in the FTP dir (pvengine.zip). Note that this has some other
> changes related to paths: you may need to copy your standard scenes,
> include, ini, and insert menu files to 'My Documents\POV-Ray\v3.7'.
I've uploaded the files to the FTP dir (glass/include & glass/scenes) not
all the scene files needed additional changes.
Basically I deprecated the textures in glass_old.inc and added appropriate
comments to the file header.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Holsenback wrote:
> I've uploaded the files to the FTP dir (glass/include & glass/scenes) not
> all the scene files needed additional changes.
> Basically I deprecated the textures in glass_old.inc and added appropriate
> comments to the file header.
thanks for that, looks good.
-- Chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
