3D Character Artist, Technical Rigger, and Animator

Project Overview: WISEcode Modular Owl Character System

This is not a request for a static model or a single finished animation. We need a master owl asset that can be recolored, posed, animated, exported, and placed into any digital environment without rebuilding the character.

The owl will be used across:

• WISEcode products and applications
• Websites and interactive experiences
• Product onboarding and education
• Marketing and social media
• Video and motion graphics
• Future conversational and AI experiences

The character must preserve the design, proportions, personality, and visual identity of the existing WISEcode owl.

Core Project Goal

Create one production-ready master owl that can:

• Change between approved color variations
• Be posed and animated through a professional control rig
• Support expressive facial and full-body animation
• Be rendered against transparent or custom backgrounds
• Be exported as an optimized GLB for web and application use
• Support future accessories, animations, and character variations
• Be maintained by another qualified artist or developer after handoff

The master system should initially support our blue , green , and red owl characters without requiring separate models or rigs.

Must Have Project Requirements

Accurate 3D Character Model

The artist must create a complete three-dimensional interpretation of the supplied WISEcode owl.

The model must include:

• Complete front, back, side, top, and underside geometry
• Fully modeled wings, body, head, tail, feet, and talons
• Functional eyes, eyelids, beak, and mouth
• A clean silhouette from every viewing angle
• Animation-ready topology
• Clean UVs, normals, and deformation areas
• Optimized geometry suitable for both rendering and real-time use

The finished owl must look like the supplied character—not a generic, realistic, or redesigned owl.

2. Complete Character Rig

The owl must have a professional, animator-friendly control rig.

The rig must provide direct control over:

Face and Head

• Head and neck
• Eyes and independent eye direction
• Pupils and iris scale
• Upper and lower eyelids
• Blinks and winks
• Brows or expressive eye shapes
• Beak and jaw
• Mouth and tongue where required
• Facial expressions
• Ear tufts

Body

• Spine and torso
• Chest and belly
• Squash and stretch where appropriate
• Body lean and weight shifts
• Root and center-of-gravity control

Wings

• Independent left and right wings
• Wing folding and spreading
• Wing-tip gestures
• Primary and secondary feather groups
• Feather fanning and overlap
• FK and any appropriate assisted controls

Lower Body

• Legs and feet
• Individual or grouped talon controls
• Ground contact
• Foot placement
• IK/FK functionality where appropriate
• Perching and gripping poses

Tail and Feathers

• Tail direction and fanning
• Major feather-group controls
• Ear-tuft and feather secondary motion
• Manual control over any automated movement

Every major control must be clearly named and logically organized.

3. Modular Color and Material System

The character must support multiple branded owl identities from the same master model.

At minimum, the following regions should be independently adjustable:

• Main body
• Face
• Chest and belly
• Wings
• Wing tips
• Tail
• Ear tufts
• Eye iris
• Eyelids
• Beak
• Feet and talons
• Accent markings

The initial system must include tested presets for:

• Blue owl
• Green owl
• Red owl

Color changes must not require repainting textures, duplicating the rig, or rebuilding the character.

Materials should be organized so future seasonal, promotional, metallic, or special-edition variations can be added efficiently.

4. Facial Expression and Speech System

The owl must communicate emotion clearly through its eyes, eyelids, beak, head, and face.

The system must support core expressions such as:

• Neutral
• Happy
• Excited
• Proud
• Curious
• Thinking
• Confused
• Concerned
• Disappointed
• Surprised
• Skeptical
• Frustrated
• Warning
• Tired
• Playful

Expressions should be adjustable and, where practical, blendable.

The character must also support:

• Beak opening and closing
• Stylized speech movement
• Basic visemes or equivalent speech shapes
• Automated or hand-authored lip-sync workflows
• Facial animation independent from body animation

The final solution should allow the owl to speak naturally without forcing human mouth anatomy onto the character.

5. Core Animation System

The initial animation library should focus on reusable product and brand behaviors rather than a massive list of isolated animations.

Required Animation Categories

Idle and Awareness

• Neutral idle
• Attentive or listening idle
• Thinking or processing idle
• Happy idle
• Concerned idle
• Natural blinking and gaze
• Head tilts and observational movements

Communication

• Speaking
• Listening
• Explaining
• Pointing
• Presenting
• Nodding yes
• Shaking no
• Waving
• Encouraging
• Asking a question

Product Reactions

• Starting a scan
• Processing or analyzing
• Scan complete
• Scan unsuccessful
• Score reveal
• Positive-score reaction
• Mixed-score reaction
• Low-score or warning reaction
• Comparing two or more products
• Suggesting a better option
• Success
• Error
• Try again

Emotional Reactions

• Happy
• Celebrating
• Curious
• Thinking
• Confused
• Surprised
• Concerned
• Disappointed
• Supportive
• Warning

Basic Movement

• Standing
• Walking or hopping
• Turning
• Takeoff
• Hovering
• Flying
• Landing
• Perching

The selected candidate will help determine the exact animation list, variations, and production priority.

6. Animation Architecture

Animations must be reusable, clearly named, and delivered as separate clips or actions.

The animation system should support:

• Clean looping
• Smooth transitions
• Crossfading between states
• Layered facial and body animation
• Gaze control independent of the main animation
• Blinking during other actions
• Speaking while gesturing
• Emotion layered over idle or speech
• Left- and right-facing variations where needed
• In-place and root-motion versions where appropriate

The owl should be able to transition naturally among states such as:

• Idle to listening
• Listening to thinking
• Thinking to speaking
• Speaking to a reaction
• Reaction back to idle
• Standing to takeoff
• Flight to landing

The artist should establish consistent starting and ending poses so animations can blend without visible snapping.

7. Real-Time and GLB Requirements

The final GLB must be tested as a functional production asset—not only exported successfully from the source software.

The GLB must:

• Load in modern browsers
• Preserve the skeleton and approved animations
• Preserve materials and color variations
• Maintain correct scale and orientation
• Work with Three.js and React Three Fiber
• Support transparent rendering
• Avoid missing textures or external dependencies
• Avoid unsupported rig constraints
• Be reasonably optimized for web and application use
• Allow animations to be triggered individually by name

Any simulation, constraint, or procedural motion that cannot be exported must be baked into supported bones, shape keys, or animation data.

Required Deliverables

The final production handoff must include:

Master Assets

• Rigged master Blender file
• High-quality master model
• Optimized real-time model
• Approved lower-detail version if required
• Blue, green, and red material presets
• Complete UVs and texture-source files
• Shape keys or blend shapes
• Facial-expression controls
• Speech or viseme controls
• Feather and secondary-motion controls

Animation Assets

• Approved core animation library
• Separate, clearly named animation clips
• Facial-expression presets
• Pose library
• Transition animations
• Real-time optimized animation data
• Animation manifest listing each clip and its intended use

Export Assets

• GLB/glTF
• FBX
• Source texture files
• Transparent-background animation previews
• Still turntable renders
• Rig demonstration video
• Color-preset demonstration
• Test files showing animations running in the target environment

Documentation

• Rig-control guide
• Material and color-editing guide
• Animation naming guide
• GLB export instructions
• Instructions for creating new animations
• Instructions for adding accessories
• Instructions for adding new color variations
• List of dependencies and known limitations

All project source files and custom scripts created specifically for the project must be included in the handoff.

Technical Quality Standards

The completed asset must demonstrate:

• Clean topology
• Reliable deformation
• No broken or disconnected geometry
• No visible wing or feather clipping during approved animations
• No foot sliding during grounded movement
• Clean eye and eyelid movement
• Correct wing folding
• Stable feather behavior
• Consistent animation naming
• Clean animation curves
• Predictable animation transitions
• Organized files and collections
• No unexplained dependencies
• Successful GLB playback in the actual target environment

The rig should be intuitive enough that a qualified animator can use it without reverse-engineering the setup.

Items to Discuss With the Selected Candidate

The following should be finalized collaboratively based on the candidate’s technical approach and our implementation needs:

• Final polygon budgets
• Number and complexity of model LODs
• Bone count and real-time performance limits
• Bone-based versus geometry-based feather system
• Shape keys versus joint-based facial animation
• Exact viseme set and lip-sync workflow
• Level of individual feather control
• Physics-driven versus baked secondary motion
• Exact launch animation list
• Animation clip count by project phase
• Animation frame rate
• Root motion versus in-place movement
• Runtime material-switching method
• Accessory attachment system
• Three.js and React Three Fiber integration approach
• Mobile performance targets
• File-size targets
• Review schedule and animation approval batches

The candidate should explain the tradeoffs behind their recommended approach rather than simply selecting the most complex solution.

Candidate Value-Add Opportunities

A strong candidate may improve the project by proposing:

• A simplified animator-facing control panel
• A developer-facing control API
• Procedural eye tracking
• Procedural blinking
• Runtime gaze targeting
• Emotion-intensity controls
• Animation state-machine recommendations
• A reusable accessory socket system
• A lightweight mobile model
• Automated color-variant generation
• Automated GLB export tools
• Animation compression recommendations
• A browser-based character test environment
• Reusable animation layers
• Better methods for managing feather performance
• A scalable system for future owl personalities
• Integration documentation for developers
• A practical roadmap for expanding the animation library

These are not substitutes for the required deliverables. They are opportunities for the candidate to demonstrate technical leadership and improve long-term scalability.

Definition of Done

The project is complete when WISEcode receives one fully editable master owl system that:

• Faithfully matches the supplied owl design
• Supports the blue, green, and red character variations
• Provides complete control over the face, eyes, eyelids, beak, head, body, wings, major feathers, tail, legs, feet, and ear tufts
• Supports expressive facial and body animation
• Includes the approved core animation library
• Transitions cleanly between product states
• Exports to a functional, optimized GLB
• Can be placed into any transparent or custom environment
• Can be controlled by developers inside an interactive experience
• Can be expanded without rebuilding the model or rig
• Includes complete source files and usable documentation
• Has been tested in the actual target environment