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