stbenge <UN### [at] hotmailcom> wrote:
> Those other ones were quite buggy. Odd numbers wouldn't work, the
> function for testing the control pigment wasn't accurate, and the thing
> was not filling a unit cube correctly.
>
> While testing this, also I realized that the more it stretches a
> height_field, the slower it becomes. I wish I could make it more
> efficient somehow.

Hi Samuel

I had a look at your macro to see if I could make it more efficient.
Here's what I came up with:


#macro SliceHF(HeightField, ControlPigment, NrOfSlices)

  #local Step = 1/NrOfSlices;
  #local M_Fn = function { pigment { ControlPigment } }
  #local N_Fn = function(_C) { M_Fn(0, _C*Step, 0).gray }

  union {
    #local Cn = 0;
    #local Dn = N_Fn(Cn);
    #while (Cn < NrOfSlices)
      #local Cp = Cn;
      #local Cn = Cn + 1;
      #local Dp = Dn;
      #local Dn = N_Fn(Cn);
      #if (Dn != Dp)
        intersection {
          object { HeightField }
          box { <0, Dp, 0>, <1, Dn, 1> }
          translate -Dp*y
          scale <1, Step/(Dn - Dp), 1>
          translate Cp*Step*y
        }
      #end // if
    #end // while
  }

#end // macro SliceHF


But I'm not sure if it still works like you intended.

--
Tor Olav
http://subcube.com

Post a reply to this message

Tor Olav Kristensen wrote:
> stbenge <UN### [at] hotmailcom> wrote:
>> Those other ones were quite buggy. Odd numbers wouldn't work, the
>> function for testing the control pigment wasn't accurate, and the thing
>> was not filling a unit cube correctly.
>>
>> While testing this, also I realized that the more it stretches a
>> height_field, the slower it becomes. I wish I could make it more
>> efficient somehow.
> 
> Hi Samuel
> 
> 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.

With the changes you made, it might be actually be advantageous to use 
this instead of an isosurface for some things.

Thanks! If I release another version of hf_tools.inc, I'll include your 
version and give you proper credit :)

Post a reply to this message

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

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.

Your slicing method shows GREAT promise, so by all means continue with its
development. I foresee *many* uses for your technique.

Ken

Post a reply to this message

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

>
> 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

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

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

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

> 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

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