Inspection lighting is different from cinematic lighting
A product viewer has a practical job: make the model understandable. The user needs to see silhouette, material roughness, edges, and scale. Heavy contrast may look beautiful in a hero render, but it can hide the exact details a viewer is supposed to inspect. Begin with a neutral lighting rig and add drama only after the object is readable.
A useful default rig has three layers. Hemisphere light creates a gentle base so shadowed areas are not pure black. A directional key light gives the object a main highlight and shape. A rim or back light separates the object from the background. This setup is simple, fast, and easy to explain in UI.
PBR materials need an environment
Many GLB files use MeshStandardMaterial or MeshPhysicalMaterial. These materials are designed for physically based rendering, which means roughness, metalness, and environment reflections affect the final look. If a metallic object looks dead, adding a bright point light may not solve the problem. It may need an environment map or at least a balanced studio setup.
For a lightweight static tool, start with direct lights and document the limitation. For a production configurator, add an HDR environment and expose intensity controls. The important design choice is to separate inspection mode from brand mode. Inspection mode should reveal the asset; brand mode can be more stylized.
Keep the background honest
Dark UIs are popular for 3D tools, but dark models on dark backgrounds need help. A subtle grid, a floor, or a rim light can keep the object from disappearing. The background should not compete with the model, but it should provide enough contrast to judge scale and orientation.
On mobile, highlights can compress quickly because the canvas is small and device brightness varies. Test the same lighting rig on a narrow viewport. If the object becomes a dark blob, the rig needs a stronger fill light or a background that is less close to the material color.
Expose presets, not every light property
A public tool does not need every possible light slider. It needs a few reliable presets: neutral studio, product glossy, clay inspection, and dark hero. Each preset can be a small set of intensities and positions. That is easier for users to compare and easier for search visitors to understand.
When a preset includes code, keep it short and copyable. The goal is not to replace learning; it is to give a working baseline that can be pasted into a Vite or vanilla Three.js scene.
When this guide is the right tool
Use this guide when the problem is specific enough that a broad Three.js tutorial would waste time. The focus here is lighting in a real browser page: what to check first, what to measure, and what to avoid before the scene becomes harder to reason about.
The practical rule is simple: Start with a stable inspection rig before chasing dramatic lighting. If that sentence describes the scene in front of you, treat the article as a checklist. Read the explanation, copy the smallest useful code pattern, then test the result in a narrow mobile viewport and a wide desktop viewport before adding more polish.
Common mistake to avoid
The common mistake is treating Three.js lighting setup for readable product viewers as a visual tweak instead of a scene-system decision. Three.js problems often look like one broken line of code, but the actual issue is usually a chain: asset assumptions, renderer settings, camera math, material setup, interaction state, and page layout all meet inside the canvas.
That is why the safest fix is incremental. Start from a known-good scene, change one variable, and keep a visible diagnostic while testing. Use a rim light to separate dark materials from dark backgrounds. When the scene works, remove temporary helpers and leave behind only the checks that make sense for users.
Publishing check
Before publishing, run the scene through three questions. Does the page remain useful if WebGL fails or the asset loads slowly? Does the same scene still read clearly on a phone? Can another developer understand the important settings without reverse-engineering the whole file?
The last pass should be boring on purpose: verify canvas size, console errors, mobile performance, source links, internal links, and the related guide path. For PBR assets, environment lighting often matters more than adding another point light. If any answer is fuzzy, fix that before introducing a new effect or a larger asset.
Readable studio rig
scene.add(new THREE.HemisphereLight(0xf4efe4, 0x202020, 1.4));
const key = new THREE.DirectionalLight(0xffffff, 2.2);
key.position.set(4, 5, 3);
scene.add(key);
const fill = new THREE.DirectionalLight(0x88b7ff, 0.7);
fill.position.set(-3, 2, 4);
scene.add(fill);
const rim = new THREE.DirectionalLight(0x65d8c2, 1.2);
rim.position.set(-4, 3, -4);
scene.add(rim);FAQ
When should I use Three.js lighting setup for readable product viewers?
Use it when your Three.js scene has a focused lighting problem and you need a practical checklist before adding more visual polish.
Is the code snippet production-ready?
Treat the snippet as a clear starting point. Test it in your scene, adapt naming and paths, and verify behavior on mobile hardware before publishing.
What should I check after applying this guide?
Run the scene through mobile sizing, console errors, loading states, source links, and related guide paths so the page remains useful even when assets or WebGL fail.