Torsten Crass wrote:
>> That is more likely a difference in the way the function image type 
>> works.  Since your heightfield is realtively low resulution such a 
>> difference shows up more strongly than usual.  
> 
> 
> I see. Still funny it's not mentioned in the "changes from 3.5 -> 3.6" 
> list since it apparently isn't a mere bug fix or speed improvement.
> 

I don't remember the details but it probably is a change to make the way 
function images work more consistent.  I would not call it a bugfix 
although IIRC there have been complaints that function images don't work 
as expected in the past.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 01 May. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message

In article <cb9jqa$6gk$1@chho.imagico.de> , Christoph Hormann 
<chr### [at] gmxde>  wrote:

> Torsten Crass wrote:
>>> That is more likely a difference in the way the function image type
>>> works.  Since your heightfield is realtively low resulution such a
>>> difference shows up more strongly than usual.
>>
>>
>> I see. Still funny it's not mentioned in the "changes from 3.5 -> 3.6"
>> list since it apparently isn't a mere bug fix or speed improvement.
>>
>
> I don't remember the details but it probably is a change to make the way
> function images work more consistent.  I would not call it a bugfix
> although IIRC there have been complaints that function images don't work
> as expected in the past.

No, you are wrong here:  We fixed a long-existing bug in height-field
smoothing that is mentioned in the release notes (iirc).  In short,
height-field smoothing did not work correctly before and thus now is looks
"different" compared to older versions of POV-Ray because those versions
were simply buggy.

    Thorsten

____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich wrote:
> 
> No, you are wrong here:  We fixed a long-existing bug in height-field
> smoothing that is mentioned in the release notes (iirc).  In short,
> height-field smoothing did not work correctly before and thus now is looks
> "different" compared to older versions of POV-Ray because those versions
> were simply buggy.

That does not sound reasonable to me, the smoothing change would only 
influence the normal vector returned by trace(), not the intersection 
point.  The difference Thorsten Crass observed is in the intersection 
points and not only in the normals.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 01 May. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message

In article <cbchvs$lmo$1@chho.imagico.de>, chr### [at] gmxde says...
> Thorsten Froehlich wrote:
> > 
> > No, you are wrong here:  We fixed a long-existing bug in height-field
> > smoothing that is mentioned in the release notes (iirc).  In short,
> > height-field smoothing did not work correctly before and thus now is looks
> > "different" compared to older versions of POV-Ray because those versions
> > were simply buggy.
> 
> That does not sound reasonable to me, the smoothing change would only 
> influence the normal vector returned by trace(), not the intersection 
> point.  The difference Thorsten Crass observed is in the intersection 
> points and not only in the normals.
> 
> Christoph
> 
> 

I thought that there was a glitch which sometimes caused gaps in the 
surface of some objects when smoothed. If height fields employed the same 
algorithm to calculate its intersection points, then it would in effect 
generate an incorrect object. Therefor it effects both normals 'and' 
intersections. I could be wrong about that though. It isn't just normals 
that get adjusted with smoothing, I thought.

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message

In article <cbchvs$lmo$1@chho.imagico.de> , Christoph Hormann 
<chr### [at] gmxde>  wrote:

>> No, you are wrong here:  We fixed a long-existing bug in height-field
>> smoothing that is mentioned in the release notes (iirc).  In short,
>> height-field smoothing did not work correctly before and thus now is looks
>> "different" compared to older versions of POV-Ray because those versions
>> were simply buggy.
>
> That does not sound reasonable to me, the smoothing change would only
> influence the normal vector returned by trace(), not the intersection
> point.  The difference Thorsten Crass observed is in the intersection
> points and not only in the normals.

I do not know for sure.  A certain variance is to be expected.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich wrote:
>>
>>That does not sound reasonable to me, the smoothing change would only
>>influence the normal vector returned by trace(), not the intersection
>>point.  The difference Thorsten Crass observed is in the intersection
>>points and not only in the normals.
> 
> 
> I do not know for sure.  A certain variance is to be expected.

I checked and there is a difference in parstxtr.cpp, 
Make_Pattern_Image(), didn't bother to look in which change it was 
introduced.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 01 May. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message

In article <cbe1k0$2cq$1@chho.imagico.de> , Christoph Hormann 
<chr### [at] gmxde>  wrote:

> I checked and there is a difference in parstxtr.cpp,

What difference?

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

On Thu, 24 Jun 2004 15:38:23 +0200, "Thorsten Froehlich" <tho### [at] trfde>
wrote:
> > I checked and there is a difference in parstxtr.cpp,
>
> What difference?

IIRC, previously pattern was wrongly mapped on grid.
There was discusson somewhere most probably in *.programming group.

ABX

Post a reply to this message

Thorsten Froehlich wrote:
> 
>>I checked and there is a difference in parstxtr.cpp,
> 
> 
> What difference?
> 

Leaking the first parts of the 3.6 source into public... ;-)

3.6-release/source/parstxtr.cpp, line 140:


	Image->iwidth  = Image->width;
	Image->iheight = Image->height;
	Image->Colour_Map_Size = 0;
	Image->Colour_Map = NULL;

3.5-release/source/parstxtr.cpp, line 135:

	Image->iwidth  = Image->width;
	Image->iheight = Image->height;
	Image->width--;
	Image->height--;
	Image->Colour_Map_Size = 0;
	Image->Colour_Map = NULL;


Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 01 May. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message

In article <cbeoar$5qj$1@chho.imagico.de> , Christoph Hormann 
<chr### [at] gmxde>  wrote:

> Leaking the first parts of the 3.6 source into public... ;-)
>
> 3.6-release/source/parstxtr.cpp, line 140:

In article <nimld0heoied5mnbj3ge1eblb3j6a766pj@4ax.com> , ABX
<abx### [at] abxartpl>  wrote:
> IIRC, previously pattern was wrongly mapped on grid.
> There was discussion somewhere most probably in *.programming group.

Ah, yes, that is a bugfix for the incorrect mapping of one pixel.  There is
a subtraction later on doing the right thing already.  Still, I think the
result is that especially for a small image or when sampling a very noisy
image the samples will be radically different because they the width of the
sample is one off compared to 3.5 (3.6 is correct now, in 3.5 the sampling
was incorrect).

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message