For those who don’t know the tool: Flair is a stylized renderer inside Autodesk Maya, focused on NPR looks in the viewport and rendering, with style shaders, materials, and line effects that sit upstream of comp and delivery.

macOS arrives, and it is not a footnote

Flair 1.2 adds macOS support for Maya 2024 and newer. The supported operating systems now cover Windows, Linux (Rocky), and macOS, with macOS builds on Apple Silicon only. The setup requirements are macOS 14 as minimum and macOS 26 as recommended, alongside Windows 10 and 11 and RHEL based Linux options. Linux availability is tied to specific license tiers.

Proxies stop being special materials and start being a toggle

A core workflow change in 1.2 is how proxies work. Any flairShader material can now double as a proxy with a single toggle, replacing the old ShaderFX proxy material. The new proxy behavior supports Wobble, Offsets, and multiple NoiseFX types. That matters because the proxy no longer needs to be a separate shaded thing you babysit, it becomes a mode of the same material you already use.

This is a practical fix for hard-shell proxy intersections and visible component lines when proxy geometry overlaps other geometry. With the proxy living inside the same shader, you can apply effects like Wobble Blur to introduce diffusion and gradients rather than accepting a hard boundary.Using proxy offsets to localise line thresholds, so a region can show only depth-based silhouettes while the rest of the scene keeps different line logic. That kind of localised override can be the difference between a clean frame and a late night of per-shot hacks.

You still want to test this carefully in production. Even when an update says it is seamless, changes to proxy behaviour can alter look dev deltas in ways that only show up once animation starts doing unpleasant things.

Lines get more controllable and more mischievous

Flair 1.2 adds a set of line features that target a classic pain point: outlines and inlines are not the same thing, so stop treating them as if they are. A new Canvas Override global attribute can replace the beauty pass with the canvas colour. In practice, this lets you inspect what Flair effects and line work contribute, without the underlying shaded colours distracting you. The attribute appears in the globals documentation and in the release notes as a new global control.

For outlines specifically, the update adds Outline Width Offset, letting you modify line width for outlines relative to inlines. In the video, this becomes a look-dev lever for graphic styles in which the silhouette reads as bold while interior lines stay subtle, or where outlines disappear entirely, leaving only internal structure.

Light response also gets split. There are new controls over Outline and Inline Light Response for both clean and rough lines. That separation enables a sharper art direction trick: negative light response. Negative light response shows lines in shaded parts of the scene, which the update calls out as a “noir-style” option. In the demo, that produces lines where you would otherwise get pure darkness. It is a neat tool for stylized lighting setups where you want form to read in the shadows without repainting the entire grade.

Depth based sketchiness control arrives too, via Sketchiness Depth Range and Sketchiness Depth Factor. This lets sketchiness increase or decrease along scene depth, and it is presented as a global control that works across scenes, rather than relying only on placing proxy planes at different distances. For facilities that build reusable style presets across sequences, this is the sort of knob that can save time when layout changes the scale of a set and your line breakup suddenly looks wrong.

Licensing grows up: subscription, plus options studios actually ask for

Flair 1.2 expands licensing beyond subscription to include perpetual and floating licenses, and it introduces a licensing server to manage floating seats. Online licenses can be migrated to a new machine six hours after the previous activation. The release log also calls out fixes for activation on new Windows machines where wmic is missing, and an installer fix when an older install folder path no longer exists.

Activation for floating licensing occurs by entering a hostname or IP address for the license server, after which the client fetches available licenses and activates the first one that is free. That maps cleanly to typical facility patterns where artists should not care which workstation holds a seat today, only whether the pool has one left.

Performance and saving: fewer reasons to stare at a frozen UI

The Sequence Renderer gets asynchronous saving of images to speed up rendering, with image writes moved to a separate process so they do not interfere with rendering. It also gains continuous improvement for anti-aliasing beyond 32 TAA samples up to 254 samples, and the camera list can now be unlimited.

Material handling gets several workflow improvements. Keyed attributes in flairShader materials now work in Parallel and Serial evaluation modes. All material attributes appear in the Channel Box and the Attribute Spreadsheet. There are fixes for a GPU memory leak tied to assigning materials to components while scrubbing the timeline, and several other fixes around AOV blending, vertex baking, and material conversion.

There is also a new “Sanitize Flair” button in the toolbox that unloads the plugin and tries to remove all traces of Flair from an open scene, with a confirmation dialog and no undo. That is the sort of scorched earth tool that you hope you never need, until the day you really need it.

Unreal Engine enters the chat, via beta testing

Alongside the Maya 1.2 release, the newsletter announces beta testing for Flair for Unreal Engine. The team received an Epic MegaGrant last year and that it led to a major roadmap overhaul and a late Maya update, while enabling focus on bringing Flair to Unreal Engine.

The Unreal version is not nearly as feature-rich as the Maya version yet, but it is completely modular. The modular approach is a way to mix and match different effects to create a custom style. Beta testers are recruited by replying to the email, with testing planned for April and a questionnaire at the end of the month to help prioritize features and guide future development. If you live in a pipeline where Unreal Engine sits in previs, virtual production, or realtime look dev, a modular stylized renderer could be very useful. It could also be a moving target, because beta testing exists for a reason.

One last reminder before you install anything on the main machine: validate look changes on a copy of your scene library, because even small line and proxy changes can ripple through a show. And yes, the nori lines look great in a demo, but your shots will still find a way to be difficult.

https://docs.artineering.io/flair/release-log/

https://artineering.io/

The post Artineering Flair 1.2 for Maya hits macOS first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

What exactly is Device Preview Plus supposed to do once the calibration itself is finished? And how far can a monitor tool stretch before it starts trying to become part of the wider image pipeline? In this interview, Heath Barber speaks about Datacolor’s current direction for SpyderPro, including display simulation, custom device profiles, C2PA content credentials, and the role of calibration in workflows that no longer end at a single screen.

Heath Barber (LinkedIn) is Senior Product Director, Consumer Solutions at Datacolor and has spent nearly 21 years with the company in a series of senior software, product and imaging roles. His previous positions including Senior Director, Software Technology; Global Market & Technology Manager, Imaging; Global Software Technology Manager; and Director of Development, Imaging Color Solutions. That long run across Datacolor’s software and imaging side makes him a useful guide for a conversation.

From monitor calibration to device simulation

DP: SpyderPro now includes Device Preview. On the box, that sounds simple enough. In practice, what does it do?

Heath Barber: Device Preview is really a way of simulating how your image or media might look on other output devices without you having to physically move the file across ten different screens and start guessing what changed where.

The classic comparison is print preview. People in print workflows have done this for years. You work on one display, but you still want a reasonable idea of how the final output will behave on paper. Device Preview takes that idea and extends it to screens. Instead of asking only, “How will this print?”, we are asking, “How will this look on a phone, on a tablet, on another class of display, or on another type of viewing device?”

That matters more than people sometimes admit. A lot of media today is first consumed on a phone. My wife is a wedding photographer, and like many photographers, one of the first things she wants to understand is how an image will look when a client opens it on a mobile device. That first impression often happens on an iPhone, an iPad or some Samsung tablet, not on a calibrated studio monitor. So what we did was build custom profiles that simulate those device classes as closely as possible on your own screen.

In other words, you are still looking at your calibrated monitor, but the software is applying a transformation that approximates how the image would appear on another device. It is not magic, and it is not the same as physically holding that exact phone in your hand, but it gives you a much more informed preview than simply hoping for the best.

Custom targets and ICC profiles

DP: There are already quite a few screen presets in there. Can users add their own?

Heath Barber: Yes, and that is where things get interesting. If you actually have access to the screen you want to simulate, you can create your own profile for it. The underlying idea here is the ICC profile, which is basically a standardised description of how a device represents colour.

If you calibrate that display with SpyderPro, create an ICC profile for it, and place that profile where Device Preview expects it, the software can use it as another target. So you are not limited to the built-in presets forever. You can extend the system yourself if you have the hardware and you are willing to profile it properly.

That is actually a useful kind of crowdsourcing. It means users can build simulation targets for screens we may not have added officially yet. Otherwise, the alternative is simply waiting for us to issue an update with more presets. This way, if you need a very specific display and you have access to it, you are not stuck.

In practice, this matters because not all displays fail in the same way. Some are cooler, some warmer, some over-saturate, some clip shadow detail, some compress highlights in ugly ways. An ICC profile gives you a measured description of that behaviour. Once you have that, you can simulate it much more intelligently.

DP: Can Device Preview also be useful in a more classic post-production or grading pipeline? For example, can it simulate ACES or broadcast-style viewing targets?

Heath Barber: Yes, absolutely. Some of those things are already there in one form or another (RAW, JPG, PNG, TIFF, obviously, which is common for screenshots and frame exports), and one of the goals of Device Preview Plus is to support a much broader set of output types and colour spaces than the earlier beta did.

That is important because once you move beyond stills and basic display calibration, you run straight into colour-management questions. ACES, for example, is not just a buzzword people throw around to sound serious. It is a standardised colour pipeline used in film and post to help move images consistently between cameras, applications, VFX, grading and final delivery. Broadcast standards do something similar in their own context. They define how media should behave so that a signal is interpreted predictably.

What Device Preview Plus is trying to do is give users a way to preview those kinds of transformations and output conditions within a simpler interface. It is not trying to replace a full finishing pipeline, but it does let you think more concretely about where your image is going and how it might look once it gets there.

That matters because color correction is never done in a vacuum. You are always correcting toward some destination, even if people do not always say it that way.

DP: So in the long run, could this also help compare different source looks or make camera matching easier before you are deep into grading?

Heath Barber: That is part of the bigger ambition, yes. I would phrase it less as “this replaces grading” and more as “this gives you more context earlier in the workflow.” A lot of users do not only want calibration. They want to understand what their material is going to do when it moves from capture through editing and eventually toward delivery. So one goal of this relaunch was to build a stronger foundation for that kind of ecosystem thinking.

Part of that was hardware support, including better support for multiple monitors. Part of it was product structure, so users can start at one level and move upward without feeling that they bought into a dead end. But the big conceptual shift was image processing. That is what starts moving SpyderPro out of the little utility corner and into actual day-to-day workflow relevance.

If you can preview, compare and process images more meaningfully before the very end of the chain, that is valuable. People do not always need a giant facility pipeline to benefit from that. A photographer, editor, videographer or small studio can still gain a lot by seeing likely output behavior earlier and more clearly.

What C2PA actually is

DP: Let’s say somebody changes an image in the pipeline and then blames someone else. How do I know who broke it?

Heath Barber: That is where C2PA comes into the conversation. C2PA is essentially a standard for content credentials, which has been driven by Adobe and a few other companies, including Meta and Google. The simplest way to explain it is that it works like a verified provenance layer for media, which is supplied by approved partners and products. It is a way of attaching information to an image, video or audio file so that the history of that asset can be preserved and inspected.

Now, it is important not to oversell it. This is not an unbreakable security vault. It is not meant to function like heavy-duty encryption where the whole system collapses if one person touches the file. The goal is different. The goal is to create a reliable chain of information around authorship, origin and edits, so that platforms, applications and viewers can read that history and present it meaningfully.

If somebody strips that information out, that itself can become part of the story. So the point is not only to preserve history, but also to make tampering or removal more visible. Important to note is: Not everybody can supply the data, because a “C2PA” approval stamp needs a verified supplier to integrate it. Stripping the data away is easy, as anybody who has had an intern delete sidecar files before knows.

But adding that information requires a vetted, approved software company, like Adobe or Datacolor. Quite a few other big names in our space are currently in the process of that verification, by the way – we don’t know if this system will be the one that solves the problems, but as far as we can guess today, it might stick.

From our perspective, that becomes interesting because we sit so early in the image workflow. Calibration and device preview happen near the beginning of a chain. If you can begin attaching useful metadata there, and if that metadata continues downstream, then the image starts carrying some of its own history with it.

Tracking edits through the chain

DP: So if somebody in a studio changes an image and sends it on, that history could travel with the file?

Heath Barber: Yes, that is the idea, assuming the applications in the chain support reading, preserving and writing that metadata. If a file moves into Photoshop, for example, and Photoshop adds edits while preserving the content credentials, then a later viewer or platform that supports C2PA can show that there was an earlier version, then another change, then another change, and so on. That is why I often describe it more like versioning or historical tracking than some kind of hard lock. You are building a timeline of the asset.

And that is valuable because a surprising amount of confusion in media workflows is not about whether an image was changed. Of course it was changed. The question is how, where, by whom, and in which order. That is where provenance becomes useful. It turns vague suspicion into something much more inspectable.

Why that matters for media professionals is obvious. If you are a photographer, editor, colorist or VFX artist, so-called technical metadata is not boring background noise. It is often the only trail of breadcrumbs you get when something looks wrong and you need to work backwards.

DP: Could C2PA become a foundation for more reliable metadata in professional media workflows?

Heath Barber: Yes, I think it could. Right now, the public conversation around C2PA is often dominated by AI detection, content authenticity and platform labeling. Those are real issues, but for media professionals there is another side to it, and that side is workflow visibility.

A lot of tools and viewers today do not really surface the kind of information a colorist, editor or photographer would care about most. To them, that data may just look like clutter. To us, it can be gold. It can tell you what settings were used, what was embedded, what transformations were applied, and how the file evolved.

That is why I think there is a major opportunity here that goes beyond headlines about “real versus fake.” For working professionals, the value may be that you can finally see what happened to an asset in a way that is consistent and transportable.

Camera metadata, edit history and proof

DP: I assume camera makers already contribute a lot of that information.

Heath Barber: Yes, they do. A camera can capture all kinds of useful metadata: model, lens, focal length, exposure settings, stop values, capture conditions and more. That information is already part of the professional world. The big question is not whether metadata exists. It does. The question is whether that metadata survives and whether it remains visible and trustworthy as the file moves through the pipeline.

If you can preserve camera-side information, then add edit-side information, then preserve output and transformation information, suddenly you have something much more powerful than isolated metadata fragments. You have a chain.

DP: So, for a professional production, that could eventually help prove what is captured, what is altered, and what is generated?

Heath Barber: That is certainly one of the ambitions around this whole space. It is tricky because media workflows are messy, and the real world is rarely as neat as standards documents would like it to be. But yes, the direction is toward being able to say: this is where the asset originated, this is what was done to it, and this is what remains attributable, and it is traceable. That is useful not only for protecting creators, but also for protecting the workflow itself. When something goes wrong, being able to inspect the chain matters.

DP: Ideally, you would like every screen in the workflow to have a little Spyder hanging from it.

Heath Barber: Sure, but the larger point is that I want to push us more into software. Spyder, as a hardware product, is well established. People know what a Spyder does, and the current platform supports most of the display technology our customers are working with today and what we see coming in the next several years. That is exactly what frees us to put our energy into software, because that is where we can deliver the most value the fastest. Workflow integration, format support, analysis tools, environmental adaptation, and content credentials. Those are software problems, and software is how we solve them best.

So Spyder remains the foundation, but the surrounding software layer is where we can build more capability and more relevance. Things like device simulation, image processing, and metadata let us move beyond “put sensor on screen, click calibrate, done.” That workflow still matters, but it does not have to be the whole story. And honestly, we are not done innovating on display calibration or colour-critical display analysis. 

DP: You recently updated the Spyder software. What is next?

Heath Barber: There is a lot in the pipeline, but the part I can talk about today is the ecosystem side. We are working closely with key vendors across both video and photography to make sure the experience is as seamless as possible from capture through delivery. The goal is to give creators the critical tools they need to do their best work and to genuinely improve their productivity, not to add another piece of software they have to babysit.

Imaging is a team sport. People move between cameras, software, displays, tablets, phones, edit systems, grading tools, review tools, and delivery platforms all the time. So if you want to be relevant, you cannot act like calibration lives on its own little island. It has to connect into the broader ecosystem. That does not mean every user needs a huge enterprise pipeline. It does mean the tools should feel aware of how people actually work.

The market has also changed. A lot of users today are not interested in spending endless hours tweaking every parameter inside complicated full-featured suites that are harder to use than the editing and DCC tools they are already trying to keep up with. They want tools that do most of the job well, clearly and efficiently. That is not laziness. That is reality. So part of the job is figuring out where in the workflow we can add value without making the tool feel like homework.

Light-meter integration and the viewing environment

DP: What about the light meter side? Is that becoming a bigger part of the system too?

Heath Barber: Yes, very much so. That is one of the more exciting areas for us. Built-in ambient light sensing is useful up to a point, but it is broad and limited. A dedicated light meter is much more accurate, and once you have that, you can begin describing the viewing environment in a much more meaningful way.

Right now, we already think in terms of multiple zones around the viewing setup. What is the light behind the screen, what is the light facing the viewer, what is happening around the workspace. The current system uses that information in a relatively constrained way, but the longer-term plan is to expand that into a much richer map of the environment, because your monitor does not exist in a vacuum either. The room changes what you perceive. Ambient light, direction, intensity and colour temperature all influence how you see the image.

So if you can measure the environment more accurately, you can calibrate more intelligently and also preview output conditions more realistically. In other words, better environmental data improves both the monitor correction side and the device preview side.

From three zones to room mapping

DP: So eventually, instead of just one or two measurements, you could map the room.

Heath Barber: Exactly. Think of it less as a single reading and more as building a spatial picture of the environment. If you know what the room is doing around the display, then you can make much smarter decisions.

And that leads to some interesting possibilities. If you have multiple measuring points, or eventually multiple devices monitoring the environment, you can start blending those readings into a more complete model. That could matter for studio setups, mobile work or any workflow where lighting conditions are inconsistent.

Once you start seeing it that way, calibration becomes less about a single screen measurement and more about understanding the conditions in which that screen is actually being used.

DP: So the real shift here is that calibration is no longer treated as an isolated task.

Heath Barber: Exactly. That is really the core of it. Calibration still matters, obviously. It is the foundation. But once that foundation is in place, the next logical step is to ask what else can be built on top of it. That is where device simulation, image processing, metadata, content credentials and environmental measurement all come in. We are trying to move from a narrow utility toward something that participates more fully in the image workflow.

That does not mean it suddenly becomes a complete post-production platform. It does mean we are trying to make it more useful to the way people actually create, review and deliver media today.

The post SpyderPro learns new tricks: where colour goes wrong first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

The latest update to Nuke Stage stays with the preview: real-time playback of photoreal environments on LED walls, plus live compositing tools that shoulkd feel familiar to artists. The tool targets virtual production and in camera visual effects (ICVFX), with a workflow designed to keep VFX artists in creative control on set.

The core stays high-resolution playback for 2D and 2.5D environments, with EXR as the playback format and USD used for 3D geometry. Live compositing comes from a set of Nuke nodes rewritten for real-time performance, so operators can blend the on-set environment with the physical build and manage the relationship between camera and screen.

The practical takeaway: this is not a game engine project that happens to output to a wall. It is a VFX-flavoured playback and live comp system that tries to keep your pipeline language intact.

The parts you actually run on set

Foundry built a three part architecture: an editor where the operator works, a headless networking relay, and render nodes that run on each machine driving the wall. A launcher defines where those processes run and can start them across a larger stage, then the editor connects to the relay and render nodes and reports cluster health.

A typical topology puts the editor and relay on the control machine, distributes renders to the render nodes, then sends images to the wall. The setup flow walks through networking first, then hardware outputs and physical displays, then display mapping, and then cameras and tracking. Configurations can be exported and imported so teams do not have to repeat the same stage setup every day. Unless they want to. But in general, that is the unglamorous part of virtual production that still decides whether you shoot before lunch or after dinner.

Metadata Vault: your future self says thanks

The headline feature is metadata capture via a Vault that records on-set decisions for handoff into post. The Nuke Stage supports logging scene data, camera tracking, lens metadata, timecode, scene settings, and colour decisions. The Vault documentation also describes two capture workflows: Snapshots for a point-in-time save, and Take Record, which creates a camera USD file between defined start and end points.

If you have ever tried to reproduce a wall look from a vague note like “match take three but slightly warmer with some *Ooompf* “, this aims to make the record concrete. It will not fix bad habits, but it can at least preserve what you actually did on set.

NotchLC and EXR playback, plus a faster sequencer loop

On the playback side, the feature list now includes native support for NotchLC and B44 EXR for high-resolution background playback. There is a drag-and-drop sequencer panel, one-click keyframing, and editing and interpolation tools for timing changes.

In the operator view, the track-based sequencer remains central. Content created in Nuke can be staged over time, keyframed, and adjusted live for collaborative iteration with the on-set team.

USD scenes and splats, now aimed at the wall

Nuke Stage supports importing OpenUSD scenes that can be edited and overridden for real-time blending of virtual and physical sets. For file and colour standards, the tool lists OpenEXR and OpenColorIO alongside ACEScg support via ACES. It also claims support for HDR and a color pipeline intended to carry creative decisions from set into post.

For scene representations, the tool now highlights importing and controlling Gaussian Splats for high fidelity 3D scenes, alongside standard USD geometry. In the broader ecosystem, Foundry also shipped Gaussian Splat support in Nuke and built a USD based 3D system in there too, which positions splats and USD as shared data types across stage and post.

Standard hardware, scaling, and the usual fine print

The product page repeats the goal of running on commodity hardware without specialist media servers or bespoke equipment, and scaling across render node clusters. It frames this as cost and setup-time control and as a way to make stages repeatable.

Pricing is not specified in the sources. The product page offers a register your interest contact flow.

New tools and innovations should be tested before use in production, especially anything that touches playback codecs, cluster timing, genlock, tracking inputs, and colour consistency. Run your own worst-case plate, your own camera tracking feed, and your own handoff into post before you bet a shoot day on it.

https://www.foundry.com/products/nuke-stage

The post Foundry expands Nuke Stage for LED walls first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

For those who don’t know the tool: CinCraft LensCore is a Nuke plugin for compositing and it sits late in post inside the CinCraft lens data ecosystem.

Ray traced lens behavior, inside a comp

ZEISS calls CinCraft LensCore as a physically based way to create cinematic lens looks for visual effects and animation in a 2D comp. It builds on Virtual Lens Technology, shown at FMX 2025, and it targets the hand-built lens look stacks that often drift from shot to shot once schedules get real. Digital Production has tracked this rollout from the earlier Virtual Lens Technology push, first with Virtual Glass: ZEISS enters the simulated optics game and later with ZEISS CinCraft Virtual Lens enters beta: real glass, virtual magic, which sets LensCore up as the compositing side of that same lens data story.

LensCore centres on a GPU-accelerated, ray-traced rendering engine for Nuke that simulates lens behaviour across every pixel and every frame, apparently exceeding typical digital lens effects. The demo at the FMX booth looked great, but you’ll have to test it yourself with your own footage and renders.

One click looks, with a shelf of profiles

LensCore applies a complete lens look with one click, covering bokeh, defocus, distortion, vignetting, and other optical effects tied to a specific physical lens. A digital lens shelf lets artists load lens profiles for real cinema lenses or custom presets and quickly compare looks, aiming to enable repeatable workflows across sequences and teams.

Zeiss also lists lens characteristics it aims to capture, including sharpness, focus fall off, cat eye, chromatic aberration, distortion, and dirt filters. That part matters for day-to-day VFX work because the lens look rarely comes from a single knob, it comes from how those traits interact when you animate focus and exposure. About a third of the way into your show, the difference between a reusable lens profile and a fragile hero setup usually shows up in the vendor handoffs.

Focus changes that include breathing and cat eye

The LensCore digital lenses are provided per focal length, representing one real lens per digital lens. It also claims that the look changes with focus, including breathing and bokeh behaviour, and that cat eye bokeh applies in one step based on the selected lens. We are not well-versed enough in Zeiss Glass to verify that from a screen… Get the demo when it drops, and check for yourself.

The tool wants to work with both the company’s lenses and non-company lenses, and users can mimic practically any lens look – artists can still adjust lens characteristics such as chromatic aberrations after applying a lens , with the goal of keeping the experience technically credible and comparable to physically correct lens behaviour.

Depth helpers, inpaint, and performance notes

LensCore includes an inpaint feature that fills occluded areas behind defocused objects to reduce complex 3D setups and speed up compositing workflows. On performance, the GPU-based rendering hould mean that high-end renderings stay within time units artists already expect. There are also “fidelity options” and that can be adapted to your needs, including but not limited to serial-number-based approaches.

Where it sits in a wider lens data stack

LensCore sits next to other CinCraft components used earlier in the pipeline. CinCraft Scenario is an indoor-outdoor camera tracking solution for real-time applications, plus lens and point cloud data recording and export for post. CinCraft Mapper is a service providing frame-accurate lens distortion and shading data for post, including GUI and command line use on Linux, Windows, and macOS. The same files work with the eXtended Data (a lens-embedded technology introduced in 2017, part of the foundation for the CinCraft ecosystem).

Availability, demo, and licensing

LensCore was demonstrated at FMX 2026 in Stuttgart at booth 2.1 in the Marketplace. Worldwide availability is set for June 1, 2026 through the CinCraft webshop, with multiple licenses available. The LensCore demo version becomes available on June 1, 2026. Pricing is not yet specified; you’ll have to wait three more weeks for that. As always, test new tools before use in production, especially on shots with heavy grain, fine detail, fast motion, and tight edge work.

Digital Production will publish an interview soon – if you have any specific questions you’d want to ask (About Lenscore and Zeiss, not in General – I am NOT falling for that AGAIN), drop me a line through the contact page!

https://www.zeiss.com/photonics-and-optics/en/home/content/newsroom/news-overview/2026/cincraft-lenscore.html

https://www.zeiss.com/photonics-and-optics/us/cinematography/cincraft/virtual-lens-technology.html

The post ZEISS CinCraft LensCore targets Nuke lens looks first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

For those who don’t know the topic: Blender is a DCC with the Cycles renderer. The new texture cache sits in Cycles rendering performance, alongside existing memory and render speed controls.

The problem it aims to fix

Texture-heavy scenes can burn memory fast, even before you hit your sample count. The new texture cache in Cycles targets that pressure by changing what gets loaded at render time, and how. The core idea: instead of pulling full image textures into memory, the system loads only the tiles and resolutions actually needed for the render. That means the renderer can avoid carrying the entire source image when the shot only uses a fraction of it, or when the texture resolves to a smaller mip level in-frame.

This is a straight-up memory efficiency play for scenes that rely on lots of image textures. Claims about the size of the improvement exist, but specific benchmark numbers and test conditions are very difficult, because it wholly depends on your scene – so test before using it in production!

.tx files, generated next to your textures

Cycles Texture Cache generates a matching .tx file for each image texture and places it in a blender_tx folder next to the source image. The .tx file stores the texture in a form optimized for tiled access and multi-resolution loading, so the renderer can pull only the tiles and mip levels it needs.

# Generate tx files for all images in a blend file.
blender scene.blend --command maketx
# Generate tx file for a specific image file.
blender --command maketx image.png --colorspace sRGB

The workflow aims to stay mostly invisible. The .tx files regenerate automatically when the source image changes. Cycles also infers settings such as color space and filtering based on how the image gets used in shader nodes, rather than forcing artists to maintain a parallel set of cache settings by hand. That last part matters for production sanity: texutre caching that requires constant babysitting tends to get switched off right before deadline.

CPU, GPU, and the day-to-day reality check

The feature is working across CPU rendering and all GPU backends. It is also already available in daily builds, with additional improvements planned for render farms and production pipeline use.

If you manage shared storage, you will care about where those .tx files live, who writes them, and when. The currently accessible details do not fully spell out a studio-grade policy story for cache location, locking, or multi-user coordination. Still, the direction is clear: get memory use under control without turning texture management into another job title.

Schedule, availability, and pricing

Blender 5.2 LTS is in alpha, with a full release expected in July. Pricing is the same as always for Blender – free and Open Source. Before you roll this into a show, test it on your own shots, your own storage, and your own farm tooling, because new caching systems love to surface edge cases at the worst possible time.

https://code.blender.org/2026/05/cycles-texture-cache/

https://developer.blender.org/docs/release_notes/5.2/

The post Blender 5.2 LTS targets texture-heavy renders first appeared on DIGITAL PRODUCTION and was written by Bela Beier.