I'm trying to write my first new HF_ macro (as in shapes.inc) and the first
thing I want to do is rewrite the HF_Square (as HF_pressmold()) so that you
don't get excess mesh where you don't want it. That is, not a square, but a
cut out shape. What seems to be offered are these dot operators.

There are five possible components and the supported dot types to access
these components -- from the isosurface section of POV help:

F( ).x | F( ).u | F( ).red
to get the red value of the color vector
F( ).y | F( ).v | F( ).green
to get the green value of the color vector
F( ).z | F( ).blue
to get the blue value of the color vector
F( ).filter | F( ).t
to get the filter value of the color vector
F( ).transmit
to get the transmit value of the color vector
F( ).gray
to get the gray value of the color vector
gray value = Red*29.7% + Green*58.9% + Blue*11.4%
F( ).hf
to get the height_field value of the color vector
hf value = (Red + Green/255)*0.996093

If another function is declared and used by a new HF_ macro in order to get
another color channel that channel might tell the macro where to cut off
excess mesh to get the shape desired. I don't know if transmit and filter
channels can be easily made by all paint programs or if theres a way the
masks corel draw can make for .png files can be accessed (is transmit a
mask channel?).

All the colors make white, that shows up on all color channels, I think. So,
you'd have to do some sort of compare...

#if (red_component < blue_component + green_component)
--make a mesh point on the grid--
#else
--skip this part of the grid--
#end

I think the above code would cut out all elements of a picture with a strong
red tinge.

However, how does one express that cutting so that HFCreate_() can read it?
Will HFCreate have to be rewritten too?

And if so... what's a good way to do it? make another array grid just to
tell the create macro where to cut? There should be a better way...

Just thinking out loud here, maybe someone out there has ideas.

normdoering

Post a reply to this message

In article <web.3dcd4ff566ca52347efeba520@news.povray.org>,
 "normdoering" <nor### [at] yahoocom> wrote:

> If another function is declared and used by a new HF_ macro in order to get
> another color channel that channel might tell the macro where to cut off
> excess mesh to get the shape desired. I don't know if transmit and filter
> channels can be easily made by all paint programs or if theres a way the
> masks corel draw can make for .png files can be accessed (is transmit a
> mask channel?).

I think the best way would be a separate mask function. That way, you 
aren't limited to an image with an alpha channel. You could then use a 
user defined function to mask out parts of the image. (I don't even know 
how POV image maps handle alpha channels, I've never used it.)


> All the colors make white, that shows up on all color channels, I think. So,
> you'd have to do some sort of compare...

Now I just couldn't figure out this sentence...the colors of a height 
field image are not shades of gray. The red and green channels are 
combined to get 16 bit precision out of 2 8-bit channels, the blue 
channel is ignored. You could probably use the blue channel for mask 
information, if that's what you are asking...it won't work if you then 
use a grayscale image, and it will limit you to image files unless you 
do some extra work to encode the mask into a pigment function.


> However, how does one express that cutting so that HFCreate_() can read it?
> Will HFCreate have to be rewritten too?

Probably. For this you should probably write your own version, not 
modify the height field macros in shapes.inc, which could cause problems 
parsing other people's code.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

Christopher James Huff wrote:
>In article <web.3dcd4ff566ca52347efeba520[at]news.povray.org>,
> "normdoering" <nor### [at] yahoocom> wrote:
>
>> If another function is declared and used by a new HF_ macro in order to get
>> another color channel that channel might tell the macro where to cut off
>> excess mesh to get the shape desired. I don't know if transmit and filter
>> channels can be easily made by all paint programs or if theres a way the
>> masks corel draw can make for .png files can be accessed (is transmit a
>> mask channel?).
>
>I think the best way would be a separate mask function. That way, you
>aren't limited to an image with an alpha channel. You could then use a
>user defined function to mask out parts of the image. (I don't even know
>how POV image maps handle alpha channels, I've never used it.)
>
>
>> All the colors make white, that shows up on all color channels, I think. So,
>> you'd have to do some sort of compare...
>
>Now I just couldn't figure out this sentence...

In my Corel photopaint I can separate the red, green and blue channels and
each each channel becomes a separate grey scale kind of picture. White and
black are the same on all channels and the difference in colors shows up
only in subtle variations in grey shades. A strongly red color is whiter in
the red channel and darker in the blue and green channels. If the red is
pure enough it's twice as bright as either blue or green.

>the colors of a height field image are not shades of gray.

I found out that you don't need to use the .hf dot operator, you can use
either .red, .green, .blue or .grey operators on color images and the HF_
macros work.

> The red and green channels are combined to get 16 bit precision out
> of 2 8-bit channels, the blue channel is ignored.
> You could probably use the blue channel for mask information,
> if that's what you are asking...

Ah, I picked the wrong color.

> it won't work if you then use a grayscale image, and it will limit
> you to image files unless you do some extra work to encode the mask
> into a pigment function.

Maybe the best way would be to let the user decide what they want to use.
Since the dot operator is chosen outside the HF_ macro it wouldn't matter
what the macro thought the channel was. That is, you could write any of
these:

#declare MeshCut = function {MyCutImage(x,z,y).red}
#declare MeshCut = function {MyCutImage(x,z,y).blue}
#declare MeshCut = function {MyCutImage(x,z,y).transmit}
#declare MeshCut = function {MyCutImage(x,z,y).grey}

to get a working function.

>> However, how does one express that cutting so that HFCreate_() can read it?
>> Will HFCreate have to be rewritten too?
>
>Probably.

I was afraid of that. This is getting more complicated the more I think
about it.

>For this you should probably write your own version, not
>modify the height field macros in shapes.inc, which could cause problems
>parsing other people's code.

Right. But that's not really what I meant. When I talking about "rewriting"
it has to do with the way I write code, I find other code that's close to
what I want and copy it to a new file, rename the function/macro/whatever,
and start making changes. Less typing, less re-inventing all the little
wheels that make it work.

The HF_macros may not actually be the closest to what I want, they're just
what I found and what people here know about (thanks to help from you
guys here I know that is). They can take a hand drawn image that was scanned
in and make a limited type of mesh. However, it's not exactly the
"sculpting with a pencil" idea I'm trying to implement. Warp may have
turned me on to some great "close" code, The Subdivision Surface Suite.

http://enphilistor.users4.50megs.com/sss.zip

normdoering

Post a reply to this message

In article <web.3dcda89c6f496618178f7f9c0@news.povray.org>,
 "normdoering" <nor### [at] yahoocom> wrote:

> >Now I just couldn't figure out this sentence...
> 
> In my Corel photopaint I can separate the red, green and blue channels and
> each each channel becomes a separate grey scale kind of picture. White and
> black are the same on all channels and the difference in colors shows up
> only in subtle variations in grey shades. A strongly red color is whiter in
> the red channel and darker in the blue and green channels. If the red is
> pure enough it's twice as bright as either blue or green.

Right, images are represented with red, green, and blue channels.


> >the colors of a height field image are not shades of gray.
> I found out that you don't need to use the .hf dot operator, you can use
> either .red, .green, .blue or .grey operators on color images and the HF_
> macros work.

Right, .red, .green, and .blue return the values of specific color 
components, .grey returns the grayscale value, and .hf returns a height 
value using the same technique the height_field object uses.


> I was afraid of that. This is getting more complicated the more I think
> about it.

Heh, well, it looks like the height field macros were rewritten to use a 
rectangular patch of triangles, and it would take some big changes to 
handle other geometries. My original version wrote the triangles more 
directly, which would have made this modification easier, but my version 
didn't output in mesh2 format. Looks like the tetrahedron subdivision 
spherical height field is gone too...I liked that one, it didn't have 
the pinching problems at the poles, and spread out the triangles better.
Someone else gave some code that might be easier to modify than the 
height field macros.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

Christopher James Huff wrote:

>.... looks like the height field macros were rewritten to use
> a rectangular patch of triangles, and it would take some big
> changes to handle other geometries. My original version wrote
> the triangles more directly,...

I may have a copy already, I've downloaded more stuff from these newsgroups
than I recall, but I think I want to see your method. I don't want the
triangles in rectangular patches.

> ... which would have made this modification easier, but my version
> didn't output in mesh2 format.

That'a okay. Outputting different formats isn't that big a deal. You just
need a understanding of the format.

>... Looks like the tetrahedron subdivision spherical height field is
> gone too...

The what? I never saw any early versions (yet) so I don't know what you're
talking about. I only found out the HF_ macros existed a day or so ago when
you guys told me they were there.

> I liked that one, it didn't have the pinching problems at the poles,
> and spread out the triangles better. Someone else gave some code that
> might be easier to modify than the height field macros.

I may have this, but I'll have to check on what I downloaded tonight. If
not, I'll be looking for them.

normdoering

Post a reply to this message

In article <web.3dcdf5256f496618178f7f9c0@news.povray.org>,
 "normdoering" <nor### [at] yahoocom> wrote:

> That'a okay. Outputting different formats isn't that big a deal. You just
> need a understanding of the format.

Well, it just calculated the undisplaced positions of each point, 
calculated the displacement for those points, and then wrote a triangle 
with those points. Not well optimized at all, but not limited to a 
rectangular sheet.
BTW, just leaving out triangles will produce ragged edges, you will 
probably need to smooth that out somehow, which would probably be 
easiest if you had an array of vertices and another of validity flags.


> The what? I never saw any early versions (yet) so I don't know what you're
> talking about. I only found out the HF_ macros existed a day or so ago when
> you guys told me they were there.

It was a version of the spherical height field that didn't use a 
rectangular sheet wrapped around the sphere. When you do that, the top 
and bottom get pinched together at the poles, wasting triangles and 
potentially causing visible artifacts. An alternative method is to 
repeatedly subdivide a polyhedron, usually a tetrahedron or octahedron. 
Each level of subdivision increases the number of triangles by 4, so you 
don't get as tight control of the resolution, but the triangles are all 
more or less of equal size and equally spread out, and without the 
obvious patterns leadinging towards the poles. Looks like it disappeared 
when the macros were updated for mesh2.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

Christopher James Huff wrote:
>In article <web.3dcdf5256f496618178f7f9c0[at]news.povray.org>,
> "normdoering" <nor### [at] yahoocom> wrote:
>
>> That'a okay. Outputting different formats isn't that big a deal. You just
>> need a understanding of the format.
>
>Well, it just calculated the undisplaced positions of each point,
>calculated the displacement for those points, and then wrote a triangle
>with those points. Not well optimized at all, but not limited to a
>rectangular sheet.

Still, I'm looking for better starter material to work from. My macros will
probably be complex so I'm looking for more complexable tools. For example,
Ingo Janssen wrote "makemesh.inc" It has the macros and functions for
builing mesh2 objects. It looks like I'll be able to use that one rather
than the one in shapes.inc.

http://members.home.nl/seedseven/makemesh.html

His  BuildWriteMesh2() macro has options to write Wavefront *.obj files,
*.pcm files, for Chris Colefax' Compressed Mesh Macros, and *.arr files,
which writes only the arrays to a file. This last one is a great advantage
as it's the best mode for reading arrays back later for further mesh
manipulations. Another advantage, the array used by BuildWriteMesh2()
looks, at my first glance here, to be one dimensional, not thought of as a
rectangular grid.

Janssen's macro is called this way:

#include "makemesh.inc"

      BuildWriteMesh2
      ( VecArr,     //  The array that contains the vertices of the mesh.
        NormArr,    //   normal vectors that go with the vertices.
        UVArr,      //   uv_vectors
        U,          //   # of subdivisions of the surface in the
u-direction.
        V,          //   # of subdivisions in the v-direction.
        FileName    //  file, "" or .obj or .pcm or .arr that's written to.
     )

>BTW, just leaving out triangles will produce ragged edges, you will
>probably need to smooth that out somehow, which would probably be
>easiest if you had an array of vertices and another of validity flags.

Valadity flags?

Right now I'm not even sure how this bit of code works:

 #while (J<xRes+1+Smooth)
 #local K = 1-Smooth;
    #while (K<zRes+1+Smooth)

         #local UV = <(J-1)/(xRes-1),0,(K-1)/(zRes-1)>;

         #local P  = (UV*Ext*<1,0,1> + MnExt);

         #if (UVheight)
            #local H = Function(UV.x, UV.z, 0);
         #else
            #local H = Function(P.x, P.y, P.z);
// -----------------------------------------------------------------
// What kind of data is the Function that reads the picture data here
// assigning to H? Does the picture reading function read a 2D array
// of data and assign a 3D point to H or just the height value?
//
// I've only used these picture reading functions in isosurfaces and
// never learned to use them in a pixel by pixel read.
// ------------------------------------------------------------------

         #end

         #declare PArr[J][K] = P + H*Ext*y;

         #declare K = K+1;
      #end
      #declare J = J+1;
   #end

   HFCreate_()
#end
>
>> The what? I never saw any early versions (yet) so I don't know what you're
>> talking about. I only found out the HF_ macros existed a day or so ago when
>> you guys told me they were there.
>
>It was a version of the spherical height field that didn't use a
>rectangular sheet wrapped around the sphere. When you do that, the top
>and bottom get pinched together at the poles, wasting triangles and
>potentially causing visible artifacts. An alternative method is to
>repeatedly subdivide a polyhedron, usually a tetrahedron or octahedron.
>Each level of subdivision increases the number of triangles by 4, so you
>don't get as tight control of the resolution, but the triangles are all
>more or less of equal size and equally spread out, and without the
>obvious patterns leadinging towards the poles. Looks like it disappeared
>when the macros were updated for mesh2.

Hmmm, right now what I want is to is learn how the picture reading function
works in a pixel by pixel loop and then create a one dimensional array of
vertices, what BuildWriteMesh2() seems to use.

--normdoering

Post a reply to this message