3D Modelling Company: A Practical Selection Guide

How to choose a 3D modelling company for game production

A game asset can look convincing in a portfolio and still be expensive or impractical to use in production. Before hiring a 3D modelling company, art directors need to know whether the provider can turn a creative brief into an asset that fits the engine, the animation system, the target hardware, and the remaining production schedule.

The strongest supplier relationship is built around an inspectable workflow rather than a general promise to create high-quality assets. Briefs should define the deliverable, technical limits, review points, ownership boundaries, and acceptance criteria before modeling begins. That comparison becomes especially important when a team needs characters, props, environments, or other reusable assets without extending its internal capacity.

This guide is aimed at studio leads, producers, art directors, and technical artists evaluating external support. It explains how to compare modeling teams, write a usable brief, test a first asset, and control revisions. A portfolio can establish visual range, but it cannot by itself prove production reliability, topology quality, documentation standards, or the ability to meet a project milestone.

What a game-focused modelling partner should deliver

A reliable partner should deliver more than a visually attractive mesh. The model must be built for a defined use, prepared for downstream work, and tested in the conditions that matter to the game. The exact package depends on the asset, but the acceptance criteria should always describe what the receiving team can inspect and use.

For character work, a complete package may include a high-resolution sculpt, production topology, UVs, textures, material assignments, a rig, weight painting, reference poses, and engine-ready export files. An environment asset may instead require modular pieces, collision meshes, material variants, lighting or blueprint data, and assembly instructions. These are possible examples of deliverables, not universal requirements.

Deliverable area	What the studio should be able to inspect	Common production question
Source asset	Layered, named, and organized working files	Can another artist take over the asset without reconstructing its structure?
Game-ready mesh	Intended triangle count, topology, pivots, naming, and scale	Does the mesh meet the agreed technical budget?
Materials	Texture layout, material channels, resolution, and compression rules	Can the asset be imported and adjusted inside the engine?
Character deformation	Rig, skin weights, test poses, and deformation notes where applicable	Does the mesh deform correctly in the required animations?
Environment integration	Module dimensions, collision, variants, and assembly guidance	Can the art team assemble and reuse the pieces as intended?
Handoff	Export settings, file manifest, known limitations, and revision history	Is it clear which files and versions are authoritative?

Separate visual quality from production quality

Visual quality determines whether an asset supports the game’s art direction. Production quality determines whether the team can animate, optimize, combine, reuse, maintain, and ship it. A model can score well in a still render yet fail in a rig test, engine import, or modular scene assembly.

When comparing vendors, use the same evaluation rubric for every candidate. Ask for evidence from a relevant asset type and ask the supplier to explain the decisions behind it. A finished portfolio image with dramatic lighting may hide a dense mesh, a stretched UV, unstable topology, or a file structure that would increase the receiving studio’s workload.

Evaluation area	Weak evidence	Useful evidence
Art direction	One attractive render with no context	Turnaround views and a clear explanation of the intended style
Topology	Claims that the model is “clean”	Wireframe or topology views plus a discussion of deformation and editing needs
Game readiness	A generic marketplace-style export	Assets shown in an engine, with import settings and technical targets documented
Scale	Unlabelled dimensions	Defined units, reference dimensions, and pivots
Reuse	A single finished prop	Variants, material swaps, or modular pieces demonstrated
Documentation	Files sent without guidance	A manifest, naming standard, texture guide, and known limitations

The receiving studio should also be candid about what its pipeline can absorb. A provider may be able to produce an excellent sculpt but not support the studio’s engine, version control system, or automated asset validation. Conversely, a production-focused vendor may produce work that is technically compliant but visually too generic. Both are commercial risks if they are not identified during evaluation.

Define the asset and the decision it must enable

Many weak outsourcing briefs describe a subject without defining its job. “Create a sci-fi crate” is not enough. The brief should say whether the crate is hero scenery, a repeated prop, a physics object, a destructible object, or part of a larger modular kit. Each use changes the modeling and testing priorities.

Start by connecting the assignment to a production decision. A studio may need a provider because a named asset is blocking environment layout, or because a character milestone has more approved work than the internal team can complete. The selected company should help refine the request, not hide ambiguity behind a broad estimate.

State the asset and its role. Describe the object, character, creature, environment, or kit and explain how it appears in the game.
Define the target platform or hardware. Record any supplied triangle, texture, memory, or frame-time constraints. Do not ask the vendor to invent requirements the studio has not approved.
List the required output stages. Separate optional additions from mandatory deliverables such as topology, UVs, textures, rigging, LODs, collision, or an engine import.
Attach the visual references. Include approved concept art, measurements, material notes, lighting references, and comparable assets from the same project.
Define the review process. State who provides feedback, which round includes structural changes, and what must be true for final acceptance.
Set the handoff format. Name expected file formats, folder structure, naming rules, version-control approach, and required documentation.

A useful brief distinguishes requirements from preferences. Triangle count might be a hard engine constraint, while a particular camera angle might only be needed for promotional presentation. Confusing those categories creates unnecessary revisions and weakens cost comparison.

Build a brief that reduces revision risk

The brief is a control mechanism. It lets the studio and supplier identify ambiguity before paid work starts. It should contain enough detail for an artist to act, but it should not prescribe every brush stroke. Leaving room for craft is important when the provider has a legitimate reason to solve a visual or technical problem.

Divide the brief into six sections. First, provide context about the game, the asset’s function, and the intended player-facing result. Second, define the visual target through approved references and written notes. Third, specify production constraints. Fourth, list the deliverables and the required file formats. Fifth, describe collaboration and review. Sixth, state acceptance criteria and ownership terms.

Brief section	Include	Exclude
Context	Game genre, asset role, target sequence, and intended experience	Unrelated genre history or broad marketing language
Visual target	Approved references, shape, proportion, material, wear, and scale	Multiple contradictory style directions
Technical target	Engine, platform, budget, scale, pivots, LODs, and validation steps	Undefined terms such as “optimized” or “game-ready”
Deliverables	Exact asset states, formats, resolution, naming, and documentation	Assumptions that a final Blender or Maya file always satisfies the need
Review plan	Reviewers, milestones, response times, and revision scope	Open-ended approval with no responsible decision-maker
Acceptance	Measurable checks and signed-off reference frames	Approval based only on subjective preference

For an animation-heavy character, include a pose list and required deformation views. For an environment kit, provide the camera space, modular grid, collision expectations, and gameplay interactions. For a collectible or inventory object, specify whether the same model is seen at different sizes. This prevents the classic mismatch where a studio approves a beauty asset that does not function in its actual game context.

Use a paid test to test the working relationship

A small paid test can be more informative than a long questionnaire. Select a representative but contained task that exercises the studio’s real production constraints. It should be narrow enough to review clearly and substantial enough to reveal how the supplier interprets a brief, organizes files, communicates progress, and handles feedback.

The strongest test is not necessarily the most complex sculpt. A modest prop can expose naming, scale, UV, material, import, and documentation weaknesses. A stylized character can expose blocking, topology, rig, and iteration discipline. The test should mimic a milestone in the actual project while avoiding the ambiguity of a full production asset.

Give every candidate the same brief, reference bundle, and technical constraints.
Ask each supplier to identify missing information before work starts.
Schedule a brief kickoff and one intermediate checkpoint.
Evaluate the work in the engine or target context, not only in a render.
Score the files and communication separately from visual style.
Record whether requested corrections were resolved without resetting agreed boundaries.

Do not let free-concept work become an unbounded test. A supplier can spend considerable time on a polished sample that will never become a contracted asset. Paid tests clarify expectations, but the contract should define how approved test work is used and whether it carries into the wider project.

Compare quotes on scope rather than headline price

Comparing a total price without normalizing scope produces false savings. Two providers may quote the same amount for very different results: one may include only a textured model, while the other may include topology review, rigging, multiple LODs, collision, source files, documentation, and an engine test.

Ask for a deliverable matrix and identify which costs are fixed, which depend on revisions, and which are separate services. The studio should also establish what happens if the concept changes after modeling starts. A provider may need a new estimate because structural work has already been completed, while a simple texture adjustment may fall inside the agreed revision allowance.

Cost item	Questions for the quote	Control for comparison
Base asset	What exact model state does the price cover?	Compare equivalent mesh, texture, and material states
Additional stages	Are rigging, LODs, collision, or variants separate?	Price optional stages individually
Revisions	How many rounds and what type of feedback are included?	Define categories such as minor, structural, and new scope
Source files	Which working files, versions, and naming are delivered?	Require a file manifest for every quote
Technical adaptation	Does the supplier import and validate the asset in the target engine?	Specify the engine, version, and test scene
Schedule	Which dates depend on feedback turnaround?	Make dependencies visible in the project plan

Price is only one part of the production decision. A lower quote can become more expensive if it omits validation, causes a rework cycle, or arrives after the milestone that needed the asset. The relevant comparison is the cost of an approved, usable asset at the required milestone, including studio time spent fixing unclear files and resolving preventable issues.

Test the files in the real engine workflow

The common standard is reproducibility. Another artist should be able to understand the asset, make controlled changes, and move it into the game pipeline without reverse-engineering undocumented decisions. The production stages outlined in this 3D character modeling creation guide provide a useful reference for discussing concept development, sculpting, topology, rigging, skinning, rendering, and animation as connected activities rather than isolated deliverables.

An asset is not finished when the modeling software opens it without an error. The receiving team should confirm that the imported result behaves as expected. Technical validation often exposes problems hidden by the source application, especially around scale, axes, material interpretation, texture compression, naming, and animation setup.

Use a controlled import test with the same engine version, import settings, and representative scene conditions used by the project. Record the result rather than relying on a verbal assurance that the file works. The test should cover the operations the game will perform, not only whether the asset appears in the viewport.

Confirm dimensions, orientation, origin, pivot placement, and naming.
Check mesh budgets and inspect for unexpected dense areas or hidden geometry.
Verify material assignments, texture packing, resolution, and compression artifacts.
Test LOD transitions or equivalent performance representations where required.
Exercise collision, interaction, or animation behavior where those features are part of the asset.
Record warnings, missing dependencies, and manual steps required after import.

For a character, deformation is the decisive test. A neutral portrait can conceal tight areas around the shoulders, hips, knees, or face. Test the actual rig against representative poses and camera distances. For environment assets, assemble the pieces in a realistic scene and check seams, collisions, repeatable dimensions, and interactions with gameplay systems. This is where technical and art review meet.

Control revisions with decision rights and acceptance criteria

Revision disputes usually come from unclear authority, not from unusually difficult art. The studio must know who can approve a milestone, who consolidates feedback, and when a change is treated as a new requirement. The supplier must know which decisions are fixed for the current stage.

Every review should identify the asset state being judged. “The face is wrong” is not actionable feedback. A marked view, reference frame, and explanation of the intended change creates a testable outcome. Comments should distinguish visual corrections, technical defects, new features, and changes caused by upstream concept revisions.

Freeze the review baseline. Record the submitted version, brief, reference images, and milestone.
Consolidate feedback. Assign one producer or art lead to merge duplicate or conflicting notes.
Classify requests. Mark each note as correction, refinement, defect, or scope change.
Resolve dependencies. Note whether a correction must wait for an upstream decision.
Approve against criteria. State exactly which conditions have been met and which remain open.
Lock accepted files. Preserve the approved version and document subsequent changes.

Acceptance should be based on the brief, not on a supplier’s confidence that the work looks finished. A useful acceptance statement might confirm that the silhouette matches the approved reference, the asset uses the agreed scale and naming, the texture set imports without missing dependencies, and the file package contains the listed deliverables. It should also record any accepted limitations so they do not reappear as new defects later.

Use a structured pilot before a broader commitment

A broader engagement is safer when the studio has observed the supplier under realistic conditions. A pilot can test communication, adherence to a technical brief, source-file quality, and revision behavior on a bounded work package. It also gives both sides a chance to identify process gaps before they appear in a larger milestone.

The pilot should have a written entry condition, a fixed scope, a review schedule, and a defined exit decision. The supplier should understand that the test can be evaluated on process as well as visuals. The studio should enter with a representative brief rather than an intentionally easy exercise.

At the end of the pilot, ask the art, technical art, and production teams to assess the work separately. Their concerns may differ. Artists may focus on silhouette and materials, while technical artists examine topology and import behavior. Producers will notice missed dependencies, weak version control, and unclear ownership. The strongest recommendation combines these views rather than averaging them into a vague score.

Pilot dimension	Question to answer	Recommended evidence
Brief comprehension	Did the supplier identify constraints and ask useful questions?	Kickoff notes, clarification log, and milestone plan
Art execution	Does the result satisfy the approved visual target?	Turnaround, comparison views, and art review
Technical execution	Does the asset pass the agreed production checks?	Engine import, topology inspection, and test results
Collaboration	Are updates and feedback actionable and timely?	Checkpoint records and revision log
Handoff	Can another team member use the files without support?	Package audit and documentation review
Commercial predictability	Did scope, revisions, and change requests remain controlled?	Estimate comparison and final change log

If the pilot reveals repeated late escalations or unclear file ownership, fix the process before increasing the order. If the supplier cannot maintain basic communication in a small project, a larger one will not make that risk disappear. If the work is strong but the documentation is weak, contract a specific handoff deliverable rather than accepting an informal habit that will complicate maintenance.

Protect ownership and keep the project maintainable

Commercial terms should cover the work the studio receives, the rights needed to use and modify it, confidentiality, approved third-party material, and what happens to source files at project completion. A deliverable can technically belong to the studio while remaining practically unusable if the supplier retains the only editable copy or withholds essential components.

Ownership language should be connected to the actual asset package. Define whether the agreement includes source geometry, texture files, rigs, weight data, working files, and documentation. If the provider uses third-party add-ons, licensed scans, or reference material, require disclosure rather than assuming those components are covered by the contractor’s ownership promise.

Long-term maintainability also depends on naming and organization. Ask for a manifest that identifies the authoritative file for each asset and records engine-specific exports separately from editable source. Version-control conventions should prevent generic names such as “final” and “final2” from becoming the only way to distinguish revisions. A naming system is useful only if the supplied documentation explains it.

Require editable source files, not only flattened or packaged exports.
Identify third-party components and their permitted use.
Define confidentiality and access rules for unreleased concepts and builds.
Record which party may approve revisions and changes to the brief.
Specify delivery of the final source, engine export, textures, and documentation.
Confirm how the studio can maintain or replace the asset after production.

What a 3D modelling company should include in its proposal

A serious proposal should let the studio understand the proposed method, not merely display attractive images. It should connect the supplier’s approach to the asset’s visual and technical requirements. The depth of detail may vary, but the proposal should make dependencies visible.

Ask which stages the supplier will perform, which outputs remain editable, how progress will be reviewed, and how the project will be validated. A response that relies on broad claims about quality or experience is less useful than one that explains a concrete workflow.

Proposal section	Useful question	Signals careful scoping
Understanding	How will the supplier connect the model to its role in the game?	The response references the brief, camera context, and intended use
Method	Which stages are in scope, and which need studio inputs?	Block-out, sculpt, topology, materials, and validation are assigned
Technical plan	How will scale, topology, textures, and import be checked?	Checks correspond to the project’s actual constraints
Schedule	Which milestone unlocks the next stage?	Dependencies and review windows are named
Revisions	How are corrections separated from new scope?	The process recognizes structural and non-structural changes
Deliverables	What files, states, and documentation will arrive?	The package is specific enough to audit

Ask the supplier to identify where it needs help from the studio. Strong providers can usually explain which concept decisions, reference files, engine settings, or feedback must come from the client. A proposal that claims no dependency may be less honest than one that names the collaboration required to succeed.

Make the final decision on production evidence

The best 3D modelling company is not automatically the one with the widest range of styles or the most dramatic portfolio. The best fit is the supplier that can meet the asset’s artistic target, technical constraints, milestone, and maintenance needs while communicating clearly enough for the studio to make decisions with confidence.

Reduce the evaluation to five checks before signing a larger agreement:

Art fit: Can the supplier reproduce the approved direction rather than merely work in a related style?
Technical fit: Does the provider understand the engine constraints, downstream pipeline, and required validation?
Process fit: Are milestones, feedback, revisions, and file ownership defined clearly?
Capacity fit: Can the supplier meet the schedule while preserving the agreed review points?
Handoff fit: Will the studio receive editable, documented files that another team member can maintain?

A practical way to finalize the decision is to review the pilot against a one-page acceptance sheet. List the approved brief, test results, unresolved risks, final file inventory, and the exact conditions for scaling up. If any required point remains ambiguous, resolve it in writing before the next batch of assets enters production.

Frequently asked questions

What should I look for when choosing a 3D modelling company?

Look for evidence that the supplier can meet the asset’s art target, technical budget, schedule, and handoff requirements. Review a relevant pilot, source files, engine imports, communication behavior, and revision handling. Portfolio quality matters, but it should be considered alongside production evidence.

Should I choose the company with the lowest quote?

Not automatically. Normalize the quotes so that they cover equivalent deliverables, revisions, file formats, documentation, and testing. A lower quote can cost more if the studio must re-model assets, rebuild materials, correct imports, or resolve unclear handoff packages.

What files should a modelling company deliver?

The exact package depends on the project, but it may include editable source files, production meshes, UV layouts, textures, materials, rigs, weights, LODs, collision, engine exports, and documentation. The contract should name each required file and its expected state instead of relying on the term “game-ready.”

How many revisions should a contract include?

The contract should describe revision categories, responsible reviewers, feedback turnaround, and the boundary between corrections and new work. Number of rounds alone is less useful than defining whether the allowance covers minor adjustments, material changes, structural changes, or entirely new features.

Do I need a paid test before outsourcing a large batch?

A paid test is advisable when the work is technically complex, the asset has downstream dependencies, or the supplier is new. Use a bounded task that resembles the production work and evaluate the result in the actual engine context. The test should have a written scope, schedule, and exit decision.

Should a 3D modelling company provide rigging and animation?

Only if those stages are required and included in the quote. Modeling, rigging, skinning, and animation have different deliverables, specialist needs, and review criteria. Define the boundary between them so the studio does not receive an asset that looks finished but cannot meet its animation requirements.

How do I verify that a model is game-ready?

Import it into the intended engine using the project’s pipeline, then test scale, naming, materials, textures, performance representations, collision, and deformation where relevant. A file opening successfully in a modeling application is not sufficient evidence that it is ready for production.

What should happen if I change the concept during production?

The studio and supplier should classify the change, identify which completed stages it invalidates, and agree on the cost and schedule impact before additional work begins. Upstream concept changes may affect more than the visible model, including topology, textures, rigging, and downstream schedules.

Can an external modelling team work with an internal art team?

Yes, if responsibilities are explicit. Internal artists may own concepts, art direction, review, or integration while an external team handles defined production stages. Shared folders, naming rules, review forums, and named decision-makers are necessary to prevent feedback from becoming fragmented.

How should ownership and source files be handled?

The agreement should state which source geometry, textures, rigs, documentation, and engine exports the studio receives, along with the rights to use and modify them. It should also identify any third-party components, preserve editable working files, and ensure that the final package can be maintained without relying on undocumented supplier knowledge.

Veltrixia Games

Menu

How to Choose a 3D Modelling Company for Game Production