Layers as Materials - Now Available in After Effects Beta

AE 27 Beta: expose Layers as Material Sources references through AEGP and scripting

I am developing Cycles AE, a third-party Artisan renderer. I would like to read the layer selected in AE 27 Beta's native Material Assignment dropdown, so users can reuse their native material assignments without assigning the same source again in a separate Layer Control effect.

Is there a supported API for retrieving this reference per material slot? If there is, please point me to the suite/function or scripting property, the minimum SDK version, and a sample. Otherwise, please consider exposing it through the public AEGP and scripting APIs.

Environment and scope
- Windows, After Effects 27.0x61 Beta.
- Native diagnostic built with SDK 25.6_61 headers, using AEGP_DynamicStreamSuite4 and AEGP_StreamSuite5.
- SDK 26.5 headers were also reviewed, but that SDK was not used to build the live diagnostic.
- Automated inspection used AfterFX.com -noui -noerr -r. The material selection and its persistence after reopening were separately confirmed in the UI by the project owner.
- macOS, UXP, and any newer SDK-specific accessor have not been tested for this issue.

Reproduction workflow
1. Use Advanced 3D in AE 27 Beta, add a GLB model and a precomposition layer to the same composition.
2. In the model's native Material Assignment dropdown, assign the precomposition layer to a material slot.
3. Save and reopen the project; verify the dropdown still names that source layer.
4. Recursively enumerate the model layer's PropertyGroups in ExtendScript, including named groups, looking for LAYER_INDEX properties.
5. Independently obtain the layer root using AEGP_GetNewStreamRefForLayer, recursively enumerate children with AEGP_GetNumStreamsInGroup / AEGP_GetNewStreamRefByIndex, and query every node's match name, grouping type, and AEGP_GetStreamType. Inspect both LAYER_ID and ARB types.

Observed in our saved test project
- Target: GLB layer "Target" (ID 71), material "Material0". Assigned source: precomp layer "Texture Source" (ID 70).
- ExtendScript found no LAYER_INDEX reference. Explicit inspection of ADBE3D Material Parade also found none. Five unrelated NO_VALUE reads raised caught exceptions; the traversal completed.
- Native recursion inspected 186 nodes on the GLB layer and 766 nodes across all seven composition layers. No enumerated group was truncated by the diagnostic's depth limit, and no recorded SDK inspection call failed.
- Across those 766 nodes: zero AEGP_StreamType_LAYER_ID and zero AEGP_StreamType_ARB. No opaque ARB payload was decoded; no ARB-typed stream was found.
- ADBE3D Material Parade / ADBE3D Material Atom Intrin (Material0) was visible as a NO_DATA group with 13 children, including texture offset, rotation, scale, opacity, roughness, metallic and emission controls. None exposed the selected source layer.
- AEGP_StreamGroupName_MATERIAL_OPTIONS resolves to ADBE Material Options Group, which exposes different material controls; it did not provide this assignment either.
- Positive control: in a project copy, an ordinary Layer Control targeting the same source correctly returned Layer ID 70 through the SDK. Layer-reference decoding therefore works in the diagnostic.

Requested behavior
The highest priority is a supported read-only getter for the native source reference of each material slot, usable by third-party Artisan renderers. A documented DynamicStream LAYER_ID property or a dedicated suite accessor would both be useful. Please expose the assignment type (default, layer, Substance, missing/unresolved) and a host-managed layer reference/ID rather than requiring layer-name matching or reverse engineering project data.

Please also document material-slot identification, source evaluation stage/time, dependency and cache invalidation behavior, and allowed calling contexts/threads for animated sources. Consistent access for models and parametric meshes would enable us to use the same workflow. A setter would be useful later, but reading the existing assignment is the immediate need.

This report concerns API discoverability/exposure in the tested configuration. It does not establish that every possible API lacks this capability, and it is not a report that the saved UI assignment is lost. If the supported solution requires another SDK or build, that guidance would resolve the immediate question.

Diagnostic evidence, counts, a positive control, and the diagnostic C++ source have been prepared and can be provided separately.

​I was hoping for this to come soon, thanks! While the first step is interesting, the current implementation is too basic to be usable. There is no point in assigning a custom texture map if the only available slot is diffuse/albedo. We need individual slots for all possible material channels if we want to utilize custom maps properly.

As a fix this could be implemented by providing dropdown menus for each. But this isn't the only design problem. Custom maps seem to require you to have the layers available in the comp. For a single mesh in a single comp this isn’t that bad, but imagine 20 meshes with custom maps used in multiple comps. That will be quite the mess. It would be better if some additional mechanism could be designed that allows isolated set up for materials that meshes can reference from other than the comp itself. Just like it does with .sbsar. A dedicated material library panel where both .sbsar and custom maps could be created/reviewed could be much more useful. Additionally a manager that could assign materials to the meshes in a way that it makes the source media always reference that data so it isn’t instanced per comp, but could be overwritten if the users wants to could be welcome.

In above’s context, assigning materials could be upgraded to allow drag-drop from material library to the viewer, highlighting which model/part of model the material will be assigned to. And also from the Properties Panel the dropdown menu could be a thumbnail based grid rather than a flat list.

All in all I think there's a lot of work still to be done to make this a proper 3D working environment, and I would ask you to be cautious with these 1% quick fixes that stack up to a potentially clunky and incoherent design that puts you into a position where if you really want to make it work, the previous work needs to be redesigned along with it.

I was recently testing out possible workflows for product label replacements inside AE using real 3d+shading. I got a really reasonable result with using:

• KeenTools GeoTracker for motion tracking the bottle and exporting a null and camera.
• RedGiant Geo for shading, lighting and rendering the 3D model/texture.
• RE:VisionEffects ReelSmartMotionBlur to render motion blur.

None of the above can be achieved yet natively and this update isn't getting it closer. Some key features are still missing other than the obvious geo tracker.

• No native 3d motion blur in Advanced Renderer
• No access to the linear light data from the Advanced Renderer
• No individual texture slots for all possible material inputs.

The reason I mention the linear light problem is because the renderer is internally clamped to 0-1 which causes motion blur and DoF to render inaccurately. It also makes it impossible to properly merge 3D workflows with other scene referred data like log video. The Advanced Renderer now lives sort of in it's own limited world but even internally doesn't render nicely because it's only a linear to 2.2 gamma conversion rather than some form of tone mapping.

I hope we can see some more thought through feature updates around the new 3D system in the near future. With some solid decisions on what it should do in it’s basis, the possible use cases will become much larger than only solving smaller problems here and there.

Below you can see my efforts. Don’t mind the UV mapping being funky in one of them. It's the quality of the material, lighting and render that really matters here.

​