"Bald Eagle" <cre### [at] netscapenet> wrote:

> Also - just thought you might be interested in what I did with a propeller -
> seems similar to making a feather...
>
Indeed, I am no using spline for the moment, just maths functions (cos, sin, and
a little random) and sphere_sweep to draw the rachis and barbs. I will use
spline for the shape of the vane.

Post a reply to this message

"Fractracer" <lg.### [at] gmailcom> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
>
> > Also - just thought you might be interested in what I did with a propeller -
> > seems similar to making a feather...
> >
> Indeed, I am no using spline for the moment, just maths functions (cos, sin, and
> a little random) and sphere_sweep to draw the rachis and barbs. I will use
> spline for the shape of the vane.

So, I couldn't find a personal copy anywhere, but Wheee!  The Wayback Machine
had one  :)

https://web.archive.org/web/20050413175956/http://baillp.free.fr:80/Data/feather.inc

Here's some quick code to get you started:

#version 3.71;

global_settings {
 assumed_gamma 1.0
}

#declare Aspect = image_width/image_height;
camera {
 location <0, 0, -2>
 right x*Aspect
 look_at <0, 0, 0>
}

#include "colors.inc"
#include "feather.inc"

light_source { <10, 50, 0>  color rgb <1, 1, 1>}

#declare _seed = 123;
#declare _seedcolor = 345;
#declare _length = 1;
#declare _width = 0.25;
#declare _depth = 0.01;
#declare _sym = 0.9;
#declare _fun = 0.8;
#declare _test = false;

object {Feather(_seed, _seedcolor, _length, _width, _depth, _sym, _fun, _test)}

Post a reply to this message

On 14-11-2017 18:51, Bald Eagle wrote:
> "Fractracer" <lg.### [at] gmailcom> wrote:
> 
>> Working also on a feather's macro.
> 
> IIRC, I found a great little feather macro a few years ago.
> I can't seem to find it online, but I can check on my laptop at home.
> 
> Unless anyone else is familiar with it, and has a link or archive copy.
> 
> <cough> <sotto voce> (Thomas) </sotto voce> <cough>
> 

Unfortunately...

-- 
Thomas

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> 
https://web.archive.org/web/20050413175956/http://baillp.free.fr:80/Data/feather.inc


Just a loop to show some variation.
Looks like _sym and _fun need to be kept between 0 and 1.
There may be some other refinements needed to get rid of some domain error in
asin and divide by zero errors, but if you look through Mr. Baillehache's code,
it's quite --- intricate.

[Side note:  it seems he moved to Japan and just kept on runnin' with that math
thing....
http://www.bayashiinjapan.net/CollisionDetection/3dCollisionDetectionFourierMotzkin.pdf
]


---------------------------------- test scene -------------------------

#version 3.71;

global_settings {
 assumed_gamma 1.0
}

#declare Aspect = image_width/image_height;
camera {
 location <0, 1, -10>
 right x*Aspect
 look_at <0, 1, 0>
}

#include "colors.inc"
#include "feather.inc"

light_source { <10, 50, 0>  color rgb <1, 1, 1>}

#declare _Seed = 10;
#declare _Seedcolor = 20;
#declare _length = 2;
#declare _width = 0.25;
#declare _depth = 0.01;
#declare _Sym = 0.1;
#declare _Fun = 0.05;
#declare _test = false;


#for (F, 1, 10)
 #declare _seed = _Seed * F;
 #declare _seedcolor = _Seedcolor * F;
 #declare _sym = _Sym + F*0.08;
 #declare _fun = _Fun + F*0.08;
 object {Feather(_seed, _seedcolor, _length, _width, _depth, _sym, _fun, _test)
translate <-5+F, 0, 0>}
#end

Post a reply to this message

Attachments:
Download 'feather.png' (39 KB)

Preview of image 'feather.png'

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> > 
https://web.archive.org/web/20050413175956/http://baillp.free.fr:80/Data/feather.inc
>
>
> Just a loop to show some variation.
> Looks like _sym and _fun need to be kept between 0 and 1.
> There may be some other refinements needed to get rid of some domain error in
> asin and divide by zero errors, but if you look through Mr. Baillehache's code,
> it's quite --- intricate.
>

Who better than an eagle could help me for the feathers ;)
Thank you for your help, I have a quick look at the code, complicated, but whith
tima and patience I think I can adapt or modified the code, maybe using
sphere_sweep for a curved rachis...
Also I will add the possibility of changing the textures (easy).

Post a reply to this message

"Fractracer" <lg.### [at] gmailcom> wrote:

> Who better than an eagle could help me for the feathers ;)
Ha!  It often gets amusing around here.
I still remember your help with circumscribing spheres around triangles  :)
I might want to try a variation of that using geometric inversion...

> Thank you for your help, I have a quick look at the code, complicated, but whith
> tima and patience I think I can adapt or modified the code, maybe using
> sphere_sweep for a curved rachis...

I've had a chance to edit it for clarity, and I added 2 (crude) blocks of code
to restrict the asin argument to between -1 and 1.  As I'm sure you've noticed
it throws a "domain error in asin" error - probably due to small rounding
errors.
Maybe soon I'll decipher the meaning and function of the calculations - it seems
at first glance to be some repetitive sphere-cylinder sweeps that move up and
then down the rachis.
I think the rachis could be redefined with a spline or array, and then the rest
of code could be adjusted to make the rest of the feather using those variable
points rather than a fixed x-coordinate.

It looks like _sym probably needs to be limited to between 0 and 1 (I haven't
extensively tested this yet)
but _fun is a variable that is used to calculate a probability which seems to
control the appearance of imperfections - the peeling and separation.  I've only
varied that from 0.5 to 1.3 in my last test, and it was fine.

> Also I will add the possibility of changing the textures (easy).

Yes, I was wondering how to get something other than a banded pattern, and more
of a realistic pattern.  Possibly as another parameter for the macro so that the
pattern can be defined in the scene and passed to the macro.

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.

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:

> I've had a chance to edit it for clarity, and I added 2 (crude) blocks of code
> to restrict the asin argument to between -1 and 1.  As I'm sure you've noticed
> it throws a "domain error in asin" error - probably due to small rounding
> errors.

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 start and at the end of the loop. Maybe easy to
fix, I will see this this evening.

> Maybe soon I'll decipher the meaning and function of the calculations - it
> seems at first glance to be some repetitive sphere-cylinder sweeps that move
> up and then down the rachis.

You're right, the cylinders are drawn in x plane, it is the cause of the colored
gradient of the feather.

> I think the rachis could be redefined with a spline or array, and then the
> rest of code could be adjusted to make the rest of the feather using those
> variable points rather than a fixed x-coordinate.

The barbs may also made with sphere_sweep (like on my previous picture), but
this need a lot of objects to obtain a tighten feather.

> It looks like _sym probably needs to be limited to between 0 and 1 (I haven't
> extensively tested this yet) but _fun is a variable that is used to calculate > a
probability which seems to control 
the appearance of imperfections - the
> peeling and separation.  I've only varied that from 0.5 to 1.3 in my last
> test, and it was fine.

Unless we want some extravagant feather...

> Yes, I was wondering how to get something other than a banded pattern, and
> more of a realistic pattern.  Possibly as another parameter for the macro so
> that the pattern can be defined in the scene and passed to the macro.
>
See the picture, I made it fast...

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

Some cleaning...
Two brains are better than one.

Post a reply to this message

Attachments:
Download 'feather1.png' (435 KB)

Preview of image 'feather1.png'

"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 start and at the end of the loop. Maybe easy to
> fix, I will see this this evening.

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.

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



> The barbs may also made with sphere_sweep (like on my previous picture), but
> this need a lot of objects to obtain a tighten feather.

Right - as it is, these feathers take up a lot of memory.  The 10 feathers I'm
testing with gobble [sic] up >700 MB.  :O

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.


> > Yes, I was wondering how to get something other than a banded pattern, and
> > more of a realistic pattern.  Possibly as another parameter for the macro so
> > that the pattern can be defined in the scene and passed to the macro.
> >
> See the picture, I made it fast...

Excellent - I'm glad it's that easy.
Another common coloration is a slightly different color going up the edge of one
side of the feather.


> > 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.
>
> Some cleaning...
> Two brains are better than one.

We hope   ;)


― Robert A. Heinlein


Hope you have a great day  :)

Post a reply to this message

"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

"Fractracer" <lg.### [at] gmailcom> wrote:

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

yes, excellent.
I'll replace my kludge tonight with:

#if (abs(_X) <= 1)
     #declare _X = sgn(_X);
#end

Post a reply to this message