POV-Ray : Newsgroups : povray.binaries.images : rendering height fields with overhangs Server Time
22 Jun 2024 22:57:56 EDT (-0400)
  rendering height fields with overhangs (Message 11 to 17 of 17)  
<<< Previous 10 Messages Goto Initial 10 Messages
From: Kenneth
Subject: Re: a less buggy hf_slicer
Date: 19 Dec 2009 15:50:00
Message: <web.4b2d3b2d5f6b9df665f302820@news.povray.org>
stbenge <UN### [at] hotmailcom> wrote:

> > [Tor Olav wrote:]
> > I had a look at your macro to see if I could make it more efficient.
> > Here's what I came up with:
> >
> > But I'm not sure if it still works like you intended.
>
> It seems to work better than my versions.
>

I just did an A/B test of your 3rd version with Tor's reworked version, and the
first thing I noticed in Tor's was some coincident-surface speckling of the HF
base--NOT related to the plane (I moved that out of the way.) Perhaps there are
some duplicate slices at the base? (Just a guess.)

Also, with your version, water_level can be used in the HF to erase the base (or
any part of the HF.)  In Tor's version, water_level doesn't behave normally, and
instead produces some odd results (a square block shows up below the
water_level.)  Just thought I'd mention these differences.

Keep those developments coming!!

Ken


Post a reply to this message

From: Alain
Subject: Re: rendering height fields with overhangs
Date: 19 Dec 2009 15:57:04
Message: <4b2d3e20$1@news.povray.org>

>
> BTW, a question about one of your #while loop lines:
> hfs_pv=hfs_function(0,hfs_V,0).x
>
> Any particular reason why you used .x (i.e., .red) rather than .gray?  Just
> curious.
>
> Ken
>
>

If all 3 colour chanels are the same, it's faster and gives the same result.
Using ".x", you only access one value.
Using ".gray" you need to access all 3 chanels, then you perform a 
ponderated average.


Alain


Post a reply to this message

From: Kenneth
Subject: Re: rendering height fields with overhangs
Date: 19 Dec 2009 16:20:01
Message: <web.4b2d4324ce3532365f302820@news.povray.org>
Alain <aze### [at] qwertyorg> wrote:


> > Any particular reason why you used .x (i.e., .red) rather than .gray?  Just
> > curious.

>
> If all 3 colour chanels are the same, it's faster and gives the same result.
> Using ".x", you only access one value.
> Using ".gray" you need to access all 3 chanels, then you perform a
> ponderated average.
>
Thanks, Alain. I never thought about that, when using a grayscale image to begin
with.

Ken


Post a reply to this message

From: Kenneth
Subject: Re: rendering height fields with overhangs
Date: 19 Dec 2009 16:35:00
Message: <web.4b2d44acce3532365f302820@news.povray.org>
Alain <aze### [at] qwertyorg> wrote:


> If all 3 colour chanels are the same, it's faster and gives the same result.

Going back over sbenge's code, I see that his version uses a pigment for the
function (i.e., rgb colors)--which might benefit from .gray (if we happen to use
something other than grayscale 'bumps' as the pigment pattern); whereas Tor's
code *does* use .gray for all pigments. BUT, I assume that bumps as a PIGMENT
(rather than as a PATTERN) has three color channels internally? All three the
same, of course. In which case, .red would make sense.

Ken


Post a reply to this message

From: stbenge
Subject: Re: rendering height fields with overhangs
Date: 20 Dec 2009 00:07:11
Message: <4b2db0ff@news.povray.org>
Kenneth wrote:
> stbenge <UN### [at] hotmailcom> wrote:
>> Hello,
>>
>> Here's a method for slicing a height_field into many pieces and
>> translating/scaling the parts to create caves and overhangs. It renders
>> faster than an isosurface...
> 
> Once again, you've come up with some magical sleight-of-hand! (Your POV code
> creations are coming so fast, I can't keep up with them!) I was hoping someone
> might come up with a method for producing HFs with overhangs. Kudos to you!
> 
> Results so far just astound me; it's one amazing tool. (I haven't yet tried Tor
> Olav's version; just noticed it.) In the short time I've been playing with your
> version #3 code, there seem to be endless shapes it can produce (by varying this
> or that parameter.)  Yeah, I'm experimenting with some of your code, adding
> things here and there, doing everything I can to break it (!) just to see what
> will happen--then putting it back together, of course. :-) I continue to
> 'examine' the code to see how it operates, and what exactly it does. Seems like
> voodoo at present.  :-p

Thanks.

It was a good idea, executed poorly. Tor's version is faster and more 
accurate. If I end up making a scene with this, I'll be using his version :)


Post a reply to this message

From: Alain
Subject: Re: rendering height fields with overhangs
Date: 20 Dec 2009 11:44:27
Message: <4b2e546b@news.povray.org>

> Alain<aze### [at] qwertyorg>  wrote:

>
>> If all 3 colour chanels are the same, it's faster and gives the same result.
>
> Going back over sbenge's code, I see that his version uses a pigment for the
> function (i.e., rgb colors)--which might benefit from .gray (if we happen to use
> something other than grayscale 'bumps' as the pigment pattern); whereas Tor's
> code *does* use .gray for all pigments. BUT, I assume that bumps as a PIGMENT
> (rather than as a PATTERN) has three color channels internally? All three the
> same, of course. In which case, .red would make sense.
>
> Ken
>
>

If you use the bozo, wood or agate pigment, you need to use .gray. Those 
use a default colour map that have colours other than gray.

For all other pigments, .red, .green or .blue are OK as they use a gray 
scale by default.

Alain


Post a reply to this message

From: Sven Littkowski
Subject: Re: rendering height fields with overhangs
Date: 16 Jan 2010 20:59:19
Message: <4b526ef7@news.povray.org>
Something here reminds me for the flying mountains of Pandora ("Avatar" 
movie)...

Good idea, your way to create over-hangs.

Sven


Post a reply to this message

<<< Previous 10 Messages Goto Initial 10 Messages

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