USER FORUM

*(you are viewing a thread; or go back to
list of threads)*

**Make a gear**

*(by normandajc)*

I realise a gear. I give you a example

alpha = 20 degres

module m= 0.5 or 0.6 or 0.8 or 1 or 1.25 or ......

number of teeth z = 17 or more

pitch diameter d = m * z

base diameter db = d*cos(alpha)

outside diameter do = d + 2*m

root diameter dr = d - 2.5 *m

angle = 360 / z /2

example

with alpha =20 m=5 z=20

d=100 db=93.97 do=110 dr=87.5 angle=9

active "g002-sketch-in-plane " modified the value

active "g004-rotate" changed repeat ( z number of teeth )

you can try

alpha = 20 degres

module m= 0.5 or 0.6 or 0.8 or 1 or 1.25 or ......

number of teeth z = 17 or more

pitch diameter d = m * z

base diameter db = d*cos(alpha)

outside diameter do = d + 2*m

root diameter dr = d - 2.5 *m

angle = 360 / z /2

example

with alpha =20 m=5 z=20

d=100 db=93.97 do=110 dr=87.5 angle=9

active "g002-sketch-in-plane " modified the value

active "g004-rotate" changed repeat ( z number of teeth )

you can try

**(no subject)**

*(by whitequark)*

The entity hit testing is really slow on this file. I wonder if it could be easily improved...

**(no subject)**

*(by Jonathan Westhues)*

That gear (a) steps and repeats all the construction geometry, not just the final tooth form, and (b) assembles all the teeth together as solid Boolean operations, instead of just piecing together curves. So with some small changes, the regeneration time and entity count can be greatly reduced, as attached.

Though hit testing could be improved too. You could accelerate the existing code with a bounding box test, or with an O(log n) data structure for the entities, but either of those would add complexity. The simplest option might be to let gl do the test with a selection buffer. That might even be a net reduction in lines of code, and might benefit naturally from any later work to speed up rendering.

Though hit testing could be improved too. You could accelerate the existing code with a bounding box test, or with an O(log n) data structure for the entities, but either of those would add complexity. The simplest option might be to let gl do the test with a selection buffer. That might even be a net reduction in lines of code, and might benefit naturally from any later work to speed up rendering.

**(no subject)**

*(by normandajc)*

Hello

your version is better my initial program a lot.

I modified slightly your program. gear_faster2.slvs

Thank you

your version is better my initial program a lot.

I modified slightly your program. gear_faster2.slvs

Thank you

**(no subject)**

*(by Jonathan Westhues)*

gear_faster2 still steps and repeats the construction geometry; so you have one copy per tooth of all the circles and stuff, even though they're all exactly coincident. So regeneration is faster, but entity selection is still slow.

I was lazy and just retraced the tooth form in a second group, since you'd already sketched it in the first one. The cleanest way to draw the gear would be to put only the construction geometry in one group, put the tooth form in a second group, and then step and repeat the second group. That's fast, avoids duplication, and also makes the constraints easier to follow (since the tooth form can depend on the construction geometry but not vice versa).

I was lazy and just retraced the tooth form in a second group, since you'd already sketched it in the first one. The cleanest way to draw the gear would be to put only the construction geometry in one group, put the tooth form in a second group, and then step and repeat the second group. That's fast, avoids duplication, and also makes the constraints easier to follow (since the tooth form can depend on the construction geometry but not vice versa).

**(no subject)**

*(by normandajc)*

Actually, it is better.

Thank you for the explanations

Thank you for the explanations

**Post a reply to this comment:**