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

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

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

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

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

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

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

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

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

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

Sven Littkowski <jam### [at] yahoocom> wrote:
> 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?

That's odd. I DO see the green color, using just your code example. Did you
combine the 'MyLandscape' object with some other CSG and then apply another
different 'gray' texture?
>
> I have the thread "The Colony Ship" inside the "Images" section here,
> and could upload the images there. But here is the code:
>

Yes, post an image there.

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:

>
> 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.
>

Actually, that's only half-true (which has just become clear to me-- and I've
been working with the HF_Cylinder macro for years!)

As the 'depth' value in the macro increases, the radius of the entire
height_field cylinder ALSO increases (but not the *length* of the cylinder)--
you end up with a 'fatter' cylinder, which actually distorts the 3D image_map
pattern. The pattern looks stretched-out horizontally. (You can see this by
setting 'depth' to an extreme .99.)

IDEALLY, as 'depth' increases, the cylinder should stay at the same radius, with
the image_map function simply 'eating into' it. But that's not what happens.

I'm working on some SCALE equations to compensate for this, but it's...
complicated. The first thing to do is to scale up the *length* of the cylinder,
to get the embossed pattern to look undistorted again. Then the entire cylinder
needs to be scaled *down*, to get it back to its original radius and length.

The tricky thing about this is that it all depends on the particular 'depth'
value used.

Post a reply to this message

Am 14.02.2016 um 21:01 schrieb Kenneth:

> As the 'depth' value in the macro increases, the radius of the entire
> height_field cylinder ALSO increases (but not the *length* of the cylinder)--
> you end up with a 'fatter' cylinder, which actually distorts the 3D image_map
> pattern. The pattern looks stretched-out horizontally. (You can see this by
> setting 'depth' to an extreme .99.)
> 
> IDEALLY, as 'depth' increases, the cylinder should stay at the same radius, with
> the image_map function simply 'eating into' it. But that's not what happens.

That wouldn't be ideal either, as it would /reduce/ the effective radius
of the entire height_field cylinder on average, creating the opposite
distorting effect.

The fact is that there is no ideal solution (because there is no telling
what the average height of your image_map function is), and whoever
implemented HF_Cylinder just picked this particular implementation for
other properties.

The primary reason may have been that a corresponding behaviour in
HF_Sphere makes it easy to use for modeling planets, with the nominal
radius specifying sea level and everything else being raised above it.

> I'm working on some SCALE equations to compensate for this, but it's...
> complicated. The first thing to do is to scale up the *length* of the cylinder,
> to get the embossed pattern to look undistorted again. Then the entire cylinder
> needs to be scaled *down*, to get it back to its original radius and length.
> 
> The tricky thing about this is that it all depends on the particular 'depth'
> value used.

Maybe the easiest way to approach this is to simply adjust the nominal
radius parameter as you change the depth parameter.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 14.02.2016 um 21:01 schrieb Kenneth:
>

> >
> > IDEALLY, as 'depth' increases, the cylinder should stay at the same radius,
> > with the image_map function simply 'eating into' it. But that's not what
> > happens.
>
> That wouldn't be ideal either, as it would /reduce/ the effective radius
> of the entire height_field cylinder on average, creating the opposite
> distorting effect.
>

I was assuming (probably incorrectly) that the image_map itself would always
have *some* pure white areas in it-- which would equate to the max height of the
HF (meaning, the max radius of the HF_Cylinder.) It's that max radius I was
referring to. In experiments I'm doing with two really odd (and dynamic) scaling
equations, I can *almost* get that max radius AND height to stay at set values,
no matter what the 'depth' value. But "almost" isn't quite good enough yet...
:-/

Post a reply to this message

Seeing all these problems, I am wondering, if there is a possibility in
POV-Ray, to twist a given OBJECT to become a cylinder.

If that function does not exist yet, here is a suggestion:
1
That function needs to twist an object of any dimension, example:
that object is not 1 unit tall, but lets say 10 units (imagine a box)
2
When twisting to a cylinder, there is no standard size (of 1 unit), but
the radius is set by the user, this way, a cylinder-twisted object with
a height of 10 units would not lead to a cylinder that is fully filled,
if the cylinder radius was set to let's say 100 units. Also, the user
can set the begin and end radius, that enables cylinders and also funnels.

Here my vision:

/*
The object ("MyObject) must be centered by the user at < 0, 0, 0 > and
the lowest point (Z axis) must be 0, while the highest point is open
(any number). The user cares about that by using the proper radius. The
OBJ_Cylinder function creates a cylinder from let's say -X to +X, the
radius from -Z to +Z.

Here, MyObject is assumed to range
from <-10.0, 0.0, -5.0> to <10.0, 10.0, 5.0>
*/

#declare TheLandscape = object
{
 OBJ_Cylinder(object { MyObject }, // the object to be twisted
                             10.0, // X (X Expanse of object)
                              5.0, // Z (Z Expanse)
                            100.0, // Cylinder Radius Begin
                             90.0, // Cylinder Radius End
  )
 rotate < 90.0, 0.0, 0.0 >  // any common object modifiers)
}

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

On 14.02.2016 16:42, Kenneth wrote:
> clipka <ano### [at] anonymousorg> wrote:
>> Am 14.02.2016 um 21:01 schrieb Kenneth:
>>
> 
>>>
>>> IDEALLY, as 'depth' increases, the cylinder should stay at the same radius,
>>> with the image_map function simply 'eating into' it. But that's not what
>>> happens.
>>
>> That wouldn't be ideal either, as it would /reduce/ the effective radius
>> of the entire height_field cylinder on average, creating the opposite
>> distorting effect.
>>
> 
> I was assuming (probably incorrectly) that the image_map itself would always
> have *some* pure white areas in it-- which would equate to the max height of the
> HF (meaning, the max radius of the HF_Cylinder.) It's that max radius I was
> referring to. In experiments I'm doing with two really odd (and dynamic) scaling
> equations, I can *almost* get that max radius AND height to stay at set values,
> no matter what the 'depth' value. But "almost" isn't quite good enough yet...
> :-/
> 
> 
>

Post a reply to this message

On 2/15/2016 6:20 AM, Sven Littkowski wrote:
> Seeing all these problems, I am wondering, if there is a possibility in
> POV-Ray, to twist a given OBJECT to become a cylinder.
>
> If that function does not exist yet, here is a suggestion:
> 1
> That function needs to twist an object of any dimension, example:
> that object is not 1 unit tall, but lets say 10 units (imagine a box)
> 2
> When twisting to a cylinder, there is no standard size (of 1 unit), but
> the radius is set by the user, this way, a cylinder-twisted object with
> a height of 10 units would not lead to a cylinder that is fully filled,
> if the cylinder radius was set to let's say 100 units. Also, the user
> can set the begin and end radius, that enables cylinders and also funnels.
>
> Here my vision:
>
> /*
> The object ("MyObject) must be centered by the user at < 0, 0, 0 > and
> the lowest point (Z axis) must be 0, while the highest point is open
> (any number). The user cares about that by using the proper radius. The
> OBJ_Cylinder function creates a cylinder from let's say -X to +X, the
> radius from -Z to +Z.
>
> Here, MyObject is assumed to range
> from <-10.0, 0.0, -5.0> to <10.0, 10.0, 5.0>
> */
>
> #declare TheLandscape = object
> {
>   OBJ_Cylinder(object { MyObject }, // the object to be twisted
>                               10.0, // X (X Expanse of object)
>                                5.0, // Z (Z Expanse)
>                              100.0, // Cylinder Radius Begin
>                               90.0, // Cylinder Radius End
>    )
>   rotate < 90.0, 0.0, 0.0 >  // any common object modifiers)
> }
>
> -------------------------------------------------------
>
> On 14.02.2016 16:42, Kenneth wrote:
>> clipka <ano### [at] anonymousorg> wrote:
>>> Am 14.02.2016 um 21:01 schrieb Kenneth:
>>>
>>
>>>>
>>>> IDEALLY, as 'depth' increases, the cylinder should stay at the same radius,
>>>> with the image_map function simply 'eating into' it. But that's not what
>>>> happens.
>>>
>>> That wouldn't be ideal either, as it would /reduce/ the effective radius
>>> of the entire height_field cylinder on average, creating the opposite
>>> distorting effect.
>>>
>>
>> I was assuming (probably incorrectly) that the image_map itself would always
>> have *some* pure white areas in it-- which would equate to the max height of the
>> HF (meaning, the max radius of the HF_Cylinder.) It's that max radius I was
>> referring to. In experiments I'm doing with two really odd (and dynamic) scaling
>> equations, I can *almost* get that max radius AND height to stay at set values,
>> no matter what the 'depth' value. But "almost" isn't quite good enough yet...
>> :-/
>>
>>
>>

Maybe this will help.

http://www.reocities.com/SiliconValley/Lakes/1434/bend.html

I've never used it.


Mike

Post a reply to this message

Am 15.02.2016 um 12:20 schrieb Sven Littkowski:
> Seeing all these problems, I am wondering, if there is a possibility in
> POV-Ray, to twist a given OBJECT to become a cylinder.

Nope. Not with arbitrary objects.

> If that function does not exist yet, here is a suggestion:

Forget it. With most shapes, you'd need to convert them to something
more generic first, meshes being the most obvious choice.

Post a reply to this message

On 2/15/2016 11:32 AM, Mike Horvath wrote:
>
> http://www.reocities.com/SiliconValley/Lakes/1434/bend.html
>
> I've never used it.
>
>
> Mike

Are these links all written down anywhere (like in the wiki)? Or is it 
just individual bookmarks.

Years ago, someone had a blob tutorial (Jaime or Warp?) that I'd like to 
find.

dik

Post a reply to this message

I saw it, just recently. The URL was given to me inside one of my
threads here, where I asked about water media.

On 15.02.2016 17:30, dick balaska wrote:
> Years ago, someone had a blob tutorial (Jaime or Warp?) that I'd like to
> find.

Post a reply to this message

Somewhere inside my "Wanted: Air and Water" thread, inside the GENERAL
section of this newsgroup.

On 15.02.2016 17:30, dick balaska wrote:
> Years ago, someone had a blob tutorial (Jaime or Warp?) that I'd like to
> find.

Post a reply to this message

Here it is, I found it:
http://runevision.com/3d/

On 15.02.2016 17:30, dick balaska wrote:
> Years ago, someone had a blob tutorial (Jaime or Warp?) that I'd like to
> find.

Post a reply to this message

On 2/15/2016 5:30 PM, dick balaska wrote:
> On 2/15/2016 11:32 AM, Mike Horvath wrote:
>>
>> http://www.reocities.com/SiliconValley/Lakes/1434/bend.html
>>
>> I've never used it.
>>
>>
>> Mike
>
> Are these links all written down anywhere (like in the wiki)? Or is it
> just individual bookmarks.
>
> Years ago, someone had a blob tutorial (Jaime or Warp?) that I'd like to
> find.
>
> dik
>

I just happened to remember it.


Mike

Post a reply to this message