Look Development: The Decisions That Matter

Look development is the stage of a 3D project where an asset's materials and its response to light are designed, tested and approved in isolation, before that asset appears in a single production shot. A lookdev artist takes a finished model, builds its shaders and textures, and proves on a controlled turntable that the surface reads correctly: that brushed aluminum looks like brushed aluminum from every angle, that a fabric keeps its weave under a hard key light, that a painted product matches the physical sample sitting on the client's desk.

It matters to anyone paying for or producing 3D imagery at volume: product marketers building a catalog of renders, agencies producing campaign visuals, architects and retail teams working with visualization studios, and in-house teams whose assets will be reused across dozens of shots and formats. The logic is simple. Approving a look once, in a controlled setup, is far cheaper than discovering halfway through shot production that a material falls apart under a different light, and then re-rendering every frame that used it.

This guide answers the questions that come up most often when teams plan, buy or run look development. Each section starts with the short answer and then gets into the detail: reference, turntables, lighting environments, color management, approval gates, time planning and the mistakes that cause the most rework.

What is look development, and where does it sit in a 3D pipeline?

Look development sits between modeling and shot production: it takes a geometrically finished asset and turns it into an approved, reusable surface definition that lighting and rendering can rely on. In a typical pipeline the order is modeling, UV layout, texturing and shading (which together make up most of lookdev), approval, and then the asset's hand-off to layout, lighting and rendering of actual shots.

The word "isolation" is the important part of the definition. During lookdev the asset is not sitting in a set, surrounded by props, lit for mood and seen through a single camera. It sits alone on a neutral stage, lit by known, repeatable lighting, rotating on a turntable so every surface is seen. That isolation is what makes the review fair. If a material looks wrong in a finished shot, it is hard to know whether the shader, the lighting, the camera exposure or the compositing is at fault. If it looks wrong on a standard turntable, the shader is the prime suspect.

What lookdev actually produces

The deliverable of look development is not a picture; it is a package. A well-run lookdev stage hands the next department:

• The shading network or material definitions, named consistently and assigned to the correct geometry groups.
• The texture set at agreed resolutions, color spaces and bit depths, with a naming convention the pipeline can parse.
• Approved turntable renders under each reference lighting environment, with the render settings used to make them.
• Notes on any known limits, such as a displacement map that needs a minimum subdivision level, or a clearcoat that looks too strong below a certain camera distance.
• An approval record: who signed off, on which version, and under which lighting.

Before that package is created, the geometry itself should have passed its own checks. Look development on a mesh with flipped normals, overlapping UVs or incorrect scale wastes shading time, which is why a disciplined process for validating 3D assets before they move downstream is a precondition rather than an optional extra.

When should look development start, and what must be finished first?

Look development should start as soon as the model's silhouette, scale and UV layout are locked, and not before. Shading on geometry that is still changing is one of the most common sources of wasted hours, because every topology or UV change can invalidate texture work that was painted or projected onto the old layout.

That does not mean lookdev waits in a queue doing nothing. Several parts of it can run in parallel with late modeling:

• Reference gathering can start on day one. Photographing a physical sample, sourcing manufacturer finish specifications and collecting material swatches does not depend on geometry at all.
• Lighting environments and the turntable scene can be built once for a whole project, or reused from a studio standard, before any asset is ready.
• Base material presets such as a studio's standard stainless steel, frosted glass or matte plastic can be calibrated against reference ahead of time and then applied and tuned per asset.
• Color management configuration should be decided and distributed to every workstation before the first texture is painted.

The lock points that matter

A practical rule is to define three lock points and write them into the schedule. The first is geometry lock: no silhouette or topology changes without a formal change request. The second is UV lock: texel density and UV layout are final, so painted maps will not need to be redone. The third is look lock: the material has been approved and may only be changed through a re-review. Each lock point should have a named owner who can grant exceptions, because exceptions will be needed and should be deliberate rather than accidental.

The file format used to hand geometry across tools also affects timing. If the model is authored in one package and shaded in another, the interchange path decides whether UV sets, normals, material assignments and scale survive the trip. It is worth settling which 3D file formats and interchange routes the project will use before lookdev begins, rather than discovering that a hand-off strips the material IDs the shader assignments depend on.

What reference does a look development artist actually need?

A look development artist needs physical or photographic reference of the actual material, captured under known lighting, and ideally with a color and gray calibration target in frame. Developing a look from memory, or from a brief that says "premium matte black," reliably produces a material that looks plausible in isolation and wrong next to the real product.

The reference hierarchy

Not all reference carries the same weight. In descending order of usefulness:

1. The physical object or a finish sample. Nothing replaces being able to tilt a sample under a desk lamp and watch how the highlight spreads, where the Fresnel effect brightens the edges, and whether the finish has a directional grain.
2. Calibrated photography of that object. Photographs shot with a color checker and a gray card in frame, at a known exposure, under simple and documented lighting. Several angles, including a grazing angle that reveals surface texture and a near-mirror angle that reveals the specular lobe.
3. Manufacturer specifications. Paint codes, finish descriptions, gloss units, fabric composition. These tell you what the surface is; they rarely tell you exactly how it renders, but they narrow the search.
4. Uncalibrated photography. Product shots from a website or a phone photo. Useful for understanding character, but treat color and brightness values as approximate, because you do not know the camera's processing or the display it was graded on.
5. Mood and style reference. Images that show the intended feel of the final work. These guide art direction, not material accuracy.

How to shoot usable reference

If the studio or client can photograph the sample, a few habits make the reference far more useful. Shoot in the camera's raw format so white balance and exposure can be corrected consistently. Include a color checker chart in at least one frame of each setup; the widely used 24-patch chart gives a set of known color values to calibrate against. Include a neutral gray card or gray ball, and if possible a chrome ball, which records the lighting environment so it can be approximated in the render. Keep the lighting simple, such as a single softbox plus ambient fill, and note the setup. Shoot the sample flat and at several tilt angles.

The payoff comes later. When a reviewer says "the render is too warm," the team can place the calibrated photograph and the render side by side, check the gray patch in both, and decide whether the difference is in the material, the lighting or the display, instead of arguing from memory.

How should the turntable and reference lighting environments be set up?

The turntable should rotate the asset a full 360 degrees under a small set of fixed, documented lighting environments, with a neutral backdrop, a gray and chrome reference ball, and camera settings that never change from asset to asset. The whole point is comparability: when two assets are reviewed on the same stage, any difference you see is a difference in the assets.

Components of a good lookdev stage

• A neutral backdrop or ground plane in a mid gray, so the asset's color is not pulled by a colored surround and contact shadows are visible.
• Reference spheres: a diffuse gray sphere shows how the lighting falls on a neutral surface, and a mirror sphere shows the environment reflected. Placed in frame beside the asset, they let a reviewer separate "the lighting changed" from "the material changed."
• A color chart rendered as a textured plane with the correct values in the working color space, which should look correct if the color pipeline is correct.
• A fixed camera with a locked focal length, exposure and framing rules, so every asset is seen at comparable scale and brightness.
• A turntable rotation of the asset, commonly paired with a separate slow rotation of the lighting environment so highlights travel across a stationary asset. The two reveal different problems: rotating the asset shows every face; rotating the light shows how the specular response behaves as the angle changes.

Choosing the reference lighting environments

Three to five environments usually cover the useful range. A typical set is a neutral, evenly lit studio HDRI for judging base color and roughness; a high-contrast setup with one hard key light for judging shape, bump and specular highlights; an outdoor daylight HDRI with a strong sun and blue sky fill; and, where relevant, a dim interior or night environment that reveals how dark materials and emissive elements behave. The exact choice depends on where the asset will end up. A kitchen appliance for e-commerce may not need a night exterior, but it does need a bright, soft studio setup that mimics product photography.

These environments should be treated as studio infrastructure, versioned and reused. Building and maintaining them is closely tied to the wider question of how lighting presets and rigs are standardized across a studio, since the same discipline that makes shot lighting repeatable makes lookdev reviews fair.

Render settings belong in the standard too. Sample counts, ray depth limits, and whether caustics or subsurface scattering are enabled all change how a material appears. If lookdev renders with higher ray depth than production will use, glass and liquids can look richer on the turntable than they ever will in shots. Running controlled render tests and parameter wedges on the turntable is the cleanest way to find settings that are both accurate and affordable.

Which color management decisions must be locked before shading begins?

The working color space, the texture color spaces, the view transform used to display renders, and the output transforms for delivery must all be decided and shared across every tool before the first material is built. If look development and shot production use different color pipelines, an approved material will not look the same in shots, and no amount of shader tweaking will fix a problem that lives in the display transform.

Most professional pipelines manage this with OpenColorIO, the open-source color management framework hosted by the Academy Software Foundation. OCIO lets a studio define a single configuration file that every supporting application reads, so a texture tagged as sRGB, a render in a linear scene-referred space, and a display set to a particular view transform are interpreted identically in the texturing tool, the renderer, the compositing package and the review player.

The decisions to write down

• Scene-linear working space. Rendering happens in linear light. The team needs to agree which linear space and primaries it uses, for example a linear Rec.709 space or an ACES working space such as ACEScg.
• Texture color space rules. Color textures such as base color are usually authored in an sRGB-encoded space and converted to linear; data textures such as roughness, metalness, normal and displacement must be read as raw, non-color data. Tagging a roughness map as sRGB is a classic error that silently changes how glossy a surface appears.
• View transform. How linear render data is mapped to the monitor. Different view transforms handle highlights and saturated colors very differently, so a material approved under one view transform can look clipped or dull under another.
• Delivery transforms. The output color space for web images, print, broadcast or HDR delivery.
• Review display calibration. Reviewers approving color should look at calibrated displays in a consistent viewing environment. An approval made on an uncalibrated laptop in bright daylight is only an approval of that screen.

Keeping color management consistent from look development through to delivery is one of the few rules in this field with almost no legitimate exceptions. If a client or partner studio needs to receive assets, the color configuration should travel with them, alongside the texture color-space tags.

How do you know a material will hold up in the actual shots?

You know a material will hold up only by testing it under the lighting conditions of the actual shots, at the distances and camera angles those shots use, before approval is final. A turntable proves the material is internally consistent and plausible; it does not prove it survives the specific backlight, colored practical or extreme close-up a particular shot demands. This is the hardest question in look development because the answer requires information from a stage of the pipeline that usually has not happened yet.

Why hero lighting approvals fail

A common and costly mistake is approving materials in the hero lighting setup only. A hero setup is usually flattering by design: soft key, clean rim light, generous fill. Materials tuned under it can hide a range of problems:

• A roughness map with too little variation looks elegant under soft light and turns plasticky under a hard sun.
• A subsurface scattering setting that reads as soft skin or wax under frontal light glows unnaturally when the asset is backlit.
• A bump or normal map that is invisible in diffuse light becomes a noisy, crawling pattern at grazing angles.
• A dark fabric that holds detail in a bright studio collapses into a flat black shape in a dim interior.
• A metallic finish that looks rich when reflecting a detailed HDRI looks gray and dead when reflecting a plain set with little to reflect.

Practical ways to test against shot conditions

The most effective technique is to collect a small set of "shot proxies" early. As soon as layout or previsualization gives a rough idea of the shots, extract the lighting environment and camera from two or three of the most demanding ones: the closest close-up, the harshest lighting, the most unusual color. Drop the lookdev asset into those proxies and render a handful of frames. They do not need to be finished; they need to be representative.

Where shots do not exist yet, as is common in product visualization, define the extremes from the brief. If the renders will be used for a website hero at large size, test a close crop at full resolution. If they will be used in a room scene, test with colored bounce light from walls. If an interactive configurator is planned, test in the real-time engine rather than assuming an offline render will translate, a question covered in depth in the guide to choosing between real-time and offline rendering.

Scale matters as much as light. A material viewed at five meters, at fifty centimeters and at five centimeters is effectively three different materials. Texture resolution, displacement detail and microsurface variation that are invisible at a distance become the whole image in a macro shot. The lookdev plan should say which distances the asset must support and test at each one.

Should you build a shared material library or shade every asset from scratch?

For most studios and in-house teams producing more than a handful of assets, a shared, calibrated material library is the better default, with bespoke shading reserved for hero assets and materials the library does not cover. The trade-off is consistency and speed against specificity, and the right balance depends on how many assets you produce and how much they need to match one another.

A library is a set of approved base materials, such as anodized aluminum, satin chrome, oak veneer, clear glass, matte ABS plastic and brushed steel, each developed against reference, reviewed on the standard turntable and documented with the parameters that may and may not be changed. Artists start from these and adjust within limits rather than starting from an empty shader. Both commercial renderers and open-source tools support this workflow; Pixar's RenderMan documentation and the Blender Foundation's material and shading guides both describe physically based material setups that lend themselves to reusable, parameterized presets.

Two rules keep a library healthy. First, version every library material and let assets reference a specific version, so that an improvement to "brushed steel v3" does not silently change an asset approved with v2. Second, record which library materials each asset uses, so that when a library change is intentional, you know exactly which assets need a re-review. Licensing deserves attention too: if the library includes purchased textures, scanned materials or third-party shaders, check that the terms cover client work and redistribution, which is part of the wider topic of licensing 3D models and assets.

What does a sound look development approval process look like?

A sound approval process gives every asset an explicit, recorded sign-off from a named decision-maker, on a specific version, under the standard lighting environments and at least one shot-representative setup, before the asset enters production shots. The approval is a gate, not a courtesy; assets that have not passed it should not be available to shot lighting.

Writing review notes that help

The quality of lookdev feedback determines how many rounds an asset takes. Useful notes name the lighting environment and frame, describe the difference from reference in physical terms, and say which direction to move. "In the hard key environment at frame 40, the highlight is too tight compared to the sample photo; the finish should look slightly more satin" is actionable. "Make it pop more" is not. Where several stakeholders review, consolidate notes before they reach the artist, so the artist is not asked to make the metal both warmer and cooler by different people in the same round.

Who should sign off

Keep the approver list short and explicit. In a product project, that is typically one person on the client side who can speak for brand and product accuracy, plus the studio's lead for technical soundness. If the product manager, brand manager and a regional marketing lead all have to approve, agree up front whose word is final on color, so that the approval does not stall on a disagreement between reviewers.

How long does look development take, and how should you plan for it?

Look development time depends mainly on the number of distinct materials, how closely they must match physical products, how many lighting conditions they must survive, and how many review rounds are needed; a simple asset reusing library materials may take hours, while a hero asset with bespoke finishes that must match a physical sample can take days. There is no honest single figure, but the drivers are predictable, which makes planning possible.

The main time drivers

• Material count and complexity. Five distinct finishes take longer than one. Layered materials such as car paint with flakes and clearcoat, woven fabrics, and translucent materials like skin, wax or frosted plastic take longer than opaque, uniform ones.
• Match requirement. "Looks plausible" is faster than "matches the physical sample on a calibrated screen." Matching usually adds reference capture, side-by-side comparison and additional revision rounds.
• Coverage. Each additional lighting environment and shot proxy adds render and review time.
• Review structure. The number of approvers and their turnaround time often matter more than artist hours. A two-day wait for feedback between rounds adds calendar time even if no one is working.
• Library reuse. Starting from calibrated library materials can remove a large share of the shading effort for common finishes.

Worked example: planning lookdev for a small product range

The following example is illustrative, not a client project, and the hours are planning assumptions rather than industry benchmarks. Imagine a home-appliance brand that needs photoreal renders of one kettle design in four colorways for e-commerce and a launch campaign. The kettle has five distinct materials: a painted steel body, a brushed stainless base, a glossy black plastic handle, a clear glass water window, and a small chrome logo badge. The client provides physical samples of all four paint colors.

Two points stand out in this example. First, the widest swing comes from whether the studio already has a standard turntable and library; with both in place, the low end of the range is realistic. Second, the four colorways cost far less than four separate assets, because once the painted steel material is correct in one color, the others are mostly base color adjustments checked against their samples. That is the real economic argument for lookdev: the investment in one correct material spreads across every variant and every shot that uses it.

Now consider the alternative. If the team skipped the shot-proxy stage and discovered during campaign rendering that the glass window looked flat under warm interior light, the fix would require revising the material, re-reviewing it, and re-rendering every image already produced with the kettle, across all four colorways. The few hours of proxy testing are an insurance premium against that outcome.

What are the most common look development mistakes, and how do you fix them?

The most common look development mistakes are approving materials in hero lighting only, developing looks without reference, running different color pipelines in lookdev and shot production, and changing approved materials without re-review. Each has a clear symptom and a clear fix.

Diagnosing a material that looks wrong in a shot

When a material that was approved looks wrong in a shot, work through a fixed order rather than immediately editing the shader. First, confirm the shot uses the approved material version. Second, check the display and view transform: is the shot being reviewed through the same color pipeline as lookdev? Third, drop the gray and chrome reference spheres into the shot and compare them to the lookdev stage; if the spheres look different, the lighting is the cause, not the material. Fourth, check render settings such as ray depth and sampling. Only when all of these match should the material itself be reopened, and any change should go back through review.

Specialized asset types need extra care. Heavy volumetric effects such as smoke, clouds or fire have their own lookdev considerations, including density scale and emission color, discussed in the guide to volumetrics and OpenVDB. Stylized projects follow the same principles of reference, standard lighting and approval, even when the target is a painterly or toon look rather than photorealism.

When is it worth bringing in outside look development help?

It is worth bringing in outside help when assets look inconsistent between shots, when materials must match a physical product precisely, or when a growing library needs a consistent look development standard that the current team does not have time to build. In each case the problem is less about artist skill and more about process, infrastructure and calibration.

Signs you need help

• Inconsistency between shots. The same product looks like a different color or finish depending on the image. This usually signals a missing standard: no shared lighting environments, no enforced color pipeline, or approvals given under a single setup.
• Physical product matching. E-commerce, packaging and product launch work is judged against the real object. Customers notice when the render and the delivered product differ, and returns or complaints can follow. Matching reliably needs calibrated reference capture, a managed color pipeline and disciplined review.
• Library standardization. Once a team is producing dozens or hundreds of assets, or several vendors are contributing, a documented lookdev standard with shared environments, material presets and approval rules becomes the thing that makes everything look like one brand.
• Pipeline transitions. Moving from offline rendering to a real-time engine, or adopting a new renderer, often changes how materials behave. An external team that has done the translation before can save many trial-and-error cycles.

What to ask a potential partner

Ask to see their turntable stage and reference lighting environments, and how they version them. Ask which color management configuration they use and how they hand it to clients. Ask how they capture and use reference, and what their approval process records. Ask for examples of the same asset shown under several lighting environments rather than a single polished hero image. A partner who can answer all of these clearly is offering a process, not just renders.

If you are weighing this for a product line, retail environment or campaign, our 3D visualization and rendering service covers lookdev as part of the production pipeline, and the wider 3D design and development practice can help set up a material library and review standard your own team can maintain.

Where this comes from

• Academy Software Foundation — OpenColorIO
• Pixar RenderMan — Look development documentation
• Blender Foundation — Material and shading guides

The figures and practices above come from the sources listed.

Working on something like this?

We take on 3D Design & Development work for teams who want it done once, properly. Tell us what you are building and we will tell you honestly whether we are the right studio for it. Start a project.

Where to go next

• Render Farm and Pipeline Management, Done Properly
• A Practical Guide to 3D for E-commerce