SKAP is an online service built to boost skin detail for digital heads used in VFX and games. The workflow starts from what most teams already have: a head model plus textures in the 2K to 8K range. From that input, SKAP generates 16K textures aimed at pushing pores and fine wrinkles into the kind of resolution that makes shader graphs feel seen.

The core outputs are displacement and cavity. Normal maps are also part of the offering for game engine use in Unity and Unreal Engine. Haemoglobin and melanin maps are available as additional outputs, aimed at supporting more accurate blood flow and pigmentation patterns.

What you feed it

SKAP takes two main ingredients: a head model file with suitable topology, resolution, and UV layout, plus a 2K to 8K texture, either diffuse or displacement. An optional ID mask can be uploaded to identify non-skin areas of the head, with the claim that it improves output quality. Not independently verified at press time.

UV layouts for MetaHuman assets in Unreal Engine and scans from 3D Scan Store are part of the compatibility story.

The maps that come back out

Displacement and cavity are the headline outputs, intended to drop into familiar surfacing and render pipelines. Multi-channel displacement is part of the feature set, splitting low-, medium-, and high-frequency detail across RGB channels Normal maps can also be generated for real-time work in Unity and Unreal Engine. Haemoglobin and melanin maps round out the optional set for skin shading workflows that want dedicated pigment signals. On the SKAP homepage, same-day turnaround and manual calibration by an in-house team are presented as marketing claims.

The handoff is blunt and practical. After the sculpt is finalised, the export list is a basemesh plus an 8K displacement texture,. A few craft notes from the trenches: It suggests storing a morph target before detailing, pushing detail a little stronger than usual, then blending intensity back with the morph brush at low settings to control where the detail lands. It also recommends setting alpha mid value to 50 to help avoid an overly bumpy look when dragging alphas.

Preview before you commit, because rendering is a snitch

Previews as a sanity check: A 2D map preview helps review micro-detail distribution and coherence before applying it back onto the 3D model. A 3D result view supports the same idea: validate the signal, then decide how it fits the look.

Pricing in human numbers

SKAP uses a credit model. A base set of displacement and cavity outputs uses 40 credits. Normal, haemoglobin, and melanin outputs add an additional 5 to 15 credits. Each credit has a base cost of 1 US dollar, with discounts available for bulk purchases.

Where it lands in production reality

In practical terms, SKAP is pitched as a middle move: take an existing head, feed it in, pull back higher-resolution skin detail, and keep rolling without booking a full scan job. The documentation includes guides for using the outputs in Mari and in Maya with Arnold.

As always, new tools and innovations should be tested before use in production. Run it through your own shaders, your own lighting, and your own deadlines, then decide whether it earns a place in the wokrflow.

https://skap.texturing.xyz/

The post Texturing XYZ puts SKAP online, pores included first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

For those who don’t know the tool: Hive Auto Rigger from Create 3D Characters is bundled with Zoo Tools Pro for Autodesk Maya. It builds modular character rigs that do not require Zoo Tools on the animator’s machine and targets animation and game export workflows.

A face to match the body

Hive Auto Rigger can now generate full joint based facial rigs inside Maya. The update adds production ready components for eyes, brows, cheeks and mouth, completing the facial set within the existing modular framework. The mouth module, previously labelled beta, is now described as “production-ready”. Create 3D Characters states that the system supports both human and creature characters, including snouted designs.

The facial setup is joint-based rather than purely blendshape-driven. In practice, deformation is controlled by skeletal joints and skin weights. This approach is commonly favoured in real-time pipelines where predictable evaluation and engine export matter more than sculpt heavy setups.

Built for real time, on paper

According to the official product page, the facial modules are engineered for real time performance in Unreal Engine and Unity. The facial components follow the same modular logic as Hive’s body rigs. Users position modules in Maya, generate the rig, and export through standard workflows such as FBX. Hive also supports auto skin workflows and corrective blendshapes. An API is available for technical customisation, although the public documentation does not detail its scope.

Compatibility and cost

Hive Auto Rigger supports Maya 2020 and later on Windows, macOS and Linux, and works with Commercial, Indie and Educational licences. Zoo Tools Pro, including Hive, is sold via subscription. The first month costs 40 dollars and includes access to the full toolset, training and assets. Subsequent months are 10 dollars per month.

Create 3D Characters states that after the first month, users may continue to use the acquired version commercially even if they cancel. For teams already using Hive for body rigs, the addition of full facial modules removes the need for a separate face system. Whether the joint based approach meets your deformation standards is something you will need to test on real production assets.

// Official product information and pricing
// https://create3dcharacters.com/maya-hive-autorigger/

// Company homepage
// https://create3dcharacters.com/

The post Hive adds joint facial rigs to Maya first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

For those who don’t know the tool: The Pixel Farm develops PFTrack, a node-based 3D camera tracking and photogrammetry system used in VFX, virtual production, and survey-driven pipelines. It exports to DCC tools including Autodesk Maya and integrates LiDAR and image based reconstruction.

The Pixel Farm has released PFTrack 26.02, a point update to its camera tracking and photogrammetry software. The release focuses on export reliability, Survey Solver behaviour and data validation rather than new solver technology. According to the published change list, the update introduces improvements to Maya export scripts, OBJ texture handling, LiDAR import logging and node connectivity within the Survey Solver. It also resolves a keyboard shortcut conflict in the Orient Camera node.

Maya export scripts corrected

The updated Maya export scripts now automatically parent background image planes to cameras on export. This addresses a long standing friction point in matchmove handoff. Previously, depending on scene configuration and export path, artists could end up manually re-parenting image planes inside Maya to maintain alignment between the solved camera and its background plate. The revised script automates this relationship at export time.

For tracking teams delivering camera solves into Maya-centric pipelines, this reduces post-export clean-up and the risk of misalignment during layout or scene assembly. The vendor statement does not detail changes to other DCC export scripts.

Survey Solver and OBJ texture loading

PFTrack 26.02 updates the way OBJ mesh textures with numbered filenames are loaded into the Survey Solver node. OBJ sequences or assets that rely on incrementally numbered texture files will now load correctly when imported into Survey Solver. The official notes do not specify naming conventions, but refer to numbered filenames in general terms.

For facilities using photogrammetry meshes or survey derived assets with multiple texture tiles, correct automatic loading reduces manual reassignment inside the node graph. It also limits the possibility of mismatched textures during camera solve refinement. The change appears limited to texture loading behaviour inside Survey Solver and does not reference modifications to the OBJ importer elsewhere in the application.

LiDAR import logging added

The update adds explicit error logging when importing corrupted or incomplete LiDAR survey data files. PFTrack supports LiDAR survey data within its camera-solving and scene-reconstruction workflows. In previous versions, incomplete or damaged files could fail during import without detailed diagnostic output.

With 26.02, the system now logs errors when such data is detected. The vendor documentation does not describe the logging format, verbosity level or where logs are written. It does state that error logging is triggered when corrupted or incomplete LiDAR files are imported.

Photogrammetry node connectivity fixed

A further fix addresses connector logic in Studio and Enterprise editions. Photogrammetry nodes can now be connected to secondary inputs of the Survey Solver where appropriate. The official wording specifies that this applies to Studio and Enterprise only.

This suggests that earlier builds restricted valid node graph connections in certain configurations, potentially limiting more complex photogrammetry driven solves. The updated connector logic restores the ability to route photogrammetry outputs into secondary Survey Solver inputs when supported by the node’s design.

The vendor has not published technical detail about which specific input sockets were affected or how the internal validation rules have changed. Not independently verified at press time.

Facilities using advanced node graphs that combine survey data, image based reconstruction and manual constraints should review existing templates to confirm expected behaviour after updating.

Scope and positioning

This release does not introduce new solver models, GPU-acceleration changes, or major UI revisions. It is positioned as a maintenance and workflow refinement update. The focus remains on export reliability, data validation and node graph correctness. For studios that rely on PFTrack for camera tracking, survey alignment and photogrammetry reconstruction, these adjustments address specific operational irritations rather than expanding feature breadth.

PFTrack is available in three editions. PFTrack Solo is priced at £699 for a permanent licence. PFTrack Studio is offered on a rental basis, with pricing listed at £59 for a five day rental period. PFTrack Enterprise pricing is available on request from The Pixel Farm. As always, facilities should confirm current licensing terms and support options directly with their vendor before procurement.

As always, new tools and updates should be tested in controlled conditions before being introduced into active production pipelines.

The post PFTrack update tidies Maya and LiDAR workflows first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

For those who don’t know the tool: Kangaroo Builder is a character rigging toolkit for Autodesk Maya used to build body and facial rigs, manage skinning and author blendshapes. It sits squarely in character TD land and complements Maya’s rigging tools without pretending to replace them. It is developed by Thomas Bittner and integrates directly into Maya-based pipelines.

A familiar problem, now inside the rig

Transferring facial blendshapes between meshes with different topologies remains one of the more time-consuming and error-prone tasks in character production. It usually appears late in the process, just when schedules are already tight. Artists either rebuild shapes by hand, rely on wrap-based deformation tools, or accept compromises in deformation quality. Kangaroo Builder’s latest update introduces a feature explicitly designed to address this gap from inside the rigging toolset itself.

Kangaroo Builder now includes a new topology transfer workflow called “Landmark Warp”. The tool is included in version 5.19 and later and is designed to warp one mesh onto another using user-defined landmarks, even when the two meshes have different vertex counts and edge flow. This is not a general retopology solution, nor is it presented as one.

What Landmark Warp actually does

Landmark Warp works by letting users place corresponding markers on a source mesh and a target mesh. These markers define spatial relationships rather than relying on shared topology. Once enough landmarks are placed, the system computes a deformation that warps the source mesh to match the target mesh’s overall shape. The warped result can then be used to transfer existing facial blendshapes via Kangaroo Builder’s Shape Editor.

The key point is that this process operates on shape deformation rather than topology matching. The meshes do not need identical structure, only a reasonably comparable form. This makes the tool applicable to character variants, cleaned-up scan data, or iterative design changes where topology has drifted but proportions remain recognisable.

The developer notes that Landmark Warp relies on SciPy, a Python scientific computing library, which must be installed and accessible in Maya’s Python environment. This dependency is documented but may be overlooked in locked-down studio setups, which is worth flagging early in any evaluation.

Intended use, and what it is not

Nobody would describe Landmark Warp as a fully automatic solution. The quality of the result depends heavily on landmark placement and mesh preparation. Internal geometry such as teeth, tongues, or inner mouth surfaces can interfere with the warp unless managed carefully. This is stated explicitly in the documentation.

It is also not intended to replace dedicated wrap deformers or offline retargeting tools. Instead, the value proposition is convenience and context. Landmark Warp lives inside the same environment used to build and edit the rig. For many teams, that maybe matters more than absolute automation.

Why this matters in production

Topology drift is a fact of life in character production. Directors ask for changes. Scans get cleaned. Game and film assets diverge. Facial rigs, however, tend to be built once and guarded carefully. Any tool that reduces the cost of reusing that work deserves attention.

By embedding topology transfer directly into a rigging toolkit, Kangaroo is addressing a real and persistent problem. The approach is conservative rather than flashy. It assumes skilled users, manual setup, and informed judgement. That will suit experienced character TDs more than newcomers, which aligns with the tool’s existing audience.

It also reflects a broader trend of rigging tools absorbing tasks that used to live in separate utilities. Whether this is desirable depends on pipeline philosophy, but it does reduce context switching, which is often where errors creep in.

Compatibility and licensing

Kangaroo Builder runs on Autodesk Maya. At the time of writing, version 5.19 supports Maya 2023 and later on Windows and macOS, and Maya 2024 and later on Linux. Landmark Warp is included in the standard distribution and does not require a separate licence.

Licensing remains unchanged. Kangaroo Builder is free for non-commercial use, including students and personal projects. Commercial licences are available for indie users and studios. Pricing is published on the official website and may change, so readers should check the current terms directl.

At the time of writing, these are the prices: (Copied from the site)

Indy Perpetual – 220 USD
For freelancers making less than 85k USD per year in revenue

Single Perpetual – 400 USD
Recommended for or small studios with only one rigger

3 Seats Perpetual – 1000 USD
Recommended for small studios

6 Seats Perpetual – 1800 USD

Unlimited Seats Perpetual – 4000 USD

What is still unclear

No public information is available on how Landmark Warp behaves on extreme topology differences or highly stylised characters. There is also no data on performance with dense meshes or very large blendshape libraries. These gaps do not invalidate the feature, but they do mean that due diligence is required before deployment.

As with any rigging or deformation tool, results will depend on mesh quality, landmark placement, and user expertise. Early adopters should expect iteration, not miracles. Anyone hoping for a one-click solution will be dissapointed. s always, new tools and workflow changes should be tested thoroughly on representative assets before being introduced into active production.

The post Kangaroo Builder learns to move faces between meshes first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

Pixar’s RenderMan 27.0 is not a mere update: For the first time since the RIS introduction in 2014, RenderMan’s rendering core has been fundamentally rebuilt. The headline act: XPU, Pixar’s hybrid CPU+GPU architecture, now capable of producing final-frame renders. With multi-GPU support, full compositing pipelines, and feature parity with RIS in most production cases, XPU has stepped from experimental preview to the new backbone of RenderMan’s future.

According to Pixar, version 27 marks the most significant performance and interactivity leap in over a decade. The new architecture combines compute scalability with physically based consistency, while also supporting new aesthetic flexibility through a fully integrated Stylized Looks framework.

XPU: From Preview to Production

RenderMan’s XPU engine now operates as a complete production renderer, supporting both CPU and GPU resources simultaneously. This dual utilisation allows artists to push hardware to its maximum throughput, whether on workstations or render farms. The new final-frame rendering mode eliminates the former division between lookdev and production rendering, streamlining pipelines previously dependent on RIS for the last mile. XPU now supports multi-GPU rendering, with the caveat that all GPUs in use must be identical and contain full scene memory. The engine’s minimum requirement has been raised to CUDA 12.8.1, reflecting its deeper reliance on modern GPU driver capabilities. Pixar confirms that this configuration is the foundation for all future RenderMan development.

Adaptive, Smarter, Faster

Under the hood, Pixar’s engineers have reworked adaptive sampling, aligning it with internal techniques used in Pixar Animation Studios’ own productions. Adaptive metrics such as “relativepixelvariance” and “mse” AOV-based control now run per object, delivering more accurate sampling without inflating render times. Checkpointing, a feature long requested by production supervisors, has been fully implemented. Artists can now save partial renders at defined intervals, resuming from checkpoints without rerendering full frames. This system, combined with interactive denoising, significantly tightens iteration loops in look development. The denoiser itself now outputs timing data, integrates directly with live renders, and can be toggled interactively. Pipeline engineers can expect improved configurability for modern, distributed render farms.

Deep Compositing and AOV Control

Version 27 brings complete deep data workflows to XPU. OpenEXR 3.0 Deep IDs are fully supported, allowing compressed ID manifests to be automatically generated for compositing. Artists can extract object-level data directly from deep renders using Pixar’s new deepidextract utility. Compositing teams gain matte and holdout workflows, expanded AOV handling, and support for the shadows and invshadows LPE prefixes. OpenEXR metadata is now written natively, ensuring compatibility with Nuke and other deep compositing tools. Cryptomatte, while not yet part of the initial 27.0 release, is scheduled to arrive in a dot update, according to Pixar’s release notes.

Geometry, Lighting, and Volume Precision

Geometry handling in XPU 27 has been heavily rewritten to achieve parity with RIS. Nested instancing, long a sticking point, now supports material inheritance and attribute propagation without breaking shading hierarchies. Displacement, motion blur, and volume interactions have been stabilised, with notable improvements in the handling of semi-sharp subdivision creases.

Lighting gains precision as well. Mesh lights are now fully supported, and light filters have been corrected for spline and falloff anomalies. The PxrPathTracer integrator adds new clamping controls (clampDepth and clampLuminance), aligning noise handling across both rendering architectures. Volumetric fidelity benefits from the new interior volume aggregates, enabling complex materials such as murky liquids or translucent crystals. Artists can now fine-tune deep shadow error parameters for exact compositing control.

MaterialX Lama: Early Access, Serious Potential

RenderMan 27 introduces MaterialX Lama, Industrial Light & Magic’s modular shading system, as Early Access inside XPU. The system allows layered material construction using physically accurate combiners. Pixar’s current implementation supports LamaDielectric, LamaConductor, and GeneralizedSchlick nodes with anisotropy, single scattering, and extinction behaviour now properly matching or exceeding RIS accuracy. Full support is scheduled during the 27.x release cycle. Pixar notes that look differences compared to RIS are expected in this early phase and requests feedback from studios integrating Lama in production.

Stylised Looks: Non-Photorealism, Physically Based

The Stylized Looks suite has matured from experiment to production toolset. It now ships as a unified subsystem under XPU, comprising PxrStylizedControl, PainterlyBrush, Lines, Hatching, Canvas, and Toon filters. Each operates as a display or sample filter, allowing NPR (non-photorealistic rendering) effects such as painterly brush strokes, toon shading, curvature-based outlines, and cross-hatching, all integrated directly with RenderMan’s physically based lighting.

The system supports AOV outputs, interactive denoising, and compositing passes. The new PainterlyBrushXPU filter enables procedural brush strokes with depth and lighting awareness. StylizedCanvasXPU and StylizedLinesXPU introduce compositing and in-filter distortion options with up to 96 preset line textures. Pixar’s stated goal: to let stylised rendering coexist with physically plausible shading without breaking pipeline compatibility.

Integration and Pipeline Alignment

RenderMan 27 strengthens its integration with major DCC applications and pipeline frameworks. Solaris, SideFX’s USD-based environment in Houdini, now features deeper RenderMan embedding, including improved UI, native support for OpenSubdiv 3.6.1, and GPU progress tracking in hdPrman. RenderMan LOP nodes have been refactored, and “RenderMan Render Vars” replace the older “Standard Render Vars” for more robust USD conformity.

RenderMan for Blender reintroduces Qt-based UIs via PySide6, restoring the texture manager and preset browser on Blender 4.x. Artists now benefit from native light linking, velocity blur control, and on-the-fly texture conversion.

In Maya, RenderMan’s Texture Manager has been modernised, adopting OpenImageIO for mipmapped texture conversion. Pixar’s proprietary texture format has been replaced by OpenEXR, aligning with the VFX Reference Platform 2024 standards. The legacy txmake utility remains available for backward compatibility but is now officially deprecated.

The Texture Manager now supports ACES-compliant defaults, HiDPI UIs, and multi-selection editing. Pixar warns that lowercase <udim> tokens will no longer be recognised; pipelines must adopt the uppercase <UDIM> convention for USD compliance.

Complying with the VFX Reference Platform 2024

RenderMan 27 aligns fully with VFX Reference Platform 2024, standardising on current builds of Python, OpenEXR, OpenImageIO, and USD. For production pipelines, this ensures compatibility with other industry-standard applications and reduces dependency conflicts across render nodes. The change affects texture formats, shader APIs, and compositing metadata. Pixar’s move to OpenEXR for both image outputs and texture caching is particularly significant, replacing proprietary workflows with interoperable standards.

Performance and Statistics

Performance instrumentation across XPU has been expanded, with scene ingestion, GPU allocation, and adaptive ray counters now visible in live statistics panels across DCCs. The stportal interface presents real-time timers, counters, and memory metrics, enabling TDs to diagnose bottlenecks without external profiling tools. RenderMan’s JSON reporting system has been refined for both RIS and XPU, offering standard and detailed modes for automated render diagnostics. Memory tracking now includes deduplication efficiency, critical for large USD scenes.

Future of RIS

While RIS remains functional in version 27, Pixar has confirmed its future deprecation. The renderer continues to support legacy pipelines, but new features including deep compositing, MaterialX Lama, and multi-GPU acceleration, are exclusive to XPU. Pixar recommends transitioning new projects to XPU immediately to ensure feature parity and forward compatibility. The company has maintained RIS only for existing productions requiring deterministic CPU-only rendering or legacy shader behaviour.

Non-Commercial Version – still free.

The free Non-Commercial RenderMan 27 is Pixar’s way of saying, “Go ahead, break it, just don’t charge for it.” The edition now includes full XPU support, right down to final-frame rendering, meaning anyone can experiment with the same hybrid CPU–GPU tech used on Pixar features. It’s designed for personal projects, research, and plugin tinkering, with no watermarks, only a polite request to credit RenderMan if your test project accidentally becomes an internet hit.

Naturally, there’s a catch or two. The licence is strictly non-commercial, locked to two machines, and politely expires every 120 days, because nothing keeps a pipeline sharp like forced renewals. The Stylized Looks suite, Pixar’s NPR playground of painterly brushes and toon shaders, is absent here, reminding users that true artistry still costs a studio licence. Still, for anyone wanting to explore the XPU ecosystem without opening the budget spreadsheet, it’s a generous, production-grade sandbox.

Compatibility, Stability, and What Comes Next

RenderMan 27’s release is a clear signal: Pixar’s renderer is now fully committed to hybrid GPU computing and open pipeline standards. With XPU stabilised for final-frame rendering, Solaris deeply embedded, and MaterialX Lama laying the foundation for unified shading, the software’s architecture is more extensible than at any point in its history. The move to industry formats and the inclusion of non-photorealistic rendering tools reflect Pixar’s recognition that creative flexibility and pipeline efficiency must coexist.

RenderMan 27.0 should be thoroughly tested before deployment in production, especially when adopting early access features such as MaterialX Lama. Pixar’s documentation explicitly requests user feedback to refine those systems during the 27.x cycle.

The post Pixar’s RenderMan 27.0 first appeared on DIGITAL PRODUCTION and was written by Bela Beier.