 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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).
I think this is not good. Suppose you do an object which contain
heightfield,
now you want to use this object in a scene, but you need to scale the
object,
so you will need to rescale all the texture of the heightfield! I think
a scene or an object must be scale (uniform) independant.
I don't know why you change this. If you tell me "this is only for
optimization,
if I use the old code for texture, you will lose all the optimization",
so
I say we can discuss and see if this is good. Otherwise please put the
Megapov0.4 code for the texture of heightfield :).
Thanks for reading me,
I hope the explanation is clear otherwise tell me it, I will explain
again.
Fabian.
THE HEIGHFIELD
---------------
#declare Foo = object {
height_field {
tga "foo.tga"
water_level 0.001
smooth
}
rotate <-90, 0, 0> // Turn onto XY plane. Now points along -Z
scale < 2, 2,-2> // Scale to Cube size. Now points along +Z
translate < -1,-1,-1> // Center around origin
// These transformations are done automatically by Moray, as this
// is done before texturing, I need to transform the texture
// accordingly.
material {
Foo_tex
}
scale <30.0, 40.0, 15.0>
translate <-120.0, 37.5, 14.98>
}
THE TEXTURE
------------
#declare Foo_tex =
material
{
texture
{
material_map
{
gif "rhombmap4_big.gif"
once
texture
{
pigment
{
image_map
{
gif "Dsc01619_public.gif"
}
turbulence 0.15
ramp_wave
scale <1/60,1/80,1/30> //MegaPov0.5 but
// you need also to add translation
// scale 1 //Megapov0.4
}
}
texture
{
pigment
{
image_map
{
gif "Dsc01619_public.gif"
}
scale <1/60,1/80,1/30> //MegaPov0.5 but
// you need also to add translation
// scale 1 //Megapov0.4
}
}
texture
{
pigment
{
color rgb <0.656233, 0.656233, 0.656233>
}
}
texture
{
pigment
{
image_map
{
gif "dirt_miller_fab.gif"
}
scale <3.0/60, 3.0/80, 1.0/30> //MegaPov0.5 but
// you need also to add translation
// scale <3.0,3.0,1.0> //Megapov0.4
}
}
texture
{
pigment
{
image_map
{
gif "grassg.gif"
}
scale <3.0/60, 3.0/80, 1.0/30> //MegaPov0.5 but
// you need also to add translation
// scale <3.0,3.0,1.0> //Megapov0.4
}
}
}
scale <2.0, 2.0, 1.0> // I need to perform these
// transformations because the heightfiled is transform
// by Moray, before giving the texture.
translate <-1.0, -1.0, 0.0>
}
}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Fabian BRAU <Fab### [at] umh acbe> wrote:
: I think this is not good. Suppose you do an object which contain
: heightfield,
: now you want to use this object in a scene, but you need to scale the
: object,
: so you will need to rescale all the texture of the heightfield!
It sounds like a bug.
--
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,
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
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
|
|
| |
| |
|
|
|
|
| |
|
|
