mirror of
https://github.com/BelfrySCAD/BOSL2.git
synced 2024-12-29 16:29:40 +00:00
Merge pull request #1309 from adrianVmariano/master
doc fixes, snap hinge angle fix
This commit is contained in:
commit
febf811cc5
8 changed files with 26 additions and 11 deletions
|
@ -47,6 +47,7 @@ _ANCHOR_TYPES = ["intersect","hull"];
|
|||
// The direction and spin are used to orient other objects to match when using `attach()`.
|
||||
// - Spin is a simple rotation around the Z axis.
|
||||
// - Orientation is rotating an object so that its top is pointed towards a given vector.
|
||||
// .
|
||||
// An object will first be translated to its anchor position, then spun, then oriented.
|
||||
// For a detailed step-by-step explanation of attachments, see the [Attachments Tutorial](Tutorial-Attachments).
|
||||
// .
|
||||
|
@ -206,6 +207,7 @@ _ANCHOR_TYPES = ["intersect","hull"];
|
|||
// [X-Y-, X+Y-, X-Y+, X+Y+]
|
||||
// ]
|
||||
// ```
|
||||
// .
|
||||
// You can specify edge descriptors directly by giving a vector, or you can use sums of the
|
||||
// named direction vectors described above. Below we show all of the edge sets you can
|
||||
// describe with sums of the direction vectors, and then we show some examples of combining
|
||||
|
@ -310,6 +312,7 @@ _ANCHOR_TYPES = ["intersect","hull"];
|
|||
// ```
|
||||
// [X-Y-Z-, X+Y-Z-, X-Y+Z-, X+Y+Z-, X-Y-Z+, X+Y-Z+, X-Y+Z+, X+Y+Z+]
|
||||
// ```
|
||||
// .
|
||||
// You can specify corner descriptors directly by giving a vector, or you can use sums of the
|
||||
// named direction vectors described above. Below we show all of the corner sets you can
|
||||
// describe with sums of the direction vectors and then we show some examples of combining
|
||||
|
|
|
@ -306,8 +306,9 @@ function project_plane(plane,p) =
|
|||
// - A list of three points. The planar coordinate system will have [0,0] at plane[0], and plane[1] will lie on the Y+ axis.
|
||||
// - A list of coplanar points that define a plane (not-collinear)
|
||||
// - A plane definition `[A,B,C,D]` where `Ax+By+CZ=D`. The closest point on that plane to the origin will map to the origin in the new coordinate system.
|
||||
// If you do not supply `p` then you get a transformation matrix which operates in 3D, assuming that the Z coordinate of the points is zero.
|
||||
// This matrix is a rotation, the inverse of the one produced by project_plane.
|
||||
// .
|
||||
// If you do not supply `p` then you get a transformation matrix which operates in 3D, assuming that the Z coordinate of the points is zero.
|
||||
// This matrix is a rotation, the inverse of the one produced by project_plane.
|
||||
// Arguments:
|
||||
// plane = Plane specification or list of points to define a plane
|
||||
// p = points, path, region, VNF, or bezier patch to transform.
|
||||
|
|
|
@ -798,6 +798,7 @@ function grid_copies(spacing, n, size, stagger=false, inside=undef, nonzero, p=_
|
|||
// - If given a centerpoint `cp`, centers the ring around that centerpoint.
|
||||
// - If `subrot` is true, each child will be rotated in place to keep the same size towards the center when making rings.
|
||||
// - The first (unrotated) copy will be placed at the relative starting angle `sa`.
|
||||
// .
|
||||
// When called as a function, *without* a `p=` argument, returns a list of transformation matrices, one for each copy.
|
||||
// When called as a function, *with* a `p=` argument, returns a list of transformed copies of `p=`.
|
||||
//
|
||||
|
@ -918,6 +919,7 @@ function rot_copies(rots=[], v, cp=[0,0,0], n, sa=0, offset=0, delta=[0,0,0], su
|
|||
// - If given a centerpoint `cp`, centers the rotation around that centerpoint.
|
||||
// - If `subrot` is true, each child will be rotated in place to keep the same size towards the center when making rings.
|
||||
// - The first (unrotated) copy will be placed at the relative starting angle `sa`.
|
||||
// .
|
||||
// When called as a function, *without* a `p=` argument, returns a list of transformation matrices, one for each copy.
|
||||
// When called as a function, *with* a `p=` argument, returns a list of transformed copies of `p=`.
|
||||
//
|
||||
|
@ -998,6 +1000,7 @@ function xrot_copies(rots=[], cp=[0,0,0], n, sa=0, r, d, subrot=true, p=_NO_ARG)
|
|||
// - If given a centerpoint `cp`, centers the rotation around that centerpoint.
|
||||
// - If `subrot` is true, each child will be rotated in place to keep the same size towards the center when making rings.
|
||||
// - The first (unrotated) copy will be placed at the relative starting angle `sa`.
|
||||
// .
|
||||
// When called as a function, *without* a `p=` argument, returns a list of transformation matrices, one for each copy.
|
||||
// When called as a function, *with* a `p=` argument, returns a list of transformed copies of `p=`.
|
||||
//
|
||||
|
@ -1079,6 +1082,7 @@ function yrot_copies(rots=[], cp=[0,0,0], n, sa=0, r, d, subrot=true, p=_NO_ARG)
|
|||
// - If given a centerpoint `cp`, centers the rotation around that centerpoint.
|
||||
// - If `subrot` is true, each child will be rotated in place to keep the same size towards the center when making rings.
|
||||
// - The first (unrotated) copy will be placed at the relative starting angle `sa`.
|
||||
// .
|
||||
// When called as a function, *without* a `p=` argument, returns a list of transformation matrices, one for each copy.
|
||||
// When called as a function, *with* a `p=` argument, returns a list of transformed copies of `p=`.
|
||||
//
|
||||
|
@ -1392,7 +1396,8 @@ function sphere_copies(n=100, r=undef, d=undef, cone_ang=90, scale=[1,1,1], perp
|
|||
// - placed at uniformly spaced points along the path. If you specify `n` but not `spacing` then `n` copies will be placed
|
||||
// - with one at path[0] if `closed` is true, or spanning the entire path from start to end if `closed` is false.
|
||||
// - If you specify `spacing` but not `n` then copies will spread out starting from one set at path[0] for `closed=true` or at the path center for open paths.
|
||||
// - If you specify `sp` then the copies will start at distance `sp` from the start of the path.
|
||||
// - If you specify `sp` then the copies will start at distance `sp` from the start of the path.
|
||||
// .
|
||||
// When called as a function, *without* a `p=` argument, returns a list of transformation matrices, one for each copy.
|
||||
// When called as a function, *with* a `p=` argument, returns a list of transformed copies of `p=`.
|
||||
//
|
||||
|
|
|
@ -601,6 +601,7 @@ module stroke(
|
|||
// path or region boundary with the given dash pattern.
|
||||
// - When called as a function, returns a list of dash sub-paths.
|
||||
// - When called as a module, draws all those subpaths using `stroke()`.
|
||||
// .
|
||||
// When called as a module the dash pattern is multiplied by the line width. When called as
|
||||
// a function the dash pattern applies as you specify it.
|
||||
// Arguments:
|
||||
|
|
15
gears.scad
15
gears.scad
|
@ -3436,16 +3436,16 @@ function _gear_tooth_profile(
|
|||
// gear_data = planetary_gears(mod=|circ_pitch=|diam_pitch=, n, max_teeth, ring_carrier=|carrier_ring=|sun_carrier=|carrier_sun=|sun_ring=|ring_sun=, [helical=], [gear_spin=]);
|
||||
// Description:
|
||||
// Calculates a planetary gear assembly that approximates a desired transmission ratio. A planetary gear assembly can be regarded as having three
|
||||
// elements: the outer ring gear, the central sun gear, and a carrier that holds several planet gears, which fit between the sun and ring
|
||||
// elements: the outer ring gear, the central sun gear, and a carrier that holds several planet gears, which fit between the sun and ring.
|
||||
// The transmission ratio of a planetary gear assembly depends on which element is fixed and which ones are considered the input and output shafts.
|
||||
// The fixed element can be the ring gear, the sun gear, or the carrier, and then you specify the desired ratio between the other two.
|
||||
// You must also specify a maximum number of teeth on the ring gear. The function calculates the best approximation to your desired
|
||||
// transmission ratio under that constraint: allowing more teeth will generally give a more accurate approximation. Note that the planet gears
|
||||
// transmission ratio under that constraint: a large enough increase in the allowed number of teeth will yield a more accurate approximation. Note that the planet gears
|
||||
// appear uniformly spaced around the sun gear, but this uniformity is often only approximate. Exact uniformity occurs when teeth_sun+teeth_ring
|
||||
// is a multiple of the number of planet gears.
|
||||
// .
|
||||
// You specify the dedsired ratio using one of six parameters that identify which ratio you want to specify, and which is the driven element.
|
||||
// Each different ratio is limited to certain bounds. For the case of the fixed carrier system, the run and ring rotate in opposite directions.
|
||||
// You specify the desired ratio using one of six parameters that identify which ratio you want to specify, and which is the driven element.
|
||||
// Each different ratio is limited to certain bounds. For the case of the fixed carrier system, the sun and ring rotate in opposite directions.
|
||||
// This is sometimes indicated by a negative transmission ratio. For these cases you can give a positive or negative value.
|
||||
// .
|
||||
// The return is a list of entries that describe the elements of the planetary assembly. The list entries are:
|
||||
|
@ -3453,8 +3453,9 @@ function _gear_tooth_profile(
|
|||
// - ["ring", teeth, profile_shift, spin]
|
||||
// - ["planets", teeth, profile_shift, spins, positions, angles]
|
||||
// - ["ratio", realized_ratio]
|
||||
// .
|
||||
// The sun and ring gear are assumed to be placed at the origin. The planet gears are placed at the list of positions. The gears all
|
||||
// have a spin in degrees. The planets list also includes the angular position of each planet in the `angels` list.
|
||||
// have a spin in degrees. The planets list also includes the angular position of each planet in the `angles` list.
|
||||
// One of the planets always appears on the X+ axis when `gear_spin` is zero. The final list entry gives the realized ratio of
|
||||
// the assembly, so you can determine how closely it approaches your desired ratio. This will always be a positive value.
|
||||
// .
|
||||
|
@ -3465,7 +3466,7 @@ function _gear_tooth_profile(
|
|||
// The computation of planetary gear assembles is about determining the teeth counts on the sun, ring and planet gears,
|
||||
// and the angular positions of the planet gears.
|
||||
// The tooth size or helical angle are needed only for determining proper profile shifting and for determining the
|
||||
// gear separation for the planet gears. If you need a particular size assembly, you can do a planetary calculation
|
||||
// gear positions for the profiled shifted gears. To control the size of the assembly, do a planetary calculation
|
||||
// with a module of 1 and then scale the module to produce the required gear dimensions. Remember, you should never
|
||||
// use `scale()` on gears; change their size by scaling the module or one of the other tooth size parameters.
|
||||
// Arguments:
|
||||
|
@ -3503,7 +3504,7 @@ function _gear_tooth_profile(
|
|||
// Example(3D,Med,NoAxes,Anim,Frames=5,VPT=[0.128673,0.24149,0.651451],VPR=[38.5,0,21],VPD=222.648): Here we request a sun/ring ratio of 3 and it is exactly achieved. The carrier, shown in blue, is fixed. This example is shown with helical gears. It is important to remember to flip the sign of the helical angle for the planet gears.
|
||||
// mod=1;
|
||||
// helical=25;
|
||||
// gear_data = planetary_gears(mod=mod, n=4, max_teeth=82, sun_ring=3, helical=helical,gear_spin=360/33*$t);
|
||||
// gear_data = planetary_gears(mod=mod, n=4, max_teeth=82, sun_ring=3, helical=helical,gear_spin=360/27*$t);
|
||||
// ring_gear(mod=mod, teeth=gear_data[1][1], profile_shift=gear_data[1][2], helical=helical, gear_spin=gear_data[1][3],backing=4,thickness=7);
|
||||
// color("blue"){
|
||||
// move_copies(gear_data[2][4]) cyl(h=12,d=4);
|
||||
|
|
|
@ -415,7 +415,7 @@ module folding_hinge_mask(l, thick, layerheight=0.2, foldangle=90, hingegap=unde
|
|||
// Example(Med):
|
||||
// size=100;
|
||||
// apply_folding_hinges_and_snaps(
|
||||
// thick=3, foldangle=54.74,
|
||||
// thick=3, foldangle=acos(1/3),
|
||||
// hinges=[
|
||||
// for (a=[0,120,240], b=[-size/2,size/4]) each [
|
||||
// [200, polar_to_xy(b,a), a+90]
|
||||
|
|
|
@ -2814,6 +2814,7 @@ function associate_vertices(polygons, split, curpoly=0) =
|
|||
// Given a texture name, returns a texture. Textures can come in two varieties:
|
||||
// - Heightfield textures which are 2D arrays of scalars. These are usually faster to render, but can be less precise and prone to triangulation errors. The table below gives the recommended style for the best triangulation. If results are still incorrect, switch to the similar VNF tile by adding the "_vnf" suffix.
|
||||
// - VNF Tile textures, which are VNFs that cover the unit square [0,0] x [1,1]. These tend to be slower to render, but allow greater flexibility and precision for shapes that don't align with a grid.
|
||||
// .
|
||||
// In the descriptions below, imagine the textures positioned on the XY plane, so "horizontal" refers to the "sideways" dimensions of the texture and
|
||||
// "up" and "down" refer to the depth dimension. If a texture is placed on a cylinder the "depth" will become the radial direction and the "horizontal"
|
||||
// direction will be the vertical and tangential directions on the cylindrical surface. All horizontal dimensions for VNF textures are relative to the unit square
|
||||
|
@ -3436,6 +3437,7 @@ function texture(tex, n, inset, gap, roughness) =
|
|||
/// - As a VNF texture tile. A VNF tile exactly defines a surface from `[0,0]` to `[1,1]`, with the Z coordinates
|
||||
/// being the height of the texture point from the surface. VNF tiles MUST be able to tile in both X and Y
|
||||
/// directions with no gaps, with the front and back edges aligned exactly, and the left and right edges as well.
|
||||
/// .
|
||||
/// One script to convert a grayscale image to a texture heightfield array in a .scad file can be found at:
|
||||
/// https://raw.githubusercontent.com/BelfrySCAD/BOSL2/master/scripts/img2scad.py
|
||||
/// Arguments:
|
||||
|
@ -3733,6 +3735,7 @@ function _find_vnf_tile_edge_path(vnf, val) =
|
|||
/// - As a VNF texture tile. A VNF tile exactly defines a surface from `[0,0]` to `[1,1]`, with the Z coordinates
|
||||
/// being the height of the texture point from the surface. VNF tiles MUST be able to tile in both X and Y
|
||||
/// directions with no gaps, with the front and back edges aligned exactly, and the left and right edges as well.
|
||||
/// .
|
||||
/// One script to convert a grayscale image to a texture heightfield array in a .scad file can be found at:
|
||||
/// https://raw.githubusercontent.com/BelfrySCAD/BOSL2/master/scripts/img2scad.py
|
||||
/// Arguments:
|
||||
|
|
|
@ -668,6 +668,7 @@ function u_div(a,b) =
|
|||
// - Otherwise, if `center` is not `undef` and `center` evaluates as false, then the value of `uncentered` is returned.
|
||||
// - Otherwise, if `anchor` is not `undef`, then the value of `anchor` is returned.
|
||||
// - Otherwise, the value of `dflt` is returned.
|
||||
// .
|
||||
// This ordering ensures that `center` will override `anchor`.
|
||||
// Arguments:
|
||||
// anchor = The anchor name or vector.
|
||||
|
|
Loading…
Reference in a new issue