Documente Academic
Documente Profesional
Documente Cultură
This is a collection of extended primitives including NUBRS Curves and polygonal objects.
There is a command for creation and a node for construction history support. They work
almost exactly like the built-in primitives, except the following restrictions:
the -edit (-e) and query (-q)-flags are not yet supported (in scripts you could use
getAttr/setAttr on the make-node instead)
the polygon primitives have no uv-coordinates yet (see 3), therefore the -texture (tx)-flag and attribute are not implemented
parameters
pivot
pivotX
pivotY
pivotZ
basedToPivot
axis
axisX
axisY
axisZ
Most of the individual Attributes are quite self-explanatory or work like those from the
standard-primitives, like radius, height etc. All others are described below:
Polygonal Objects:
Bevel Box
A polygonal cube with
filleted rims.
Bevel Cylinder
height
width
depth
subdivisions width
subdivisions height
subdivisions depth
dimension type
fillet radius
fillet as fraction
subdivisions fillet
A polygonal cylinder
with filleted rims.
radius
height
height type
fillet radius
fillet as fraction
subdivisions width
subdivisions height
subdivisions fillet
subdivisions cap
Bevel Tube
A polygonal pipe with
filleted rims.
radius
thickness
height
height type
fillet radius
fillet as fraction
subdivisions width
subdivisions height
subdivisions fillet
subdivisions cap
Capsule
A polygonal cylinder
with a half-spherical cap
on each end. The cap
height is a factor
dependent on the radius.
radius
height
height type
cap height
subdivisions width
subdivisions height
subdivisions cap
Spindle
A polygonal cylinder
with a conical cap on
each end. The cap height
is a factor dependent on
the radius.
Star
radius
height
height type
cap height
subdivisions width
subdivisions height
subdivisions cap
inner radius
outer radius
height
subdivisions width (tines)
subdivisions height
twist
Flower
A polygonal Flower,
which is basically a
cylinder with extrude
sides.
inner radius
outer radius
height
subdivisions width
(petals)
subdivisions height
Gear
A polygonal Cogwheel.
The offset and taper
attributes are
normalized factors
concerning height or
cog-dimensions.
Standard Profile
bore radius
root radius
pitch radius
tip radius
height
subdivisions width (cogs)
subdivisions height
(sections)
root offset
tip offset
height offset
cog width
inner offset
taper
twist
A polygonal standard
construction profile: H,
L, U, T, X or Z-shape.
width
height
depth (length)
with thickness
height thickness
subdivisions height
shape
splitCap
sideLength1
sideLength2
fillet
fillet Radius
fillet as fraction
degree (linear or
cubic)
Four-Sided Object
Three different four-sided
shaped NURBS curves: Kite
(includes Rhombus),
Parallelogram, Trapezium.
Has different modes, note
that not any attribute works
on any mode. Available only
as a linear curve at the
moment.
Fillet N-Gon
width
height
sideLength1
sideLength1
Angle
Offset
Shape Mode ( 1 or 2 )
radius
fillet
fillet Radius
segments
degree (linear or
cubic)
Star
A NURBS curve star. The
twist parameter twists the
tines.
radius 1 (inner)
radius 2 (outer)
tines
twist
degree (linear or
cubic)
Flower
A NURBS curve Flower.
radius 1 (inner)
radius 2 (outer)
petals
degree (linear or
cubic)
Gear
A NURBS curve cogwheel.
The bevel, offset and taper
attributes are normalized
factors concerning cogdimensions.
Standard Profile
root radius
pitch radius
tip radius
cogs
root offset
tip offset
cog width
degree (linear or
cubic)
twist
width
height
width thickness
height thickness
shape
2 Important Notice
In several cases it would make sense to limit certain attributes in connection to other
attributes values, e.g. radius1 should never be greater than radius2. However that would
cause the following problem: In Maya, one can animate every attribute. So what happens if
two attributes are keyframed, but one attribute limits the other? One value would be in a
state which does not correspond to what you see in Maya.
For that reason I decided not to implement any limitations between attributes. That may
lead to unexpected or unusable results, it is the user's responsibility to deal with that.
I can't really explain what the problem is and if this is only a bug or a general problem.
However, because of that and because of the fact that also the bevel way produces a
triangle (at least when having an odd number of subdivisions) I decided to do it the other
way.
I know it is no good for smooth poly/SubD modeling but neither of the two ways is really.
Furthermore all in my opinion those primitives are better suited in a non-organic poly
workflow. Not that I would bar someone from doing so ;) but I personally just wouldn't use
the bevel cube as a basis for smooth-poly modeling in this case you just have other/better
means to get round edges.