{"id":535,"date":"2026-10-23T14:53:52","date_gmt":"2026-10-23T06:53:52","guid":{"rendered":"https:\/\/en.meishesdk.com\/blog\/?p=535"},"modified":"2026-10-23T14:53:53","modified_gmt":"2026-10-23T06:53:53","slug":"makeup-elements-and-looks-how-to-organize-cosmetic-assets","status":"publish","type":"post","link":"https:\/\/en.meishesdk.com\/blog\/535.html","title":{"rendered":"Makeup Elements and Looks: How to Organize Cosmetic Assets"},"content":{"rendered":"\n

Meishe’s makeup content is organized on a two-layer model: elements<\/strong> \u2014 single components like one lip product or one eye treatment \u2014 and looks<\/strong> \u2014 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.<\/p>\n\n\n\n

1. Product Positioning<\/h2>\n\n\n\n

The Meishe Face Beauty SDK renders reshaping, smoothing, and makeup compositing from one detection pass per frame \u2014 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.<\/p>\n\n\n\n

2. The two layers<\/h2>\n\n\n\n
Layer<\/th>What it is<\/th>What it gives your team<\/th><\/tr><\/thead>
Element<\/td>One component \u2014 a lip shade, an eyeshadow, a blush<\/td>The smallest unit a designer authors and the smallest unit applied<\/td><\/tr>
Look<\/td>A combination of elements \u2014 a full evening look in one tap<\/td>Fast user experience: one apply instead of five<\/td><\/tr>
Per-element intensity<\/td>Light, standard, strong presentation levels for each element<\/td>Curated ranges that keep every face looking right<\/td><\/tr>
Package<\/td>The container elements and looks ship in<\/td>Content updates without app releases<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Because a look references its elements rather than containing them, editing one shared element updates every look that uses it \u2014 a shade correction lands everywhere at once, with no re-export of the collection.<\/p>\n\n\n\n

\"Makeup<\/a><\/figure>\n\n\n\n

<\/p>\n\n\n\n

3. What the model means day to day<\/h2>\n\n\n\n

For designers.<\/strong> 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 \u2014 not a rebuild of the library.<\/p>\n\n\n\n

For product managers.<\/strong> 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.<\/p>\n\n\n\n

For engineers.<\/strong> Nothing about the catalogue touches the binary. Packages arrive as data, resolve by identifier on every platform, and update through your delivery channel \u2014 the integration you shipped at launch serves year-two content unchanged.<\/p>\n\n\n\n

\n

The snippet below is schematic. Names and signatures are illustrative, not the shipped API.<\/p>\n<\/blockquote>\n\n\n\n

\/\/ Illustrative: a look references elements; intensity is a curated level.\nimport { createBeautyRuntime } from \"@meishe\/beauty\"; \/\/ placeholder name\n\nconst rt = await createBeautyRuntime({ platform: \"android\" });\n\nawait rt.assets.resolve([\"look.workday.01\"]);\nawait rt.looks.apply(\"look.workday.01\");\nawait rt.looks.setElementLevel(\"lip.satin.maple\", \"standard\");<\/code><\/pre>\n\n\n\n
4. Where the two-layer model pays off<\/h2>\n\n\n\n
Scenario<\/th>What happens<\/th><\/tr><\/thead>
A shade needs correcting after launch<\/td>Edit the one element; every look containing it picks up the fix on next resolve<\/td><\/tr>
A seasonal collection ships<\/td>New elements plus new combinations; last season’s assets carry forward<\/td><\/tr>
Two product lines share brand identity<\/td>Shared elements across catalogues keep tone consistent by construction<\/td><\/tr>
A look underperforms<\/td>Retire or recombine it \u2014 elements stay available for the next attempt<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
5. Why teams choose Meishe<\/h2>\n\n\n\n
Advantage<\/th>What it means for your project<\/th><\/tr><\/thead>
Self-developed engine<\/td>The cross-platform audio\/video processing engine used across the product family \u2014 over 20 years of development experience, more than 70 video-related patents<\/td><\/tr>
Real-time, no preprocessing<\/td>Looks render the moment the camera opens<\/td><\/tr>
Content as data<\/td>Packages publish through your channel \u2014 campaigns without app releases<\/td><\/tr>
Authoring included<\/td>Designers work in the Asset Creation Platform against the same model the runtime consumes<\/td><\/tr>
Special Effects Customization<\/td>Produced collections available when in-house capacity is short<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
6. What shipping teams ask first<\/h2>\n\n\n\n
    \n
  • How large should a launch catalogue be?<\/strong>\u00a0A focused set of elements with generous combinations outperforms a large flat list \u2014 the model is built for recombination.<\/li>\n\n\n\n
  • Who owns the catalogue structure?<\/strong>\u00a0Your team authors it; the Special Effects Customization service can deliver produced collections that match your structure.<\/li>\n\n\n\n
  • Can the catalogue extend after launch?<\/strong>\u00a0Continuously \u2014 new elements and looks ship as packages, joining a library the runtime already knows how to resolve.<\/li>\n<\/ul>\n\n\n\n
    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 \u2014 a property flat asset lists never offer.<\/p>\n\n\n\n
    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.<\/p>\n\n\n\n
    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.<\/p>\n\n\n\n
    A quick tour of a working catalogue makes the model concrete. A launch set of twelve elements \u2014 four lip shades, three eye treatments, two blushes, three finishing touches \u2014 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.<\/p>\n\n\n\n
    That arithmetic is why the two-layer model rewards teams differently from flat asset lists. Volume stops being authoring burden and becomes combinatorial coverage \u2014 the catalogue grows faster than the work that maintains it.<\/p>\n\n\n\n
    In short: author small, combine wide, publish as data \u2014 and let the model carry the catalogue’s weight instead of the team.<\/p>\n\n\n\n
    The same reading applies to retirement: removing a look from the menu is a catalogue edit, not a content deletion \u2014 its elements remain available for whatever combination comes next.<\/p>\n\n\n\n
    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.<\/p>\n\n\n\n
    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.<\/p>\n\n\n\n
    FAQ<\/h2>\n\n\n\n
    Can one element appear in many looks?<\/strong>
    Yes \u2014 looks reference elements rather than containing them, so a signature lip shade can anchor dozens of combinations while remaining a single authored asset.<\/p>\n\n\n\n
    How do intensity levels work across a look?<\/strong>
    Each element carries its own light, standard, and strong presentation, so a look’s balance stays curated even as users tune individual pieces.<\/p>\n\n\n\n
    What happens to old looks when elements update?<\/strong>
    They pick up the update \u2014 the reference structure is the point of the model, and it keeps the whole catalogue consistent after a single edit.<\/p>\n\n\n\n
    Is the same catalogue available on every platform?<\/strong>
    Yes. Packages resolve by identifier on iOS, Android, Web, Desktop (Windows), and smart hardware, with React Native and Flutter through the short-video solution.<\/p>\n\n\n\n
    Do designers need engineering support to publish?<\/strong>
    No \u2014 the Asset Creation Platform authors and publishes packages directly; engineering stays on product work.<\/p>\n","protected":false},"excerpt":{"rendered":"
    Meishe’s makeup content is organized on a two-layer model: elements \u2014 single components like one lip product or one eye treatment \u2014 and looks \u2014 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 […]<\/p>\n","protected":false},"author":1,"featured_media":536,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[7],"tags":[40,46,403],"class_list":["post-535","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-face-ar-sdk","tag-face-ar-sdk","tag-face-beauty-sdk","tag-makeup"],"_links":{"self":[{"href":"https:\/\/en.meishesdk.com\/blog\/wp-json\/wp\/v2\/posts\/535","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/en.meishesdk.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/en.meishesdk.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/en.meishesdk.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/en.meishesdk.com\/blog\/wp-json\/wp\/v2\/comments?post=535"}],"version-history":[{"count":1,"href":"https:\/\/en.meishesdk.com\/blog\/wp-json\/wp\/v2\/posts\/535\/revisions"}],"predecessor-version":[{"id":537,"href":"https:\/\/en.meishesdk.com\/blog\/wp-json\/wp\/v2\/posts\/535\/revisions\/537"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/en.meishesdk.com\/blog\/wp-json\/wp\/v2\/media\/536"}],"wp:attachment":[{"href":"https:\/\/en.meishesdk.com\/blog\/wp-json\/wp\/v2\/media?parent=535"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/en.meishesdk.com\/blog\/wp-json\/wp\/v2\/categories?post=535"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/en.meishesdk.com\/blog\/wp-json\/wp\/v2\/tags?post=535"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}