Ok,

I made an example file from scratch and post it in the group
you wanted. There is also 2 picture in the images groups.

Fabian.


> 
> Fabian,
> 
> I have been unable to verify this bug report in my tests.  Nothing has been
> specifically changed about the height-field transformation or texturing code
> (any bug that affects height-fields in this way should affect other objects
> as well).  Please post an entire scene (including necessary image files for
> the height-field and textures) demonstrating the bug in the
> binaries.scene-files group.  Thanks.
> 
> I tested using crater.pov (a demo that is part of the official
> distribution).
> 
> -Nathan
> 
> Fabian BRAU <Fab### [at] umhacbe> wrote...
> > Hello Nathan,
> >
> > First, congratulation for your global optimization: a scene which needs
> > 4 min 45 sec to render (it was mainly heightfield with material_map)
> > needs 3 min to render now!
> > But there is a problem. This is not a bug because I know how get
> > megapov0.5 work correctly. The code is below.
> >
> > There is a difference between Megapov0.4 and Megapov0.5:
> >
> > With Megapov0.4 once you have given the texture to the heightfield,
> > if you scale the heightfiled, you dont need to modify the texture,
> > the appearance of the heightfield and its texture is scale (
> > for uniform one) independant.
> >
> > With Megapov0.5, if you scale your heightfield (after give the texture)
> > by scale <x,y,z> and suppose, in general, that your texture have
> > already a scaling like scale <a,b,c>, to have the same result than
> > with megapov0.4 you need to scale your texture by scale <a/x,b/y,c/z>.
> > This is true for translation (and certainly with rotation).
> >

Post a reply to this message