A camera sees an image. An avatar needs instructions. The space between those two is where much of the useful work in camera-driven character systems happens.
NVIDIA's April AR SDK programming guide documents face and body tracking, feature configuration, image buffers and output data. It is a developer toolkit for obtaining estimates, rather than a complete character with an opinion about how those estimates should be used.
Suppose the tracker reports the orientation of a person's head. A realistic avatar might follow that orientation closely. A small cartoon character may need a larger visible turn to convey the same intention. A character with an enormous head might need a reduced movement to avoid looking unstable. The measurement is shared; the interpretation depends on the character.
Facial proportions introduce a similar issue. The distance between two image landmarks does not directly describe how far a different character should open its mouth. A useful mapping needs a reference state and some normalization. Otherwise moving closer to the camera could change the apparent expression even if the person's face stays the same.
I would begin with a deliberately limited vocabulary: head orientation, a few broad facial changes, and clear handling of tracking loss. That is enough to judge whether the character feels connected to the person. Adding dozens of controls before the basic relationship feels right can make failures harder to understand.
The neutral pose is particularly important. An avatar that appears tense or surprised while the operator is resting becomes tiring to watch. Calibration is not only a technical initialization step; it defines what the character considers ordinary. Different people may need different mappings to reach the same readable result.
Timing affects expression too. If the head turns promptly but the mouth follows much later, the character feels assembled from disconnected streams. A frame identifier or timestamp should travel with the measurements. Smoothing can be useful, but it should be chosen with the complete motion in mind rather than applied independently everywhere.
A communication avatar also needs behavior when the camera cannot see enough. It could ease toward a resting pose, hold briefly, or signal that tracking has been lost. The appropriate choice depends on the use. A performance tool and a casual call have different expectations, but neither benefits from a violently jumping face.
This is why I would evaluate a camera-driven avatar in conversation rather than only in a demonstration of exaggerated expressions. Listening, glancing aside and beginning to speak are revealing movements. They show whether the system preserves the quieter parts of communication.
The SDK makes the observation side more accessible. The expressive side still needs deliberate design. A successful avatar should make the person's intention easier to read, using the available measurements as material rather than treating them as a finished performance.