"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Fractracer" <lg.### [at] gmailcom> wrote:
>
> > Yes, a lot of. I have made a debug file to see the values output by
> > asin(2.*_x/_l-1.0) // in the #while (_x<=_l-_xp) loop drawing spheres and
> > cylinders for the barbs //. SOme of this values are > to 1.5 (when _x = 0). > In
fact the errors appears at the sta
rt and at the end of the loop. Maybe easy   > to fix, I will see this this evening.

Oops! I'm stupid! Working too fast, not enough time, not thinking... And I got
the output of asin rather than the input of asin...

> I noticed that it was just a string of errors in two lines of the code.
> That's where the cylinders are generated.
> And it's only in the second calculation where (_x+_xp) is used
> I just did a quick
> #declare _X = (2.*(_x+_xp)/_l-1.0);
> and then did 2 sequential #if statements to check if <-1 or >1, and then set
> it > to -1 or 1 to eliminate out-of-bounds values.
> That got rid of all the errors.

Maybe one #if statement can make the job, with #if (abs(_X) <= 1)

> There might be a more elegant faster way with select(), but it was getting late.
Time, O time...

> Modeling a bald eagle - with 7000 feathers - wouldn't be possible.
> Perhaps one of the things to look at is adjusting the number of steps in the
> loop to get a feather with fewer primitives.
> Of course, somehow generating a mesh that could be instantiated would be
> pretty great as well.

Since the loop is based on _x, it is possible to get this value and store it in
an array for a sphere_sweep or a mesh.


> Another common coloration is a slightly different color going up the edge of
> one side of the feather.

No problems, I just have to define another texture. I wrote a test in the top of
the macro:
#ifndef(tx_feather)
#declare Texture_all = 0;
#end

Another in the sphere and cylinder
#if (Texture_all = 0)
then the original pigment is applied.

And in the end of the union block for the two sides:
#if (Texture_all = 1)
texture {tx_feather}
#end

> There also seems to be some unnecessary calculations, and "magic numbers" - it
> would be great to simplify a lot of that, move the equations out into some
> descriptive #declare or #local statements, and then use those meaningful
> variable names in the calculations so that it's easier to follow what's going
> on.

Right. More visibility help to better understand.


> ― Robert A. Heinlein
> Hope you have a great day  :)

Thank you, you too.

Post a reply to this message