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

> Great... now where do I get that mesh?

You could read the replies to your messages to find out. Your question 
has been answered a few times.


> Have you forgotten how I started this?

Yes: by making silly assumptions ("...you can see that it looks like a 
wireframe. Is there a way to use POV-ray to write out that information 
as a mesh..."), and at best half-reading the replies to your messages 
(such as the ones telling you about the height field macros in 
shapes.inc).

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

Slime wrote:
>To turn an image into a height field mesh, you must sample the image at each
>pixel and interpret the color as a height value. Then you place triangles in
>the correct places so that their vertices are at the heights of
>corresponding pixels.
>
>If you're writing the macro to sample the image, ...

You can write macros to sample images? Great. How do I learn to do that?

Fine, I'll write a macro to make meshes... I didn't know macros could read
picture files. I thought they could only read text files.

>then you can do whatever
>you want with the height values. You can wrap the image around a cylinder
>shape if you want.

I want to do more than that. I wan to blob them and add them together like
you do with an isosurface.

>Turning an isosurface into a mesh is harder, as people have mentioned,
>'cause you're trying to turn a 3D function into a 2D surface.
>
>> Great... but is there a way to output a mesh?
>
>You can cause a mesh to be parsed by using the mesh or mesh2 syntax, in this
>case in conjunction with macros and while loops.

Maybe you can... but I don't have a clue. Where do I learn to write macros
that can read image files like jpeg and gif and png?

>If you want to output the
>mesh so that you can read it in later, you can use the #fopen and #write and
>#fclose directives. (All these are in the documentation.)

I read over that briefly, but I came away with the impression that only text
files could be read. You can read image files?

>
>> There should be... and POV should read compressed mesh files without
>having
>> to go through a macro.
>
>I'm not sure what you mean by "compressed mesh files." POV-Ray can read its
>own mesh type. If you want to know why it doesn't read other types of meshes
>(.obj for instance), check the documentation, it's somewhere in the FAQ
>(section 9 i think).
>
> - Slime
>


normdoering

Post a reply to this message

normdoering <nor### [at] yahoocom> wrote:
>>  You talked about isosurfaces. Heightfields have nothing to do with that.

> They do from a user's perspective. Both of them take images, jpegs, gifs,
> etc. and derive a z coordinate from the "brightness" of a pixel point.

  I see nowhere in the isosurface syntax description that it would take
an image as parameter. Also nowhere is mentioned anything about a
z-coordinate being derived from this hypotetical image.

  Yes, you can create a pigment from an image, and then use this pigment
to create a pigment function, and then use this function to create an
isosurface. However, that's a property of a pigment, not an isosurface.
There's nothing in the isosurface itself which would make it directly
related to images.
  (Besides, even when you do this, there's absolutely no reason why do
would have to get a z value from the pigment in question; you can use
the pigment to get any value you want, eg. an x or y value, a radius
or whatever.)

> That's the essence of a mesh. The picture gives you pixels in an orderly
> x,y or u,v set of coordinates and the grayscale values give you a z.

  Now I got lost.
  I don't see how images, isosurfaces or heightfields are in any relation
to "the essence of a mesh".

  A mesh is simply a collection of triangles arranged in any way you want,
without any limitations.
  Of course you can create a mesh using data from an image, but that doesn't
make meshes inherently related to images. You don't need an image in order
to create a mesh, even though it's one way of doing it.

> Now if
> you could turn specially drawn pictures into mesh structures and manipulate
> them like you can manipulate an isosurface you'd have a way of making
> intricate, but very large, wireframe/mesh models.

  You are making things a lot more complicated than they are. Simply forget
all that stuff about isosurfaces. They have nothing to do with what you want
to do. Your question clearly seems to be:

  "How can I create a mesh which is like a heightfield using an image?"

  I gave you the answer previously: See the section 7.13.1.1 of the
POV-Ray 3.5 documentation. You can adapt the implementation of those macros
for your purposes.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Johannes Dahlstrom <sad### [at] tkukoulufi> wrote:
>> Great... now where do I get that mesh?

> Just code a macro which does this for you. Shouldn't be too difficult.

  If you people just would read the answers given by people.
  Let me repeat again:

  Please, please, please read the section 7.13.1.1 of the POV-Ray 3.5
documentation.

  Will you please do that for me? Thanks.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

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

> Yes, and that's the key. I want to make meshes using a kind of image_map
> function. That "pixelation" is the essence of a mesh.

Um, no...it is the "essence" of a rasterized image. I suppose it's 
possible it might create render errors in a grid formation when you get 
the camera too close for the isosurface settings, but I don't see how it 
could look that way with a height field.


> That isosurface is taking 2D vectors and creating a z value from its 
> greyscale to give you the full x,y,z definition of a mesh vector or 
> point. I'm talking about patching pov so that it outputs that mesh... 
> not a picture, it outputs a mesh file.

Listen: Just open up shapes.inc and look at the height field macros. You 
might be able to do what you want with no modifications to them, or you 
may need to copy them to another file and customize them or write your 
own macros using the same techniques.
You can generate the mesh with whatever data you want this way, no need 
to build a mesh and then modify it. If you want, though, you could write 
it out in a data file readable by the #fread directive instead of a mesh 
object file, then you could generate a basic mesh and then modify it. 
The PCM macros apparently support this kind of thing, you don't have to 
write it all yourself.
No need to patch POV for this, the existing version is capable enough.

More advanced mesh composition features have been discussed before in 
these newsgroups, you might want to look at those threads, it sounds 
like the features you want would be mostly covered. The only real 
benefits are parse speed and convenience though, and it has nothing to 
do with your misunderstanding of isosurfaces which started this thread.

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

>What do you mean by manipulating a mesh "like you can manipulate an
>isosurface"?

I mean you can "press" an image, like a jpeg, on to what will be the outer
surface of a 3D "sculpture" with isosurfaces and then you can press other
images onto other isosurfaces and rotate them and blob them together. If
you think of the image that's pressed onto the isosurface as if it were a
"mesh" (what I may mistakenly call a "wireframe") then you see a way to
manipulate mesh files... by taking shallow "mesh sheets", think of it as a
tinfoil sheet, and bringing them together with isosurface like functions,
blobbing and such.

>Anyway, it has already been explained that you can generate the needed
>mesh with the scene description language, if you have a more specific
>question about doing this, ask it.

How do I write a macro that reads an image file, like a jpeg? How do I
extract
the pixel values from a jpeg with a macro?

>And just drop the word "wireframe"
>from your vocabulary until you learn how to use it correctly, please...

What's the difference between a wireframe and a mesh?

normdoering

Post a reply to this message

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

> You can write macros to sample images? Great. How do I learn to do that?

Reading the replies answering this question would be a good start.


> I want to do more than that. I wan to blob them and add them together like
> you do with an isosurface.

Doing this with meshes is extremely, *EXTREMELY* difficult, as a macro 
or a patch. If you need to do that, you'd be better off using an 
isosurface.


> Maybe you can... but I don't have a clue. Where do I learn to write macros
> that can read image files like jpeg and gif and png?

Use the same method the height field macros use for images. Use an 
image_map in a pigment function, then call the function to get the color 
for each pixel.

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

Johannes Dahlstrom wrote:
>normdoering wrote:
>
>> Great... now where do I get that mesh?
>
>Just code a macro which does this for you. Shouldn't be too difficult.

Okay, has anyone ever done this before? I've never seen a macro that read
image files. Can I find examples of how such a macro might be written?

normdoering

Post a reply to this message

Christopher James Huff wrote:
>Listen: Just open up shapes.inc and look at the height field macros.

shapes.inc... hmmm okay. Thanks maybe that's what I'm looking for. I don't
know yet.

>No need to patch POV for this, the existing version is capable enough.

Maybe... But until I look at what I can do with macros I won't be sure.
It sounds a bit like saying you don't need pov because if you have a C
compiler you can write a ray tracer. I don't quite think you guys have
grasped what I'm saying though -- not you're fault. I don't know how to
describe it.

Post a reply to this message

Christopher James Huff wrote:
>Doing this with meshes is extremely, *EXTREMELY* difficult, as a macro
>or a patch.

That's why I wanted someone else to do it. You might as well have told me to
write my own ray tracer. You're all just saying "no" I won't write such a
patch.

Okay. I was just asking. It's just an idea I'm throwing out there.

Post a reply to this message