POV-Ray : Newsgroups : povray.unofficial.patches : Simulated surface scanning. Server Time
2 Nov 2024 09:20:12 EDT (-0400)
  Simulated surface scanning. (Message 1 to 6 of 6)  
From: Charles Fusner
Subject: Simulated surface scanning.
Date: 9 Jan 2000 16:31:56
Message: <3878FD34.DB90D806@enter.net>
This is just an idea I happened to think while working on a macro 
that places "sweat beads" on user specified objects (glasses, mugs,
bottles, etc), and sort of inspired by something Warp said about
how simple the Raw triangle format was, and how a macro might be
written to convert PCM to Raw files, and the two thoughts sort of
re-combined into something completely different.

Anyway, I was thinking, wouldn't it be theoretically possible,
using trace(), a while loop, and file i/o to "scan" user 
specified objects like a 3D scanner does and produce mesh
output in some common format like Raw or PCM that could, in
turn be further manipulated, or converted into other file
formats? 

Why? Well, how many times on these groups or c.g.r.r. has it
been asked whether there were programs to convert POV into 
any other formats? Usually the answer is no, partly because
not all POV geometric prims are easily tesselated (take 
quartics, isosurfaces, or julia fractals for example), but
mostly because of the complexity of the POV language and
the inherant difficulty in parsing routines that do not 
simply use the POV source, but are nevertheless up to date 
with the latest syntax. 

By letting POV itself perform the tesselation in a simulated
3D scan of a virtual object, both problems are obviated. POV
can already parse its own scene code, and no matter what new
objects are added, always will be able to. Complex objects
might require rediculously dense meshes (a mesh density 
parameter to the scan routine would be essential), but in
theory, shouldn't it be possible to convert just about anything
using this method?

I have a vague idea how one might go about the process, but
it's merely an intuitive guess, and with no formal knowledge of
3D scanning techniques, I'm probably hopelessly off base, and
am currently working four separate projects at once (again!
arg! When will I learn?) already, so I submit this idea to the
gathering such that if anyone else has the requisite knowledge
and finds it a worthwhile project, perhaps such a macro or 
macros will find there way into POV users toolboxes someday.

Crazy ideas by:
Charles


Post a reply to this message

From: Nieminen Juha
Subject: Re: Simulated surface scanning.
Date: 10 Jan 2000 08:52:46
Message: <3879e42e@news.povray.org>
This is a very clever idea.
  However, it will only work for certain locations of the camera. You can't
tesselate complicated objects with this trace() method, only parts that are
visible from certain places.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/


Post a reply to this message

From: Ron Parker
Subject: Re: Simulated surface scanning.
Date: 10 Jan 2000 10:27:54
Message: <3879fa7a@news.povray.org>
On 10 Jan 2000 08:52:46 -0500, Nieminen Juha wrote:
>  This is a very clever idea.
>  However, it will only work for certain locations of the camera. You can't
>tesselate complicated objects with this trace() method, only parts that are
>visible from certain places.

Not true; you can always trace again after you find the first intersection to
find more.  But the real problem is that it's not really all that easy to turn
a collection of sample points into an unambiguous mesh; many papers have been
written on the topic, and many more will be written before it's considered 
"solved."

-- 
These are my opinions.  I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html


Post a reply to this message

From: Charles Fusner
Subject: Re: Simulated surface scanning.
Date: 10 Jan 2000 21:35:55
Message: <387A9717.5DE48F6A@enter.net>
Ah, I had a feeling it wasn't as simple as it sounded at first
consideration. Might be a good low priority background project
to experiment with, if I get some time, but I see what you mean:
it might be a lot more limited that I initially imagined. Oh
well, worth mentioning I suppose. Perhaps someday it'll amount
to something.

Charles


Post a reply to this message

From: Ken
Subject: Re: Simulated surface scanning.
Date: 10 Jan 2000 21:39:20
Message: <387A9872.F4A2330E@pacbell.net>
Charles Fusner wrote:
> 
> Ah, I had a feeling it wasn't as simple as it sounded at first
> consideration. Might be a good low priority background project
> to experiment with, if I get some time, but I see what you mean:
> it might be a lot more limited that I initially imagined. Oh
> well, worth mentioning I suppose. Perhaps someday it'll amount
> to something.
> 
> Charles

Keep trying Charles. That was one of the most refreshing ideas I have
heard since Nathan introduced photon mapping.

-- 
Ken Tyler -  1300+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/


Post a reply to this message

From: Margus Ramst
Subject: Re: Simulated surface scanning.
Date: 12 Jan 2000 18:57:56
Message: <387D157D.BDBFB10@peak.edu.ee>
I have thought about doing this. I already have done a few different sampling
macros. But these just generate point clouds. You can't regenerate the surface
from a point cloud; additional information is needed.
There are several methods for tessellating objects, such as marching cubes and
marching triangles.

What I've been thinking about is a method similar to marching cubes, where the
volume of the object is split into small boxes and intersections within each box
are sampled (from the centre of the box towards the corners). The pattern of
intersections should then theoretically give an approximation of the surface
passing through the sample box.
I see mainly 2 problems here:
There may be multiple intersections along a sampling interval, whereupon
sampling must be refined (recursively or otherwise).
Secondly, even simple point cloud generation is very slow in POV script, if any
level of precision is required. Tessellation would be worse.

Margus

Charles Fusner wrote:
> 
> 
> Anyway, I was thinking, wouldn't it be theoretically possible,
> using trace(), a while loop, and file i/o to "scan" user
> specified objects like a 3D scanner does and produce mesh
> output in some common format like Raw or PCM that could, in
> turn be further manipulated, or converted into other file
> formats?
>


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.