AM
Adrian Mariano
Tue, Jul 12, 2022 12:42 AM
I believe the twist deforms the belt teeth (by shear). You may want to
focus on what you really want the belt to do and start simpler and then
move towards more complex. The example is a little silly, since you
wouldn't want a belt to turn inside-out.
On Mon, Jul 11, 2022 at 8:35 PM mikeonenine@web.de wrote:
Adrian Mariano wrote:
I am not sure what you mean when asking "are the examples so new". The
BOSL2 library itself requires the latest stable OpenSCAD version,
A beautiful tree and no error messages. 2021.01 did the trick, thanks for
the tip.
The belt looks interesting, the twist could be useful. Will try to
re-engineer the code to my requirements, but hope I will not find myself
out of my depth. I only need it for one project, but maybe I can learn
something.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
I believe the twist deforms the belt teeth (by shear). You may want to
focus on what you really want the belt to do and start simpler and then
move towards more complex. The example is a little silly, since you
wouldn't want a belt to turn inside-out.
On Mon, Jul 11, 2022 at 8:35 PM <mikeonenine@web.de> wrote:
> Adrian Mariano wrote:
>
> I am not sure what you mean when asking "are the examples so new". The
> BOSL2 library itself requires the latest stable OpenSCAD version,
>
> A beautiful tree and no error messages. 2021.01 did the trick, thanks for
> the tip.
>
> The belt looks interesting, the twist could be useful. Will try to
> re-engineer the code to my requirements, but hope I will not find myself
> out of my depth. I only need it for one project, but maybe I can learn
> something.
>
>
>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
>
M
mikeonenine@web.de
Tue, Jul 12, 2022 2:07 AM
I believe the twist deforms the belt teeth (by shear). You may want to
focus on what you really want the belt to do and start simpler and then
move towards more complex. The example is a little silly, since you
wouldn't want a belt to turn inside-out.
True, but twist is acceptable if the belt is long enough.
The example is not so silly if the straight runs cross over as per my attempt (animation) earlier in this thread - then both ends are the right way round. It is not ideal for the straight runs to rub against each other in the middle, even if only back-to-back, but OK in a low-power (hand-operated) application.
What I am after ultimately is a better version of that animation that can be combined with other moving parts in a way that makes sense. But OpenSCAD has limits on what can be done with animation anyway. In the animation I did, all the teeth only move back and forth one position (slow forward, instantaneous back) giving the illusion of continuous motion. Also only the straight runs are actual “belt”. The curved sections are only stationary black semicircles behind the cogs.
What I imagine is required is some kind of flexible polygon, or a means of sending each belt tooth around a defined path. The speeds of the belt and the cogs obviously need to reflect the number of teeth on each. The more I think about it and the more I look at the Toothed belt.scad code, the more I think it can’t be done, unfortunately.
Adrian Mariano wrote:
> I believe the twist deforms the belt teeth (by shear). You may want to
> focus on what you really want the belt to do and start simpler and then
> move towards more complex. The example is a little silly, since you
> wouldn't want a belt to turn inside-out.
True, but twist is acceptable if the belt is long enough.
The example is not so silly if the straight runs cross over as per my attempt (animation) earlier in this thread - then both ends are the right way round. It is not ideal for the straight runs to rub against each other in the middle, even if only back-to-back, but OK in a low-power (hand-operated) application.
What I am after ultimately is a better version of that animation that can be combined with other moving parts in a way that makes sense. But OpenSCAD has limits on what can be done with animation anyway. In the animation I did, all the teeth only move back and forth one position (slow forward, instantaneous back) giving the illusion of continuous motion. Also only the straight runs are actual “belt”. The curved sections are only stationary black semicircles behind the cogs.
What I imagine is required is some kind of flexible polygon, or a means of sending each belt tooth around a defined path. The speeds of the belt and the cogs obviously need to reflect the number of teeth on each. The more I think about it and the more I look at the Toothed belt.scad code, the more I think it can’t be done, unfortunately.
AM
Adrian Mariano
Tue, Jul 12, 2022 2:46 AM
It's not that the belt twists but that the teeth themselves deform
into a shear-transformed shape. Actual twist of a real belt
presumably twists only the belt and not the teeth.
Your requirements seem fairly simple, so I'm not sure why you think it
can't be done. Very complicated things can be done, and a belt is
not really particularly complicated. The existing belt is already
set up for animation, with steps 4. It doesn't go very fast. The
notion of "sending the teeth along a path" is really exactly what's
going on right now. Notice how beltpath is computed and then used to
compute the belt, with the teeth offset controlled by $t.
On Mon, Jul 11, 2022 at 10:08 PM mikeonenine@web.de wrote:
Adrian Mariano wrote:
I believe the twist deforms the belt teeth (by shear). You may want to focus on what you really want the belt to do and start simpler and then move towards more complex. The example is a little silly, since you wouldn't want a belt to turn inside-out.
True, but twist is acceptable if the belt is long enough.
The example is not so silly if the straight runs cross over as per my attempt (animation) earlier in this thread - then both ends are the right way round. It is not ideal for the straight runs to rub against each other in the middle, even if only back-to-back, but OK in a low-power (hand-operated) application.
What I am after ultimately is a better version of that animation that can be combined with other moving parts in a way that makes sense. But OpenSCAD has limits on what can be done with animation anyway. In the animation I did, all the teeth only move back and forth one position (slow forward, instantaneous back) giving the illusion of continuous motion. Also only the straight runs are actual “belt”. The curved sections are only stationary black semicircles behind the cogs.
What I imagine is required is some kind of flexible polygon, or a means of sending each belt tooth around a defined path. The speeds of the belt and the cogs obviously need to reflect the number of teeth on each. The more I think about it and the more I look at the Toothed belt.scad code, the more I think it can’t be done, unfortunately.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
It's not that the belt twists but that the teeth themselves deform
into a shear-transformed shape. Actual twist of a real belt
presumably twists only the belt and not the teeth.
Your requirements seem fairly simple, so I'm not sure why you think it
can't be done. Very complicated things can be done, and a belt is
not really particularly complicated. The existing belt is already
set up for animation, with steps 4. It doesn't go very fast. The
notion of "sending the teeth along a path" is really exactly what's
going on right now. Notice how beltpath is computed and then used to
compute the belt, with the teeth offset controlled by $t.
On Mon, Jul 11, 2022 at 10:08 PM <mikeonenine@web.de> wrote:
>
> Adrian Mariano wrote:
>
> I believe the twist deforms the belt teeth (by shear). You may want to focus on what you really want the belt to do and start simpler and then move towards more complex. The example is a little silly, since you wouldn't want a belt to turn inside-out.
>
> True, but twist is acceptable if the belt is long enough.
>
> The example is not so silly if the straight runs cross over as per my attempt (animation) earlier in this thread - then both ends are the right way round. It is not ideal for the straight runs to rub against each other in the middle, even if only back-to-back, but OK in a low-power (hand-operated) application.
>
> What I am after ultimately is a better version of that animation that can be combined with other moving parts in a way that makes sense. But OpenSCAD has limits on what can be done with animation anyway. In the animation I did, all the teeth only move back and forth one position (slow forward, instantaneous back) giving the illusion of continuous motion. Also only the straight runs are actual “belt”. The curved sections are only stationary black semicircles behind the cogs.
>
> What I imagine is required is some kind of flexible polygon, or a means of sending each belt tooth around a defined path. The speeds of the belt and the cogs obviously need to reflect the number of teeth on each. The more I think about it and the more I look at the Toothed belt.scad code, the more I think it can’t be done, unfortunately.
>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
M
mikeonenine@web.de
Wed, Jul 13, 2022 10:04 PM
It's not that the belt twists but that the teeth themselves deform
into a shear-transformed shape. Actual twist of a real belt
presumably twists only the belt and not the teeth.
Your requirements seem fairly simple, so I'm not sure why you think it
can't be done. Very complicated things can be done, and a belt is
not really particularly complicated. The existing belt is already
set up for animation, with steps 4. It doesn't go very fast. The
notion of "sending the teeth along a path" is really exactly what's
going on right now. Notice how beltpath is computed and then used to
compute the belt, with the teeth offset controlled by $t.
On Mon, Jul 11, 2022 at 10:08 PM mikeonenine@web.de wrote:
Adrian Mariano wrote:
I believe the twist deforms the belt teeth (by shear). You may want to focus on what you really want the belt to do and start simpler and then move towards more complex. The example is a little silly, since you wouldn't want a belt to turn inside-out.
True, but twist is acceptable if the belt is long enough.
The example is not so silly if the straight runs cross over as per my attempt (animation) earlier in this thread - then both ends are the right way round. It is not ideal for the straight runs to rub against each other in the middle, even if only back-to-back, but OK in a low-power (hand-operated) application.
What I am after ultimately is a better version of that animation that can be combined with other moving parts in a way that makes sense. But OpenSCAD has limits on what can be done with animation anyway. In the animation I did, all the teeth only move back and forth one position (slow forward, instantaneous back) giving the illusion of continuous motion. Also only the straight runs are actual “belt”. The curved sections are only stationary black semicircles behind the cogs.
What I imagine is required is some kind of flexible polygon, or a means of sending each belt tooth around a defined path. The speeds of the belt and the cogs obviously need to reflect the number of teeth on each. The more I think about it and the more I look at the Toothed belt.scad code, the more I think it can’t be done, unfortunately.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
I have now found the animation - I must have blinked and missed the movement the first time I looked at it.
It is indeed rather slow at $t*4, much slower than parts that have to move at $t*360 to complete full rotations or cycles, e.g. translate([0,0,x*sin($t*360)]).
In the animation below, the cogwheel is slowed to $t*180, as the eccentric hole shows, and the belt is running at $t*64, which results in it sort of doing 3 steps forward and 2 steps back, which shows in the changing interference patterns generated by the teeth. Apart from that, adjusting parameters in the belt program often produces some strange results.
How can the speeds of the belt and cogwheel (together with other parts) be matched so that a mechanism runs in a smooth and meaningful way?
Adrian Mariano wrote:
> It's not that the belt twists but that the teeth themselves deform
> into a shear-transformed shape. Actual twist of a real belt
> presumably twists only the belt and not the teeth.
>
> Your requirements seem fairly simple, so I'm not sure why you think it
> can't be done. Very complicated things can be done, and a belt is
> not really particularly complicated. The existing belt is already
> set up for animation, with steps 4. It doesn't go very fast. The
> notion of "sending the teeth along a path" is really exactly what's
> going on right now. Notice how beltpath is computed and then used to
> compute the belt, with the teeth offset controlled by $t.
>
> On Mon, Jul 11, 2022 at 10:08 PM [mikeonenine@web.de](mailto:mikeonenine@web.de) wrote:
>
> > Adrian Mariano wrote:
> >
> > I believe the twist deforms the belt teeth (by shear). You may want to focus on what you really want the belt to do and start simpler and then move towards more complex. The example is a little silly, since you wouldn't want a belt to turn inside-out.
> >
> > True, but twist is acceptable if the belt is long enough.
> >
> > The example is not so silly if the straight runs cross over as per my attempt (animation) earlier in this thread - then both ends are the right way round. It is not ideal for the straight runs to rub against each other in the middle, even if only back-to-back, but OK in a low-power (hand-operated) application.
> >
> > What I am after ultimately is a better version of that animation that can be combined with other moving parts in a way that makes sense. But OpenSCAD has limits on what can be done with animation anyway. In the animation I did, all the teeth only move back and forth one position (slow forward, instantaneous back) giving the illusion of continuous motion. Also only the straight runs are actual “belt”. The curved sections are only stationary black semicircles behind the cogs.
> >
> > What I imagine is required is some kind of flexible polygon, or a means of sending each belt tooth around a defined path. The speeds of the belt and the cogs obviously need to reflect the number of teeth on each. The more I think about it and the more I look at the Toothed belt.scad code, the more I think it can’t be done, unfortunately.
> >
> > ---
> >
> > OpenSCAD mailing list
> > To unsubscribe send an email to discuss-leave@lists.openscad.org
I have now found the animation - I must have blinked and missed the movement the first time I looked at it.
It is indeed rather slow at $t\*4, much slower than parts that have to move at $t\*360 to complete full rotations or cycles, e.g. translate(\[0,0,x\*sin($t\*360)\]).
In the animation below, the cogwheel is slowed to $t\*180, as the eccentric hole shows, and the belt is running at $t\*64, which results in it sort of doing 3 steps forward and 2 steps back, which shows in the changing interference patterns generated by the teeth. Apart from that, adjusting parameters in the belt program often produces some strange results.
How can the speeds of the belt and cogwheel (together with other parts) be matched so that a mechanism runs in a smooth and meaningful way?
AM
Adrian Mariano
Wed, Jul 13, 2022 10:57 PM
I don't do animations, so I don't understand the animation system very
well, but It sounds like you don't understand how the animation works.
You can't just change 4*$t to something else. The reason for the 4 is
that the teeth are four layers wide, so four steps moves a tooth to
the next position. The $t parameter is changing the location where
the teeth are placed onto the belt. If you compute those four frames
it will create an endless looping movement. You need to set steps to
4. If you want a matching cog wheel you should make a wheel that
completes a one-tooth rotation in 4 steps for it to match up. If you
have other things in the model and need more than 4 steps it should be
possible but some tweak of the model appears necessary.
On Wed, Jul 13, 2022 at 6:05 PM mikeonenine@web.de wrote:
Adrian Mariano wrote:
It's not that the belt twists but that the teeth themselves deform into a shear-transformed shape. Actual twist of a real belt presumably twists only the belt and not the teeth.
Your requirements seem fairly simple, so I'm not sure why you think it can't be done. Very complicated things can be done, and a belt is not really particularly complicated. The existing belt is already set up for animation, with steps 4. It doesn't go very fast. The notion of "sending the teeth along a path" is really exactly what's going on right now. Notice how beltpath is computed and then used to compute the belt, with the teeth offset controlled by $t.
On Mon, Jul 11, 2022 at 10:08 PM mikeonenine@web.de wrote:
Adrian Mariano wrote:
I believe the twist deforms the belt teeth (by shear). You may want to focus on what you really want the belt to do and start simpler and then move towards more complex. The example is a little silly, since you wouldn't want a belt to turn inside-out.
True, but twist is acceptable if the belt is long enough.
The example is not so silly if the straight runs cross over as per my attempt (animation) earlier in this thread - then both ends are the right way round. It is not ideal for the straight runs to rub against each other in the middle, even if only back-to-back, but OK in a low-power (hand-operated) application.
What I am after ultimately is a better version of that animation that can be combined with other moving parts in a way that makes sense. But OpenSCAD has limits on what can be done with animation anyway. In the animation I did, all the teeth only move back and forth one position (slow forward, instantaneous back) giving the illusion of continuous motion. Also only the straight runs are actual “belt”. The curved sections are only stationary black semicircles behind the cogs.
What I imagine is required is some kind of flexible polygon, or a means of sending each belt tooth around a defined path. The speeds of the belt and the cogs obviously need to reflect the number of teeth on each. The more I think about it and the more I look at the Toothed belt.scad code, the more I think it can’t be done, unfortunately.
OpenSCAD mailing list To unsubscribe send an email to discuss-leave@lists.openscad.org
I have now found the animation - I must have blinked and missed the movement the first time I looked at it.
It is indeed rather slow at $t4, much slower than parts that have to move at $t360 to complete full rotations or cycles, e.g. translate([0,0,xsin($t360)]).
In the animation below, the cogwheel is slowed to $t180, as the eccentric hole shows, and the belt is running at $t64, which results in it sort of doing 3 steps forward and 2 steps back, which shows in the changing interference patterns generated by the teeth. Apart from that, adjusting parameters in the belt program often produces some strange results.
How can the speeds of the belt and cogwheel (together with other parts) be matched so that a mechanism runs in a smooth and meaningful way?
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
I don't do animations, so I don't understand the animation system very
well, but It sounds like you don't understand how the animation works.
You can't just change 4*$t to something else. The reason for the 4 is
that the teeth are four layers wide, so four steps moves a tooth to
the next position. The $t parameter is changing the location where
the teeth are placed onto the belt. If you compute those four frames
it will create an endless looping movement. You need to set steps to
4. If you want a matching cog wheel you should make a wheel that
completes a one-tooth rotation in 4 steps for it to match up. If you
have other things in the model and need more than 4 steps it should be
possible but some tweak of the model appears necessary.
On Wed, Jul 13, 2022 at 6:05 PM <mikeonenine@web.de> wrote:
>
> Adrian Mariano wrote:
>
> It's not that the belt twists but that the teeth themselves deform into a shear-transformed shape. Actual twist of a real belt presumably twists only the belt and not the teeth.
>
> Your requirements seem fairly simple, so I'm not sure why you think it can't be done. Very complicated things can be done, and a belt is not really particularly complicated. The existing belt is already set up for animation, with steps 4. It doesn't go very fast. The notion of "sending the teeth along a path" is really exactly what's going on right now. Notice how beltpath is computed and then used to compute the belt, with the teeth offset controlled by $t.
>
> On Mon, Jul 11, 2022 at 10:08 PM mikeonenine@web.de wrote:
>
> Adrian Mariano wrote:
>
> I believe the twist deforms the belt teeth (by shear). You may want to focus on what you really want the belt to do and start simpler and then move towards more complex. The example is a little silly, since you wouldn't want a belt to turn inside-out.
>
> True, but twist is acceptable if the belt is long enough.
>
> The example is not so silly if the straight runs cross over as per my attempt (animation) earlier in this thread - then both ends are the right way round. It is not ideal for the straight runs to rub against each other in the middle, even if only back-to-back, but OK in a low-power (hand-operated) application.
>
> What I am after ultimately is a better version of that animation that can be combined with other moving parts in a way that makes sense. But OpenSCAD has limits on what can be done with animation anyway. In the animation I did, all the teeth only move back and forth one position (slow forward, instantaneous back) giving the illusion of continuous motion. Also only the straight runs are actual “belt”. The curved sections are only stationary black semicircles behind the cogs.
>
> What I imagine is required is some kind of flexible polygon, or a means of sending each belt tooth around a defined path. The speeds of the belt and the cogs obviously need to reflect the number of teeth on each. The more I think about it and the more I look at the Toothed belt.scad code, the more I think it can’t be done, unfortunately.
>
> ________________________________
>
> OpenSCAD mailing list To unsubscribe send an email to discuss-leave@lists.openscad.org
>
> I have now found the animation - I must have blinked and missed the movement the first time I looked at it.
>
> It is indeed rather slow at $t*4, much slower than parts that have to move at $t*360 to complete full rotations or cycles, e.g. translate([0,0,x*sin($t*360)]).
>
> In the animation below, the cogwheel is slowed to $t*180, as the eccentric hole shows, and the belt is running at $t*64, which results in it sort of doing 3 steps forward and 2 steps back, which shows in the changing interference patterns generated by the teeth. Apart from that, adjusting parameters in the belt program often produces some strange results.
>
> How can the speeds of the belt and cogwheel (together with other parts) be matched so that a mechanism runs in a smooth and meaningful way?
>
>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
M
mikeonenine@web.de
Thu, Jul 14, 2022 12:41 AM
mikeonenine wrote Mon, Jul 11, 2022 10:07 PM:
What I am after ultimately is a better version of that animation that can be combined with other moving parts in a way that makes sense.
Adrian Mariano wrote Mon, Jul 11, 2022 10:46 PM:
“Your requirements seem fairly simple, so I'm not sure why you think it
can't be done. Very complicated things can be done, . . .”
Adrian Mariano wrote Wed, Jul 13, 2022 6:57 PM
“I don't do animations, so I don't understand the animation system very
well”
Yes you do - you managed to animate the belt.
“but It sounds like you don't understand how the animation works”
Granted. Otherwise I would not be asking.
Adrian Mariano wrote Wed, Jul 13, 2022 6:57 PM
“If you have other things in the model and need more than 4 steps it should be
possible but some tweak of the model appears necessary”
Well, yes! So how might translate([a*sin($t*360),0,0]) be tweaked, for instance?
mikeonenine wrote Mon, Jul 11, 2022 10:07 PM:
What I am after ultimately is a better version of that animation that can be combined with other moving parts in a way that makes sense.
Adrian Mariano wrote Mon, Jul 11, 2022 10:46 PM:
“Your requirements seem fairly simple, so I'm not sure why you think it \
can't be done. Very complicated things can be done, . . .”
Adrian Mariano wrote Wed, Jul 13, 2022 6:57 PM
“I don't do animations, so I don't understand the animation system very \
well”
Yes you do - you managed to animate the belt.
“but It sounds like you don't understand how the animation works”
Granted. Otherwise I would not be asking.
Adrian Mariano wrote Wed, Jul 13, 2022 6:57 PM
“If you have other things in the model and need more than 4 steps it should be \
possible but some tweak of the model appears necessary”
Well, yes! So how might translate(\[a\*sin($t\*360),0,0\]) be tweaked, for instance?
AM
Adrian Mariano
Thu, Jul 14, 2022 1:29 AM
Well, you see, I wrote that example by copying another example and the
animation stuff was already there.
I don't know what translate([asin($t360),0,0]) has to do with
anything. You can't transform some other component in isolation. You
need to know how the parts are going to interact. Right now the belt
has four steps. If you want the belt to actually complete a full
revolution for some reason you'll need 4teeth steps and then you'll
need to use teeth$t instead of $t, or something like that. Maybe
best to do it mod 4? (Mod 8?) Knowing how to include the wheel
requires knowing the teeth size on the wheel.
Jordan said $t went between 0 and 1, but I'm observing it going
between 0 and 8, which seems a little strange. But I haven't been
able to get the belt to work with 168 steps (going all the way around)
and am not sure why...which gets back to what I said before about I
not really understanding the animation system. It should be trivial
to make this change and for some reason it is not.
Here's the code if anyone wants to play:
include<BOSL2/std.scad>
include<BOSL2/turtle3d.scad>
r_small = 19; // radius of small curve
r_large = 46; // radius of large curve
flat_length = 100; // length of flat belt section
teeth=42; // number of teeth
belt_width = 12;
tooth_height = 9;
belt_thickness = 3;
angle = 180 - 2atan((r_large-r_small)/flat_length);
beltprofile = path3d(subdivide_path(
square([belt_width, belt_thickness],anchor=FWD),
20));
beltrots =
turtle3d(["arcsteps",1,
"move", flat_length,
"arcleft", r_small, angle,
"move", flat_length,
// Closing path will be interpolated
// "arcleft", r_large, 360-angle
],transforms=true);
beltpath = rot_resample(beltrots,teeth4,
twist=[180,0,-180,0],
long=[false,false,false,true],
smoothlen=15,closed=true);
belt = [for(i=idx(beltpath))
let(tooth = floor((i+($t)4)/2)%2)
apply(beltpath[i]
yscale(tooth
? tooth_height/belt_thickness
: 1),
beltprofile)
];
skin(belt,slices=0,closed=true);
On Wed, Jul 13, 2022 at 8:45 PM mikeonenine@web.de wrote:
mikeonenine wrote Mon, Jul 11, 2022 10:07 PM:
What I am after ultimately is a better version of that animation that can be combined with other moving parts in a way that makes sense.
Adrian Mariano wrote Mon, Jul 11, 2022 10:46 PM:
“Your requirements seem fairly simple, so I'm not sure why you think it
can't be done. Very complicated things can be done, . . .”
Adrian Mariano wrote Wed, Jul 13, 2022 6:57 PM
“I don't do animations, so I don't understand the animation system very
well”
Yes you do - you managed to animate the belt.
“but It sounds like you don't understand how the animation works”
Granted. Otherwise I would not be asking.
Adrian Mariano wrote Wed, Jul 13, 2022 6:57 PM
“If you have other things in the model and need more than 4 steps it should be
possible but some tweak of the model appears necessary”
Well, yes! So how might translate([asin($t360),0,0]) be tweaked, for instance?
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
Well, you see, I wrote that example by copying another example and the
animation stuff was already there.
I don't know what translate([a*sin($t*360),0,0]) has to do with
anything. You can't transform some other component in isolation. You
need to know how the parts are going to interact. Right now the belt
has four steps. If you want the belt to actually complete a full
revolution for some reason you'll need 4*teeth steps and then you'll
need to use teeth*$t instead of $t, or something like that. Maybe
best to do it mod 4? (Mod 8?) Knowing how to include the wheel
requires knowing the teeth size on the wheel.
Jordan said $t went between 0 and 1, but I'm observing it going
between 0 and 8, which seems a little strange. But I haven't been
able to get the belt to work with 168 steps (going all the way around)
and am not sure why...which gets back to what I said before about I
not really understanding the animation system. It should be trivial
to make this change and for some reason it is not.
Here's the code if anyone wants to play:
include<BOSL2/std.scad>
include<BOSL2/turtle3d.scad>
r_small = 19; // radius of small curve
r_large = 46; // radius of large curve
flat_length = 100; // length of flat belt section
teeth=42; // number of teeth
belt_width = 12;
tooth_height = 9;
belt_thickness = 3;
angle = 180 - 2*atan((r_large-r_small)/flat_length);
beltprofile = path3d(subdivide_path(
square([belt_width, belt_thickness],anchor=FWD),
20));
beltrots =
turtle3d(["arcsteps",1,
"move", flat_length,
"arcleft", r_small, angle,
"move", flat_length,
// Closing path will be interpolated
// "arcleft", r_large, 360-angle
],transforms=true);
beltpath = rot_resample(beltrots,teeth*4,
twist=[180,0,-180,0],
long=[false,false,false,true],
smoothlen=15,closed=true);
belt = [for(i=idx(beltpath))
let(tooth = floor((i+($t)*4)/2)%2)
apply(beltpath[i]*
yscale(tooth
? tooth_height/belt_thickness
: 1),
beltprofile)
];
skin(belt,slices=0,closed=true);
On Wed, Jul 13, 2022 at 8:45 PM <mikeonenine@web.de> wrote:
>
> mikeonenine wrote Mon, Jul 11, 2022 10:07 PM:
>
> What I am after ultimately is a better version of that animation that can be combined with other moving parts in a way that makes sense.
>
>
> Adrian Mariano wrote Mon, Jul 11, 2022 10:46 PM:
>
> “Your requirements seem fairly simple, so I'm not sure why you think it
> can't be done. Very complicated things can be done, . . .”
>
>
> Adrian Mariano wrote Wed, Jul 13, 2022 6:57 PM
>
> “I don't do animations, so I don't understand the animation system very
> well”
>
> Yes you do - you managed to animate the belt.
>
> “but It sounds like you don't understand how the animation works”
>
> Granted. Otherwise I would not be asking.
>
> Adrian Mariano wrote Wed, Jul 13, 2022 6:57 PM
>
> “If you have other things in the model and need more than 4 steps it should be
> possible but some tweak of the model appears necessary”
>
> Well, yes! So how might translate([a*sin($t*360),0,0]) be tweaked, for instance?
>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
M
mikeonenine@web.de
Thu, Jul 14, 2022 3:40 AM
Well, you see, I wrote that example by copying another example and the
animation stuff was already there.
I don't know what translate([asin($t360),0,0]) has to do with
anything. You can't transform some other component in isolation.
OK, I do a lot of copying too. It is supposed to be the biggest compliment you can make to the originator.
translate([a*sin($t*360),0,0]) is for simple harmonic motion because my design has some reciprocating parts. I don’t want to reveal more than that at the moment.
All the parts I have been transforming have been in isolation because you can’t transmit motion from one part to another in OpenSCAD. OOPS! But it works!
Your explanations and code look interesting. I may need a couple of days to get my head round that.
Adrian Mariano wrote:
> Well, you see, I wrote that example by copying another example and the
> animation stuff was already there.
>
> I don't know what translate(\[a*sin($t*360),0,0\]) has to do with
> anything. You can't transform some other component in isolation.
OK, I do a lot of copying too. It is supposed to be the biggest compliment you can make to the originator.
translate(\[a\*sin($t\*360),0,0\]) is for simple harmonic motion because my design has some reciprocating parts. I don’t want to reveal more than that at the moment.
All the parts I have been transforming have been in isolation because you can’t transmit motion from one part to another in OpenSCAD. OOPS! But it works!
Your explanations and code look interesting. I may need a couple of days to get my head round that.
M
mikeonenine@web.de
Fri, Jul 15, 2022 6:42 AM
Eureka!
M
mikeonenine@web.de
Fri, Jul 15, 2022 6:42 AM
Eureka!
