When you get in close to an isosurface (at least one that's had an image map
/ picture impressed on it) 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, or mesh
2?

You could then use POV-ray to do more complex wireframe/mesh modeling.

It would be a big help for those who want to animate isosurfaces.


normdoering

Post a reply to this message

normdoering <nor### [at] yahoocom> wrote:
> When you get in close to an isosurface (at least one that's had an image map
> / picture impressed on it) you can see that it looks like a wireframe.

  If it looks like a wireframe it doesn't mean it is a wireframe. It probably
means that your accuracy is too low.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

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

> When you get in close to an isosurface (at least one that's had an image map
> / picture impressed on it) 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, or mesh
> 2?

You are mistaken. What you see are precision errors of the intersection 
solving algorithm, you probably just need to adjust your isosurface 
settings.
There is no wireframe information to write out. If there were, 
isosurfaces would be a lot faster.

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

You really can't put an isosurface to a wireframe.  You could create
approximations using an algorithm such as the marching cubes algorithm, but
it wouldn't be perfect.

I was once working on a macro that approximated an isosurface using a slight
variant of the marching cubes algorithm, but never quite finished it.
Parsing would take an extremely long time, especially if you wanted it to be
really accurate.  But the result would render very quickly compared to the
original isosurface.

-DJ

"normdoering" <nor### [at] yahoocom> wrote in message
news:web.3dc175b4282cec51d2ac4d730@news.povray.org...
>
> When you get in close to an isosurface (at least one that's had an image
map
> / picture impressed on it) 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, or
mesh
> 2?
>
> You could then use POV-ray to do more complex wireframe/mesh modeling.
>
> It would be a big help for those who want to animate isosurfaces.
>
>
> normdoering
>
>

Post a reply to this message

DJ Wiza wrote:
>You really can't put an isosurface to a wireframe.  You could create
>approximations using an algorithm such as the marching cubes algorithm, but
>it wouldn't be perfect.
>
>I was once working on a macro that approximated an isosurface using a slight
>variant of the marching cubes algorithm, but never quite finished it.
>Parsing would take an extremely long time, especially if you wanted it to be
>really accurate.  But the result would render very quickly compared to the
>original isosurface.
>
>-DJ

What are marching cubes?

I like modeling with isosurfaces, but less for the use of equations to make
shapes than for its height field like feature of being able to take an
image map, a picture I've drawn in Corel photopaint, or drawn with a pencil
and scanned. The problem with the height field is that it's always "flat."
Now, a height field looks like a wire frame too up close. Also, the basic
idea of using grey scale values as z values should be easy to implement.
What's needed is a way to bend, cut, join, and otherwise manipulate the
wire frames produced.

Drawing grey scale picture is a hell of a lot more efficient way of
generating a limited type of 3D data than trying to grab vertices with a
mouse and move them around in modelers like hamanapatch and what not.

Is there a way you could make height fields more flexible? Make it so you
can bend, wrap, join height field into a 3D object, like a head or skull?

Is what I'm asking clear?

Don't tell me a height field isn't a wireframe internally... It doesn't
matter, a grey scale picture should certainly easily become a wireframe.

Post a reply to this message

normdoering <nor### [at] yahoocom> wrote:
> Is there a way you could make height fields more flexible?

  Please see the section 7.13.1.1 of the POV-Ray 3.5 documentation.

> Don't tell me a height field isn't a wireframe internally...

  You talked about isosurfaces. Heightfields have nothing to do with that.

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

> Is there a way you could make height fields more flexible? Make it so you
> can bend, wrap, join height field into a 3D object, like a head or skull?
>
> Is what I'm asking clear?
>
> Don't tell me a height field isn't a wireframe internally... It doesn't
> matter, a grey scale picture should certainly easily become a wireframe.


The code to render height fields is strongly based upon their rectangular
shape. The way it's coded, it's able to speed up the rendering a lot just by
making use of this fact. If you distort the height field's shape, you lose
this property and the height field will render at the same speed as a mesh.
Therefore, you might as well use a mesh. You should be able to write macros
that will take a function or pigment and create any shape mesh you want from
it in a height-field like fashion.

In fact, I believe there are macros for cylindrical and spherical height
fields in the standard include files somewhere.

 - Slime
[ http://www.slimeland.com/ ]

Post a reply to this message

Warp wrote:

> normdoering <nor### [at] yahoocom> wrote:
>> Is there a way you could make height fields more flexible?
> 
>   Please see the section 7.13.1.1 of the POV-Ray 3.5 documentation.
> 
>> Don't tell me a height field isn't a wireframe internally...
> 
>   You talked about isosurfaces. Heightfields have nothing to do with that.
> 

Well, height_fields indeed don't have anything to do with isosurfaces, but 
height fields in general do: a function of form y - my_height_func(x,0,z) 
produces one. And of course an isosurface height field is much more 
flexible than a traditional one.

Post a reply to this message

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

> What are marching cubes?

It's an algorithm for automatically creating a mesh from an arbitrary 
mathematically defined object. A patented method, actually...there are 
other similar non patented methods. The basic idea is to sample the idea 
on a 3D lattice to find connected points on its surface.


> Is there a way you could make height fields more flexible? Make it so you
> can bend, wrap, join height field into a 3D object, like a head or skull?

Doing so would lose the speed advantages of a height field, you might as 
well use a mesh. You could write macros to generate a mesh with all the 
distortions you want, look at the height field macros in shapes.inc for 
examples. Parsing will be slow, though.


> Don't tell me a height field isn't a wireframe internally... It doesn't
> matter, a grey scale picture should certainly easily become a wireframe.

It isn't, and it does matter. POV can't render wireframes, they are 
impossible to raytrace. Wireframe is a rendering method where lines 
(wires) are drawn to the image, not a kind of shape. Again, what you are 
seeing is simply a rendering error...in this case, one I've never seen.

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

> Again, what you are seeing is simply a rendering error...
> in this case, one I've never seen.
>

He mentioned he's using image_map functions, so I think the "wireframe" 
effect is just pixelation...

Post a reply to this message

Warp 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.
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 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're not quite listening to what I'm saying. Could be my fault I don't
know how to describe my idea.

normdoering

Post a reply to this message

>The code to render height fields is strongly based upon their rectangular
>shape. The way it's coded, it's able to speed up the rendering a lot just by
>making use of this fact. If you distort the height field's shape, you lose
>this property and the height field will render at the same speed as a mesh.
>Therefore, you might as well use a mesh...

Right! But there is no mesh! That's the problem. How do I get that mesh?
There's only 2D pictures with POV turning it into something that looks like
a mesh.

I'm talking about outputting a mesh. Remember what I said about turning
isosurfaces into meshes.

>You should be able to write macros
>that will take a function or pigment and create any shape mesh you want from
>it in a height-field like fashion.
>
>In fact, I believe there are macros for cylindrical and spherical height
>fields in the standard include files somewhere.

Great... but is there a way to output a mesh?

There should be... and POV should read compressed mesh files without having
to go through a macro.
>
> - Slime
>


normdoering

Post a reply to this message

normdoering wrote:

> Great... but is there a way to output a mesh?
> 
> There should be... and POV should read compressed mesh files without
> having to go through a macro.

No, that's the whole point of having a programmable SDL. If something can 
be done with a macro, it makes no sense to create a patch to do it (not 
counting possible speed issues, that is).

Post a reply to this message

Christopher James Huff wrote:
....
>Doing so would lose the speed advantages of a height field, you might as
>well use a mesh.

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

Have you forgotten how I started this?

Post a reply to this message

Johannes Dahlstrom wrote:
>Christopher James Huff wrote:
>
>> Again, what you are seeing is simply a rendering error...
>> in this case, one I've never seen.
>>
>
>He mentioned he's using image_map functions, so I think the "wireframe"
>effect is just pixelation...
>

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

normdoering

Post a reply to this message

normdoering wrote:

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

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

Post a reply to this message

> Right! But there is no mesh! That's the problem. How do I get that mesh?
> There's only 2D pictures with POV turning it into something that looks
like
> a mesh.
>
> I'm talking about outputting a mesh. Remember what I said about turning
> isosurfaces into meshes.


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, then you can do whatever
you want with the height values. You can wrap the image around a cylinder
shape if you want.

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

> 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
[ http://www.slimeland.com/ ]

Post a reply to this message

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

> There should be... and POV should read compressed mesh files without having
> to go through a macro.

Um, no, it shouldn't. Those mesh files aren't a POV format, they are a 
third party thing that has no official support. And the whole point of 
using macros is the flexibility you gain.

-- 
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 <sad### [at] tkukoulufi> wrote:
> And of course an isosurface height field is much more 
> flexible than a traditional one.

  If you have the time for waiting for it to finish rendering. ;)

-- 
#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.3dcadd16195c50e490f0db7e0@news.povray.org>,
 "normdoering" <nor### [at] yahoocom> wrote:

> 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.
> That's the essence of a mesh.

That's the essence of a height field. Meshes and isosurfaces are both 
much more flexible. What you are asking to do makes it no longer a 
height field, but a mesh would easily do it.


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

What do you mean by manipulating a mesh "like you can manipulate an 
isosurface"?
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. And just drop the word "wireframe" 
from your vocabulary until you learn how to use it correctly, please...

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

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

normdoering <nor### [at] yahoocom> wrote:
> What's the difference between a wireframe and a mesh?

  A mesh is a data structure containing vertex vectors, normal vectors and
index triplets which tell which vertices form triangles.
  From the point of view of the user, a mesh is a collection of free
triangles.
  A mesh is an object.

  A wireframe is a way of representing a surface (*any* surface) by using
line drawing.
  A mesh can be drawn easily as a wireframe (by drawing a line for each
edge of each triangle), but that doesn't make wireframes exclusive to
meshes. All surfaces can be represented as a wireframe (it's only a
question of how easy or difficult it is). Many other surfaces can also
be rather easily drawn as wireframes.
  A wireframe is basically an image, a visualization.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

normdoering <nor### [at] yahoocom> wrote:
> 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?

  Have you killfiled me or what?

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

Warp wrote:
>normdoering <nor### [at] yahoocom> wrote:
>> 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?
>
>  Have you killfiled me or what?
>
>#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
>-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -
>

No, I was busy reading shapes.inc
You've been a help -- I'm not blowing you off. I'm just doing several things
at once.
I'm looking at the HF_Square and HF_etc.. macros right now.

Anyone know where I can find examples of calling these functions?


normdoering

Post a reply to this message

Warp wrote:
>normdoering <nor### [at] yahoocom> wrote:
>> What's the difference between a wireframe and a mesh?
>
>  A mesh is a data structure containing vertex vectors, normal vectors and
>index triplets which tell which vertices form triangles.
>  From the point of view of the user, a mesh is a collection of free
>triangles.
>  A mesh is an object.
>
>  A wireframe is a way of representing a surface (*any* surface) by using
>line drawing.
>  A mesh can be drawn easily as a wireframe (by drawing a line for each
>edge of each triangle), but that doesn't make wireframes exclusive to
>meshes. All surfaces can be represented as a wireframe (it's only a
>question of how easy or difficult it is). Many other surfaces can also
>be rather easily drawn as wireframes.
>  A wireframe is basically an image, a visualization.

Thanks for the info.

But I meant something more abstract than mesh or wireframe... that's the
problem I have communicating this idea. When I say "The wireframe (or mesh)
is IN THERE" I don't mean there's a mesh2 file or wireframe there, I mean
the information, the 3D data, must be accessible in some form or else you
couldn't even ray trace it.

I suppose isosurfaces calculate the information on the fly as the image
needs it and doesn't save that information to a swap file or anything like
that (excuse my lack of programming terminology) but it does calculate some
form of 3D information in a way I don't understand and it can use the u,v /
x,y information from an image. The image itself tells you how many vertices
are needed, one for each pixel, the isosurface is calculating some form of
z value based on the greyscale so you must have the information you need to
create a mesh2.

Are there any mesh modelers out there that can do this?

normdoering

Post a reply to this message

Honestly man, I think you need to work with POV-Ray a lot longer so that you
have a real fundamental understanding of how it works before you attempt
whatever it is you're trying to do. I think your understanding of
isosurfaces is too limited for us to explain how to do... whatever it is
you're trying to do.

At the very least, you need a good explanation of how isosurfaces work,
because your explanation of how you think they work holds no similarity to
how they actually do.

 - Slime
[ http://www.slimeland.com/ ]

Post a reply to this message

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

> But I meant something more abstract than mesh or wireframe... that's the
> problem I have communicating this idea. When I say "The wireframe (or mesh)
> is IN THERE" I don't mean there's a mesh2 file or wireframe there, I mean
> the information, the 3D data, must be accessible in some form or else you
> couldn't even ray trace it.

What POV does is calculate the intersection of a ray with the surface. 
That's all it knows about: "this surface intersects this ray at this 
distance along the ray". You could get a mishmash of points on the 
surface that are visible from the camera, but this is not enough 
information to reliably create a wireframe or mesh. There are algorithms 
for analyzing these "point clouds", but there is no perfect way of doing 
it, because some of the information is just lost.


> I suppose isosurfaces calculate the information on the fly as the image
> needs it and doesn't save that information to a swap file or anything like
> that (excuse my lack of programming terminology) but it does calculate some
> form of 3D information in a way I don't understand and it can use the u,v /
> x,y information from an image. The image itself tells you how many vertices
> are needed, one for each pixel, the isosurface is calculating some form of
> z value based on the greyscale so you must have the information you need to
> create a mesh2.

What you describe is a depth buffer. MegaPOV's post_process patch 
allowed output of depth information, or you could fake it with fog or 
textures. I'm pretty sure this isn't what you want, though: it doesn't 
match anything you've said before...all it will do is let you render the 
image and use it as a height field. (either a height_field primitive or 
a macro-generated mesh)

The result will be an object that might looks barely acceptable from one 
direction, if you don't have any shadows, refractions, or reflections to 
give it away and don't change the camera. The first ray intersection 
data alone is pretty much useless, especially for mesh processing. The 
only thing it's really been used for is to control post processing 
filters.


> Are there any mesh modelers out there that can do this?

Not really sure what you want here.

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

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

> Anyone know where I can find examples of calling these functions?

The documentation? The demo files?

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

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

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

So far I've seen you say you want:
Output of isosurface mesh data (originally confusing it with "wireframe" 
rendering). It's been explained that this data doesn't exist, but that 
there is a patch that can generate a mesh approximation of most shapes, 
including the isosurface.

Output of depth information. That's a new one, I answered it in my other 
message. It just isn't very useful.

Reading of PCM files. They are already readable through macros, such a 
third party format designed for the scene language doesn't belong as a 
built in feature.

Some way to distort height fields. The answer is no, use a mesh instead. 
Height fields are intentionally made more specialized and less flexible 
as an optimization, they can be faster than an equivalent mesh. Meshes 
don't have the limitations, and are made for this kind of object.

A way to "blob" meshes together. There are several ways you could do 
this, all of them are complex algorithms that would require lots of 
coding. You aren't asking for a little thing here, your best bet is to 
look at a mesh modeller. Just look at the ones that are available, the 
POV-Ray web site has lots of them listed in the links pages.

And finally, a way to progressively modify a mesh. You probably don't 
need to actually generate the intermediate meshes, you can generate the 
mesh in one step unless you want to add "deformations" that depend on 
other points in the mesh (you haven't described anything like this, only 
using image data to deform the mesh). You've been pointed to the height 
field macros as an example and starting point.

I think you need to decide what you want, it will make answering you 
much less frustrating.

-- 
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.3dcb0056195c50e4a5ab7de50[at]news.povray.org>,
> "normdoering" <nor### [at] yahoocom> wrote:
>
>> Anyone know where I can find examples of calling these functions?
>
>The documentation? The demo files?
>
>Christopher James Huff <cja### [at] earthlinknet>
>http://home.earthlink.net/~cjameshuff/
>POV-Ray TAG: chr### [at] tagpovrayorg
>http://tag.povray.org/
>

No, I found those. I mean using them in creative ways.
Ways I'm not going to think of for awhile.

normdoering

Post a reply to this message

Slime wrote:
>Honestly man, I think you need to work with POV-Ray a lot longer so that you
>have a real fundamental understanding of how it works before you attempt
>whatever it is you're trying to do. I think your understanding of
>isosurfaces is too limited for us to explain how to do... whatever it is
>you're trying to do.
>
>At the very least, you need a good explanation of how isosurfaces work,
>because your explanation of how you think they work holds no similarity to
>how they actually do.
>
> - Slime
>

No, just working with pov doesn't tell you how it's programmed. I'm not
really that interested in how it's programmed. I'm not talking about
patching this myself.

What I really need now is examples of creative use of the HF_ macros. Maybe
someone out there is using those HF_ macros in shapes.inc in a way similar
to what I have in mind? I don't know. But before I reinvent the wheel I'd
like to find out what's been done already.

normdoering

Post a reply to this message

normdoering <nor### [at] yahoocom> wrote:
> No, just working with pov doesn't tell you how it's programmed. I'm not
> really that interested in how it's programmed. I'm not talking about
> patching this myself.

  "Patching" is a term which means modifying the source code of the program
in order to add a feature (or fix a bug or whatever).

  Since what you want to do is doable with the scene description language,
you don't need to patch anything.

> What I really need now is examples of creative use of the HF_ macros. Maybe
> someone out there is using those HF_ macros in shapes.inc in a way similar
> to what I have in mind? I don't know. But before I reinvent the wheel I'd
> like to find out what's been done already.

  Read my answer to your question in the other group. (Your mistake was
simply that the macro wants a function returning a scalar, while you were
trying to give it a function returning a color; this has a very easy solution
which I mentioned there.)

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

normdoering <nor### [at] yahoocom> wrote:
> No, I found those. I mean using them in creative ways.
> Ways I'm not going to think of for awhile.

  You can make your own versions of those macros with more features. But
this requires more or less deep knowledge about the POV-Ray scene description
language, which is can only be achieved with practice and more practice.
It's not something you will learn in 5 minutes.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

Christopher James Huff wrote:
> What POV does is calculate the intersection of a ray with the surface. 
> That's all it knows about: "this surface intersects this ray at this 
> distance along the ray". You could get a mishmash of points on the 
> surface that are visible from the camera, but this is not enough 
> information to reliably create a wireframe or mesh. There are algorithms 
> for analyzing these "point clouds", but there is no perfect way of doing 
> it, because some of the information is just lost.
> 

There are ways to directly render a point cloud, without creating a mesh 
or other surface.

Post a reply to this message

In article <3dcc161e@news.povray.org>, Simon Adameit <gom### [at] gmxde> 
wrote:

> There are ways to directly render a point cloud, without creating a mesh 
> or other surface.

I am aware of that, the simplest is to just draw the points. He hasn't 
asked about anything like that, he specifically asked for mesh or 
"wireframe" output, and seems to believe that having points on the 
surface automatically means you have a mesh. Unless you are going to use 
some kind of volumetric rendering, point clouds can not be raytraced 
without first being processed into a mesh or some other object. This 
processing is difficult, and the resulting surface doesn't always match 
the original very closely. Point cloud data won't be of much help for 
any of the things he has asked about, especially the partial data you 
would get from the first intersections.

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

Warp wrote:
>normdoering <nor### [at] yahoocom> wrote:
>> No, I found those. I mean using them in creative ways.
>> Ways I'm not going to think of for awhile.
>
>  You can make your own versions of those macros with more features. But
>this requires more or less deep knowledge about the POV-Ray scene description
>language, which is can only be achieved with practice and more practice.
>It's not something you will learn in 5 minutes.

Yea, I know -- but thanks for pointing them out to me, everyone. If I hadn't
asked for the "wireframe" feature I would never have known I could get a
macro to read data from a 2D picture and write a mesh2 file.

This feature is, potentially, actually more powerful than what I asked for.
Problem is I'll have to do a lot of very hard macro writing to get what I
want.

Has anyone worked with this feature and webpublished, written similar
macros? More examples would be a help.

normdoering

Post a reply to this message

Christopher James Huff wrote:

> Unless you are going to use 
> some kind of volumetric rendering, point clouds can not be raytraced 
> without first being processed into a mesh or some other object.

Do you consider this to be some kind of volumetric rendering?

http://www.graphics.stanford.edu/~henrik/papers/psp/

Post a reply to this message

Warp wrote:
>normdoering <nor### [at] yahoocom> wrote:
>> No, just working with pov doesn't tell you how it's programmed. I'm not
>> really that interested in how it's programmed. I'm not talking about
>> patching this myself.
>
>  "Patching" is a term which means modifying the source code of the program
>in order to add a feature (or fix a bug or whatever).
>
>  Since what you want to do is doable with the scene description language,
>you don't need to patch anything.
>
>> What I really need now is examples of creative use of the HF_ macros. Maybe
>> someone out there is using those HF_ macros in shapes.inc in a way similar
>> to what I have in mind? I don't know. But before I reinvent the wheel I'd
>> like to find out what's been done already.
>
>  Read my answer to your question in the other group. (Your mistake was
>simply that the macro wants a function returning a scalar, while you were
>trying to give it a function returning a color; this has a very easy solution
>which I mentioned there.)

Thanks, I haven't found your answer yet, but someone else told me about the
vector versur float and conversion and dot operators (which in the
documentation are only mentioned in the isosurface section as far as I
know).

normdoering

Post a reply to this message

normdoering <nor### [at] yahoocom> wrote:
> Has anyone worked with this feature and webpublished, written similar
> macros? More examples would be a help.

  Yes, there are some famous macro sets made by people which handle
meshes. For example the surface subdivision suite (by John VanSickle),
which allows automatically making a mesh more detailed than the original,
as well as the POV-Ray compressed mesh handler macros (by Chris Colefax),
which allow you to make a wide variety of things to meshes, such as
deformations, morphing, hair-growing, etc.

  They can be found at these places:

http://enphilistor.users4.50megs.com/sss.htm
http://www.geocities.com/ccolefax/pcm.html

  (Note that due to the fact that (currently) you can't extract information
from a mesh inside POV-Ray, the meshes have to be converted to a specialized
format called PCM, which these macros can handle. The converter can be
found at the second link above.)

-- 
#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 <3dcc3148@news.povray.org>, Simon Adameit <gom### [at] gmxde> 
wrote:

> Do you consider this to be some kind of volumetric rendering?
> 
> http://www.graphics.stanford.edu/~henrik/papers/psp/

Interesting...somewhat like a blob or isosurface, but not. No more 
foolproof than converting to a mesh, and probably prone to other errors, 
but probably useful for data from real world objects. It has 
restrictions that seem to make the kind of point data being discussed 
here useless. It needs a lot of points, and probably doesn't do well 
with thin areas (where the thickness of the object is close to or lower 
than the distance between points on the same "side", so the nearest 
point can be on the opposite side of the object). The paper says it is 
for extremely high resolution models, especially where triangles are 
smaller than pixels, and a mesh doesn't give any real benefit.

It isn't what I meant by volumetric rendering, but it does require 
sampling a volume...it seems to do "ray marching", stepping along the 
ray until point density goes above a threshold, then using the points 
within a certain distance of that location (though the abstract says 
within a distance to the ray, which doesn't seem to make sense) to 
figure out an approximation of the real distance.

That is a very interesting paper, I'm going to have a try at 
implementing that object...need to get some papers of my own written 
first, though. Homework...bleh.

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

Warp wrote:
>normdoering <nor### [at] yahoocom> wrote:
>> Has anyone worked with this feature and webpublished, written similar
>> macros? More examples would be a help.
>
>  Yes, there are some famous macro sets made by people which handle
>meshes. For example the surface subdivision suite (by John VanSickle),
>which allows automatically making a mesh more detailed than the original,
>as well as the POV-Ray compressed mesh handler macros (by Chris Colefax),
>which allow you to make a wide variety of things to meshes, such as
>deformations, morphing, hair-growing, etc.
>
>  They can be found at these places:
>
>http://enphilistor.users4.50megs.com/sss.htm
>http://www.geocities.com/ccolefax/pcm.html
>
>  (Note that due to the fact that (currently) you can't extract information
>from a mesh inside POV-Ray, the meshes have to be converted to a specialized
>format called PCM, which these macros can handle. The converter can be
>found at the second link above.)
>
>#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
>-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -
>

Thanks for your help. I was familiar with the compressed mesh, but the
surface subdivision stuff by John VanSickle is new to me. It sounds like
one I could learn a lot from.

If you're interested I'm going to move this HF_ macro talk to either
tutorials or advanced user area (maybe they need a special group for macros
here?) when I really get kicking on my macro writing (no doubt it will give
me lots of questions) and I'll share what I'm working on.

As noted before, this is no longer about patching. Only patching I want now
is a way to speed of the process... parsing takes forever when you use a
lot of resolution on the mesh.

Maybe complining macros so they run faster? I'm sure that's been discussed
before.

--normdoering

Post a reply to this message