Ok

But I will send it to you directly not in a public NG ;), this is 
a part of a big project so...

But I am sure that this appear with material_map. Perhaps not with other
kind of texture.

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

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

Fabian BRAU <Fab### [at] umhacbe> wrote...
> 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 rendered your scene with MegaPov 0.4, MegaPov 0.5, and Official POV-Ray
3.1g.  Interestingly, MegaPov 0.4 was the one that was different.
Therefore, the most probable explanation is that MegaPov 0.4 was incorrect
and that someone (either myself or someone else) fixed a bug and forgot
about it.  Does anyone remember any discussion about this?

Again, MegaPov 0.5 produces the same results as the official version for me
when running your test scene.

-Nathan

Post a reply to this message

Even more interestingly:

When I _run_ MP0.5 but _set_

  #version unofficial MegaPov 0.4;

in the scene file I really get the same result
as with 0.4 (i.e. the result differing from 0.5
and from official 3.1).

So I guess it was not just forgetting about a bug fix.
Actually, I found the 0.4 behaviour quite reasonable
'cause it saves a lot of work when rescaling objects.
Still, a way to be backwards compatible would be
nice since otherways many textures in old scenes
have to be rescaled manually.

-Hans-

Nathan Kopp wrote:
> 
> Fabian BRAU <Fab### [at] umhacbe> wrote...
> > 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 rendered your scene with MegaPov 0.4, MegaPov 0.5, and Official POV-Ray
> 3.1g.  Interestingly, MegaPov 0.4 was the one that was different.
> Therefore, the most probable explanation is that MegaPov 0.4 was incorrect
> and that someone (either myself or someone else) fixed a bug and forgot
> about it.  Does anyone remember any discussion about this?
> 
> Again, MegaPov 0.5 produces the same results as the official version for me
> when running your test scene.
> 
> -Nathan

Post a reply to this message

> I rendered your scene with MegaPov 0.4, MegaPov 0.5, and Official POV-Ray
> 3.1g.  Interestingly, MegaPov 0.4 was the one that was different.
> Therefore, the most probable explanation is that MegaPov 0.4 was incorrect
> and that someone (either myself or someone else) fixed a bug and forgot
> about it.  Does anyone remember any discussion about this?

No Megapov0.4 IS the correct one. I think a simple argument to prove 
it is that any scene must be scale independant (uniforme one of course). 
This is why normal was already modified. I think it would nice to keep
the
feature of megapov0.4 but one can keep backward compatibility with
#version.

What do you think about it?

Fabian.

Post a reply to this message

If I have:

sphere
{ 0,1
  texture { whatever }
  scale 2
}

the texture is scaled by 2 as well as the object itself.

  If I have:

heigh_field
{ whatever
  texture { whatever }
  scale 2
}

I expect no different behaviour here. The texture should be scaled by 2 as
well as the primitive in question (in this case a heighfield, but it
shouldn't matter which).
  Does it work in a different way?-o

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

In article <3925049C.1C146F91@umh.ac.be>, Fabian BRAU 
<Fab### [at] umhacbe> wrote:

> No Megapov0.4 IS the correct one. I think a simple argument to prove 
> it is that any scene must be scale independant (uniforme one of 
> course). This is why normal was already modified. I think it would 
> nice to keep the feature of megapov0.4 but one can keep backward 
> compatibility with #version.

If the texture is not scaled along with the object, that is a problem. 
Textures are supposed to be transformed along with the object by all 
transformations after the texture...this will scale the object but not 
the texture:
object {
    scale...
    texture {...}
}
while this will scale them both:
object {
    texture {...}
    scale...
}

If MegaPOV 0.4 behaved otherwise, it had a bug.
My guess is the fix slipped through with the transform syntax patch, it 
is the only thing that I know of which affected transforms.

-- 
Christopher James Huff - Personal e-mail: chr### [at] yahoocom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://chrishuff.dhs.org/
TAG Web page: http://tag.povray.org/

Post a reply to this message

Suppose you have a heightfield with a material_map:

This is the feature of official and megapov0.5:

If you scale by scale <x,y,z> the heightfield (after the texture is 
given) so the material_map will still be good on the heightfield 
(you don't need to change anything), the position of each textures on
the hieghtfield will be good, BUT you will need to scale all 
the subtexture by scale <1/x,1/y,1/z>, otherwise it don't look the 
same!

This is the fearute of megapov0.4

If you scale by scale <x,y,z> the heightfield (after the texture is
given) you don't need to perform any modification!

I think the second solution is the good one because:
I have an object, I render it. Now I scale this object by 10,
I move the camera, the light, etc... accordingly, I render,
I must get the same image!
A scene must be always scale independant. I don't know if
other feature in the official pov does not repect this but...
It msut :).

Fabian.



> 
>   If I have:
> 
> sphere
> { 0,1
>   texture { whatever }
>   scale 2
> }
> 
> the texture is scaled by 2 as well as the object itself.
> 
>   If I have:
> 
> heigh_field
> { whatever
>   texture { whatever }
>   scale 2
> }
> 
> I expect no different behaviour here. The texture should be scaled by 2 as
> well as the primitive in question (in this case a heighfield, but it
> shouldn't matter which).
>   Does it work in a different way?-o
> 
> --
> main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
> ):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Fabian BRAU <Fab### [at] umhacbe> wrote:
: I have an object, I render it. Now I scale this object by 10,
: I move the camera, the light, etc... accordingly, I render,
: I must get the same image!

  Yes, I agree.

  If I make this:

object
{ Whatever
  texture { MyTexture }
  scale 10
}

I expect that to work identically no matter what kind of texture is that
'MyTexture'. It should not behave differently depending on whether it's
just a constant colored pigment or a material_map.
  If I scale everything by 10 I expect to get the exact same image.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

height_field
{ whatever
  scale anything
  texture { whatever }
}

This should solve your problem, no?

Post a reply to this message