For those who don’t know the tool: Paradigm is a GPU liquid solver that runs inside Houdini, alongside Axiom, using node based workflows for VFX liquid setups.

What 1.0 actually changes

Paradigm 1.0 targets GPU accelerated liquid simulation in Houdini, and the developer describes it as a “hybrid that can be called a FLIP solver while borrowing ideas from SPH”, whatever that means. It is supposed to be faster and more accessible than Houdini native liquid tools.

Version 1.0 ships as a sequence of point releases that stack up into something production artists can actually evaluate. The current notes focus on simulation stability, faster solvers, better sourcing, more outputs, and a Tank workflow aimed at open water setups. If you live in Houdini, this is the kind of list that determines whether you can keep a shot moving or spend the week explaining why it will be ready next week.

Sourcing gets less crunchy

The 1.0.153 to 1.0.175 updates bring a major round of sourcing work. Particle emission from source shapes improves, with spacing and layout described as more random and even, and with less repetition. A separate Particle Source node arrives to control emtoion timings in a way described as similar to source shapes. Sourcing can now push more than just positions. The solver can output particle attributes like color, temperature, viscosity, and rest as optional outputs, and it also adds age and life attributes plus lifespan controls to remove particles that age past their life value. It can also output churn, described as the magnitude of the curl of the velocity field, as an optional field.

The system also supports defining extra arbitrary particle attributes by defining them in the output tab of the solver node. Source VDBs can affect particle attributes, for example by sourcing a temperature volume source to make particles hotter. Temperature and color attributes can diffuse and dissipate. A relax force is described as now working properly and as fully deterministic. All of that translates into a much clearer story for lookdev and downstream controls. You get more handles, more outputs, and fewer excuses to bake everything into a single sim and pray.

The performance pass: SDF, advection, sorting

The 1.0.176 to 1.0.219 updates lean hard into speed and numerical behavior. A much faster SDF creation algorithm lands, plus changes to advection that make it faster by considering the SDF collision value when stepping forward. Adhesion becomes more accurate by using the collision SDF gradient for directions.

Particle handling also gets a leaf-based sorting method described as greatly improving the performance of grid sampling. The solver can better predict future resource needs when reinitialising, called Acceleration in the Advanced to Solver tab. There are also new filters for the output surface SDF, specifically erode and dilate filters, plus additional filtering options for the output surface SDF as a concept in the earlier 1.0.153 to 1.0.175 set. The end result is still an SDF output, not a finished mesh.

If you want a mesh, you still need to convert the surface SDF to a mesh using the VDB Convert node in Houdini. That’s cool for shot work, because it keeps the meshing and any post-smoothing in familiar Houdini territory, with all the usual caveats about voxel size, narrow features, and meshing time. You know the drill.

PCG everywhere: viscosity and pressure style steps

Viscosity gets a major upgrade in 1.0.176 to 1.0.219. It is described as much faster, with a new PCG-based solver. On the control side, multiple control ramps arrive for viscosity and gravity, and gravity and drag can be driven with control ramps in the earlier update set. Viscosity can be driven with a viscosity or temperature particle attribute, and there is collision conductivity for temperature diffusion plus the ability to source collision temperature for melting or freezing effects when particles touch a collider when using viscosity.

In practical terms, these controls push Paradigm closer to how artists like to art-direct liquids. You can tie behaviour to attributes, and you can do it without building a separate rig of custom forces for every shot. Also, a speed limit force bug gets fixed, where values could clamp incorrectly and produce a lower speed limit than expected. That is not glamorous.

Tank workflows and open water domains

Paradigm 1.0 adds a Paradigm Tank node for creating open water. These domains can be animated to have a moving container. Later updates describe the tank node as more stable and efficient at different scales.

For artists, that sounds like fewer edge cases and less time spent re-scaling a scene just to make the container behave. It also points to a workflow that is intentionally separate from classic boxed FLIP tanks, which feel like they belong to a different decade of fluid tools. And yes, I am thinking in decades; I am old.

Outputs, fields, and other useful knobs

The 1.0 notes mention more efficient sinks. Output field precision issues that could cause garbled outputs get fixed. Source shape noise can optionally cull source particles instead of just source values. Some blend modes get fixes when sourcing with source shapes.

None of this removes the need for real pipeline testing. New tools and innovations should always be tested before use in production, especially when the toolset is still evolving across frequent builds and wet behind the ears. (Obvious joke. Watersim. Wet. I need more coffee.)

What it does and does not include

Paradigm does not include narrow-band support yet. It does not currently have reseeding, though it is something likely to be added. A white water solver is in development, and the suggested current approach is to use Paradigm with Houdini’s white water solver.

Ocean spectrum workflows are described as not officially supported. The FAQ describes a possible approach using custom sources if the spectrum is converted to velocity fields and mask, with a desire to add full support for ocean spectrum in the future. That future support is not confirmed.

Compatibility and system requirements

Production builds of Houdini 20.0 and higher are supported. Daily builds are not supported. Windows, Linux, and macOS are supported. Nvidia and Apple GPUs are recommended, and any device that supports OpenCL 3.0 should work. Due to issues with drivers, some GPU may not be supported.

Pricing, licensing, and the parts people actually ask about

Paradigm Indie is $99 as a node locked license and can only be used with Houdini Indie. Paradigm Commercial is $199 as a node locked license and can be used with Houdini Core and FX.

Each node locked license includes one year of maintenance that renews annually, plus a perpetual license for all builds released during the maintenance period. A node locked license can be used on two devices at a time, with a maximum of two licenses per studio. Floating licenses exist for Paradigm Commercial via contacting sales.

The FAQ also states that Paradigm is free to use with Houdini Educational and Apprentice licenses, matching the vendor’s approach for Axiom. During the open beta for version 1.1, it is also free to use with no license or login required, with builds lasting 30 days from the date of publishing. The 1.1 open beta is scheduled to start in early May 2026. There is no release date, and the estimate given is 2 to 3 months, described as just an estimate.

If you are planning to integrate this fluid into a pipeline, test the licensing workflow, expiry behaviour, and Houdini version constraints in your actual studio environment. Then test again on the machine nobody loves, because that is the one that will end up simming the hero splash.

Where this sits in a broader Houdini sim stack

Liquid Thinking: Paradigm Brings GPU Speed to Houdini

Paradigm is a separate solver from Axiom, and the FAQ states there is no two-way coupling between the two. That does not stop you from using them in the same Houdini project, but it does mean you should not expect an automatic handshake between liquid motion and volumetric effects. You can still do the usual tricks using exported fields and caches, but the coupling is a pipeline job, not a one-click feature.

Axiom 4 for Houdini: Faster GPU Pyro With Better Collisions

This is also where expectations need to stay grounded. Paradigm outputs a surface SDF with filtering options, and Houdini converts that to a mesh. White water comes from Houdini’s own white water solver for now. Narrow band and re-seeding are not there yet. If your shots require those features, treat 1.0 as a serious tool that still leaves some work for you.

If you adopt it, run a focused test pass: emission behaviour, collisions with temperature effects, viscosity art direction, SDF meshing quality, and driver stability under OpenCL.

https://www.theoryaccelerated.com/paradigm

https://theoryaccelerated.notion.site/paradigm-1-0-whats-new

https://theoryaccelerated.notion.site/paradigm-1-faq

https://www.theoryaccelerated.com/axiom

The post Theory Accelerated shifts Paradigm 1.0 for Houdini first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

For those who don’t know the tool: OctaneRender is a GPU renderer with DCC plugins like Blender, Cinema 4D, and Houdini. It ships via Studio+ and has a macOS stepsibling called Octane X.

Virtual textures, now allowed on the farm

OTOY shipped OctaneRender 2026.3 with a headline change that matters to anyone who has ever watched a heavy lookdev scene bully a GPU: network rendering now supports virtual textures. Virtual textures arrived earlier in the 2026 cycle, and 2026.3 extends that system beyond the local box so you can run the same approach in distributed jobs instead of treating it like a workstation-only party trick.

If your pipeline leans on huge texture sets, this is the kind of change that can reduce the amount of manual babysitting around what fits where. It does not magically fix bad asset hygiene, but it can remove one common excuse for why a scene behaves differently on an artist’s machine versus a render node. The release notes also call out a reduction in time to first sample in render nodes when scenes contain large image counts, which pairs naturally with the idea of texture-heavy shots that take too long just to begin doing anything visible.

One practical footnote: the release notes explicitly say that virtual textures are not supported for texture displacement. That line sits inside a crash fix description, but the constraint itself matters. If your assets rely on displacement driven by high-resolution maps, you still need to plan for the old reality there, even while the rest of the texture stack gets more flexible.

Trace sets, shadow catchers, and other production glue

2026.3 continues to sand down workflow edges around features introduced earlier in the 2026 line. Trace set visibility rules can now also apply to shadow catchers, which sounds small until you are trying to art-direct what reflects in what while keeping plate integration sane. Shadow catchers often sit at the intersection of lighting cheats and comp expectations, so anything that reduces the number of special cases usually pays back quickly.

There is also an update to USD import preferences: you can override point instances so they can be used to instance other external geometries. That is a very specific knob, but pipelines that move a lot of set dressing through USD tend to accumulate a lot of “why does this instance not behave like that instance” questions. Having an explicit override in the import preferences at least gives TDs another lever that lives in the tool instead of in an external patch script.

The same release adds support for importing float and colour primvars from USD curves, and it fixes an issue where motion blur was not visible when using USD curves. If you push curves for hair, cables, trails, or procedural motion guides, this is the kind of boring detail that stops being boring the moment it breaks a shot.

For readers tracking platform standards, this is another reminder that renderer updates are increasingly about interchange stability as much as raw features. You still want speed, but you also want fewer surprises when assets cross DCC borders.

MaterialX displacement support gets more real

The 2026.3 release adds MaterialX import support for displacement shader sub graphs. It also fixes a handful of MaterialX-related issues, including proper operation for TransformNormal and TransformPoint, errors when loading scenes with Time and Frame nodes, alpha blending in HexTiledImage for color4 outputs, and import issues around bi-tangent inputs that could break normal mapping.

If your studio has been treating MaterialX as “great in theory, wobbly in practice”, this is a concrete step toward the practical side. A step, not the finish line! Not even for Scandinavian Studios! It does not claim perfect parity with every other tool, but it does show attention to the unglamorous parts: node correctness, error spam, and consistent interpretation of common transforms. A separate behavior tweak affects anisotropy: rotation in Standard Surface now matches OpenPBR and other renderers, and existing scenes are not affected. Hopefully

NRC memory use drops, plus a grab bag of fixes

OTOY says memory usage has been reduced when using the Neural Radiance Cache, referred to as NRC. The same notes mention fixes for render artifacts when using volume media in combination with NRC, plus a crash fix when rendering starts while virtual textures compile and are used in texture displacement, with the earlier reminder that virtual textures do not support texture displacement.

There is also a long list of resolved issues touching a lot of interchange formats and stability landmines: fixes for Alembic loading with materials saved as non-constant FaceSet objects, multiple FBX importer and exporter issues around vertex attributes and vertex animations, crashes on unsupported or invalid SPZ files, and potential application crashes upon initialisation on Windows and Linux.

A small but very real quality-of-life fix: empty file name nodes no longer get replaced with the directory of the containing OCS file, and they stay empty. That is the sort of bug that creates invisible path issues that only show up in a farm run at 3 a.m. on a Saturday night, while you are trying to remember what these things called “Weekends” were, the strange people in the group called “Friends” on Discord are blabbing about. Random example.

Drivers, OS baselines, and what your IT team will ask

The release notes list two explicit minimums. The minimum NVIDIA driver version required is R555, and it is R572 for GeForce RTX50 series. The minimum version of macOS required is 14.5.

Lua API tweaks for pipeline tinkerers

2026.3 includes Lua API changes that target data handling and introspection. Several octane.node functions now accept raw C arrays for cases where the API expects an array, and there are new helpers for querying animator types and retrieving animator data as a raw C array. It also states that for non-array attributes, you are allowed to set animators with different channel counts from that of the attribute type.

If your facility uses Lua to automate scene setup, tool integration, or pipeline hooks, or just is full of Autohotkey-Nerds (My People!) these are the kind of changes that can reduce wrapper code and make scripts less fragile. It is not the most glamorous section , but it is often where studios quietly win back hours.

Pricing and availability

OctaneRender 2026.3 is available via downloads linked from the release notes, including standalone builds for Windows, Linux, and macOS, plus node builds for Windows and Linux, and demo downloads for Windows and Linux.

Pricing is subscription-based via Studio+. The OctaneRender Studio+ subscription is 24€ per month billed monthly, and 20€ per month billed yearly for an annual subscription. There is also an OctaneRender Offline USB Dongle for 49 euros.

Even if the feature list sounds perfect for your exact setup, treat it like any other renderer update: test it on your own scenes, with your own texutres, on your own farm, before you let it anywhere near a delivery schedule.
https://render.otoy.com/forum/viewtopic.php?t=85624

The post OctaneRender 2026.3 adds virtual texture netrender first appeared on DIGITAL PRODUCTION and was written by Manuel Kotulla.

For those who don’t know the tool: V-Ray runs inside Autodesk 3ds Max and Blender and many other DCCs, with V-Ray GPU as the hybrid GPU and CPU engine alongside CPU rendering.

AMD is back on the render menu

After a long stretch of one-vendor reality for GPU finals, Chaos reinstated support for GPU rendering on AMD hardware in V-Ray GPU by implementing HIP as a render backend in V-Ray 7 Update 3 for Autodesk 3ds Max. The change lands in the V-Ray 7 Update 3 build for 3ds Max, (build version 7.30.02).

This matters because V-Ray GPU previously supported AMD through OpenCL, and that path wound down with the V-Ray Next era in 2018. In production terms, many shops treated V-Ray GPU as effectively tied to NVIDIA backends for years, even if the CPU engine remained fully cross platform. Support for HIP is also expected to roll out to other V-Ray integrations, including V-Ray for Blender.

What exactly changed inside V-Ray GPU

V-Ray GPU now exposes HIP as a backend option in the 3ds Max integration, alongside CUDA and RTX modes. HIP is designed to let developers target both AMD and NVIDIA from a single code base using a CUDA-like programming model, and it sits within the broader ROCm stack. On AMD, V-Ray GPU runs through HIP, and the team also opened HIP RT as the ray tracing acceleration path. HIPRT remains a work in progress in V-Ray GPU. In other words, this is not a checkbox labelled “AMD” that secretly does CPU. It is a new backend that runs V-Ray GPU on modern Radeon hardware, with the HIP path delivering the strongest and most consistent AMD results in the current test set.

Supported GPUs, drivers, and the fine print you actually need

The supported AMD generations for V-Ray GPU via HIP currently include RDNA2, RDNA3, RDNA 3.5, and RDNA4, across consumer Radeon and selected Radeon Pro products. The recommendation is RDNA3 and above. The minimum supported driver listed for AMD is AMD Software Adrenalin Edition 26.2.2.

A concrete example used for testing is the Radeon RX 9070 XT, a consumer GPU with 16 GB of GDDR6 memory, a 256 bit memory interface, and up to 640 GB per second of memory bandwidth. AMD announced the card at a €799, while retail pricing varies by board partner and region. Currently, you can get variants around 650€.

If you want to map that to pipeline decisions, the takeaway is that the minimum bar is no longer latest flagship only. The supported list includes multiple generations and both consumer and workstation lines, with a driver baseline you can actually put into an IT image.

Performance: competitive, then weirdly spicy in out-of-core

The performance story splits into two very different conversations: in core scenes that fit in VRAM, and out of core scenes that push textures into system memory.

Across the current test scene set, results are described as solid overall, with most scenes rendering without issues and output matching expected results. The RX 9070 XT is described as delivering competitive performance for a 16 GB consumer GPU, while the RTX 5080 stays ahead in most in core cases.

Then the out of core path shows up and flips the mood.

V-Ray GPU has a Use System Memory for Textures option that moves texture memory pressure into system memory. That matters when your scene does not politely fit into VRAM and you do not want a last minute downres exercise.

In the out of core scenes tested, the RX 9070 XT is not just competitive but clearly faster in several cases, with the largest gaps reaching multiple times faster in the current dataset.

That is the part to pay attention to if you live in archviz city blocks, hero characters with absurd texture stacks, or anything where the phrase texture budget is usually followed by laughter and then silence.

HIP and HIPRT: what artists should take from that alphabet soup

HIP is the enabling layer that makes AMD execution possible in V-Ray GPU. HIPRT is a separate ray tracing library for HIP aimed at ray tracing acceleration.

In the current state, HIP delivers the best AMD results, and HIPRT remains under active evaluation and not production ready. The implication for day-to-day users is simple: backend choice still matters, and the fastest mode on one vendor does not automatically exist on the other in the same way today. That is also why you should treat this update as you would any other new render backend. Test it on your own scene types, your own noise tolerances, your own texture formats, and your own deadline pressure, before you let it touch finals.

Workflow impact: more options, more responsibility

The practical upside is hardware flexibility. Some teams already sit on Radeon cards, and some freelancers shop by VRAM per euro. Bringing AMD back into the V-Ray GPU conversation adds some choice again, especially in that midrange 16 GB bracket that appears in purchasing approvals. The practical downside is that a new backend tends to surface edge cases. Output matching is described as consistent in the tested scenes, but you still need to validate your own shading networks, your own IPR expectations, and any pipeline automation that assumes a specific engine string.

If your pipeline uses Blender for lookdev or layout, it is also worth noting that HIP is not foreign there. Cycles already supports HIP as a GPU backend option on Windows and Linux, which at least reduces the surprise factor when artists see the acronym in preferences.

The boring conclusion that saves productions

That is enough to make a lot of workstation build spreadsheets suddenly look different, adn enough to justify real evaluation time in a studio where GPU rendering is not a side hobby.

https://blog.chaos.com/amd-gpu-rendering-vray
https://documentation.chaos.com/space/VMAX/707559558/7.30.02

The post Chaos restores AMD GPUs in V-Ray first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

The problem NanoGS tackles

3D Gaussian splatting can look like magic right up until it starts behaving like a tax audit. Big captures mean millions of splats. Millions of splats mean constant sorting work, a lot of memory pressure, and a very real risk that the renderer spends time drawing things the camera never sees. NanoGS targets that exact pain: rendering large-scale Gaussian splatting files in real time, while handling video memory pressure, sorting huge splat counts efficiently, and drawing only what the screen needs.

The approach focuses on a set of optimisation techniques: Nanite-style LOD clusters, screen-space error LOD selection, splat compaction, a global accumulator, and GPU radix sort. The headline promise is straightforward: large-scale Gaussian splatting scenes should render efficiently, with an emphasis on keeping memory usage low. That is a marketing claim.

Supported engine versions and what you actually install

NanoGS lists support for Unreal Engine versions UE5.6 and UE5.7. The workflow stays inside the familiar plugin lane. You download the plugin from the releases page, place it into your project’s Plugins folder, then import a PLY file using the plugin import button. That import creates a Gaussian Splat Asset, which you can drag directly into a level for rendering.

There is also an asset action to enable or disable Nanite if needed. It is an unusual sentence to write about splats, but that is the point: the tool is trying to make splats behave like a native citizen in the realtime world.

The controls that decide whether it feels stable

The plugin exposes settings grouped by intent. They map cleanly to the trade-offs most realtime teams already juggle: quality, performance, and final look. On the quality side, SH Order adjusts spherical harmonics quality. On the performance side, Sort Every Nth Frame changes how often splats get sorted. Enable Frustum Culling turns frustum culling on or off. LOD Error Threshold sets how sensitive LOD cluster switching should be. On the rendering side, Opacity Scale adjusts splat opacity, and Splat Scale adjusts splat size.

These are not vanity sliders. Sorting frequency can be the difference between a stable camera move and a shimmering mess. Culling can be the difference between a scene that fits and a scene that explodes memory. LOD sensitivity can be the difference between crisp detail and visible popping. And opacity and scale are the levers that decide whether the splats read as a coherent surface or as a cloud of regret.

About one third into your first test session, you will probably notice the same thing most teams do: the scene can look fine at rest, then fall apart during motion if sorting gets too infrequent. That is when you stop guessing and start dialing.

Debug commands that make problems obvious

NanoGS includes console commands designed for inspection and stress testing. gs.ShowClusterBounds 1 enables a Nanite cluster preview, and setting it to 0 disables that preview. gs.DebugForceLODLevel can force rendering at a specific LOD cluster level for debugging, with values like 1, 2, 3, 4 and so on.

Then there is the one that will get used the most in anger: gs.MaxRenderBudget. It limits the maximum number of visible splats after culling to save memory. The default is no limit, using 0. You can set a maximum cap such as 3,000,000. When the cap is active, the culling starts from splats far from the camera.

If you are trying to ship anything on fixed hardware budgets, this kind of explicit cap is refreshing. It makes the failure mode predictable. It also makes it easier to have honest conversations with art and production, because the tool draws a hard line instead of pretending everything will fit if you just believe harder.

Best practice: do not feed it one giant splat brick

NanoGS calls out a best practice that will sound familiar to anyone who has ever fought streaming, culling, or draw lists. A single big chunk of gaussian splatting file does not help performance optimization. Splats outside the camera view cannot be culled effectively. And if everything stays in one chunk, all splats stay engaged in sorting all the time.

The recommended format is to slice a large splat file into smaller pieces. Examples given include individual props for cinematic scenes or tiles for geo-spatial data. The repository includes a simple tile slicer written in Python to support that workflow.

Proof of concept, not a miracle

NanoGS is described as a proof of concept, with a clear warning not to expect perfect results. Issues can be reported on the project page. That framing matters for production teams because it sets the correct expectation: you are evaluating a technique and an implementation, not adopting a finished commercial renderer. The good news is that the tool is built to be tested, with the kind of switches and debug views that make evaluation less mystical.

New tools and innovations should always be tested before use in production, especially when they touch core rendering paths and memory budgets.

Release, license, and what it costs

NanoGS is released under the MIT license.

The repository lists v1.0.1 as the latest release, dated March 20, 2026.

The plugin is free.

https://github.com/TimChen1383/NanoGaussianSplatting

The post NanoGaussianSplats for UE5 first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

For those who don’t know the tool: Redshift is a GPU renderer built for fast lookdev and final frames. Vectorworks is a BIM (Building Information Modeling) and CAD hub where buildings get drafted and organised.

Architectural visualisation pipelines love a clean handoff, but they hate the part where you wait for it. Redshift for Archviz positions itself as a single-environment loop: preview inside your BIM tool, iterate while the model still feels editable, then render without rebuilding the whole look in a second app.

The core pitch is direct integration with Vectorworks, aimed at letting artists and designers stay in the same workspace while moving from real-time previews to final renders. The platform targets the usual ArchViz pressure points: quick iterations, look development that stays consistent from draft to final, and visuals that survive client meetings without the dreaded “we will render it later” disclaimer. Maxon describes this as an expansion of the same rendering technology used in its existing ecosystem, tuned for real-world, real-time architecture design workflows

Real-time lighting that behaves like a grown-up

In the feature set, the real-time preview leans hard into lighting, materials, and environment response. The toolset includes controls to change the time of day, sun position, and cloud cover, to show how natural light interacts with the design as you adjust conditions.

Cloud cover control is quite precise, spanning conditions from clear to fully overcast, specifically to visualize how clouds affect natural light, shadows, and the overall mood of an architectural render. That kind of environment knob matters because it ties directly to decision-making. When lighting direction and softness update instantly, material choices stop being theoretical and start becoming compositional tools.

Assets, materials, and the eternal fight against empty rooms

The content side is framed around libraries that help you get to “inhabited space” faster. A growing asset library includes materials, lights, and ready-to-use assets intended to speed up scene building while keeping physical accuracy and visual consistency.

On top of that, the feature descriptions call out drag-and-drop population of interiors and exteriors with a selection that includes furniture, vehicles, realistic plants, and people, and these assets interact naturally with surfaces.

Material coverage is physically correct, spanning concrete and metal through glass, wood, and textiles, with the promise that materials react naturally to light and environment. The workflow emphasis stays on applying, adjusting, and previewing changes in real time, so look development can happen while you are still shaping the design.

Mac and Windows parity, right from the start

Platform coverage is plain: Redshift for Archviz is available for Windows and macOS, andfeature parity across both platforms from the outset. That matters whether you bounce between machines in a studio or your clients do. It also matters if your pipeline includes artists who bring their own gear and do not want a surprise feature gap halfway through a project.

The Cinema 4D escape hatch for the fancy stuff

When a still image turns into a walkthrough, you need more than a preview window. The workflow includes the ability to send a project to Cinema 4D with a simple click, with the intent of enabling more advanced architectural visualisation work, including procedural animations and simulations.

The FAQ describes export from the Redshift for Archviz plugin to Cinema 4D, and states that geometry, materials, cameras, and basic lighting generally transfer well. Once in Cinema 4D, refining scenes, materials, and lighting with a higher level of control is as usual, and then extending the project with animation and simulation.

This is a practical bridge for teams who want the speed of in-app previs but still need a DCC stage for shot craft, camera choreography, or heavier scene management. It also keeps the promise of visual continuity: the same scene, lighting, and materials across preview and final output.

Installation and the beta-shaped reality

The tooling around installation is explicit enough to be useful. The install notes state that the current availability is for Vectorworks, with Revit and Archicad coming soon.

For the Vectorworks side, the guide references installing Vectorworks 2026 using default settings, downloading and signing into the Maxon App, installing an AEC Viewer, then activating the plugin inside the host application by customising the workspace and adding the Redshift entry from the Rendering category. Launch is a Auto Synch button inside the host environment. Use requires creating a MyMaxon account and accepting an EULA. The subscription bundle (Plans and Pricing) supports multiple instances with up to eight GPUs on a single computer.

Because this is new workflow territory, treat early adoption like you treat any new renderer, plugin, or bridge. Run a proper test scene, push the corner cases, and validate the round-trip before you bet a deadline on it. Do that before you put it into production.

What this means for working artists

The practical story is simple: real-time previews inside a BIM host, asset and material libraries geared at architectural scenes, cross-platform support on Windows and macOS, and a pipeline bridge into Cinema 4D for animation and simulation.

If you live in the overlap between design and storytelling, this kind of integration can reduce handoffs and shorten iteration loops. If you live in the overlap between client expectations and physics-based lighting, real-time environment controls can turn “maybe” into “yes” quickly.

Just remember the unglamorous part: new tools and innovations should be tested before use in production, even when the marketing copy sounds like it was written by a very confident sunbeam.

https://www.maxon.net/en/article/maxon-introduces-new-real-time-rendering-and-cinematic-previews-solution-for-architects

The post Maxon ships Redshift for Archviz first appeared on DIGITAL PRODUCTION and was written by Bela Beier.