TL;DR / For those who don’t know the tool: Sneeze sits between spatial services and AR and VR clients. It consumes glTF output from Blender, Maya, Houdini, Revit and Cinema 4D, and forms the engine layer of OMBI at the Metaverse Standards Forum.

A browser engine for rooms

The Metaverse Standards Forum introduces Sneeze on June 15, 2026 as an open metaverse browser engine. RP1 acts as lead architect and maintainer. The engine targets spatial services that appear through location and proximity rather than through a conventional page, tab or app-store download.

The project names Sneeze as the world’s first open metaverse browser engine. That is a marketing claim. Its practical definition is more useful: Sneeze keeps the scene graph, manages network connections, executes service logic and renders a shared spatial scene. A browser or native application supplies the shell around it. The planned release uses the Apache License 2.0 and places the code on GitHub. The final repository URL has not been published, but should be online soon.

The distinction between engine and browser matters. A web browser wraps navigation, settings, updates and user trust around an engine. Sneeze takes the engine role for spatial content. Developers can embed it beside an existing web renderer or use it inside a standalone native spatial browser.

Tabs would get crowded

A normal web browser loads one origin into one page context. Sneeze works with spatial fabrics. A spatial fabric combines mapped content, a coordinate system and related services into an environment such as a city street, university campus, factory floor, airport terminal or game arena.

Every fabric requires a map service. That service supplies geometry, terrain, objects, coordinates and streaming updates. Other services can add presence, communication, commerce, safety alerts, equipment data or location-bound content.

That model gives augmented reality a browser-style discovery mechanism. The engine opens and closes streaming connections as fabrics become relevant. It does not load each environment as a fixed document. Proximity supplies the navigation event.

Rendering gets an adapter

Sneeze routes scene rendering through ANARI, the Khronos rendering abstraction. ANARI describes meshes, materials, lights, cameras and volumes through a common API, then delegates drawing to a renderer underneath. The current architecture uses Filament through an ANARI-compatible wrapper for rastersiation. ANARI keeps that renderer replaceable. The application code above the abstraction does not need a rewrite when the engine swaps the renderer below it.

Tracking and device input pass through OpenXR. Head pose, hand pose and controller state come from the active XR runtime. Sneeze combines that tracking with the user’s position to place the virtual camera in the SOM coordinate space. The render loop reads the SOM as it exists for the current frame. It does not wait for every service writer. Network updates and WASM modules can keep changing the scene while rendering continues, and the next frame picks up the new state. That separation matters across phones, desktops, AR glasses and virtual reality headsets. Hardware changes below the abstraction layers. The scene model and service boundary stay in the engine.

For 3D, VFX and visualisation teams, this vocabulary will reach client meetings long before it settles into production pipelines. We will create the models, materials, animation and environments that spatial browsers present, so names such as SOM, glTF, WebAssembly, ANARI and OpenXR are worth learning before the next briefing becomes another group exercise in confident nodding. Again.

DCCs stop at delivery

Sneeze does not replace content creation tools. It consumes their output. glTF carries 3D models, animation and scenes from the DCC side into the browser engine.

The format can carry mesh geometry, physically based materials, textures, skeletal animation, morph targets and a hierarchy of transforms. Its binary container can package the same delivery data. Sneeze treats that payload as rendered content rather than as an editable authoring scene.

glTF does not carry the live multi-user state, service streaming or change notifications described by the browser architecture. The map service and SOM handle those jobs. The format transports assets; the spatial system handles what changes around them.

KTX supplies GPU-oriented textures. SPIR-V supplies portable shader bytecode. Compiled WASM modules carry service logic. Together they create a delivery boundary between authoring and runtime.

Materials and textures can come from Substance 3D or Quixel Mixer. Models and animation can come from the usual DCCs. The engine sees the files, not the artist’s preferred interface, node graph or collection of mysteriously named final-final files.

That boundary gives existing Blender workflows a direct route into the proposed runtime through glTF export. It does not promise that every shader, modifier, simulation or custom rig behaviour survives the trip.

Game engines need translation

Unity and Unreal Engine projects have a migration path. Assets that convert cleanly to glTF can move across. Engine-specific rendering, physics, UI and networking do not transfer directly. Those systems depend on the original runtime. Custom effects need new shaders or materials for the Sneeze rendering model, while service logic needs the host-function API instead of engine-specific calls.

That makes migration a conversion job rather than an import button. The architecture preserves the distinction between content that crosses the runtime boundary and systems that remain coupled to a game engine.

Server-side adapters provide another route. An existing application can run as a backend service and expose model data through the browser protocol, while Sneeze renders the result on the client. That route trades direct client execution for compatibility with existing server infrastructure.

Open standards, mixed maturity

The engine stack draws from the Khronos Group, the W3C and existing internet standards. ANARI handles rendering abstraction. OpenXR handles XR device interaction. glTF, KTX and SPIR-V cover 3D assets, textures and shader bytecode. WebAssembly runs service logic.

The Metaverse Standards Forum hosts OMBI as an open project for standards organisations, technology companies, developers and researchers. RP1 contributed a working prototype and leads the engine architecture and maintenance.

The project’s open-source plan puts implementation beside standardisation. Code, documentation, test cases, reference services and developer tooling all fit the contribution model. The final code URL remains the missing practical detail at press time.

Academia joins the build

The University of Rochester has launched the Open Metaverse Academic Alliance through its Center for Extended Reality. The alliance brings universities, researchers, educators and professionals into spatial standards work.

Its current focus includes OMBI. Participants can contribute use cases, conduct research, evaluate proposals and work on the open-source engine. The alliance also connects academic work with enterprise partners and student training.

Two AWE sessions, one booth hunt

The Metaverse Standards Forum and RP1 present Sneeze at AWE USA 2026 in Long Beach. The conference runs from June 15 (Yesterday) to June 18. Sean Mann and Neil Trevett will discuss the browser initiative on June 16 at 4:30 PM in Room 101A. A working roundtable follows on June 17 at 1:40 PM in Room 103B. The Forum and Khronos occupy Booth 104. RP1 occupies Booth 928. The first native browser built with Sneeze is due for discussion and demonstration during the event.

The useful boundary

For artists and pipeline teams, the immediate technical point is the runtime boundary. DCCs create assets. glTF, KTX and SPIR-V carry compiled output. WASM carries service logic. The SOM combines live scene state from separate operators.

Sneeze packages those pieces into an embeddable engine rather than a single proprietary application. Its design defines the architecture in substantial detail, while the missing repository blocks code-level inspection before launch.

Open standards case and initiative scope.
https://omb.wiki/standards

Architecture, SOM, WASM, rendering and content pipeline.
https://omb.wiki/sneeze

Original OMBI project page.
metaverse-standards.org/open-metaverse-browser-initative

OMBI launch announcement.
https://metaverse-standards.org/news/blog/introducing-open-metaverse-browser-initiative/

Forum homepage and project context.
metaverse-standards.org

Open Metaverse Academic Alliance.
https://www.rochester.edu/university-research/initiatives/extended-reality-research-and-application-extrra/open-metaverse-academic-alliance-omaa/

Open Metaverse Browser Architecture PDF.
https://cdn.rp1.com/product/Open-Metaverse-Browser-Architecture.pdf

AWE 2026 sessions.
https://www.khronos.org/events/awe-2026

The post Sneeze Brings a Browser Engine to Spatial 3D first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

For those who don’t know the tool: NeXus is INSYDIUM’s GPU particle and simulation system. The new edition runs inside Blender, while the established version belongs to the X-Particles and Fused ecosystem for Cinema 4D.

Blender gets the GPU toys

NeXus for Blender has entered beta as a native GPU-accelerated particle and simulation system. It covers particles, liquids, granular materials, smoke, fire, flocking, constraints, spreading effects, meshing, trails and instancing inside Blender. INSYDIUM rebuilt the system for Blender rather than presenting the Cinema 4D edition through a thin compatibility layer. The workflow uses Blender objects and installs through the Blender Extensions platform introduced with Blender 4.3.

The software targets rapid iteration through continuous viewport feedback. Every simulation component in the beta runs on the GPU. Final speed still depends on the graphics hardware, scene complexity and solver settings, so the phrase real time remains a workload description rather than a contractual promise from the laws of physics.

Emit first, negotiate later

The nxEmitter creates particles and transfers properties from point clouds. The current beta update expands the options controlling which properties those point clouds pass into a simulation.

The emission stage connects to a sizeable collection of modifiers. nxAttract pulls particles towards a modifier or target object. nxAvoid pushes them away from specified objects. nxDrag applies aerodynamic resistance, while nxGravity supplies the familiar downward career advice.

nxExplode pushes particles away from a point. nxSplash creates an outward cone force. nxTurbulence introduces noise-driven motion, nxVorticity adds vorticity confinement and nxWind applies directional wind forces.

These tools use layered controls. Artists can combine operations inside a modifier instead of constructing every behaviour through a large node graph. Layers can carry separate values, falloffs and blending controls.

The approach keeps routine motion design accessible while retaining per-effect control. It also lowers the interface tax for artists who want to art-direct particles without turning every adjustment into a small software engineering project.

Fluids cover several arguments

nxFluids handles liquid and granular simulation through PBD, SPH, FLIP and APIC solvers. That gives artists several numerical approaches within the same broad tool rather than tying the entire workflow to one fluid model.

FLIP and APIC cover liquid simulation. PBD and SPH support particle-based fluids and grains. Controls include viscosity, density, surface tension and particle interaction. Different densities can produce different fluid or granular behaviours inside a setup.

nxUpres separates interactive work from final density. Artists can build motion with a lower-resolution emitter, then transfer it to a destination emitter with a larger particle count. This reduces the cost of experimentation before committing to a denser result.

That workflow suits effects where broad motion must settle before final particle counts, meshing and rendering. It does not remove the need to validate the high-resolution result. Increased density can reveal collisions, gaps and surface behaviour that remain hidden in a lighter preview.

Smoke and fire join in

nxExplosiaFX handles smoke and fire. Emitters can derive from objects, splines, vertex maps, shaders and particles. Controls cover particle advection, data-channel mapping and layered treatment of emitters, collisions and forces.

The system requires a modern GPU with at least 4 GB of VRAM and current drivers. That is the minimum, not a comfortable production recommendation for every fluid or volumetric scene. Dense smoke and high particle counts have never shown much respect for minimum specifications.

Motion without node archaeology

The shaping group covers a wide range of common particle operations. nxBlend mixes parameters between neighbouring particles. nxCover distributes particles across target surfaces. nxDirection layers directional control, while nxFollowGeo keeps motion travelling along surfaces or edges.

nxPush separates overlapping particles. nxRotate applies rotational force. nxScale changes geometry scale, particle radius or mass through layered operations. nxSpeed modifies velocity, and nxSpin controls particle rotation.

nxSticky attaches particles to object surfaces. nxWave creates wave motion through noise patterns. These modifiers address jobs that often begin as a simple request and finish as a graph with three frames, two reroutes and one node nobody remembers adding.

Geometry exits the simulation

nxGenerator instances meshes at active particle positions. This turns a simulated particle state into repeated scene geometry for motion graphics, debris, vegetation-style distribution and related effects. nxMesher converts particle emitters into polygon surfaces. Its role becomes particularly important for liquids, where the final image usually needs a coherent surface rather than a visible cloud of points. nxTrail produces particle trails either as a viewport overlay or as curves. The current build fixes a spline-material issue and restores trail thickness when rendering with EEVEE.

The geometry and rendering preview demonstrates this stage of the workflow, while separate official clips cover nxMesher and fluid behaviour. Together they provide a better view of the output path than the initial announcement preview alone.

Blender versions and operating systems

NeXus requires Blender 4.3 or newer. The supported range includes Blender 4.5 LTS, Blender 5 and later releases. Windows and macOS builds are available now. Linux support is coming soon. Windows and Linux require Vulkan 1.3. macOS requires Metal 3.

Online checks remain part of the deal

A customer account is required to access the beta and its licence. Licensing takes place online, so the software needs an active internet connection. The beta also sends anonymous usage statistics. Collection remains permanently enabled during the beta and cannot be disabled. INSYDIUM states that the collected statistics contain no personal information.

Perpetual means this version stays

The beta uses a perpetual licence with a one-off payment. Buyers keep the 2026 version.

All service updates for the 2026.x line are included without extra cost. Future major versions can be upgraded for half of the full price applying at that time. The licence carries neither a subscription nor maintenance fees.

The store lists a full price of £140. The current beta price is £98 excluding VAT, representing a 30 percent reduction. Owners of an eligible Fused licence can receive 50 percent off the full price. This is a paid beta rather than a free public preview. The purchase secures the perpetual 2026 licence while exposing users to software that still carries the beta label and an active repair list. But it shows that INsydium is very confident that they havea well-working tool in their box.

The model may appeal to artists tired of accumulating monthly charges for every specialised tool in the pipeline. It also places the evaluation burden directly on the buyer, since the current product remains under development.

https://insydium.ltd/shop/index.php?route=product/product&product_id=105

• Official NeXus product page: https://insydium.ltd/products/nexus
• Official video channel: https://www.youtube.com/@INSYDIUMLTD/videos

https://insydium.ltd/products/nexus

The post NeXus Beta Lands in Blender first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

MoonshotCGI has made a free Komodo asset available through its Try our assets page. The free package is a multi LOD model, muscle ecorche, an advanced rig, 2K multiUDIM textures and a walk cycle animation. Also, there is a facial rig (Insofar as Dragons have face instead of giant maws of putrid creepyness), multiple resolution levels and files for Maya, FBX, Alembic and OBJ workflows.

For creature artists, this is the useful kind of freebie: not just a still-friendly mesh, but a rigged animal with animation data. It gives modelers, animators, TDs and lookdev artists something to poke before procurement wakes up. Test teh rig, deformation, texture coverage and caches before trusting it in a real pipeline.

Paid tiers for real jobs

The commercial product page has paid versions of Komodo Dragon starting at €292,62. License options include Non-Commercial, Indie and Studio, with Silver, Gold, Platinum and Diamond asset tiers. Non-Commercial Silver costs €292,62 and includes model, textures and lookdev. Non-Commercial Gold costs €438,93 and adds rigs. Indie Silver costs €780,33, Indie Gold costs €1.170,50 and Indie Platinum costs €1.365,57. Studio Silver costs €2.926,23, Studio Gold costs €4.096,72 and Studio Diamond costs €4.681,97.

Indie is listed for individual freelancers only. Studio tiers use 4K textures, while Non-Commercial and Indie tiers list 2K textures. Indie Platinum and Studio Diamond list walk, run and idle cycles. Studio Diamond also adds animations and simulations. So, igf the joke from the dailies session gets to big, you don’t have to rebuild it, but can buy the odel and put it in there. We assume, a lot of background gags in cinematic historey start this way.

Formats and pipeline reality

The paid product has .abc, .obj and .fbx. Textures are listed as EXR, TIFF or PNG. Rigs, lookdev and animations use .ma or .mb. Simulations use .hip, which points that part of the asset toward Houdini users. External plugins are not required at the moment. MoonshotCGI is moving its rigging workflow to mGear, and future rigs will require it when the asset description says so.

https://shop.moonshotcgi.it/en-eu/pages/try-our-assets
https://shop.moonshotcgi.it/en-eu/products/komodo-dragon

The post Free Komodo Rig for Fun first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

For those who don’t know the tool: DroneSiteBuilder is a script for Autodesk 3ds Max (AND BELDNER )that reads drone photo metadata to assemble terrain, map context, and matched cameras, bundling GeoBuild and CameraMatch and supporting handoff to Blender, SketchUp, and Autodesk Maya.

UPDATE

This just in, and we are quoting the Developer: DroneSiteBuilder is now available for Blender users too. The Blender edition I mentioned was “coming soon” is here, so the full drone-photo-to-3D-site workflow now runs natively in Blender as well as 3ds Max.

What DroneSiteBuilder is trying to fix

DroneSiteBuilder Enterprise turns a folder of drone photos into a full site context scene inside the 3ds Max ecosystem: terrain, aerial drape, buildings, roads, land cover features, points of interest, and one matched camera per photo.

The pipeline reads XMP metadata per image and uses it to place helpers at ground level and flight altitude, then creates a renderer-aware camera per photo and refines orientation using vanishing point detection. The tool targets 3ds Max 2020 or newer on Windows and uses Python 3.9 through 3.12 with NumPy and OpenCV, plus optional modules for the Google path.

First use, abbreviated

Install a standalone Python build and make sure Add Python to PATH is enabled during install, because the tool does not rely on the 3ds Max built-in Python. Place DroneSiteBuilder_Enterprise.ms and vp_detector.py in the same folder and do not install under Program Files, since Windows blocks writes there.

Launch 3ds Max and load the script via drag-and-drop into a viewport or via Scripting > Run Script. Paste your licence key into the activation dialogue and activate, with support for an Enterprise key format and existing CameraMatch Studio keys. After activation the key caches locally for thirty days and the rollout opens.

For the first build, keep original DNG or JPEG drone files in a single folder, keep filenames ending in digits, and keep an internet connection available for the auto fetch steps. Pick a terrain DEM source, keep NOAA GEOID18 enabled for continental US sites and disabled outside the US, then run Process Folder of Drone Photos and accept the summary dialogue. Inspect the result by comparing a matched camera view against the source photo.

The new checkbox: Google Photorealistic 3D Tiles

Enterprise v1.2 adds an opt in mode that fetches Google Photorealistic 3D Tiles and imports them into 3ds Max as a single merged glb, covering the photo bounding box. The intention is simple: pull a photogrammetric backdrop mesh with terrain, textures, and buildings baked into one continuous model, using the same dataset shown in Google Earth.

The Google path requires a Google Maps Platform project with billing enabled and the Map Tiles API enabled, plus a saved API key in the rollout. The manual describes 1,000 root tileset requests per month free and a per 1,000 price after that, with one DroneSiteBuilder run treated as one root tileset request. If the fetch fails, the tool reports common causes like missing API enablement, low coverage, EEA billed accounts being blocked for this endpoint, missing Python modules, and older 3ds Max builds needing a glTF importer.

This is also where the gaudrrails get real: the Google import produces mesh only content with baked textures, so you do not get separate terrain, buildings, roads, and features objects to isolate, re material, or hide by category.

The standard path is still the controllable one

If you leave the Google option off, the pipeline builds a layered context using public services. Terrain comes from USGS 3DEP in the US or OpenTopography worldwide, aerial imagery comes from Esri World Imagery as a single bounding box JPEG, and vector context comes from OpenStreetMap via Overpass.

The scene builds under a single root helper so you can move, rotate, or scale the entire site as one unit, while cameras intentionally sit outside that parent chain to support camera transplant between scenes. If buildings and roads fail to appear on a run, the manual provides a manual Overpass refetch button that rebuilds buildings, roads, and land features without disturbing terrain, drape, helpers, or cameras.

OpenStreetMap accuracy varies by location and that the resulting geometry accuracy for this context layer sits in the one to six meter range. It contrasts that with paid city model providers such as AccuCities when millimeter level detail matters.

Export and handoff from 3ds Max

DroneSiteBuilder does not change how 3ds Max exports, but it does influence what you export. The standard path creates distinct terrain, buildings, roads, and feature objects you can selectively include in deliverables, while the Google path imports a tile based mesh group that is already baked.

For broad DCC and engine handoffs, 3ds Max includes a built in exporter for glTF and supports export workflows for USD, with export options available through File export and USD and USDZ format selection when the USD tooling is installed. For USD pipelines, the official OpenUSD plugin for 3ds Max is published on GitHub, and Autodesk documentation describes supported USD content types including meshes and cameras.

If your downstream is realtime, glTF targets web and interactive use cases, and you can also push common interchange paths like FBX into engines such as Unity and Epic Unreal Engine, depending on your studio conventions. For camera and layout continuity between scenes, the bundle includes a camera transplant workflow that exports camera data to JSON and recreates it with full precision in another scene.

Practical reality check

This toolkit aims to comperss a traditional drone to 3D context workflow into a short unattended run. The promise stands or falls on your input photos keeping XMP metadata intact, on your site area having decent public map coverage, and on you verifying the result against the plate before trusting it.

We don’t know the price yet, but if you already own the camera match tool in the Studio version, you get it for free, apparently. Quoting: Existing CameraMatch Studio licence keys activate the full DroneSiteBuilder bundle. Studio holders do not pay twice. 

Try both context modes on a test job: the standard layered build when you need controllable components and re-lighting freedom, the Google mesh mode when you need a fast photogrammetry backdrop and can live with mesh-only content and licensing constraints.

https://jamiecardoso-mentalray.blogspot.com/2026/03/dronesitebuilder-enterprise-v12-one.html

https://jamiecardoso.gumroad.com/

The post DroneSiteBuilder adds Google 3D Tiles option first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

For those who don’t know the tool: 3DGS Render brings Gaussian splat import, editing, conversion and rendering into Blender. It works with PLY data and complements the KIRI Engine scanning app.

Splats learn to move

KIRI Innovation has released 3DGS Render 5.0, a free and open-source Blender add-on for handling 3D Gaussian Splatting data. The major addition transfers deformation from a proxy mesh to a Gaussian splat object. Artists can rig and animate a conventional mesh, then use that mesh to drive the splats. This brings familiar armature and character-animation methods into a data type better known for capturing static objects and environments.

The workflow does not turn the splat into a conventional polygon model. The mesh acts as the deformation source. The add-on transfers its changing shape to the Gaussian data, which can then be baked over time.

Rigging and animation tools stay on the mesh side, where Blender artists already know how to work. The splats receive the resulting deformation instead of demanding an entirely separate animation system. A demonstration transfers a stock Mixamo animation to a scanned character. The proxy carries the animation, while the splat representation follows its deformation.

The animation feature remains VERY experimental. Performance is currently limited, even though the workflow functions. That makes version 5.0 useful for tests, research and less time-sensitive work, rather than an automatic invitation to place tomorrow morning’s delivery on its shoulders.

Proxy business

The new deformation transfer begins with a proxy mesh that corresponds to the splat object. A rigged character can fill that role. Artists animate the mesh through standard Blender tools, including an armature. The add-on then transfers the deformations to the Gaussian splats. This separates animation control from the captured representation and avoids asking artists to rig a cloud of anisotropic primitives directly.

https://www.youtube.com/@3D-Tools-by-KIRI-Engine

The approach also permits existing character animation to enter the workflow. A suitable proxy can receive motion first, after which 3DGS Render passes the deformation to the splat object. That does not erase the preparation step. The mesh still needs to function as a usable proxy for the captured subject. Version 5.0 provides the transfer mechanism rather than replacing rigging, skinning or animation work.

Once transferred, the animation can be baked as a sequence of PLY files. Software that supports animated splat data through frame sequences can then receive the result outside Blender. But beware: Blender will burn during that, and you WILL take a long break.

The export method is refreshingly literal. Each frame becomes splat data rather than a compact rig with reusable controls. This gives the receiving application the baked result, while the editable rig and proxy workflow remain inside Blender.

Anyone expecting a universal character interchange format should read the filename twice. This is a sequence of PLY files, with the practical storage and pipeline implications that such a sequence brings. Meaning: Your storage will be F….illed.

Light joins the ride

Version 5.0 can also bake lighting information from the proxy mesh to the 3DGS object. That gives the proxy another job beyond deformation. Its surface can carry lighting information that transfers to the splats, joining the animation bake. Earlier versions already let imported splats react to lighting and cast shadows through the add-on’s real-time rendering mode. The new bake path connects proxy-based lighting with exported splat animation.

Inside Blender, 3DGS Render can relight splats and render them with Eevee. Artists can therefore keep capture data, proxy geometry, animation and lighting in one DCC while preparing the result. The release does not claim that baked proxy lighting replaces every lighting workflow. It provides a route for transferring that information to the splat object and carrying the result into the baked sequence.

The existing toolbox stays

Animation arrives on top of the add-on’s established editing and conversion tools. 3DGS Render imports 3DGS data stored in PLY files. Imported splats behave as Blender objects for common transformations, allowing artists to move and rescale them within a scene. The tool can crop unwanted areas from raw scans and merge separate scans. Those operations address the untidy reality of capture data, where the desired subject often arrives with pieces of floor, background or neighbouring geometry attached.

Colour editing and modifiers remain part of the workflow. The repository also describes point-cloud editing and optimisation before conversion into 3DGS data. The add-on can convert conventional meshes into 3DGS PLY files. That opens the opposite direction of travel: a mesh can become splat data for export into other software that supports the format.

The 3DGS format sits at the centre of all these operations. For a closer explanation of splats and their place in realtime production, Digital Production’s Volinga 3DGS workflow for Unreal covers the underlying representation and its practical use in an engine pipeline.

The new functionality does not promise interactive playback at production speed. Its experimental status and current performance limits should remain visible during scheduling, especially with dense scans or long frame ranges.

A short test sequence should reveal more than a triumphant press-release adjective ever could. New tools and innovations should always be tested before use in production.

Free, open and experimental

3DGS Render 5.0 costs nothing to download. Its source code is available under the Apache License 2.0. Free access does not remove the cost of validation. Teams still need to test installation, dependency compatibility, animation transfer, lighting bake, export size and playback in the destination tool.

The experimental animation feature makes that validation particularly important. It works, but current performance remains limited. The honest reading is more useful than a glossy one: splats can now follow a rigged proxy, though they have not promised to sprint.

For artists exploring animated capture data inside Blender, version 5.0 supplies a concrete workflow. Build or obtain a suitable proxy, animate it with familiar tools, transfer deformation and lighting, then bake the Gaussian result into PLY frames.

https://www.kiriengine.app/3d-tools

https://github.com/Kiri-Innovation/3dgs-render-blender-addon

The post Let’s Animate Splats in 3DGS Render? first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

For those who don’t know the tool: Pilgway makes 3DCoat for sculpting, retopology, UVs, painting and rendering. It connects to Blender, 3ds Max and Houdini (and LightWave) via applinks. 3DCoatTextura is the texture-focused sibling.

GPU paint, finally with nodes

3DCoat 2026 is now in public beta for Windows, and the big change is GPU Per-Pixel Painting. The new system adds a procedural Node System for UV-based, non-destructive texturing and lets artists create materials, masks and effects in a visual Node Editor. Parameters such as rust intensity, base color, glossiness and scratches remain editable during work, with real-time viewport feedback on the 3D model.

For artists who have spent years painting a layer, committing to it, regretting it, duplicating it, hiding it, naming it “final_final_02_nowforreal_b”, and then crying softly , this is the headline feature. The workflow moves more of the material logic into editable graphs. The development thread labels the build as an early beta and says it is not recommended for production environments. Believe the developers when they say that!

What the Node System does

The system uses GPU nodes and dynamic compilation into optimized shaders based on NodeGraph Language, or NGL. Procedural operations, mathematical operations and noise generators run directly on the GPU. That matters for texture artists because procedural work can become very chatty. Every mask, noise, curvature blend and dirt pass adds another little gremlin to the stack.

The documentation lists a full Node System with Node Editor, Node and Object Inspectors, Node Graph, NGL, GPU Nodes, Filters, Masks, Materials, Modifiers and Volumes. The GPU Texturing documentation also lists Per-Pixel Painting and PBM Channels.

The docs describe PBR texturing in 3DCoat around Albedo, Depth, Glossiness and Metalness channels. Painting can modify multiple material channels with one brush stroke. The new node system now sits beside that painting logic, rather than replacing the idea of channel-based texture work.

New smart materials, new smart masks

The 2026 beta introduces NGMaterials, NGMasks, NGModifiers and NGFilters. NGMaterials are procedural smart materials. NGMasks generate procedural wear, dirt and scratches. NGModifiers and NGFilters handle geometry deformation and procedural post-processing of current layers. The new materials support approximately 30 channels.

Procedural texturing in a painting app is always a balancing act. Artists want control without turning every barrel, robot arm or old pipe into a PhD in graph management. The Object Inspector tries to keep that sane. Parameters can be pinned from the node graph to general object or layer controls, so a material can expose useful sliders without making the artist dive into the full graph every time.

The UI adds a Node Editor, Node Inspector and Object Inspector. Node header colors are now category-based in the 2026-03 NS Beta. New nodes are created at the position where the right mouse button opened the menu, not where the cursor happens to sit when the menu action finishes.

Layers still matter

The new graph workflow does not remove the old layer habit. The beta adds the ability to select multiple painting layers, move selected layers within the painting layer tree, and group, hide, unhide, duplicate or delete them.

In GPUPPP mode, layer masks use brightness rather than relying exclusively on transparency. Normal Map Support appears in node-based materials in the 2026-03 NS Beta. A crash when clearing the Node Graph in the Node Editor has been fixed, and rectangle or CTRL selection of multiple nodes has also been fixed.

The 2026-02 preview also allows image reading and writing formats to be replaced via Python extension. Objects created by C++ functions from Python scripts will not be garbage collected by Python, avoiding double freeing.

Fabric, fur and soft displacement

The 2026-03 NS Beta adds a Soft Displacement property. The changelog describes it as a displacement effect designed to work with a normal map. It shifts vertices without affecting shading, reduces its shadow impact by half, and uses the normal map to define pixel orientation for shading.

SoftDisplacement combined with Sheen can simulate fur, while FWSNormal defines its direction. For PPP texturing, Show Displacement Mesh must be enabled and tessellation must be configured.

Retopo and modeling also get crumbs

The headline belongs to 3D texture painting, but the beta also touches retopo and modeling. The 2026-03 NS Beta adds an option in the Retopo and Modeling Room: Switching Pen Mode to Rectangle After the Select Transform Activated. Polygon Tree has been improved for speed with large files.

The Sculpt Room gets speedups for Blob tool filling in Smart Hybrid and a new lasso placement option for the Blob tool in Smart Hybrid. Live booleans get a crash fix when unghosting. STL import fixes address overly small scale on import.

3DCoatTextura’s learning mode keeps saving and loading in the internal .3b format, with a limitation of 10 layers and render watermarks. OBJ export remains available with limits: 4000 triangles from the paint room and texture export up to 512 by 512 without watermarks, or higher resolution with watermarks. Commercial use is not allowed for that free learning-mode output.

Pricing, because artists own wallets

The official 3DCoat buy page lists 3DCoat 2025 Individual Node-locked at €379, VAT not included. It is a permanent personal license, allows commercial use, works as a platform-independent license and includes 12 months of free updates.

The same page lists subsequent updates at €45 from month 13 onward after purchase, or €90 from month 25 onward if the €45 upgrade was not made, with another 12 months of free updates.

Bottom line

The best news is not just “nodes”. The useful news is that the system connects to painting layers, masks, smart materials and viewport feedback. That is where texture artists actually live.

The caution flag is equally clear. The build is beta, Windows-only in its current public form, and explicitly not recommended for production environments. Test it, break it, report the boring bugs, and do not bet a delivery on it yet. The graph may be shiny, but the deadline goblin remains undefeated.

https://3dcoat.com/forum/index.php?/topic/34175-3dcoat-2026-gpuppp-development/

The post 3DCoat 2026 gets GPU nodes first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

For those who don’t know the tool: Flying Bugs Generator is a Blender setup built with Geometry Nodes, delivered as ready-to-use assets for the Asset Browser so you can drag generators into shots and animate swarms or curve flights.

You know that feeling when you need bugs for a shot and nature refuses to cooperate? Some people just knock on the neighbor’s door and instantly receive a swarm and an entire insect census, because apparently soap is optional in that household (We are lucky, yes. Our joy knows no bounds, as well as the pest control dude on speed dial). For everyone else, there is Flying Bugs Generator in Blender, a controllable swarm machine that keeps the chaos procedural and the kitchen hygienic.

Ryan King Art has a more pipeline-friendly option: Flying Bugs Generator, a Blender tool built with Geometry Nodes for animating swarms of flying insects. The setup focuses on controllable motion and quick iteration. You adjust parameters on modifier properties to change how many bugs you get, how far they spread from a center, how noise affects the motion, plus scale, speed, rotation speed, and options for animating along a curve.

Ten bugs enter the shot, none demand attention

The pack includes ten bug types: flies, honey bees, locusts, gnats, moths, bumble bees, wasps, mosquitos, fireflies, and termites. Each type supports three movement modes. Swarm mode flies bugs around the surface of a mesh, and you can edit that mesh to steer the path.

Along Curve mode follows a curve and adds manual animation control over a set number of bugs, with editable curve handles to direct motion. Never Ending mode also uses a curve, but generates a continuous stream along it.

In other words, it is built for the common scenarios: a localized cloud of insects you art-direct with geometry, a guided flight path you key for timing, and an endless emitter you can loop without hand-placing a thousand wingbeats. You’ll probably see which one you need to remaster the 90’s cinematic masterpiece “The Mummy”.

Asset Browser delivery, aka less setup, more anmiation

All generator objects come pre-configured as assets in Blender and are intended to be used through the Asset Browser. The workflow described is to set up an asset library in user preferences, then drag and drop a generator into a scene. This turns a node setup into something a team can reuse consistently. You get a predictable entry point in the scene, and you can treat the generator like any other asset instead of a one-off node graph someone forgot to name. Sship the complexity once, expose the controls that artists actually touch, and keep the scene file readable on a Monday morning.

Pricing and the boring part you still need to know

The suggested price is $15 here: Superhive (formerly Blender Market), which is far less than the effort and materials to breed the bugs yourself, get cameras, and an animal handler to teach them to fly along the chosen paths.

Also available through Fab.com.

As always, test new tools and innovations before you bet a deadline on them, especially anything procedural that can multiply geometry, instances, and render time faster than you can say “why is the viewport at two FPS”.

https://ryankingart.gumroad.com/l/bug
https://ryankingart.gumroad.com/

The post These are the Bugs You Were Looking For (in Blender) first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

For those who don’t know the tool: image-blaster sits between concept and rough layout, using Claude to orchestrate Marble from World Labs and write splat environment files you can move into DCCs and engines.

The headline feature is the splat

image-blaster takes a single reference image and, by default, generates a Gaussian splat of the static environment as an .spz file. This splat is a static environment output, separate from any object meshes or audio it may also generate. It runs as a Claude driven workflow where you put an image into the input folder and ask Claude to blast it while confirming each step.

That .spz environment output targets the fast part of production where you need space, scale, and a place to put cameras. If your team already tracks experiments for gaussian splats, this lands squarely in that bucket, with the advantage that the output arrives as a file on disk rather than a locked viewer.

There is also a time claim of under five minutes to go from image to a fully meshed 3D environment. Treat that as a marketing claim and validate it against your own network, machine, and API limits before you build expectations around it.

Marble, SPZ, and what you actually get

image-blaster lists marble-1.1 as the world generation model it uses for the explorable environment. In practice, that means the environment representation you get from the Marble side is an SPZ splat file. SPZ is Marble’s native splat format, optimised for file size, while PLY is an uncompressed format compatible with more Gaussian splat software packages.

If you plan to wire this into a pipeline, the file format matters more than the demo. SPZ tends to travel well when you stay inside the same ecosystem, and PLY tends to travel well when you want broader compatibility. World Labs also documents a common gotcha: default generated worlds use an OpenCV coordinate system, while many DCC applications use an OpenGL coordinate system, so correcting for that by scaling the Y and Z axes by minus one while keeping X unchanged is necessary. We learned that the hard way.

Splat assets exported by the API use arbitrary model units, not meters, and points to semantics metadata values that can be used for metric scale and ground alignment. That is the kind of detail you want early, because nothing burns time like a “looks fine in the viewer” asset that arrives in the wrong coordinate frame once you ingest it. And, let’S be honest, generated stuff lacks in consistency, and everybody knows. Plan for that!

The workflow is orchestration, not a single model

image-blaster frames itself as a set of skills that orchestrate multiple models. Marble handles the environment generation path that results in the SPZ splat for the static environment. The repository has other models it can involve for cleanup and object generation, but you can treat those as optional if your goal is strictly to generate splats from images.

You run the Claude CLI, provide API keys for World Labs and fal, then feed an image and guide the process via prompts. The repository even includes a development note about removing the app folder from the Claude ignore file if you want Claude to change the React viewer. That means the output can become part of a toolchain rather than a one off experiment. You can keep the same wrapper, swap inputs, and iterate, which is usually what artists actually want when they say “make it usable.”

Where splats meet real tools

image-blaster says you can embed it under the assets of a game engine, DCC software, or a web app. It explicitly names Blender as a target DCC and calls out Three.js for web apps.

image-blaster is open source under the MIT license, but the environment generation step relies on paid APIs. World Labs API billing runs on credits purchased through the World Labs Platform, and credits purchased for the Marble app cannot be used with the API. The API pricing page has a fixed rate of 1.00 USD per 1,250 credits, with a minimum purchase of 6,250 credits or 5.00 USD.

Pipeline advice that saves you from yourself

Splat workflows reward quick iteration and punish sloppy ingestion. Lock down where SPZ files live, how they are versioned, and who converts them, especially if you plan to move between coordinate systems or into other formats. Also, test new tools and innovations before use in production. Verify coordinate orientation, scale, file integrity, and viewer behavior before anyone depends on the output for layout, virtual scouting, or client reviews.

https://github.com/neilsonnn/image-blaster
https://www.worldlabs.ai/
https://docs.worldlabs.ai/marble/export/specs

The post Image Blaster turns images into Splats first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

For those who don’t know the tool: Blender uses Blender Cycles for path-traced rendering, and viewport denoising helps lookdev stay interactive while lighting and materials evolve.

The news, minus the confetti

NVIDIA says Blender Cycles will integrate DLSS 4.5 Ray Reconstruction as a new denoiser and ship it with Blender 5.3 in the fall. The goal is a more interactive viewport while keeping a “near-final” look in real time.

DLSS Ray Reconstruction targets ray-traced and path-traced content and replaces traditional hand-tuned denoisers with an AI model that reconstructs pixels in noisy areas where rays were not sampled. It also unifies denoising and Super Resolution into a single model that uses temporal and spatial engine data to rebuild higher fidelity images. Usually, that is for games – you need all the pixels and all the fidelities for veggie-mode in Microsoft Flight Simulator (Don’t Judge, the Dune expansion is great!) Here is a list of all Games that have that, and in that list, you can even spot Redshift, Marmoset and Keyshot. Strange calling those “Games”, but who hasn’t lost to a renderer?

The same announcement says DLSS 4.5 Ray Reconstruction arrives in August for games, and it is also coming to Blender 5.3 in the fall. That timeline matters for anyone planning tool rollouts around seasonal show crunch. Prep first,so you don’t have a bad surprise up ahead.

What changes inside Cycles

Cycles already has an integration path via NVIDIA OptiX. The new piece is DLSS 4.5 Ray Reconstruction as another denoiser option, layered on top of the existing OptiX integration.

If you spend your days in a path-traced viewport, denoising is not a luxury feature. It is the thing that keeps lighting decisions moving. A denoiser that keeps interaction up while pushing the look closer to final could reduce the familiar loop of tweak, wait, squint, tweak again. This sits squarely in the Blender Cycles ecosystem: you still light and shade the same way, you still render the same way, but the viewport becomes less of a tax on iteration.

The longer arc from hacks to shipping builds

Back in February 2026, Blender artist Blake Propst tested a Blender 5.1 build with DLSS on an RTX 3090, with reports of numerous bugs and visual issues. A patch also existed that added an option to use DLSS Ray Reconstruction for viewport denoising in Cycles, and users were encouraged to test Blender 5.1 beta and report issues toward a stable release.

That earlier phase sounded like classic early integration energy: exciting demos, messy edges, lots of caveats, and a very human amount of duct tape. It did prove one thing, though: artists wanted it badly enough to put up with rough builds, because interactive path tracing is still a wrok in progress on most desks. Now the situation shifts from experiments to a shipping target in Blender 5.3.

What DLSS 4.5 Ray Reconstruction claims it does

DLSS 4.5 Ray Reconstruction uses a second generation transformer model. It is improving image quality in ray-traced and path-traced content, and the announcement lists changes such as higher compute capability, more parameters processed while maintaining similar performance to the previous model, better temporal stability, and clearer motion in ray-traced and path-traced scenes. For artists, the practical question is not whether the model sounds clever. The practical question is whether it behaves well under production pressure: animated textures, fast camera moves, thin geometry, alpha heavy foliage, refractive messes, and the kind of lookdev that loves to change one variable per second.

Viewport denoising is where time disappears

A big chunk of render pain is not final frames. It is the time you spend waiting for a viewport to become readable enough to make the next decision. A clean enough image lets you judge lighting ratios, contact shadow behavior, glossy breakup, and whether your material values drift into plastic. A noisy image forces you to wait, or worse, to guess.

The boring parts you still need to know

Pricing is not specified in the sources – propably will be part of drivers or blender itself, so should be free. Read the T&C before downloading, though.

Hardware requirements are not spelt out for Blender beyond the general statement that DLSS Ray Reconstruction works on all GeForce RTX GPUs. The Blender sources mention testing on an RTX 3090 and as part of an RTX focused stack, but they do not provide minimum GPU or driver versions for the Blender 5.3 integration. We’ll see.

https://www.nvidia.com/en-us/geforce/news/computex-2026-nvidia-geforce-rtx-announcements/

The post NVIDIA brings DLSS denoising to Blender 5.3 first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

For those who don’t know the tool: True Sky is a sky, atmosphere, and HDRI tool inside Blender for Cycles only. It targets lighting and environment lookdev, and it sits alongside tools like True Terrain 5 for building full outdoor shots.

A sky rig that insists on real scale

True Sky by True VFX is an Earth atmosphere you can fly through, built around planet-scale scattering so a single scene can move from ground level to lunar orbit. It brings a 1-to-1 Earth radius scale and a 100 km atmospheric depth (otherwise known as the Karman Line). True Sky 3 exposes Rayleigh, Mie, and ozone layers with real-world coefficients. Or at least so it claims.

But there is more: Celestial objects, including the sun, moon, all nine planets, asteroid belts, and custom emitters with true orbital positions and scalable sizes. It also has aurora and rings support. If you work in the Blender ecosystem, the practical thing is consistency: the same sky rig aims to cover horizon shots, timelapses, and space fly-bys without swapping HDRIs or rebuilding a world shader per shot. Just remember that new tools and innovations should be tested before use in production, especially when volumes sit at the center of your lighting, and te tool is all around your scene.

Cycles only, Blender 5.1 only, and here is why

The listing states it is compatible with Cycles only and does not support Eevee. It also has Blender Version 5.1 as the minimums, since Blender 5.1 changed its underlying Python version, which required rebuilding the Python modules the add-on needs and made it not backward compatible. You can access older files that worked in Blender 4.5, but those may miss some optimizations.

Exposure, HDRIs, and the classic pure white sky moment

By the way, a common first-run surprise is a pure white sky. The tool uses real world values, which can overblow images by default, and suggests adjusting exposure. Enable Exposure in the TrueSKY panel path Misc, Effects, Exposure, then lower exposure around minus 4.0 and setting opacity to 1.0.

The same FAQ notes a compositor gotcha: if compositing applies only to camera views, the background can look correct in camera but blow out in the viewport. It recommends switching Compositing Mode from Camera to Always.

Performance controls that behave like a shot budget

The dedicated docs describe a Performance panel built to balance quality and speed for volumetrics, clouds, and heavy effects. It splits into Presets, Volumes, and Extras. Presets provide a Volume Preset baseline, plus Steps Mode with Fast Steps for lookdev and Accurate Steps for flying through volumes or horizon-heavy shots. It also has a Quality Mode where Fast increases effective step size and Accurate reduces step size, plus a Fast Viewport toggle that doubles viewport step size for quicker previews. The docs suggest a simple strategy: Fast Steps plus Fast Quality for blocking, then switch to Accurate for finals. Not Revolutionary, but appreciated. Why not call it Proxy?

Volumes exposes per-layer controls, including an Atmosphere Quality slider and per-layer Cloud Quality sliders, plus an Altitude Weighting toggle that lets higher cloud layers use slightly lower quality for speed. The docs recommend raising only the hero cloud layer rather than cranking everything globally.

Extras include viewport and render helpers like viewport and camera render regions, pixel size for faster viewport renders on high-resolution screens, and tile size for CPU-friendly final renders. If you want the shortest possible summary: True-VFX gives you a place to decide what gets quality, what gets speed, and what gets left alone until the director stops moving the camera. And that is almost always the same place you wanted to put it in the first version, but ….

Pricing and licensing

True Sky 3 is early access and sets an early access price at 40 USD, 50 USD release price. Also, there is a separate Lifetime Updates option at 250USD. Licensing is GPL, and the tool can be maintained or customised by the user even after official support ends. Updates are included for the 3.x series, and a planned 15 USD upgrade fee for a future 4.0. A portion of each product sale is donated to the Blender Foundation (about 5 per cent), and 13,000 USD have already been donated by the community supporting the product line.

https://superhivemarket.com/products/true-sky?ref=586
https://truesky-documentation.pages.dev/
https://www.true-vfx.xyz/

The post True Sky 3 brings planet-scale skies to Blender first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

VOXIFY voxelizes meshes while aiming to preserve color and other material maps such as roughness and metallic. The workflow captures UVs, then creates attributes so the voxel result can pull data from the original textures. If you want a drinking game: Take a shot every time we write the word Voxel, and consider your current life choices, when you play drinking games at 8AM in the morning on a Monday, when this news comes out.

The tool targets stylised voxel art renders, LEGO-style renders, game environments, and abstract motion graphics. It also calls itself non-destructive, meaning the setup stays editable as a modifier rather than forcing an immediate apply.

Material support comes with a big practical caveat. The modifier cannot work with simple colour materials or multi-material objects unless you first bake all materials and colours into a single texture, then use that texture for colour transfer. The same rule applies to other maps. VOXIFY works well with 3D-scanned assets, where the look already lives in texture maps.

Import, scale, then touch the voxel size slider

VOXIFY loads into a scene through Blender’s append workflow. You append a VOXIFY collection from the downloaded file, which loads an empty mesh with the Geometry Nodes modifier. Duplicate that empty mesh per asset, then place the duplicate into the working collection for that shot.

Before you voxelize anything, two basics: apply transforms and keep object scale sensible. Applying scale uses the standard apply transform workflow and voxel size behaves like a real world control, so a tiny prop and a skyscraper should not share the same voxel size value. A very large object expects a larger voxel size value, otherwise performance and results fall apart.

Once the base setup behaves, voxel size becomes the main artistic lever. Smaller values create denser voxels. Larger values create chunkier results. That is where VOXIFY tries to feel like a production-friendly knob instead of a one-click filter.

Viewport choices and custom instances

VOXIFY includes controls for how the result displays in the viewport versus final render, switching the viewport representation to a point cloud for optimization, while keeping a voxel look for render. The modifier also supports custom voxel shapes. Instead of instancing cubes, you can instance a user supplied object as the voxel unit. Transparent areas get special handling. The setup includes masking transparent parts by enabling a mask with texture option and feeding an opacity map, so voxels do not fill areas that would never render.

Pruning, carving, and not paying for invisible cubes

Voxelization loves to create internal structure you never see, and VOXIFY exposes controls to deal with that. For transparent textures, the prune and mask controls help stop voxels from spawning in cutout regions. For solid objects, there is an option to remove internal voxels, reducing geometry that would sit inside the mesh and never contribute to the image. That internal removal matters both for render performance and for downstream conversion to a static mesh.

VOXIFY also brings pruning – carving out a more accurate outer shape. The prune section offers two carving methods: raycast and distance. Raycast is more accurate, while distance can help keep more vxoels where you need them. Tolerance controls how aggressively that carving behaves, and it often starts near the same value as voxel size.

Static mesh output, plus the part where topology bites back

VOXIFY includes a generate static mesh option, because internal volume matters here: without volume, the generated static mesh can end up with an unwanted inner wall. Keeping internal structure can provide the volume needed so the static mesh output produces a single outer shell rather than double walls.

Even with volume, a few stray points can remain visible. The cleanup uses a mesh selection workflow to isolate and delete unwanted vertices after generation. For leafy assets like a fern or a tree canopy, the volume approach can introduce unwanted voxels under thin surfaces. A distance tolerance control helps define how much thickness to assume, using a value that matches the thickest meaningful part of the object, such as a trunk when talking about trees (or strangely morphed elephants). Just give the algorithm enough thickness to produce a clean mesh while avoiding filling every thin sheet with junk geometry.

Fixed animation options for rigs and deformers

VOXIFY includes a fixed animation feature designed to avoid revoxelizing the mesh every frame. There is a contrast on an animated object: one mode voxelizes each frame, tracking the deforming shape. Fixed animation instead holds the shape of each voxel as it was first generated, while following the animation. There is a limitation when the animated object expands compared to the source mesh used for voxelization, which can produce gaps between cubes. A static mesh generation option can help close that visual gap, but at the cost of changing the nature of the result.

Fixed animation is especially suitable for animated characters, where deformation usually does not involve large expansion or compression. In practice, that makes it a tool for rigs where you want temporal stability, fewer recalculations, and less flicker from per-frame resampling.

Assembly animation, because everything must explode nicely now

VOXIFY includes assembly animation controls that animate voxels from a starting state into place. An animation factor control with keyframing it from 0 at the start frame to 1 at the end frame. It also flags a practical performance issue: changing the assembly value can be slow because the node graph recomputes upstream operations.

To speed that up, the tutorial demonstrates baking parts of the setup once you stop changing voxelization parameters like voxel size and maps. The idea is to freeze the heavy part of the graph so assembly animation updates closer to real time during iteration.

The assembly system includes a speed scale control that changes how fast each voxel moves from start to destination, affecting how much motion blur you might get. It also includes randomization options to avoid a layer by layer build, plus a distribution control that projects the assembled object onto a disc and uses radius and location to change where assembly starts.

Included is a progressive assembly option that tries to assemble the connected structure first, such as building the trunk before floating branches, or whatever the morphed elephant is made of. It has settings like iterations and selection controls, and the tutorial demonstrates debugging by inspecting selection masks in the viewport using standard node debugging interaction.

All of this remains a reminder that a modifier can feel like magic, until a shot needs determinism. Treat VOXIFY like any new procedural tool: test it on throwaway scenes and verify output stability before you use it in production.

Versions, requirements, storefront reality

VOXIFY requires Blender 5.1 or higher. Superhive has three tiers: Personal Use at 8 USD, Commercial Use at 25 USD, and Studio at 49 USD. The Studio tier is “team use” for up to 5 seats. Superhive also lists render engines used as Cycles and Eevee.

https://superhivemarket.com/products/voxify–mesh-to-voxel-modifier

https://www.artstation.com/marketplace/p/o5rnD/voxify-blender-mesh-to-voxel-modifier

The post VOXIFY turns Blender Meshes to Voxels and animates first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

The pack in one sentence

Berk Gedik has published Blender Light Texture Set 20 Pack, a free download that adds patterned emission to area lights instead of a perfectly flat rectangle.

What you actually get

The download includes 20 textures at 2048×2048 and a sample Blender file for setup and use. The intent is straightforward: slap a texture onto an area light so highlights, falloff, and reflections feel more like a real modifier than a perfect panel, which can read suspiciously CG in glossy shots. The set works with Cycles. Eevee does not support light textures natively, but you can still try the same images as a mask by putting a plane in front of the light and using the texture there. Expect that to behave differently than proper light texturing, because you now light with geometry, not with the light itself, so test in your own lighting rig before calling it done. Also, yes, lgiht artists will still argue about softboxes.

Pricing and access

Pricing is free. Access runs through a free Patreon signup to grab the attachment, listed as LightTexture_Set.zip, on the Blender Light Texture Set 20 Pack post. Even for free texutres, run a quick pipeline check: confirm license, color management, bit depth, and whether the patterns introduce unwanted banding or aliasing in animation before you let them anywhere near finals.

https://www.patreon.com/posts/blender-light-20-130264386

The post Free area light textures for Blender first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

For those who don’t know the tool: Levels is a free browser utility for quick grayscale map prep that can feed any DCC or engine, with code hosted on GitHub by artofpilgrim.

A small tool for the most common annoyance

Levels positions itself as a texture alpha studio in the browser. You drop in an image, dial in a black and white channel mix, adjust brightness and contrast, shape the result with a levels curve, then finish with a perspective or rectangular crop. After that, you copy to clipboard or download a PNG. This kind of workflow hits daily production reality, especially when you need a quick mask for foliage, decals, grime breakup, or anything else that starts life as a photo and ends up as a grayscale control map for shading. It also pairs neatly with a texture painting pass later, when a rough mask graduates into something worth polishing.

Channel mixing, then levels, then stop touching it

The channel mixer in Levels offers six color sliders: reds, yellows, greens, cyans, blues, and magentas. It includes presets for Default, High contrast, Dark sky, Infrared, Red filter, and Stark grunge. The goal stays simple: separate subject from background quickly, then lock in contrast.

Brightness and contrast sit as a linear legacy Photoshop pre-stage applied before Levels. The levels panel shows a histogram and gives input shadow, midtone, and highlight handles plus output black and white handles. Keyboard navigation covers Tab to focus a handle, arrow keys to nudge, and Shift plus arrow for bigger steps.

If you need to keep colour instead of converting to black and white, colour mode bypasses the conversion and applies Levels, brightness and contrast per channel. Invert sits there too, because every mask workflow eventually asks you to flip it and see if your brain calms down.

Crop tools that fix your reference photo lies

Rectangular crop supports free or locked aspect ratios: 1:1, 4:5, 5:4, 16:9, 9:16, 3:2, and 2:3. Holding Shift while dragging forces 1:1. Perspective crop lets you drag four corners of a quad to deskew a region into a rectangle. It uses bilinear sampling, includes a rule of thirds alignment grid, shows live output size, and supports 1 pixel and 10 pixel keyboard nudging. It also composes with rectangular crop, and Reset preserves the pre perspective crop.

That combination makes Levels useful beyond the obvious leaf cutout. It is a quick way to extract alhpa style grayscale sources from angled reference shots that you would otherwise fix in a heavier editor, then stash into a texture library for reuse.

Shortcuts and export that respect your time

Levels supports a real time preview. Hold Space to compare against the original image before processing, after any crop or perspective. Inputs can arrive via drag and drop, paste from clipboard, or open from disk. Exports can go straight to clipboard or to a PNG download. Exports render from the current settings even when the preview defers for responsiveness.

Shortcuts include Space for compare, I to toggle invert, Ctrl or Command plus C to copy, and Ctrl or Command plus S to download PNG. Enter and Escape apply or cancel inside crop or perspective mode. Double click resets a slider to default.

The repository also states that inputs over 4096 pixels on the long edge get downscaled with a toast notice. That limit matters if you expect full resolution scan handling, so treat it as a deliberate constraint, not a surprise feature.

Under the hood, it stays refreshingly unprecious

The GitHub repository describes a no-build step setup. It loads React 18 and ReactDOM from a CDN, and keeps the rest as plain JavaScript split into three ordered script tags.

The file layout is a index.html as shell that links CSS and the three JS files, styles.css for styles, image.js for image processing functions and presets, components.js for UI components, and app.js for the app component and DOM boot. The three JS files communicate via a window.Levels namespace with image.js populating math and data first, then components.js reading it and adding panels, then app.js rendering.

Running locally opens index.html in a modern browser, with the file protocol working for sibling script files. For touch pointer and clipboard testing, serving over HTTP using python -m http.server from the repo root is advisable

This is the part that makes it easier to keep a known good utility around. The tool does not demand a build chain just to exist, which is exactly what you want from a graysacle helper app that should still run when the rest of your stack changes.

Thomas Pilgrim Butters released Levels this week, and describes it as a simpler alternative to opening Adobe Photoshop for alpha textures, with support for alpha masks, height or roughness maps, and stylised monochrome plates from photo references. Thomas Pilgrim Butters is Lead Weapon and Prop Artist at Facepunch and an instructor at Gnomon.

https://artofpilgrim.github.io/levels/

https://github.com/artofpilgrim/levels

The post Levels cleans up alpha maps fast first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

What actually shipped

The project now includes an official add-on for Blender that connects to an external solver backend, rather than replacing Blender’s built-in simulation stack. The add-on acts as a client and runs anywhere Blender runs, including macOS, while the solver engine runs separately. And if you understand higher physics, here is an explainer. Fort the rest of us:

ZOZO’s Contact Solver codebase lives on GitHub, and the solver is a contact solver for physics-based simulations involving shells, solids, and rods. The project uses the Apache License 2.0, which you may use, modify, and redistribute the code in commercial products, including proprietary software, as long as you preserve the required notices.

A release tagged “Blender Add-on 1.0.6” has support for armature-driven deformable colliders and bug fixes related to paths containing empty spaces. That is a very production-shaped patch note, because file paths love whitespace even when pipelines do not.

The headline features, minus the marketing glitter

The add-on is exposing finite element deformable and penetration-free contacts, plus strictly strain-limited cloth intended not to stretch like rubber. That last bit aims at the old pain point where cltoh behaves like chewing gum under stress.

The tool targets cloud-deployed GPUs, with examples such as vast.ai and AWS, while still allowing local runs if you have a powerful NVIDIA GPU. It also states the workflow can run locally or remotely on Windows and Linux, with macOS supported via a remote solver engine because CUDA does not run there. Why would it.

The core technology is backed by a peer-reviewed publication in Transactions on Graphics for SIGGRAPH Asia 2024.

Hardware and deployment reality

The installation makes the split explicit: the add-on is just a client, but the solver backend requires an NVIDIA GPU with CUDA 12.x. That makes the tool’s core constraint very clear: your workstation can be lightweight, but your backend needs serious GPU muscle. There are multiple ways to connect to a backend, including running on the same machine, using an SSH-reachable Linux host, using a Docker container, or using a Windows workstation. In other words, it is built for the common studio pattern where artists drive a tool from a DCC while compute happens elsewhere.

The repository also includes a section on deploying on cloud services and includes example hourly costs for specific setups, such as approximately €0.76 per hour for a Scaleway setup and around $1 per hour for a described Amazon instance configuration. Those numbers relate to the referenced cloud configurations, not a license fee for the tool itself. And not the pricing when you did saomething a little bit wrong and are accumulating AWS-bills like a torado in a bank. You know what I am talking about.

https://github.com/st-tech/ppf-contact-solver

The post ZOZO Contact Solver gets Blender add-on first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

For those who don’t know the tool: Stylized Tree Asset Generator is a Blender Geometry Nodes based tree builder for stylized environments, with Eevee focused shading and toolsets that also run in Cycles.

Pines, at last, for people who hate needles

Stylized Tree Asset Generator now includes a dedicated Stylized Pine Tree Asset Generator as part of its 2.0 update. The new pine toolset comes with new assets, textures, shaders, and materials, and keeps the same general workflow as the original tree generator to stay consistent.

The update also targets speed and housekeeping. Version 2.0 replaces deprecated nodes from Blender 4.2, optimizes UV storage, and cleans up and optimizes the Geometry Nodes setup. It also adds directional control to the wind feature and ships an updated user guide.

If you were already using the original generator for quick background dressing, the pine addition is welcome because it expands the library beyond broadleaf shapes and lets you cover the classic stylized use case: conifers in midground forests, mountain ranges, and gamey dioramas without modeling individual branches by hand.

What it actually builds and how far you can push it

The core promise is a Geometry Nodes setup that lets you shape trees quickly, then dial resolution up or down depending on what you need. You can go from low poly silhouettes to more detailed results by adjusting resolution and density inputs, keeping a tighter leash on polygon count.

The tool generates automatic UVs so you can bake textures. That makes it easier to take a procedural look, commit it, and move on, whether you need a static asset for a library or a one-off hero tree that still has to survive export.

It also supports using your own mesh to shape the leaves. That is the escape hatch for people who like procedural trunks but want art-directed foliage shapes, or who already have leaf cards and want the generator to place them. There is also a Random Generator input intended to produce infinite variations with similar characteristics. In practice, that is the difference between a forest and a cloning accident, especially when you need dozens of trees that read as a family but do not look copied.

Some of the shading work targets Eevee. The product notes say the shading was designed in Eevee and may not work as intended in Cycles by default, while the rest of the tools work in both render engines. So if your pipeline leans on Cycles, expect to tweak materials rather than treating the lookdev as drop-in.

Presets, shaders, normals, and the parts you will actually notice

Stylized Tree Asset Generator includes preset textures and materials aimed at getting you to a usable look quickly. It lists 10 leaf texture presets, 16 trunk presets, and 12 hand-painted procedural leaf textures. Those sit alongside procedural textures that remain adjustable, so you can keep the preset as a starting point rather than a locked style.

For shading, it includes a custom toon shader for the trunk and two shading groups for leaves, one designed for simpler use and one offering deeper controls. It also includes four sets of custom normals meant to help you land the shading style you want and to keep shading stable when you animate wind and use the scatter tool.

The update also keeps the wind feature in the toolbox, and adds direction control. That matters because wind without direction tends to look like your trees are trying to shake off a bad rig. Directional control lets you line up motion with camera moves or scene beats, instead of getting random flapping.

This is also where teh usual production advice applies: test it in a real shot, with your real render settings, before you roll it into a template file and wonder why the farm hates you.

Compatibility and versions

The newest versions of the tool are made for Blender 4.2 and newer, while still including older versions of the tools as far back as Blender 3.3. If your studio sits on a locked version for a show, that matters, because it suggests you can still run a supported variant without forcing an upgrade mid-production. The 2.0 update specifically calls out node maintenance aligned with Blender 4.2, including replacing deprecated nodes and cleaning up the node graphs. That kind of update tends to be invisible until it is missing, at which point your node tree becomes an archeological dig.

Pricing and the temporary deal situation

Pricing is tiered on Superhive Market. A Standard License is listed at $12.50 and includes textures, shading nodes, geometry nodes, and tools. An Asset Pack Standard License is listed at $16.50 and adds the full asset pack. A Commercial Use option is listed at $42 and includes the asset pack while allowing commercial use.

If you are evaluating it for production, the practical move is to grab it, build a handful of trees that match your show style, bake what you need, and push them through your actual export and render path. Then decide whether it becomes a staple, a one-off, or a neat toy that lives in a personal toolkit.

https://superhivemarket.com/products/stylized-tree-generator

The post If you yearn for the pines, go Blender first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

For those who don’t know the tool: The Pixel Farm makes PFTrack, a node based matchmove and reconstruction tool that exports to DCCs like Autodesk Maya, Foundry Nuke, SideFX Houdini, Blender and Unreal Engine, with improved dense point clouds via OpenUSD.

Hero Cloud is a new reconstruction node

PFTrack Build 26.05.19 adds Hero Cloud, a node that generates a measured dense 3D point cloud from a single tracked plate. It sits in the Geometry category and runs downstream of a solved camera, turning an ordinary camera solve into spatial data you can actually measure against. Hero Cloud claims to be through-the-lens reconstruction, meaning it extracts depth from the camera movement in the shot rather than relying on a separate photogrammetry set or a LiDAR scan.

The node targets a familiar production reality: you get a brief that needs measured 3D, but the the on-set… people…. said “Fix it in Post, heheeheeh” and did not capture the extra data for cases like set extension, CG integration, lighting reference, forensic analysis, architectural measurement, and archival footage where you cannot go back and reshoot reference. If the plate is all you have, Hero Cloud aims to make that plate pull double duty.

Hero Cloud works on plates PFTrack can track and solve, and works footage sources that include cinema cameras, drones, body cams, dash cams, action cameras, mirrorless and DSLR cameras, CCTV, and archival film. Basically, every type of video. Camera metadata can help but it is not required, and the Camera Sensor Database can cover common cameras automatically, with the Camera Solver able to estimate parameters when metadata is missing.

There is a catch, and it is the same catch as every method that tries to infer depth from motion: the shot needs parallax. Locked off shots or shots with very little movement can produce sparse or unreliable results. Most production footage, including handheld stationary shots, can still have enough movement to produce usable reconstruction, while deliberate camera motion tends to produce richer results.

A cleaner route into splat training

PFTrack 26.05.19 adds a Postshot export option that writes Hero Cloud point clouds and associated tracked cameras in COLMAP format. In other words, matchmove and reconstruction can stay in the same app up to the point where you hand off to splat training.

If you already live in the Gaussian Splatting world, COLMAP is a common interchange format and COLMAP itself has both GUI and command line workflows. The practical value here is that you do not have to glue together separate tracking, reconstruction, and export steps before you ever open Jawset Postshot. You track the plate, generate the cloud, export in COLMAP format, then train the splat.

This is an artist friendly route into a workflow that has historically leaned on command line tooling. That is a reasonable and recommendable goal, but it still deserves the usual pipeline skepticism: try it on a real shot and verify your coordinate frames, scaling, and camera consistency before you let it anywhere near a deliverable.

USD point clouds now carry more than positions

The same build extends USD export to support dense point clouds with per point normal and colour data, because a point cloud that only carries XYZ positions often becomes a dumb scaffold the moment it leaves its origin app. Normals and colour help downstream tools treat the cloud as more than a vague spatial fog, and can make it easier to use for measurement, placement, modelling reference, and lookdev decisions.

Improved integration with USD aware tools including Unreal Engine, Maya, and Houdini. It also claims (!) improved FBX export reliability for very large dense point clouds, aimed at users who previously hit issues exporting big clouds via FBX.

If your pipeline already standardises on USD, this is the kind of unglamorous export detail that can decide whether a new feature becomes a daily tool or a demo-only party trick. Still, test it on your actual asset scale and on your actual DCC import settings. Export support is never a substitute for shot-based validation, and you only find the sharp edges when production hits them, much like furniture at night can only be found with toes and shins.

Photo Mesh gets a single shot input path

Studio and Enterprise editions receive an update to Photo Mesh that enables it to consume Hero Cloud point clouds as input. That creates an internal single-shot path from tracked plate to dense cloud to surfaced textured mesh, without leaving PFTrack. The Pixel Farm describes Photo Mesh as the highest fidelity route when you have a planned photo set, while Hero Cloud covers the case where you only have the hero plate.

In practical terms, this puts a reconstruction option closer to matchmove, and it reduces the number of handoffs in the middle of a cmaera tracking job. Whether it replaces any external reconstruction tooling depends on what you already trust for meshing, texturing, and scale fidelity, but the internal integration is at least a coherent story: generate the cloud, feed it into Photo Mesh, then export into the rest of your pipeline.

The viewport tweak you will actually use

26.05.19 also adds an Active Camera viewport option in viewer windows, with a snap to active clip toggle. It sounds minor, and it is, which is why it will get used: quick visual verification against the source plate tends to catch mistakes faster than hunting through node outputs. The release notes pitch it as useful for checking Hero Cloud reconstruction, but the feature applies anywhere you want a fast way to see what the tracked camera saw.

Trial and licensing notes

Solo trial mode now enables full export functionality for seven days. The release notes describe this as enough time to take a plate from track through Hero Cloud and out to Postshot or USD, rather than being limited to evaluating the toolset without export.

For Studio, the release notes state it is available on rent to buy for 5 or 30 days, or as a perpetual purchase. The PFTrack Creator Program page states PFTrack Solo licenses sell for £699. Treat that as a price reference for Solo licensing, not a promise of regional pricing or bundles.

What this changes in real work

Hero Cloud aims to shift PFTrack from a pure matchmove and survey friendly reconstruction hub toward a single shot scene reconstruction step that can be used even when the onset data plan fell apart. The strongest parts of the release are not flashy, they are connective tissue: COLMAP export for Postshot, denser USD point cloud payloads, and a meshing path that stays inside the same graph.

It is also a reminder that the industry has started to treat point clouds as a first class asset, not only a temporary byproduct. When point clouds export with colour and normals and survive the trip into USD aware DCCs, they become reusable poitn based reference that can support layout, set extension decisions, and reconstruction driven previs.

https://www.pftrack.com/post/pftrack-build-26-05-19-is-now-live

https://www.pftrack.com/post/hero-cloud-tutorial

The post PFTrack gets Hero Cloud first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

For those who don’t know the tool: MoonRay is a production path tracer with a USD Hydra render delegate for tools using OpenUSD, positioned in rendering and lookdev next to ASWF staples like OpenColorIO.

The Academy Software Foundation has added MoonRay as a hosted project, keeping the renderer under foundation governance while opening contributions to a broader community. DreamWorks Animation developed MoonRay as an open source production path tracing renderer and has used it on every one of its feature films since 2019, including The Wild Robot and The Bad Guys 2. The project uses the Apache 2.0 license and is developed in C++.

MoonRay includes support for distributed rendering and a pixel matching XPU mode that processes bundles of rays on the GPU as well as the CPU. It also includes bundled path tracing and a USD Hydra render delegate for integration into content creation tools that support the OpenUSD standard, which should make interactive preview workflows less of a custom science project in teh average pipeline.

The ASWF angle

MoonRay now sits alongside other hosted efforts in the ASWF roster, including OpenEXR, OpenVDB, OpenTimelineIO, and Open Shading Language. If your facility already treats OpenColorIO as plumbing, this is the same neighborhood.

For contributors, the project points developers to openmoonray.org and to the ASWF Slack workspace for a MoonRay channel at slack.aswf.io. Documentation is published at docs.openmoonray.org, and the source repository lives under the OpenMoonRay organization on GitHub.

Keynote season meets SIGGRAPH season

ASWF Open Source Days runs in Los Angeles on July 19 to 20, 2026, and the schedule aligns with SIGGRAPH 2026 timing. The keynote comes from DreamWorks Animation CTO Bill Ballew, with a talk titled How to Train Your Renderer: MoonRay’s Journey from DreamWorks’ Dragons to the ASWF.

The event listing describes July 19 as the main program day in Los Angeles, followed by July 20 as a full day of open source Birds of a Feather sessions within SIGGRAPH. The Call for Proposals remains open through May 24, 2026, via the Open Source Days event site.

As always, test new tools and new governance setups before you bet a production schedule on them, even when the feautres list looks exactly like what your render wranglers asked for.

https://openmoonray.org/

https://www.aswf.io/

The post MoonRay Renderer joins ASWF as hosted project first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

For those who don’t know the tool: Scene Auditor Pro is an add-on for Blender scenes that inspects datablocks and dependencies, then supports cleanup before export to Unreal Engine or Unity.

The Outliner is fine until it is not

Big productions rarely die from a single catastrophic mistake. They usually drown in tiny leftovers. Unused meshes that never got purged. Materials duplicated by imports. Textures that ballooned from sensible to cinematic for no reason. A scene that used to open instantly now takes a long sip of coffee before it even shows you a viewport.

Scene Auditor Pro positions itself as a response to that slow creep. The add-on builds a logical dependency graph from scratch rather than relying solely on the Outliner. It aims to show how objects, meshes, materials, textures, collections, and datablocks connect, so cleanup stops being a guessing game and becomes a decision.

A dependency graph that treats everything as suspicious

Scene Auditor Pro puts dependency visualization at the center: The add-on visualizes relationships across core Blender elements and linked datablocks. The point is not another pretty node view. The point is to make it obvious what is actually connected to what, and what sits alone, because orphaned and semi-orphaned data rarely announces itself. It hides in files as technical debt, and then turns up later as longer load times, higher memory use, and render slowdowns that feel impossible to diagnose.

Orphans, duplicates, and the usual suspects

The add-on includes orphan datablock detection. It calls out hidden unused meshes, materials, textures, actions, node groups, and datablocks as targets for discovery before they inflate file size and memory usage. That matters, because Blender files often accumulate leftovers in those categories during iteration.

Scene Auditor Pro also includes duplicate material and texture detection. The feature is a way to detect repeated assets across large scenes and identify opportunities to reduce unnecessary duplication. This targets common scenarios like kitbash heavy scenes, imported ArchViz content, and large environment work where the same texture set can show up under slightly different names and quietly waste memory.

The tool also looks for oversized texture maps and texture heavy materials as slowdowns – to surface the heavy hitters fast, including visibility into the largest assets and memory heavy elements. One of the claims is that it helps identify the real reasons scenes become slow or bloated, which stays in the realm of a marketing claim until you validate it on your own scenes.

Some parts read like a checklist of production annoyances, including unknown dependencies that make cleanup risky and heavy scenes with unclear bottlenecks. That is a pretty accurate description of Tuesday in many studios.

Export prep for engine pipelines

Scene Auditor Pro is part of pipeline and export validation duties, for Unreal Engine pipelines and Unity exports, plus ArchViz workflows, production cleanup, and scene handoff preparation. The theme here is less about pure Blender housekeeping and more about making sure scene data stays sane when it leaves Blender.

It also looks for missing UV maps or oversized textures as issues that can break game pipelines. If you do a lot of handoffs, the idea of seeing dependencies and unused datablocks before export can save time, or at least give you a clearer explanation for why a scene behaves badly.

Auto optimization, with a lot of caution tape

The add-on offers a step by step auto optimization approach with backup, emphasizing asset safety. It advises running auto optimization multiple times for best results. It also says that the tool will not touch data without explicit user action, and it describes multiple safety nets, transparency about what will happen, and reversibility through undo methods.

Those safety statements set expectations properly. Cleanup tools can be the fastest route to a broken scene if they run without restraint (Almost as bad as letting an AI agent loose). Here, the add-on leans into a safety first posture as a design goal, even if you will still want to test it thoroughly on duplicates of real production files.

Availability and pricing

Scene Auditor Pro is offered via Gumroad for 15 USD.

https://tarulahsanbd.gumroad.com/l/SceneAuditorPro

The post Scene Auditor Pro targets Blender bloat first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

For those who don’t know the Project: Blender Studio ships open movie assets, training, and production tooling built around the Blender DCC, including add-ons and pipeline workflows for animation and rendering, as well as battletesting the whole Blender Pipeline.

The film release, minus the fluff

Singularity is out as a short film in 4K HDR, framed as a painterly space adventure directed by Andy Goralczyk. It follows a small creature whose home gets destroyed by an ominous black hole, pushing it toward a group of luminous creatures and a mysterious celestial being.

The release matters less for the plot and more for what it packages with the movie. The singularity includes downloads of ALL production assets, frames, and high quality encodes under a Creative Commons Attribution license. That makes it usable as real-world test data for storage, conform, and review, not just a nice watch on a big screen.

Painterly look, procedural muscle

The production leans into a watercolor inspired style led by art director Vivien Lulkowski, mixing hand-crafted textures and brush strokes with generative effects. That combination aims for an organic look in the creatures while keeping the black hole graphic and geometric.

On the tool side, the film was created with the most recent in-development version of the DCC, and the team expanded the Brushstroke Tools library with new painterly assets. They also used Geometry Nodes to develop procedural “crowd animation” systems (The quotation marks are about the Crowds, not the system), which makes the project a handy reference if you want to compare node-based instancing logic against your own setups or caching strategy.

If you want a fast internal taxonomy for the kind of work this project touches, it sits squarely in animation and practical stylization, with enough proceduralism to interest anyone who keeps one eye on Geometry Nodes changes.

Story development, and what you can actually access

A dedicated story development “article “log” exists by director Andy Goralczyk, but the page requires a login to read the full content – you can support Blender Studio with a subscription for access to training.

HDR is the real production test here

The 4K HDR part is not a sticker, it is a workflow commitment. HDR delivery usually forces decisions about monitoring, transforms, and what you consider the master, especially when you also need an SDR version that holds up. The projectfocuses on watching it on a large screen, but for post teams the more interesting angle is that it gives you real files to validate ingest, grading, and export choices with.

If you are sanity-checking what HDR usually means in standards terms, ITU-R BT.2100 defines image parameter values for HDR television used in production and programme exchange. That is the kind of reference point that helps when your pipeline debates drift into vibes.

Practical take for production people

Treat the release like a compact pipeline exam. Download the encodes and frames, throw them at your review stack, test your HDR monitoring chain, and see what breaks first. If you plan to reuse any assets, read the license terms carefully, because attribution requirements can collide with real-world deliverable constraints.

https://studio.blender.org/projects/singularity/

The post Blender Singularity lands in 4K HDR 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.