Am 24.01.2015 um 21:02 schrieb Mr:

> This looks almost ok, thank you, but not yet :
> Here is the Blender result
> http://www.pasteall.org/pic/show.php?id=82782
> it uses repeat factor of 0.75
>
> And here is POV
> http://www.pasteall.org/pic/show.php?id=82783
> It uses scale factor of 1/0.75 = 1.33
> and the method you advised for translation
>
> the translate I have to add to get closer to the original is of <-0.175,0,0> but
> this is not constant: with a slightly higher tiling number still under 1 it
> reduces slightly closer to <0,0,0>

Could that be <-0.16666,0,0> rather than <-0.175,0,0>?

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 24.01.2015 um 21:02 schrieb Mr:
>
> > This looks almost ok, thank you, but not yet :
> > Here is the Blender result
> > http://www.pasteall.org/pic/show.php?id=82782
> > it uses repeat factor of 0.75
> >
> > And here is POV
> > http://www.pasteall.org/pic/show.php?id=82783
> > It uses scale factor of 1/0.75 = 1.33
> > and the method you advised for translation
> >
> > the translate I have to add to get closer to the original is of <-0.175,0,0> but
> > this is not constant: with a slightly higher tiling number still under 1 it
> > reduces slightly closer to <0,0,0>
>
> Could that be <-0.16666,0,0> rather than <-0.175,0,0>?

Indeed, this looks perfect for the case. Why this number?

Post a reply to this message

"Mr" <nomail@nomail> wrote:
> clipka <ano### [at] anonymousorg> wrote:
> > Am 24.01.2015 um 21:02 schrieb Mr:
> >
> > > This looks almost ok, thank you, but not yet :
> > > Here is the Blender result
> > > http://www.pasteall.org/pic/show.php?id=82782
> > > it uses repeat factor of 0.75
> > >
> > > And here is POV
> > > http://www.pasteall.org/pic/show.php?id=82783
> > > It uses scale factor of 1/0.75 = 1.33
> > > and the method you advised for translation
> > >
> > > the translate I have to add to get closer to the original is of <-0.175,0,0> but
> > > this is not constant: with a slightly higher tiling number still under 1 it
> > > reduces slightly closer to <0,0,0>
> >
> > Could that be <-0.16666,0,0> rather than <-0.175,0,0>?
>
> Indeed, this looks perfect for the case. Why this number?

Stupid question, it was the same logic applied to the example I guess, because
it works seamlessly, now both uv textures map the same. this is the python
making the translation (z can be scaled and offset as well):

mappingDif = ("scale <%.4g,%.4g,%.4g> translate <%.4g,%.4g,%.4g>" % \
              ( 1.0 / t_dif.scale.x,
              1.0 / t_dif.scale.y,
              1.0 / t_dif.scale.z,
              0.5-(0.5/t_dif.scale.x) + t_dif.offset.x,
              0.5-(0.5/t_dif.scale.y) + t_dif.offset.y,
              0.5-(0.5/t_dif.scale.z) + t_dif.offset.z))

Post a reply to this message

Am 25.01.2015 um 07:58 schrieb Mr:

> it works seamlessly, now both uv textures map the same. this is the python
> making the translation (z can be scaled and offset as well):
>
> mappingDif = ("scale <%.4g,%.4g,%.4g> translate <%.4g,%.4g,%.4g>" % \
>                ( 1.0 / t_dif.scale.x,
>                1.0 / t_dif.scale.y,
>                1.0 / t_dif.scale.z,
>                0.5-(0.5/t_dif.scale.x) + t_dif.offset.x,
>                0.5-(0.5/t_dif.scale.y) + t_dif.offset.y,
>                0.5-(0.5/t_dif.scale.z) + t_dif.offset.z))

Looks good. The offset should be fine, too, provided Blender applies 
offset after scaling; if instead it applies offset before scaling, 
dividing the offset by t_dif.scale.* should do the trick.

Glad I could help :)

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 25.01.2015 um 07:58 schrieb Mr:
>
> > it works seamlessly, now both uv textures map the same. this is the python
> > making the translation (z can be scaled and offset as well):
> >
> > mappingDif = ("scale <%.4g,%.4g,%.4g> translate <%.4g,%.4g,%.4g>" % \
> >                ( 1.0 / t_dif.scale.x,
> >                1.0 / t_dif.scale.y,
> >                1.0 / t_dif.scale.z,
> >                0.5-(0.5/t_dif.scale.x) + t_dif.offset.x,
> >                0.5-(0.5/t_dif.scale.y) + t_dif.offset.y,
> >                0.5-(0.5/t_dif.scale.z) + t_dif.offset.z))
>
> Looks good. The offset should be fine, too, provided Blender applies
> offset after scaling; if instead it applies offset before scaling,
> dividing the offset by t_dif.scale.* should do the trick.
>
> Glad I could help :)

Thanks a lot. Hum... well,  Now the same formula doesn't apply to environment
mapping, there is another discrepency, I'm trying to get rid of:

Blender:
http://www.pasteall.org/pic/show.php?id=82796
POV:
http://www.pasteall.org/pic/show.php?id=82797

Post a reply to this message

"Mr" <nomail@nomail> wrote:
> clipka <ano### [at] anonymousorg> wrote:
> > Am 25.01.2015 um 07:58 schrieb Mr:
> >
> > > it works seamlessly, now both uv textures map the same. this is the python
> > > making the translation (z can be scaled and offset as well):
> > >
> > > mappingDif = ("scale <%.4g,%.4g,%.4g> translate <%.4g,%.4g,%.4g>" % \
> > >                ( 1.0 / t_dif.scale.x,
> > >                1.0 / t_dif.scale.y,
> > >                1.0 / t_dif.scale.z,
> > >                0.5-(0.5/t_dif.scale.x) + t_dif.offset.x,
> > >                0.5-(0.5/t_dif.scale.y) + t_dif.offset.y,
> > >                0.5-(0.5/t_dif.scale.z) + t_dif.offset.z))
> >
> > Looks good. The offset should be fine, too, provided Blender applies
> > offset after scaling; if instead it applies offset before scaling,
> > dividing the offset by t_dif.scale.* should do the trick.
> >
> > Glad I could help :)
>
> Thanks a lot. Hum... well,  Now the same formula doesn't apply to environment
> mapping, there is another discrepency, I'm trying to get rid of:
>
> Blender:
> http://www.pasteall.org/pic/show.php?id=82796
> POV:
> http://www.pasteall.org/pic/show.php?id=82797

The best I could do was this:
http://www.pasteall.org/pic/show.php?id=82820

If you compare with Blender render below, especially look at the clouds
reflexion in the sphere, I think Scale and offset are pretty correct, but the
difference in which clouds are visible through the lateral opening shows the
mapping is still incorrect.
http://wiki.blender.org/uploads/1/12/RenderBranch.jpg

Here is the translation python code:
mappingBlend = "scale 2 scale <%.4g,%.4g,%.4g> translate -1 translate
<%.4g,%.4g,%.4g> " \
               "rotate<0,0,0> " % \
               ((1.0 / t_blend.scale.x),
               (1.0 / t_blend.scale.y),
               (1.0 / t_blend.scale.z),
               (-0.5)-(-0.5/t_blend.scale.x)+ t_blend.offset.x,
               (-0.5)-(-0.5/t_blend.scale.y)+ t_blend.offset.y,
               (-0.5)-(-0.5/t_blend.scale.z)+ t_blend.offset.z)
I had to use map_type 0 but I am guessing what would be needed for more correct
results would be cube mapping? (map_type = 3 ?) which doesn't exist yet does it?
maybe in UberPOV?  otherwise, which solution would you advise? anything else
than giving up sky_sphere for a dumb (how big?) box?

Post a reply to this message

Am 25.01.2015 um 22:50 schrieb Mr:

> The best I could do was this:
> http://www.pasteall.org/pic/show.php?id=82820
>
> If you compare with Blender render below, especially look at the clouds
> reflexion in the sphere, I think Scale and offset are pretty correct, but the
> difference in which clouds are visible through the lateral opening shows the
> mapping is still incorrect.
> http://wiki.blender.org/uploads/1/12/RenderBranch.jpg
[...]
> I had to use map_type 0 but I am guessing what would be needed for more correct
> results would be cube mapping? (map_type = 3 ?) which doesn't exist yet does it?
> maybe in UberPOV?  otherwise, which solution would you advise? anything else
> than giving up sky_sphere for a dumb (how big?) box?

Well, what format does Blender use for the environment mapping anyway?

If you could post the environment map image used, that would certainly 
help identifying the mapping.

There are various formats in use, but I'd try map_type 1 first (AFAIK 
it's the most common one), and see if rotating by 90, 180 or 270 degrees 
around the vertical and/or mirroring (scale <-1,1,1>) does the trick.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 25.01.2015 um 22:50 schrieb Mr:
>
> > The best I could do was this:
> > http://www.pasteall.org/pic/show.php?id=82820
> >
> > If you compare with Blender render below, especially look at the clouds
> > reflexion in the sphere, I think Scale and offset are pretty correct, but the
> > difference in which clouds are visible through the lateral opening shows the
> > mapping is still incorrect.
> > http://wiki.blender.org/uploads/1/12/RenderBranch.jpg
> [...]
> > I had to use map_type 0 but I am guessing what would be needed for more correct
> > results would be cube mapping? (map_type = 3 ?) which doesn't exist yet does it?
> > maybe in UberPOV?  otherwise, which solution would you advise? anything else
> > than giving up sky_sphere for a dumb (how big?) box?
>
> Well, what format does Blender use for the environment mapping anyway?
>
> If you could post the environment map image used, that would certainly
> help identifying the mapping.
>
> There are various formats in use, but I'd try map_type 1 first (AFAIK
> it's the most common one), and see if rotating by 90, 180 or 270 degrees
> around the vertical and/or mirroring (scale <-1,1,1>) does the trick.

thanks, I did try all that, but type 0 is still closer.


as listed here and in the Blender interface,the default is a cube,

http://wiki.blender.org/index.php/Doc:2.6/Manual/World/Background#Textures

"Blender can use an 2D image which it maps to a very large Box or sphere which
encompasses the entire scene"

So I also tried to add "warp { cubic }" but it only gets further from the
original


Here is the function translating the map type:

def imgMapBG(wts):
    image_mapBG = ""
    # texture_coords refers to the mapping of world textures:
    if wts.texture_coords == 'VIEW' or wts.texture_coords == 'GLOBAL':
        image_mapBG = " map_type 0 "
    elif wts.texture_coords == 'ANGMAP':
        image_mapBG = " map_type 1 "
    elif wts.texture_coords == 'TUBE':
        image_mapBG = " map_type 2 "

    if wts.texture.use_interpolation:
        image_mapBG += " interpolate 2 "
    if wts.texture.extension == 'CLIP':
        image_mapBG += " once "

    return image_mapBG

In blender, available mappings for the "sky sphere" are :

View
    The default orientation, aligned with the co-ordinates of the final render

Global
    Uses global coordinates

AngMap
    Used to wrap a standard hemisphere angular map around the scene in a dome.
This can be used for image based lighting with Ambient Occlusion set to sky
color. You'll generally need a high dynamic range image (HDRI) angular map. (It
will look like a weird spherical image).

Sphere
    Sphere mapping, similar to that of materials

Tube
    Wrap the rectangular texture around in a cylinder, similar to that of
materials

Object
    Position the texture relative to a specified object's local texture space

Post a reply to this message

Am 26.01.2015 um 09:23 schrieb Mr:

> as listed here and in the Blender interface,the default is a cube,
>
> http://wiki.blender.org/index.php/Doc:2.6/Manual/World/Background#Textures
>
> "Blender can use an 2D image which it maps to a very large Box or sphere which
> encompasses the entire scene"

There's nothing in that sentence (nor anywhere else on that page for 
that matter) saying that the default is a cube; it explicitly says "Box 
or sphere".

Again, my suggestion is to post an environment map as used by Blender, 
to have a closer look at the mapping.

> Here is the function translating the map type:
>
>      elif wts.texture_coords == 'ANGMAP':
>          image_mapBG = " map_type 1 "

That's probably wrong. I suspect the AngMap type is a mapping of the 
kind made popular by Paul Devebec, as seen here:

http://www.pauldebevec.com/Probes/

AFAIK this should correspond to POV-Ray's "fisheye angle 360" camera 
projection.

Speaking of Paul Devebec's light probes page, if Blender's default 
mapping is indeed a cubic one, chances are it matches the "Vertical 
Cross Cube Format" also shown on Paul Devebec's page.

POV-Ray currently does not provide a map_type for eiter of Paul 
Devebec's mappings (yet). I do concede that this is a pity, and I'm 
inclined to tackle it soon.

As for map_type 1, that one probably corresponds to Blender's "sphere" 
mapping, possibly with rotation about the Y-axis and/or mirroring.

>      elif wts.texture_coords == 'TUBE':
>          image_mapBG = " map_type 2 "

That might also be wrong. map_type 2 cannot be reasonably used on sky 
spheres, that's for sure; it corresponds to a "cylinder 3" camera 
projection, while Blender is more likely to use a mapping corresponding 
to a "cylinder 1" camera projection.

Post a reply to this message