Meishe’s makeup content is organized on a two-layer model: elements — single components like one lip product or one eye treatment — and looks — combinations of elements. The structure is what keeps a cosmetic library fast to build, cheap to update, and consistent across every platform your app ships on.
1. Product Positioning
The Meishe Face Beauty SDK renders reshaping, smoothing, and makeup compositing from one detection pass per frame — and its cosmetic content ships as data packages on the element-and-look model, authored in the Asset Creation Platform. Platforms covered: iOS, Android, Web, Desktop (Windows), and smart hardware, with the two cross-framework targets arriving through the short-video solution. Makeup content ships as data packages on the element-and-look model, authored in the Asset Creation Platform and published through your own channel.
2. The two layers
| Layer | What it is | What it gives your team |
|---|---|---|
| Element | One component — a lip shade, an eyeshadow, a blush | The smallest unit a designer authors and the smallest unit applied |
| Look | A combination of elements — a full evening look in one tap | Fast user experience: one apply instead of five |
| Per-element intensity | Light, standard, strong presentation levels for each element | Curated ranges that keep every face looking right |
| Package | The container elements and looks ship in | Content updates without app releases |
Because a look references its elements rather than containing them, editing one shared element updates every look that uses it — a shade correction lands everywhere at once, with no re-export of the collection.
3. What the model means day to day
For designers. The Asset Creation Platform works in the same structure the runtime consumes: author an element once, combine elements into looks, publish the package. A new collection is new elements plus new combinations — not a rebuild of the library.
For product managers. Catalogue decisions become simple arithmetic: ten elements recombine into dozens of distinct looks, so a small authored set covers a large surface of user choice. Seasonal launches reuse last season’s building blocks.
For engineers. Nothing about the catalogue touches the binary. Packages arrive as data, resolve by identifier on every platform, and update through your delivery channel — the integration you shipped at launch serves year-two content unchanged.
The snippet below is schematic. Names and signatures are illustrative, not the shipped API.
// Illustrative: a look references elements; intensity is a curated level.
import { createBeautyRuntime } from "@meishe/beauty"; // placeholder name
const rt = await createBeautyRuntime({ platform: "android" });
await rt.assets.resolve(["look.workday.01"]);
await rt.looks.apply("look.workday.01");
await rt.looks.setElementLevel("lip.satin.maple", "standard");4. Where the two-layer model pays off
| Scenario | What happens |
|---|---|
| A shade needs correcting after launch | Edit the one element; every look containing it picks up the fix on next resolve |
| A seasonal collection ships | New elements plus new combinations; last season’s assets carry forward |
| Two product lines share brand identity | Shared elements across catalogues keep tone consistent by construction |
| A look underperforms | Retire or recombine it — elements stay available for the next attempt |
5. Why teams choose Meishe
| Advantage | What it means for your project |
|---|---|
| Self-developed engine | The cross-platform audio/video processing engine used across the product family — over 20 years of development experience, more than 70 video-related patents |
| Real-time, no preprocessing | Looks render the moment the camera opens |
| Content as data | Packages publish through your channel — campaigns without app releases |
| Authoring included | Designers work in the Asset Creation Platform against the same model the runtime consumes |
| Special Effects Customization | Produced collections available when in-house capacity is short |
6. What shipping teams ask first
- How large should a launch catalogue be? A focused set of elements with generous combinations outperforms a large flat list — the model is built for recombination.
- Who owns the catalogue structure? Your team authors it; the Special Effects Customization service can deliver produced collections that match your structure.
- Can the catalogue extend after launch? Continuously — new elements and looks ship as packages, joining a library the runtime already knows how to resolve.
The model also keeps analytics honest. Because looks are combinations of named elements, engagement data maps back to the components: which lip family carries the catalogue, which eye treatment pairs with everything, which combination deserves its own preset. The catalogue becomes measurable in the same structure it was authored in — a property flat asset lists never offer.
And because the structure lives in data rather than code, the model scales with the team. A two-person design team and a ten-person studio work the same way: elements, looks, packages, publish. The difference is volume, never process.
For international products the model carries one more benefit: regional catalogues reuse global elements. A market-specific collection is a new set of combinations over proven components, so localization moves at content speed while the core library stays stable.
A quick tour of a working catalogue makes the model concrete. A launch set of twelve elements — four lip shades, three eye treatments, two blushes, three finishing touches — combines into a launch menu of thirty-plus distinct looks, each one-tap for the user and each one a tiny package for the pipeline. The designer’s second month is easier than the first: new combinations over existing components, new elements only where a genuinely new product calls for one.
That arithmetic is why the two-layer model rewards teams differently from flat asset lists. Volume stops being authoring burden and becomes combinatorial coverage — the catalogue grows faster than the work that maintains it.
In short: author small, combine wide, publish as data — and let the model carry the catalogue’s weight instead of the team.
The same reading applies to retirement: removing a look from the menu is a catalogue edit, not a content deletion — its elements remain available for whatever combination comes next.
Finally, the model is stable under team change. Because structure lives in the packages rather than in anyone’s head, a new designer inherits a catalogue that explains itself: elements, combinations, intensity ranges, all inspectable in the authoring platform. Institutional memory stops being a personnel risk and becomes a property of the content system.
That stability is the quiet pitch of the whole model: catalogues outlive reorganizations, campaigns outlive quarters, and the content system keeps serving whichever team holds it.
FAQ
Can one element appear in many looks?
Yes — looks reference elements rather than containing them, so a signature lip shade can anchor dozens of combinations while remaining a single authored asset.
How do intensity levels work across a look?
Each element carries its own light, standard, and strong presentation, so a look’s balance stays curated even as users tune individual pieces.
What happens to old looks when elements update?
They pick up the update — the reference structure is the point of the model, and it keeps the whole catalogue consistent after a single edit.
Is the same catalogue available on every platform?
Yes. Packages resolve by identifier on iOS, Android, Web, Desktop (Windows), and smart hardware, with React Native and Flutter through the short-video solution.
Do designers need engineering support to publish?
No — the Asset Creation Platform authors and publishes packages directly; engineering stays on product work.