3D Animator/Rigger (Contract - Project Based)

WISEcode· United States· lever· veröffentlicht 31.07.2026
Muss:ReactMobileAI

Project Overview: WISEcode Modular Owl Character System Project Overview

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.

  1. 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.

  1. 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.

  1. 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.

  1. 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.

  1. 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.

  1. 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.

Candidate Submission Requirements Applicants should provide:

Character-modeling portfolio

Rigging reel

Facial-rig examples

Creature, bird, or winged-character examples

Real-time character examples

GLB/glTF export examples

Animation reel

Rig-control demonstration

Proposed production software

Recommended technical approach

Proposed milestones

Cost by project phase

Revision policy

Testing and quality-assurance process

Any risks or recommended changes to this scope

Applicants must identify which portions of the work they will complete personally and whether any parts will be subcontracted.

Suggested Project Phases Phase 1: Model and Technical Direction

Character translation

Turnaround approval

Production model

Topology and UVs

Initial materials

Technical pipeline confirmation

Phase 2: Rig and Character Controls

Complete body rig

Face and eye rig

Wing and feather controls

Expression system

Color preset system

Initial GLB export test

Phase 3: Core Animation Library

Idle states

Communication gestures

Product-analysis states

Score reactions

Essential emotional reactions

Basic movement and flight

Transitions

Phase 4: Optimization and Handoff

Real-time optimization

Final GLB testing

Animation naming and cleanup

Documentation

Source files

Developer handoff

Final quality assurance

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