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