The trickiest part of dealing with animation tracks in Python is the concept of DescIDs.
DescIDs are actually used throughout CINEMA 4D, but they’re especially important when working with animation tracks. A DescID is a multi-level ID structure for individual description elements. The DescID can define multiple levels of data, like with UserData, where the first element of the DescID is always ID_USERDATA and the second element is the index for each userdata element. The multiple levels of a DescID are also used for subchannels, like the individual vector elements of a Position, Scale, Rotation or Color element.
Each element of a DescID is a DescLevel. The DescLevel also has three elements - in this case, they are the id itself, the data type and the creator.
Let’s look at some examples:
If a description element doesn’t have sub-channels, the DescID is simply the ID of the description element.
# Track for Object Enabled Boolean enabled = c4d.CTrack(op, c4d.DescID(c4d.ID_BASEOBJECT_GENERATOR_FLAG)) op.InsertTrackSorted(enabled) # Track for Light Brightness Real track = c4d.CTrack(op,c4d.DescID(c4d.LIGHT_BRIGHTNESS)) op.InsertTrackSorted(track)
Note that each vector element has its own track, just like in C4D’s timeline. The DescID for each contains two levels. Level 1 in each case is the Position track itself, which has a VECTOR type. This is the parent Position element you see in the timeline. Level 2 is the vector element for this specific track, and has a REAL type.
trackX = c4d.CTrack(op,
c4d.DescID(c4d.DescLevel(c4d.ID_BASEOBJECT_POSITION,c4d.DTYPE_VECTOR,0),
c4d.DescLevel(c4d.VECTOR_X,c4d.DTYPE_REAL,0)))
trackY = c4d.CTrack(op,
c4d.DescID(c4d.DescLevel(c4d.ID_BASEOBJECT_POSITION,c4d.DTYPE_VECTOR,0),
c4d.DescLevel(c4d.VECTOR_Y,c4d.DTYPE_REAL,0)))
trackZ = c4d.CTrack(op,
c4d.DescID(c4d.DescLevel(c4d.ID_BASEOBJECT_POSITION,c4d.DTYPE_VECTOR,0),
c4d.DescLevel(c4d.VECTOR_Z,c4d.DTYPE_REAL,0)))
op.InsertTrackSorted(trackX)
op.InsertTrackSorted(trackY)
op.InsertTrackSorted(trackZ)
When you create userdata or iterate through the userdata container, the ID you get is the DescID. However, for elements with subchannels like vectors or color, you still have to add individual tracks for each subchannel. This code sample elaborates on DescIDs and DescLevels through some print statements and also contains a custom function that creates the appropriate tracks for certain userdata types. Not all possible types are considered - it’s just a start.
import c4d
def CreateUDTrack(op,id):
tracks = []
# element0 is always UD group
# element1 is the UD itself
ud = id[1]
dtype = ud.dtype
if dtype == c4d.DTYPE_VECTOR or dtype == c4d.DTYPE_COLOR:
# get datatypes with subchannels and add multiple tracks
for v in xrange(c4d.VECTOR_X, c4d.VECTOR_Z+1):
descID = c4d.DescID(id[0],id[1],c4d.DescLevel(v,c4d.DTYPE_REAL))
tracks.append(c4d.CTrack(op,descID))
else:
# just add the single track
tracks.append(c4d.CTrack(op,id))
return tracks
def main():
for id, bc in op.GetUserDataContainer():
# id is the DescID, bc is the container
print bc[c4d.DESC_NAME], id
# look at each DescLevel
# this isn't necessary, just instructive
for level in xrange(id.GetDepth()):
print "Level ", level, ": ", \
id[level].id, ",", \
id[level].dtype, ",", \
id[level].creator
# Create tracks using custom function
tracks = CreateUDTrack(op,id)
# Loop through returned tracks and insert
for track in tracks:
op.InsertTrackSorted(track)
if __name__=='__main__':
main()
In Release 13 and greater, you can use FindCTrack to find an existing animation track for a particular DescID. It’s a good idea to do this if you’re not sure if the track exists. Otherwise, C4D will just create additional tracks for the same parameter.
# Track for Light Brightness Real
dBrightness = c4d.DescID(c4d.LIGHT_BRIGHTNESS) #assign the DescID to a var for convenience
tBrightness = op.FindCTrack(dBrightness) #find the track
if not tBrightness: #if track isn't found, create it
tBrightness = c4d.CTrack(op,dBrightness)
op.InsertTrackSorted(tBrightness)
Once you have the necessary tracks, adding keys is relatively simple. All the keys are applied to an F-Curve, which is a CCurve object in Python. So first you have to get the CCurve, and then you can use AddKey or InsertKey to add keys to the curve. Note that you can use the CTrack method FillKey to fill a key with the default values for the track, setting the appropriate interpolation. Also, you should use SetValue when setting a float value, and SetGeData when setting any other data type.
#Get the curve
curve = track.GetCurve()
#Add keys using AddKey
#Creates the key at the proper time
#Then you modify the key
keyDict = curve.AddKey(c4d.BaseTime(0))
#keyDict is a dict with key=CKey and int=index
myKey = keyDict["key"]
#Use FillKey to fill the key with default values (interpolation)
trk.FillKey(doc,op,myKey)
#Use SetValue or SetGeData to set the key value
myKey.SetValue(curve,1)
#myKey.SetGeData(curve,1)
#Add keys using InsertKey
#Define the key first
key = c4d.CKey()
#Use FillKey to fill the key with default values (interpolation)
trk.FillKey(doc,op,key)
key.SetTime(curve,c4d.BaseTime(1))
key.SetValue(curve,.5)
#key.SetGeData(curve,1)
#Then insert it
curve.InsertKey(key)
A similar task also involving DescIDs is setting the Keyframe Selection for an Object. You can use this in conjunction with the record button to create tracks, but the direct method specified above is more robust. You might however wish to enable keyframe selection on specific description IDs if you’re generating a rig or other object in Python which the user will be animating.
# Put the "Position" desclevel in a variable for convenience pos = c4d.DescLevel(c4d.ID_BASEOBJECT_REL_POSITION, c4d.DA_VECTOR) # Set Keyframe selection on each vector X,Y,Z op.SetKeyframeSelection(c4d.DescID(pos,c4d.DescLevel(c4d.VECTOR_X, c4d.DA_REAL, c4d.DA_VECTOR)), True) op.SetKeyframeSelection(c4d.DescID(pos,c4d.DescLevel(c4d.VECTOR_Y, c4d.DA_REAL, c4d.DA_VECTOR)), True) op.SetKeyframeSelection(c4d.DescID(pos,c4d.DescLevel(c4d.VECTOR_Z, c4d.DA_REAL, c4d.DA_VECTOR)), True) # Update the C4D Interface c4d.EventAdd()
]]>
Typically, axis orientation is something to be aware of when you are working with hierarchies of objects, and you want the objects in that tree to work together as a cohesive group. This is especially true when you are building skeletons of joints for character animation. (Note: “character animation” can refer to organic creatures as well as mechanical objects that require a skeleton to perform the way you intend, whether or not a similar thing in the real world would have a skeleton.) Joints have a preferred direction, and they point along their Z axis. Should joints get created that do not point along their Z axis, you will need to re-orient them to correct that. In addition, it is possible for joints to point properly along their Z axis, but be misaligned with the other axes, as defined by their parents. For chains of joints to behave properly, all of the joints in the chain need to have the same orientation. In other words, if front is Z, then top is Y, and all of the joints in the joint chain need to honor that axis alignment.
Quite often, you will create scene elements that differ from the world orientation of Y up, Z front. If possible, you will have a much easier and more predictable experience if you orient your objects similarly to the world (unless you have specific reasons not to).
In all, stacking up objects in a hierarchy can really play with your head when it comes to controlling rotation values, due to the complexities of the math involved (see, math is important—you should have paid more attention in class!). There are many resources online which discuss the topic of rotations and their behavior, but the best discussion comes from Cactus Dan, a favorite among Cinema 4D users. Look up his character tutorials. There’s real gold there…
]]>
The axis is the representation of the coordinate system in use. When positioning an object, you are typically working in world space, child space, or local space, depending upon the location of the object within a hierarchy. Objects not associated with a hierarchy are said to be in world space. Objects with parents are said to be in child space or local space. This concept is important, as the numerical readouts for each axis will differ, depending upon what they are intended to show. For example, if you have a child of a parent that has not been moved, it will read X:0, Y:0, Z:0 for position. If you choose to move the child, or offset its position, you will then see the relative distance from the parent in the numerical position readout. Now, if you were looking at the same object, located in the same place but not parented, you will see drastically different information for X, Y and Z positions, as you will be seeing the actual world space location information for that object. If all you do is model or make poses, and don’t animate much, then the impact of the previous will be limited in your case. However, should you choose to animate more than occasionally, it suddenly becomes very important for you to have a good idea as to the previous. This is particularly true if you are writing expressions with Xpresso, using math functions, writing scripts or rigging characters and working with joints.
]]>
]]>
]]>
Three: 1.00 for the air, 1.33 for the water in the glass, and 1.52 for the water glass. That will get you the ballpark result. Why just ballpark? Well, the straw would also have an IOR, as all materials in our universe have an IOR, even those that we may percieve as opaque. Even opaque materials have some penetration of light, which is why you can use Fresnel shaders and SSS shaders on anything. Fortunately, you can decide when to say when, and concentrate only on those materials that really need to react to light with the proper IOR.
]]>
There are many different color spaces in use in DCC apps today. Adobe Photoshop has a fairly complete list of color spaces in that application’s color system. Not all color spaces are created equal; in fact, the reason that we have so many color spaces is due to the fact that there is no single color space that addresses all of the needs of those using computer imaging. Some color spaces are very similar, if not identical, such as Hue, Saturation and Luminance (HSL) and Hue, Saturation and Value (HSV). Incidentally, if you are working with lighting values, and you wish to animate them (like nightclub lighting), use HSV or HSL, as you can change color by animating the Hue—otherwise the color luminance and saturation will change, which is not typically something you want. And herein lies a good example of why you would want a color space other than RGB.
Typically, synthetic imaging like 3D rendering applications, tend to favor RGB, HSV/HSL and to a lesser degree, CMYK. Renderers always render in linear space.
Some color spaces favor certain colors or values over others. RGB favors brighter colors, and as a result, darker colors will show banding, requiring you to use dithering options if available. You can see how color systems favor colors in a curve plot. Further, were you to overlay different curve plots for different color systems on top of each other, you would clearly see that some colors in some systems are not even available in others. RGB and CMYK are examples of this, as are color spaces operating within different bit depths. Prior to the transition to digital television, the NTSC color space was shifted from the RGB spectrum. This was clear whenever the color orange was present, as orange is very strong as a color in the NTSC color space, while strong oranges in RGB are harder to achieve.
Fortunately, most of those problems are a thing of the past now. Digital displays are displacing analog tube-displays (CRTs), even though the analog displays can offer truer color rendering than liquid crystal displays (LCD). Fortunately, display manufacturers are adressing these issues. This discussion has long term impact, since theatrical projection is now digital in many markets, and will be in all markets soon. Digital projection systems have different color characteristics than your typical computer monitor (and they are much more expensive), so its wise to have a color check in a facility with the proper equipment if you are doing feature film work. If not, you might end up with some very upset clients on your hands.
]]>
Dithering uses various noise patterns to blend between values. As computer graphics moved from black and white to 256 shades of gray, on through 256 shades of color, and even today, with 24 bit color and beyond, dithering is still useful. If you are asking yourself, “why?” the answer is because there is no color system on a computer that can mimic the ability of the human eye to see the vast amount of colors that we perceive, and at infinite resolution. In addition, color systems are not linear in response. If you were to view a color system like RGB as a curve, you would see that 24 bit RGB favors brighter colors over darker ones. As a result, even though you may have 24 bit color, you will perceive bands (“mach bands”) of color in the shadows. Fortunately, you can use dithering to hide these bands, and the result is very effective. And, because the dithering appears as noise, we accept the result since the look mimics film grain.
]]>
]]>