POV-Ray : Newsgroups : povray.bugreports : CLipka: Possible BUG Found!!! :-) Server Time
31 Oct 2024 06:14:29 EDT (-0400)
  CLipka: Possible BUG Found!!! :-) (Message 1 to 10 of 22)  
Goto Latest 10 Messages Next 10 Messages >>>
From: Sven Littkowski
Subject: CLipka: Possible BUG Found!!! :-)
Date: 12 Feb 2016 04:36:27
Message: <56bda79b$1@news.povray.org>
Yip,

and once again I gladly report a possible BUG! At least, it seems to be
a bug, let's see.

The following code causes no problem:

object
{
 HF_Cylinder( Fn_1, // Function,
                 0, // UseUVheight:  0 or 1
                 1, // UseUVtexture: 0 or 1
           <50,50>, // Resolution,
                 1, // Smooth: 0 or 1
                "", // FileName, ""=no file,
           <0,0,0>, // EndA,
         <0,1.5,0>, // EndB
              1.60 ,// Radius
               0.05  // Depth
             ) //-------------------------
 scale < 0.58, 0.67, 0.58 >
 rotate < 90.0, 0.0, 0.0 >
 scale < 1500.0, 1500.0, 2500.0 >
}

But using now a heightfield, I get an error message.

object
{
 HF_Cylinder( Fn_1, // Function,
                 0, // UseUVheight:  0 or 1
                 1, // UseUVtexture: 0 or 1
           <50,50>, // Resolution,
                 1, // Smooth: 0 or 1
 "Colony Ship I - Heightfield Landscape.png", // FileName, ""=no file,
           <0,0,0>, // EndA,
         <0,1.5,0>, // EndB
              1.60 ,// Radius
               0.05  // Depth
             ) //-------------------------
 scale < 0.58, 0.67, 0.58 >  // error here when using a heightfield
 rotate < 90.0, 0.0, 0.0 >
 scale < 1500.0, 1500.0, 2500.0 >
}

The error message is:
"Parse Error: Expected 'object', scale found instead"

PITA nomination?   :-)


Post a reply to this message

From: clipka
Subject: Re: CLipka: Possible BUG Found!!! :-)
Date: 12 Feb 2016 14:41:47
Message: <56be357b$1@news.povray.org>
Am 12.02.2016 um 10:35 schrieb Sven Littkowski:
> and once again I gladly report a possible BUG! At least, it seems to be
> a bug, let's see.

Guess what: Again it isn't :P

> But using now a heightfield, I get an error message.
> 
> object
> {
>  HF_Cylinder( Fn_1, // Function,
>                  0, // UseUVheight:  0 or 1
>                  1, // UseUVtexture: 0 or 1
>            <50,50>, // Resolution,
>                  1, // Smooth: 0 or 1
>  "Colony Ship I - Heightfield Landscape.png", // FileName, ""=no file,
>            <0,0,0>, // EndA,
>          <0,1.5,0>, // EndB
>               1.60 ,// Radius
>                0.05  // Depth
>              ) //-------------------------
>  scale < 0.58, 0.67, 0.58 >  // error here when using a heightfield
>  rotate < 90.0, 0.0, 0.0 >
>  scale < 1500.0, 1500.0, 2500.0 >
> }

You've misunderstood the FileName parameter.

From the documentation:

------------------------------------
There are several HF macros in shapes.inc, which generate meshes in
various shapes. All the HF macros have these things in common:

* The HF macros do NOT DIRECTLY USE AN IMAGE for input, but evaluate a
user-defined function. The macros deform the surface based on the
function values.
* The macros can either WRITE TO A FILE to be included later, or create
an object directly. If you want to output to a file, simply specify a
filename. If you want to create an object directly, specify "" as the
file name (an empty string).
...
------------------------------------

Specifying a FileName would be useful in animations, or if your
(pseudo-) height field is so large that you don't want it to be
re-computed each time you render the scene, e.g.:

    #declare RecomputeHFCylinder = (clock = 0);

    #if (RecomputeHFCylinder)
      HF_Cylinder( ..., "Foo.inc", ...)
    #end

    object {
      #include "Foo.inc"
      scale ...
    }

Note that when used in this mode, the HF_Cylinder(...) macro does not
evaluate to an object, but simply generates the specified file as a side
effect, so your code

    object {
      HF_Cylinder( ..., "Heightfield Landscape.png", ...)
      scale ...
    }

will evaluate to

    object {
      scale ...
    }

while at the same time overwriting(!) the file "Heightfield
Landscape.png" with plain text reading:

    mesh2 {...}


To generate a HF_Cylinder from an image, you'd need to use a pigment
function.


> PITA nomination?   :-)

Absolutely ;)


Post a reply to this message

From: Sven Littkowski
Subject: Re: CLipka: Possible BUG Found!!! :-)
Date: 12 Feb 2016 15:02:33
Message: <56be3a59$1@news.povray.org>
Not a bug? Damn.
Ah. Forget the PITA nomination for a moment. Yeah, put it aside.

I think, I really want to go ahead with your suggestion, to create a
twisted heightfield from an image. I will continue inside the GENERAL
section.


Post a reply to this message

From: dick balaska
Subject: Re: CLipka: Possible BUG Found!!! :-)
Date: 12 Feb 2016 19:04:33
Message: <56be7311$1@news.povray.org>
On 2/12/2016 3:01 PM, Sven Littkowski wrote:
> Not a bug? Damn.
> Ah. Forget the PITA nomination for a moment. Yeah, put it aside.

I think it qualifies for double secret pita.


Post a reply to this message

From: Sven Littkowski
Subject: Re: CLipka: Possible BUG Found!!! :-)
Date: 12 Feb 2016 20:53:07
Message: <56be8c83$1@news.povray.org>
He he he!

On 12.02.2016 19:04, dick balaska wrote:
> I think it qualifies for double secret pita.


Post a reply to this message

From: Kenneth
Subject: Re: CLipka: Possible BUG Found!!! :-)
Date: 13 Feb 2016 00:20:01
Message: <web.56beba7f56d165d233c457550@news.povray.org>
Sven Littkowski <jam### [at] yahoocom> wrote:

>
> But using now a heightfield, I get an error message.
>

The HF_Cylinder macro can be a bit daunting to work with when it uses an
image_map as a function. I re-worked your code, to give you a good introduction
to it. (Also take a look at 'Function Image' in the documentation.)

For everything to work correctly, start with a 'standard' cylinder size (1.0
length, with radius .5, not 1.0). To have the proper 'equalized' x and y
triangle resolutions in the heightfield (no squashing or stretching of
triangles), the macro's x-resolution needs to be int(pi)*res, not just res. You
can see what I mean by reducing the resolution to 10,10, to see the triangle
shapes.

To reproduce your image_map correctly on the cylinder, the image itself needs to
have a width-to-height ratio of pi:1.0 (using the appropriate image resolution
that you want, of course.)

--- code ---
#declare Fn_1 =
function{
 pigment{
  image_map{jpeg "your_image.jpg" once interpolate 2}
  // this image needs to be pi-units wide by 1.0 tall, NOT square.

// You can use these two modifiers to 'reverse' the imagery, to see it
// correctly on the INSIDE. HOWEVER, this does not reverse the *depth* of
// the heightfield. The only way to do that (that I know of) is to invert
// the image_map's colors (in Photoshop, for example.)
                //scale <-1,1,1>
                //translate <1,0,0>
               }
        }

object{
 HF_Cylinder( function{Fn_1(x,y*1.7,z).gray}, // *Needs* the function 'wrapper'
                 1, // UseUVheight:  0 or 1 // ON-- IMPORTANT
                 0, // UseUVtexture: 0 or 1
 <int(100*pi),100>, // Resolution.
                 1, // Smooth: 0 or 1
                "", // FileName, ""=no file,
           <0,0,0>, // EndA,
         <0,1.7,0>, // EndB-- if this y-value is different from 1.0,
                    // change the function's y-value above to compensate.
                .5, // Radius. Keep this at .5 for 1:1 reproduction of
                    // the image_map around the circumference.
                0.3 // Depth
             ) //-------------------------
scale < 0.58, 0.67, 0.58 >
rotate < 90.0, 0.0, 0.0 >
scale < 1500.0, 1500.0, 2500.0 >
}

Unlike a regular height_field, the image_map eats INTO the cylinder (but with
the correct 'positive' grayscale height values.) For example, if your image_map
has white values that are 1.0 in brightness, that part of the corresponding
cylindrical heightfield will by at the outer radius of the cylinder surface;
darker image colors will eat *into* the cylinder.

The HF_Cylinder macro reproduces the image_map correctly on the OUTSIDE, not the
inside. To get it to look correct on the INSIDE instead, you can 'flip' the
image left-to-right in the image_map's code as I've mentioned, OR by making the
x-value in function(x,y,z) into (-x + 1). This along with a color-INVERTED
image_map will give you the correct heightfield INSIDE the cylinder.

If you want to MAKE the cylinder taller than 1.0 (EndB above), you need to
compensate for that by increasing the triangle Y-resolution.

Have fun experimenting!


Post a reply to this message

From: Sven Littkowski
Subject: Re: CLipka: Possible BUG Found!!! :-)
Date: 13 Feb 2016 05:10:07
Message: <56bf00ff$1@news.povray.org>
Hi, big thanks. To be honest, I couldn't have worked out these
mathematics just by myself. Especially the requirements on the image.

If I understand correctly, the side ratio of the image has to be 3.14 x
1.0, correct? If I have an image 10,000 pixels high, the width needs to
be 31,400 pixels.

Well, this is exciting. I am making a test right now.

---------------------------

On 13.02.2016 00:17, Kenneth wrote:
>   // this image needs to be pi-units wide by 1.0 tall, NOT square.


Post a reply to this message

From: Kenneth
Subject: Re: CLipka: Possible BUG Found!!! :-)
Date: 13 Feb 2016 11:25:01
Message: <web.56bf563956d165d233c457550@news.povray.org>
Sven Littkowski <jam### [at] yahoocom> wrote:

>
> If I understand correctly, the side ratio of the image has to be 3.14 x
> 1.0, correct? If I have an image 10,000 pixels high, the width needs to
> be 31,400 pixels.
>

Yes. But you don't need to be 'locked in' to that ratio. Once you understand the
HF_Cylinder behavior better, you can change that. For example, in the code I
posted, I deliberately made the cylinder 1.7-units high (not 1.0) while also
using a 'standard' pi:1-ratio image-- to show how you can get the 'image
function' to still look correct on the heightfield. But if you really want a
taller cylinder than 1.0, the original image_map should be *created* taller as
well-- then you would likewise change the scale somewhere in the HF_Cylinder to
make sure everything looks correct.

By the way, if you want to apply the same image_map as a PIGMENT to your
heightfield, turn on 'UseUVtexture' in the macro. To save on memory and parse
time, pre-#declare the image_map like this...

#declare CYL_PIGMENT =
     pigment{
           image_map{jpeg "my_image.jpg"  once interpolate 2}
            };

Then you can use it as your HF function...

#declare Fn_1 =
function{
 pigment{
  CYL_PIGMENT
  //scale <-1,1,1>
  //translate <1,0,0>
  }
 }

..... and also in your texture definition.

An interesting fact: When using the 'once' keyword in the image_map, AND also
applying it as a texture/pigment, the HF_Cylinder only shows up where the
pigment is applied-- any remaining part of the cylinder disappears. It's as if
the other parts of the cylinder have a totally transparent texture on them (even
though the original image has no alpha-channel.)

By the way: In my code example, I wrote this code line...

HF_Cylinder( function{Fn_1(x,y*1.7,z).gray}

If you haven't worked with functions before, what that *really* means is
                          <x,y/1.7,z>

Multiplication and division are written the *opposite way* in functions (or
'inverse' way) of what you would normally write.


Post a reply to this message

From: Sven Littkowski
Subject: Re: CLipka: Possible BUG Found!!! :-)
Date: 13 Feb 2016 15:41:59
Message: <56bf9517$1@news.povray.org>
Yes, and that is, where my own boundaries begin: functions. That is a
field, in which I was never good (though I am excellent in some other
fields)...

But yes, I understand, that for a cylinder I have to work with 3.14, due
to its shape.

Once I manage to have the heightfield in the cylinder, I will work then
on a texture, and then on plants and finally on buildings.

----------------------------------

On 13.02.2016 11:21, Kenneth wrote:
> Sven Littkowski <jam### [at] yahoocom> wrote:
>> If I understand correctly, the side ratio of the image has to be 3.14 x
>> 1.0, correct? If I have an image 10,000 pixels high, the width needs to
>> be 31,400 pixels.
> 
> Yes. But you don't need to be 'locked in' to that ratio. Once you understand the
> HF_Cylinder behavior better, you can change that. For example, in the code I
> posted, I deliberately made the cylinder 1.7-units high (not 1.0) while also
> using a 'standard' pi:1-ratio image-- to show how you can get the 'image
> function' to still look correct on the heightfield. But if you really want a
> taller cylinder than 1.0, the original image_map should be *created* taller as
> well-- then you would likewise change the scale somewhere in the HF_Cylinder to
> make sure everything looks correct.
> 
> By the way, if you want to apply the same image_map as a PIGMENT to your
> heightfield, turn on 'UseUVtexture' in the macro. To save on memory and parse
> time, pre-#declare the image_map like this...
> 
> #declare CYL_PIGMENT =
>      pigment{
>            image_map{jpeg "my_image.jpg"  once interpolate 2}
>             };
> 
> Then you can use it as your HF function...
> 
> #declare Fn_1 =
> function{
>  pigment{
>   CYL_PIGMENT
>   //scale <-1,1,1>
>   //translate <1,0,0>
>   }
>  }
> 
> ..... and also in your texture definition.
> 
> An interesting fact: When using the 'once' keyword in the image_map, AND also
> applying it as a texture/pigment, the HF_Cylinder only shows up where the
> pigment is applied-- any remaining part of the cylinder disappears. It's as if
> the other parts of the cylinder have a totally transparent texture on them (even
> though the original image has no alpha-channel.)
> 
> By the way: In my code example, I wrote this code line...
> 
> HF_Cylinder( function{Fn_1(x,y*1.7,z).gray}
> 
> If you haven't worked with functions before, what that *really* means is
>                           <x,y/1.7,z>
> 
> Multiplication and division are written the *opposite way* in functions (or
> 'inverse' way) of what you would normally write.
> 
> 
> 
>


Post a reply to this message

From: Sven Littkowski
Subject: Re: CLipka: Possible BUG Found!!! :-)
Date: 13 Feb 2016 23:01:50
Message: <56bffc2e@news.povray.org>
Kenneth,

using your code, I am able to project the image into the shape of a
cylinder. But I cannot put my green pigment on it, it remains in its
gray colors (like the original image). How to change that?

I have the thread "The Colony Ship" inside the "Images" section here,
and could upload the images there. But here is the code:

-----------------------------------------------------------------

#declare Fn_1 = function
{
 pigment
 {
  image_map { jpeg "Colony Ship I - Heightfield Landscape.jpg" once
interpolate 2 }
// this image needs to be pi-units wide by 1.0 tall, NOT square.

// You can use these two modifiers to 'reverse' the imagery, to see it
// correctly on the INSIDE. HOWEVER, this does not reverse the *depth* of
// the heightfield. The only way to do that (that I know of) is to invert
// the image_map's colors (in Photoshop, for example.)
                //scale <-1,1,1>
                //translate <1,0,0>
 }
}

#declare TheLandscape = object
{
 HF_Cylinder(function { Fn_1(x,y*1.7,z).gray }, // *Needs* the function
'wrapper'
                                             1, // UseUVheight:  0 or 1
// ON-- IMPORTANT
                                             0, // UseUVtexture: 0 or 1
                             <int(100*pi),100>, // Resolution.
                                             1, // Smooth: 0 or 1
                                            "", // FileName, ""=no file,
                                       <0,0,0>, // EndA,
                                     <0,1.7,0>, // EndB-- if this
y-value is different from 1.0,
                                                // change the function's
y-value above to compensate.
                                           0.5, // Radius. Keep this at
.5 for 1:1 reproduction of
                                                // the image_map around
the circumference.
                                            0.3 // Depth
  ) //-------------------------
 scale < 0.58, 0.67, 0.58 >
 rotate < 90.0, 0.0, 0.0 >
 scale < 1500.0, 1500.0, 2500.0 >
}

#declare MyLandscape = union
{
 object { TheLandscape scale < 1.0, 1.0,  1.0 > translate < 0.0, 0.0,
0000.0 > }
 object { TheLandscape scale < 1.0, 1.0, -1.0 > translate < 0.0, 0.0,
5000.0 > }
 pigment { rgb < 0.05, 0.25, 0.0 > }
 finish { emission 0.0 }
}

-----------------------------------------------------------------

On 13.02.2016 11:21, Kenneth wrote:
>> Yes. But you don't need to be 'locked in' to that ratio. Once you understand the
>> HF_Cylinder behavior better, you can change that. For example, in the code I
>> posted, I deliberately made the cylinder 1.7-units high (not 1.0) while also
>> using a 'standard' pi:1-ratio image-- to show how you can get the 'image
>> function' to still look correct on the heightfield. But if you really want a
>> taller cylinder than 1.0, the original image_map should be *created* taller as
>> well-- then you would likewise change the scale somewhere in the HF_Cylinder to
>> make sure everything looks correct.
>>
>> By the way, if you want to apply the same image_map as a PIGMENT to your
>> heightfield, turn on 'UseUVtexture' in the macro. To save on memory and parse
>> time, pre-#declare the image_map like this...
>>
>> #declare CYL_PIGMENT =
>>      pigment{
>>            image_map{jpeg "my_image.jpg"  once interpolate 2}
>>             };
>>
>> Then you can use it as your HF function...
>>
>> #declare Fn_1 =
>> function{
>>  pigment{
>>   CYL_PIGMENT
>>   //scale <-1,1,1>
>>   //translate <1,0,0>
>>   }
>>  }
>>
>> ..... and also in your texture definition.
>>
>> An interesting fact: When using the 'once' keyword in the image_map, AND also
>> applying it as a texture/pigment, the HF_Cylinder only shows up where the
>> pigment is applied-- any remaining part of the cylinder disappears. It's as if
>> the other parts of the cylinder have a totally transparent texture on them (even
>> though the original image has no alpha-channel.)
>>
>> By the way: In my code example, I wrote this code line...
>>
>> HF_Cylinder( function{Fn_1(x,y*1.7,z).gray}
>>
>> If you haven't worked with functions before, what that *really* means is
>>                           <x,y/1.7,z>
>>
>> Multiplication and division are written the *opposite way* in functions (or
>> 'inverse' way) of what you would normally write.
>>
>>
>>
>>


Post a reply to this message

Goto Latest 10 Messages Next 10 Messages >>>

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.