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