Hello all.  I just wanted your feedback on something.  To my understanding,
you can't use objects like triangle meshes or bicubic patch models in CSG
differences or intersections (correct me if I'm wrong.. I know that in later
releases of the program there will be solid triangle meshes that will be
able to do this).  However, you can use heightfields (again... correct me).
Would it be possible to render an image of a complex object in a gradient z
of white and black, then convert the rendered image into a heightfield that
could be used any old way that you wanted?  In short, could you make a
reasonable representation of an already created object using a heightfield?
You could even use your old textures if you used your old image as an
image_map on the new heightfield (make the background color around the
object GIF transparent, then map it onto the heightfield).  You could make a
whole object by then moving the camera behind the black and white object and
making a second heightfield.  Of course it would be better if you used an
ortho perspective, as the camera perspective would throw off your finished
heightfield model.  I don't know if all of this makes sense, or if it would
even be useful to anyone, but the idea popped into my head and I was
wondering if it would actually work.  Basically it amounts to converting any
POV object (even CSG) into two images that would become a heightfield.  Just
curious.  Thanks.

--
Stephen Bell
http://students.oc.edu/stephen.bell

Post a reply to this message

In article <3a9d7d1a@news.povray.org>, "Stephen Bell" 
<ste### [at] yahoocom> wrote:

> Would it be possible to render an image of a complex object in a 
> gradient z of white and black, then convert the rendered image into a 
> heightfield that could be used any old way that you wanted?  In 
> short, could you make a reasonable representation of an already 
> created object using a heightfield?

It is possible, with some restrictions. For example, you obviously will 
only get one side of the object, and will miss parts of complex objects 
even if you use two height fields back-to-back. You can get the depth 
image in many ways...use a black-white gradient texture, make everything 
white and use a black fog, or just render it in MegaPOV and use the 
"depth" post_process to retrieve the depth information. Also, the 
resolution of the object will suffer, and there will probably be some 
artifacts...
If mesh objects are fine, you could use MegaPOV, which *can* use meshes 
in difference and intersection.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Chris Huff <chr### [at] maccom> wrote:
: Also, the resolution of the object will suffer

  If this is a problem, then outputting to a 48-bit png can help a lot
(you get basically 65536 depth values instead of the usual 256).

-- 
char*i="b[7FK@`3NB6>B:b3O6>:B:b3O6><`3:;8:6f733:>::b?7B>:>^B>C73;S1";
main(_,c,m){for(m=32;c=*i++-49;c&m?puts(""):m)for(_=(
c/4)&7;putchar(m),_--?m:(_=(1<<(c&3))-1,(m^=3)&3););}    /*- Warp -*/

Post a reply to this message

In article <3a9e2cf2@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   If this is a problem, then outputting to a 48-bit png can help a lot
> (you get basically 65536 depth values instead of the usual 256).

Why not a TGA or ordinary 24-bit PNG with hf_gray_16 enabled?

There should be a high-precision grayscale format somewhere out 
there...it'd be nice to store large height fields without the wasted 
space.

But anyway, there may still be problems with resolution...areas with a 
high slope will get fewer triangles, and you may have trouble getting 
them smooth. And holes inside the object or through the sides will not 
work correctly. An intersection of several height fields may help some 
of this, but will get slower and more memory consuming...the best option 
is to simply convert it to a mesh and use MegaPOV.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Chris Huff wrote:
> 
> There should be a high-precision grayscale format somewhere out
> there...it'd be nice to store large height fields without the wasted
> space.
> 

What's wrong about 16 bit greyscale png?
Just use hf_gray_16 and +fn16.

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

In article <3A9E3534.E9A9254F@gmx.de>, Christoph Hormann 
<chr### [at] gmxde> wrote:

> What's wrong about 16 bit greyscale png?
> Just use hf_gray_16 and +fn16.

I'm thinking more of 32-bit (single-precision float). 16-bit gives you 
65536 levels, though, which should be enough for practically 
anything...if you have a 5000 foot tall mountain, the smallest change in 
height you can represent will be about an inch, and you could use a 
"local" height field if you need more precision. (unless I've made an 
error in my calculations...)

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Chris Huff wrote:
> 
> I'm thinking more of 32-bit (single-precision float). 16-bit gives you
> 65536 levels, though, which should be enough for practically
> anything...if you have a 5000 foot tall mountain, the smallest change in
> height you can represent will be about an inch, and you could use a
> "local" height field if you need more precision. (unless I've made an
> error in my calculations...)
> 

Sounds correct, 
there is a 32 bit floating point format supported by HF-Lab/gforge, but i
don't know how universal it is.

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

Chris Huff <chr### [at] maccom> wrote:
: Why not a TGA or ordinary 24-bit PNG with hf_gray_16 enabled?

  Because if you ever want to modify the created image with a painting
program, it would be quite difficult?
  AFAIK the 24-bit hf_gray_16 is more like a hack.

-- 
char*i="b[7FK@`3NB6>B:b3O6>:B:b3O6><`3:;8:6f733:>::b?7B>:>^B>C73;S1";
main(_,c,m){for(m=32;c=*i++-49;c&m?puts(""):m)for(_=(
c/4)&7;putchar(m),_--?m:(_=(1<<(c&3))-1,(m^=3)&3););}    /*- Warp -*/

Post a reply to this message

On 1 Mar 2001 06:05:22 -0500, Warp wrote:
>Chris Huff <chr### [at] maccom> wrote:
>: Also, the resolution of the object will suffer
>
>  If this is a problem, then outputting to a 48-bit png can help a lot
>(you get basically 65536 depth values instead of the usual 256).

If you use global_settings{hf_gray_16} and put +fn16 on the command line, 
POV will output a 16-bit grayscale PNG, which is slightly smaller than the 
equivalent 48-bit RGB or 64-bit RGBA file.  3.5 will assume that you wanted
a 16-bit grayscale PNG if you specify hf_gray_16, even if you had +fn8 or
a bare +fn on the command line.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message