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