helical gears

  • Email
  • Sharebar
  • Email
aplesch's picture

The real advantage of gear modelling in 3d is that gears in a mesh do not have to parallel each other. It is posible to demonstrate how gears can transfer rotation (and forces) to orientations other than the driving gear. This kind of transfer is possible by use of helical gears.

Helical gears have their teeth at an angle to the axis of the gear but are otherwise very similar to spur gears. In fact, profiles through a helical gear are all identical and rotated by an amount proportional to their distance from the front. 

Based on the 3d involute gears program, helical gears therefore did not require too many changes. The main idea is that instead of just extruding the gear profile in one step, now several quads in the direction of the helical angle are generated, with the correct amount on distorttion (rotation) based on the width of each segment.

Here is the logo which is quite similar to the 3d involute gear logo but has the rotated extrusion and some smaller changes including the addition of a third gear. It takes quite a long time to run.

The triangles across the teeth were qute noticable. Changing the crease angle by editing the x3d helped. 

This update take advantage of how scope works in logo, eg. that variables are available to subprocedures.

Comments

aplesch's picture

x3d players

OK, the generated x3d almost work with external x3d players like octaga or freewrl. Some changes were necessary:

- add DEF fields in addition to id fields. DEF needs to be in capitals (!)

- ROUTE in caps.

The validator in x3d edit had lots of complaints.

 

Andy's picture

x3d casesensitivity

This should be easy to fix... I suppose the USE needs to be in capital too?? Thanks for finding this issue.

Andy's picture

fixed

I have fixed the x3d export and now it will have capital USE, DEF, and ROUTE.

For copy and paste, so far it only works on shape. I am still thinking about your copygeometry idea...  

Or maybe I should just use DEF and USE as the commands to do on any node..

aplesch's picture

case sensitivity

A couple of other x3d names which could be revised are:

bboxcenter -> bboxCenter

bboxsize -> bboxSize

Timesensor -> TimeSensor

"1,1,1" -> "1 1 1" (commas only between triplets)

 

Andy's picture

Bravo helical gears

Wow I want to learn how to do it... (I am almost done marking)..  I think this helical gear can be exported and 3D printed as well...

The creaseAngle is something I haven't looked at. Last time (some months ago) I did not seem to see it in the DOM.

I wonder how is done by EXTRUSION when I implemented it....I should try a manual x3d first..

I saw you used local variables. Do they stay after the procedure finished?

 

aplesch's picture

scope

I had an idea that it may be possible to create helical gears from the spur gears. The main idea is to rotate each profile through the gear by an amount determined by the helical angle and its distance from the front profile. The amount of rotation is tan (helical angle) * distance / pitch radius in radians. Instead of rotating each profile I rotate each segment on the profile and connect them to a twisted quadrangle.

For printing one should increase the number of fsegments (profiles) to as high as possible (10?). It will take a long time to generate a gear and the x3d will be large. Since all coordinates for a gear are on one line in the x3d I hope the resulting line length is still ok for x3dom or browsers.

Not sure how to do this with EXTRUSION since the extruded profile stays perpendicular to the path of extrusion, I believe.

Local variables are local to the procedure where they are defined (as are the inputs) but stay for all (sub)procedures which are called from the procedure. When the procedure in which they were defined finished they disappear and one does not have to worry if the name of the variable is used again for something else.

 

aplesch's picture

twisted

IndexedFaceSets are supposed to have only planar polygons, not twisted ones as I have defined:

http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/compon...

I think this is reason why there is a discrete (not smooth) boundary between each quadrangle even with a crease angle. I may change the quads procedure to generate ccw triangles instead of quads. Unfortunately this will make the x3d file size even larger (from four coords and one -1 to 6 coords and two -1) . Also I should rename the offsetz procedure but I cannot think of a good name.

I tried the x3d with octaga player and freewrl and both show the gears but do not animate. Perhaps the routes are in the wrong place for them, not sure. But ROUTE statements can occur anywhere. Perhaps they want ROUTE in all caps.

aplesch's picture

Coordinates duplicated

Another reason why there is no smoothing is that coordinates are duplicated where instead they could be shared. But this is how face mode is designed. When the turtle goes back to a point which is also used by another polygon it will create a duplicated coordinate for the x3d because logo cannot know that. Perhaps there is a way to manipulate the iindices though this sounds complicated ?

 

 

 

Andy's picture

Problem long ago

You found my problem so quickly. It is a happy feeling that someone knows my work.

I tried to solve the creaseAngle problem (duplicated coordinates) when I did the Mobius ring https://vrmath2.net/content/infinite-mobius-space 

It is not easy (not sure if any algorithm) for the turtle to check which coordinates have been recorded during the movements. I was thinking of a post PU reduction function to detect duplicated coordinates and modify the index accordingly, but that is not an easy job either.. would you be able to help with writing such as function? 

aplesch's picture

shared vertices

Is it possible to access the coordIndex field with the set command ? If it is, first my plan was to do what you suggested, in logo. A procedure which would copy the list of coordinates, remove duplicates, and then adjust the indices accordingly.

Then, for my particular case, I thought it would be easier and faster, to just deal with the 'fence' ('extrusion') and for each segment reassign the first two indices to the last two indices of the previous quad since the position in the list and the values are all known.

So I would like to try this first. But that would only work if coordIndex can be modified by set.

In javascript it also should be possible to do some thoughtful array manipulation to optimize the coords and coordIndex arrays, after PU. Somehow, I think it would make sense to use an associative array with coord triplets as (string) indices and the indices as values.