"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