For those who don’t know the tool: 3ds Max is a Windows DCC for modeling, animation, and rendering, commonly paired with Arnold and add-ons like tyFlow for archviz, motion graphics, and VFX handoffs.

What 2027.1 actually changes

3ds Max 2027.1 ships as a minor update focused on tightening outputs and expanding a couple of procedural building blocks rather than adding a brand-new workflow. The headline is Smart Bevel output quality. The update targets artifacts that show up on more complex geometry.

The other modeling-side change lands in the Data Channel modifier. Three new operators join the stack for converting data between formats, which matters when a setup depends on passing values through different data types without writing external scripts.

This is the kind of update that can quietly fix daily annoyances. It is also the kind that can quietly break a toolchain if you rely on exact behavior in procedural stacks, so test it on real scenes before you let it anywhere near teh shot schedule.

Smart Bevel: fewer ugly surprises

Smart Bevel arrived in the base 2027 release as a bevel-generation system aimed at post-Boolean intersections. In 2027.1, the focus stays on the output itself. The update wants to lessen the amount of artifacts that appear when Smart Bevel runs across more complex intersections and topology, with the stated goal (! Not tested) of reducing those artifacts rather than expanding the tool with new controls.

If your scenes lean on Boolean-heavy hard surface work, this kind of quality pass can mean less time hunting for shading glitches and less manual cleanup after the fact. If your pipeline bakes normals or exports to realtime, it can also mean more stable downstream results, since bevel quality tends to leak into everything from edge highlights to tangent space shading.

Data Channel: three new converters

The Data Channel modifier is the procedural playground for people who like building their own operators instead of clicking the same menu five hundred times. In 3ds Max 2027.1, it gains three new operators described as “converters” between data formats.

They are:; Float_to_Point3, FloatOP and PointOP, and to quote Adsk itself: “Float_to_Point3 converts a float channel into a Point3 channel. FloatOp and PointOp (a point 3 operation) let you drive changes to float and Point3 data through the DCM.”

In practice, Data Channel setups often hit friction when one part of the stack expects a different data type than the previous node outputs. Conversions sound boring until you are stuck doing workarounds for something as simple as routing a float into a vector-like structure or adapting a value for a later operator. These new operators are supposed to be a way to move data between formats inside the modifier stack.

Arnold integration: new core, plus a cloud experiment

Arnold for 3ds Max updates to MAXtoA 5.9.2.0, a feature release built on Arnold 7.5.1.1. It includes a Tech Preview of Flow Render, described as an Arnold cloud-rendering solution, plus support for tyFlow volumes. It includes a Tech Preview of Flow Render, described as an Arnold cloud-rendering solution, plus support for tyFlow volumes.

Here is the Tutorial for the Maya-Version of Flow Renderer:

Flow Render comes with 2400 minutes per user per month of render time for testing and evaluation, with feedback routed to the Arnold feedback forums.

MAXtoA also adds tyFlow volume support via a new tyFlow rollout that lets you assign an Arnold volume shader. The default uses a standard Blackbody setup driven by the tyFlow temperature channel, and there are presets that either bake an approximation of tyFlow ramps into editable Arnold ramps or generate a non-editable OSL shader to more closely match tyFlow’s look.

On the rendering side, the aov_write_rgb, aov_write_float, and aov_write_rgba shader nodes now work inside volume shader networks, with the volume raymarcher collecting and integrating AOV closures using Beer-Lambert weighting. Flat outputs like EXR and TIFF and deep EXR are supported, and Arnold logs a warning if conflicting blend_opacity settings write to the same AOV name from both surface and volume shaders. The notes also call out about a 16 percent overhead with two active volume AOVs at fine step sizes.

Normal_map gains a tangent_space_type option that adds MIKKTSpace normal mapping support, with a standard mode preserving prior behavior and a mikk mode evaluating normal maps using MIKKTSpace data for consistent shading across applications. CPU renders on Windows are also optimized, with most scenes showing faster render times.

Flow Render comes with 2400 minutes per user per month of render time for testing and evaluation, with feedback routed to the Arnold feedback forums.

On the rendering side, the aov_write_rgb, aov_write_float, and aov_write_rgba shader nodes now work inside volume shader networks, with the volume raymarcher collecting and integrating AOV closures using Beer-Lambert weighting. Flat outputs like EXR and TIFF and deep EXR are supported, and Arnold logs a warning if conflicting blend_opacity settings write to the same AOV name from both surface and volume shaders. The notes also call out about a 16 percent overhead with two active volume AOVs at fine step sizes.

Normal_map gains a tangent_space_type option that adds MIKKTSpace normal mapping support, with a standard mode preserving prior behavior and a mikk mode evaluating normal maps using MIKKTSpace data for consistent shading across applications. CPU renders on Windows are also optimized, with most scenes showing faster render times.

tyFlow volumes get a nod

One extra detail in the Arnold integration update is support for tyFlow volumes, enabling rendering of smoke and fire simulated with tyFlow’s sparse fluid engine.

For anyone doing effects lookdev directly in Max, volume compatibility is not glamorous, but it is the difference between a nice sim preview and an actual final render path. If you rely on tyFlow for quick-turn sims, this is worth a controlled test with your typical render settings and AOV requirements.

Availability, licensing, and the fine print you still have to read

3ds Max 2027.1 is compatible with Windows 11, and offered as rental-only. Subscriptions start at $255 per month or $2,010 per year. An Indie subscription option is available at $330 per year for qualifying artists under the stated income and project value thresholds.

None of this changes the basic rule for production: new tools and innovations should be tested before use in production, ideally with representative scenes, caches, and handoffs across your full pipeline.

https://help.autodesk.com/view/3DSMAX/2027/ENU/?guid=GUID-D500E31E-76EF-4C46-B856-7673A5488199
https://help.autodesk.com/view/3DSMAX/2027/ENU/?guid=GUID-C70039CE-C982-4CE0-B1AE-A7432D6FE563
https://help.autodesk.com/view/3DSMAX/2027/ENU/?guid=GUID-E0761A92-60BC-4ECE-BA54-BB7D87775039
https://help.autodesk.com/view/3DSMAX/2027/ENU/?guid=GUID-37C6EC5F-8025-4A11-A36F-EF3B285B35A5
https://help.autodesk.com/view/3DSMAX/2027/ENU/?guid=GUID-7CC2F041-F797-4DB9-B2F9-326AAB994F37

The post Autodesk updates 3ds Max to 2027.1 first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

Autodesk has released Arnold 7.5.1. The headline feature is Flow Render, a new cloud rendering tech preview that gives Arnold users 2,400 render minutes per month for testing. Beneath that, and arguably more useful once actual shots arrive, the update also fixes a long-standing gap in volume AOVs, adds MIKKTSpace normal mapping, and squeezes some extra CPU performance out of Windows.

Flow Render is here, with sensible limits and no magic involved

The loudest part of Arnold 7.5.1 is Flow Render, Autodesk’s new cloud rendering tech preview for Arnold. During the preview, users get 2,400 render minutes per month. That is 40 hours, which is enough to test the service properly, but not enough to start behaving like a streaming platform.

The basic idea is simple: submit Arnold jobs to the cloud, free up local machines, and run more variations in parallel. Autodesk pitches this as a way to speed up rendering, look development, and simulation work without tying up workstations all day.

Flow Render requires an Autodesk account login, because of course it does. Submission happens through the Arnold plugins. Autodesk lists support for Houdini, 3ds Max, Cinema 4D, and Maya, while Katana support is still listed as coming soon. The backend runs on Autodesk Platform Services through the Flow Graph Engine API, which handles the cloud storage and compute side.

Autodesk says Flow Render is aimed at everyone from larger VFX and animation studios to freelance 3D and FX artists. That is the official line. In practice, the current limits matter more than the broad target group wording. A single task can run for up to 12 hours. Users can run up to 10 tasks simultaneously, subject to service-level limits. Task data is stored for 30 days.

So yes, it is cloud rendering. No, it is not a bottomless sky-farm that will lovingly absorb every pipeline problem. At this stage it looks more like a practical overflow and evaluation option, which is honestly a lot more believable.

The more important production news is in Arnold itself

The stronger part of this release is the renderer update. Arnold 7.5.1 finally adds proper custom AOV support for volume shaders. The aov_write_rgb, aov_write_float, and aov_write_rgba shader nodes now work in volume networks just as they do for surface shaders. Previously, Arnold silently ignored them in volume contexts, which is the kind of workflow detail that tends to waste time very efficiently.

Autodesk says the volume raymarcher now collects AOV closures at each step and integrates them using Beer-Lambert weighting, so the resulting outputs remain physically consistent. Flat formats such as EXR and TIFF are supported, as is deep EXR. There is a cost, naturally. Autodesk notes roughly 16% overhead with two active volume AOVs at fine step sizes. Useful feature, non-zero bill. Reality remains intact.

Arnold 7.5.1 also adds a new tangent_space_type parameter to the normal_map shader, bringing support for MIKKTSpace normal mapping. The previous mode stays in place as standard, while the new mikk mode uses MIKKTSpace-generated normal, tangent, and bitangent data from DCC tools such as 3ds Max. That should reduce shading mismatches between applications, which is not glamorous, but is exactly the kind of boring improvement people end up appreciating.

Windows users also get CPU render optimizations. Autodesk says most scenes render faster, though not all. The examples in the release notes show a 1.16x speedup for the OpenPBR shader ball, 1.08x for gtc-robot, 1.07x for Disney cloud, and 1.04x for ALab. Intel jungle ruins stays at 1.00x, apparently choosing not to participate.

There is one incompatible rendering change worth noting. Arnold now correctly supports the exponent parameter in the OSL generalized_schlick_bsdf closure for both reflection and transmission. Scenes using non-default exponent values or heavy transmission may therefore render differently. Technically correct, slightly annoying, very Arnold-point-release.

The bug-fix list covers GPU artifacts, IPR crashes, incorrect volume mipmap selection, polymesh crashes, Hydra update problems, and several USD-related issues. So this is a proper point release: one shiny cloud headline, several genuinely useful renderer fixes, and a pile of smaller changes that will matter most to the people who have already been burned by them.

Links

Autodesk Arnold 7.5.1 release notes:
https://help.autodesk.com/view/ARNOL/ENU/?guid=arnold_core_7510_html

Autodesk Flow Render FAQ:
https://help.autodesk.com/view/ARNOL/ENU/?guid=arnold_core_rendering_ac_flow_render_faq_html

The post Arnold 7.5.1 comes with Flow Render Tech, Volume AOVs, and MIKKTSpace first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

We stumbled across something new in the render-cloud jungle, and it’s not just another GPU-as-a-service with a fancy landing page . Praxilla is a tiny Austrian startup with big ambitions: fast, affordable, and even collaborative cloud rendering that plugs straight into Blender.

Could this be the thing that makes you rethink your local workstation’s role in your pipeline? And what exactly is “collaborative rendering,” anyway? They’ve got an introduction video that hints at their plans, but we wanted to dig deeper. So, we asked.

DP: Oh no, yet another cloud rendering solution? What makes you different?
Praxilla: Yes, it looks like render clouds are multiplying faster than donut tutorials on YouTube. But we’re not “just another.” Here’s the short version: Praxilla is a distributed render farm built by two founders who were tired of watching their machines wheeze through endless frames. Instead of selling raw GPU horsepower, we built something that’s plug-and-play with Blender. Upload directly from Blender, monitor progress in our job handler, and download frames – no extra setup, no arcane FTP servers, no “please install seven dependencies first.”

She had this animation project that kept her poor PC running all night long – fans spinning like a jet engine, the room heating up like a sauna. She’d wake up in the morning, coffee in hand, praying the render hadn’t crashed at frame 237. That was her normal. We looked at each other and thought: this is insane.

Why should artists babysit a progress bar that moves slower than Windows updates? Most GPUs out there are idle, waiting for Netflix or Minesweeper. So we said: let’s build a network that actually makes them useful. That’s how Praxilla was born.

Get in Touch: Praxilla on Facebook | Praxilla on Linkedin | Praxilla on instagram

DP: Which tools can I currently connect to your service?
Praxilla: Right now: Blender with Cycles and Eevee. Why? Because Blender is open, its community is massive, and frankly, it’s where our hearts are. The donut memes were just a bonus. But it’s not the endgame. Maya, 3ds Max (Arnold), and Cinema 4D (Redshift) are on our roadmap. We’re not trying to be a “Blender-only” club – we’re building infrastructure that works for the wider industry.

DP: On which cloud infrastructure is the rendering performed and what exactly is being processed?
Praxilla: Right now, we rely on a secure network from a trusted third-party provider. That gives us the flexibility to scale and the reliability artists need, while we prepare to expand into our own dedicated infrastructure. For users, the experience is the same: jobs get split into frames, get rendered on multiple nodes and delivered back. The standard is 12-15 nodes at once, which means an animation that would normally block your workstation for hours can be finished in minutes.

DP: How do I pay for rendering?
Praxilla: We keep it simple: you buy packages of rendering hours. Prices start at 2.50 € per GPU hour, and yes, we give generous discounts. That means it’s indie-friendly – you don’t need a studio budget to use us. And no, your files don’t hang around forever. Uploaded scenes are deleted immediately after the rendering finishes on the nodes, and the files stay in the cloud for a maximum of two weeks (unless you delete them earlier). No digital skeletons in our closets.

DP: Can I limit my jobs to run only within the EU?
Praxilla: By default, jobs can run in different regions of our provider’s network. But if required, the nodes can be limited to Europe only. Just request it! The storage, however, is always in the EU.

DP: What happens to my frames if my account runs out of funds?
Praxilla: We don’t delete progress. If you run out of hours mid-job, the render pauses. Once you top up, it picks up right where it left off. No heartbreak, no lost frames.

DP: How flexible is the hardware configuration?
Praxilla: Right now, it’s standardized. That’s what makes it stable. You don’t have to worry about which driver version or GPU mix you’re getting. Every node is tuned to behave the same way. As we expand, we’ll offer more choices, but we’d rather be consistent than throw you into a GPU lottery.

DP: Do you offer automatic scaling?
Praxilla: At the moment, the system distributes each job automatically across up to 15 nodes. Currently, jobs are processed one after the other, and a multiple-job queue will be available soon. True dynamic auto-scaling across many simultaneous jobs isn’t part of the setup yet.

DP: How do you handle GPU virtualization and allocation?
Praxilla: We don’t chop GPUs into virtual slices or make you share them with strangers. Each job gets dedicated GPUs: Not just one, but up to multiple full cards working in parallel. That way, performance is consistent and predictable, and your renders won’t slow down even if someone else is tackling a huge project at the same time.

DP: Is there redundancy or failover in case a node crashes mid-render?
Praxilla: Absolutely. If a node dies (and sometimes they do, Murphy’s Law and all), the frame is instantly reassigned to another. You won’t even notice unless you’re watching logs like a hawk.

DP: What’s your approach to driver and software versioning for render consistency?
Praxilla: We currently support Blender 4.0 to 4.5. Our job handler makes sure your file runs with the exact version you choose, so you don’t get any surprises like lighting or shading looking different between local and cloud renders.

DP: How do you ensure security during file transfer and storage?
Praxilla: Uploads and downloads are fully encrypted (TLS). Files are removed from the render nodes as soon as rendering finishes and are then stored in secure cloud storage in the EU for a maximum of two weeks, unless you delete them earlier.

DP: How do you handle extremely large datasets or texture-heavy scenes?
Praxilla: We do see projects with video files and large textures. Upload can take a while depending on your internet, but once staged, the farm handles them fine. If your project file is larger than about 7 GB, just let us know so we can prepare everything on our side. We recommend optimizing where you can, but we don’t shy away from “monstrous” files.

DP: How do I submit my render job to Praxilla Cloud?
Praxilla: Technically, it’s just two steps (since Blender has to be open already, haha): choose “Render Animation with Praxilla”, confirm your settings, and hit upload. That’s it: No complicated dashboards, it feels just like rendering locally, only way faster. No magic! But jokes aside, we always recommend starting with a small frame range first, just to make sure everything looks the way you expect before sending the full animation.

DP: How is the dashboard structured?
Praxilla: We do have a separate job handler. Think of it as your render cockpit: you see all jobs, the progress, estimated times, and you can download the jobs from there. It’s clean, lightweight, and designed so you don’t feel like you need a sysadmin degree to use it.

DP: How does the Praxilla job handler work?
Praxilla: The job handler is our little control center outside Blender. It automatically takes care of uploads, job tracking, and lets you download.  It also shows you job progress, estimated time, and updates you about the job status. Think of it as a polite assistant, so you don’t have to babysit the render.

DP: Can I change parameters mid-job?
Praxilla: Not yet. If you change HDRIs mid-job, you’ll need to restart. We’re working on smarter checkpointing, but today, it’s “cancel and relaunch.”

DP: Will I get notifications when a job completes or fails?
Praxilla: The Job Handler updates in real time, so you can always see the exact status of your job — whether it’s running, finished, or if something went wrong.

DP: Can I preview rendered frames while the job is running?
Praxilla: As soon as the first frame has finished, you can download it directly from your dashboard on our website to check if everything looks right before the rest completes. Instant gratification included.

DP: Can I send the output directly to another cloud storage service?
Praxilla: Currently, we deliver to your local machine. Cloud-to-cloud transfers (Dropbox, S3, GDrive) are planned.

DP: Is there an API for automated job submission?
Praxilla: Yes, such API is available on demand. If you need to hook Praxilla straight into your pipeline without opening the Job Handler, just let us know and we’ll set it up for you.

DP: Right now, all rendering happens on Praxilla’s own cloud hardware? Have you considered hybrid setups that mix cloud nodes with an artist’s local resources?
Praxilla: Why should your own GPU sit idle while ours do the work? Hybrid setups are on our roadmap — and they’re the stepping stone to something bigger: collaborative rendering. And we will make it happen. We’re still working on the security side of things, of course. But as mentioned earlier, Tariq comes from an IT security background. And really, who could be more ideal for this role than him?

DP: What are the main challenges when trying to integrate personal machines into a cloud render network?
Praxilla: The big challenge is security and consistency. Letting someone else’s file touch your PC without them touching your stuff is tricky — and the other way around too. Your project has to stay protected from anything on their machine. That’s why everything has to run in a secured environment, which we are already working on.

DP: How will collaborative rendering work?
Praxilla: You’ll install a small app along with a prepared USB stick. When you want to contribute, the app reboots your PC into that secure USB environment, and your machine temporarily becomes a render node whenever it’s idle. No one sees your files, no one can poke your system. Everything runs inside that isolated environment. You just contribute GPU time. And in return, you earn either cash or rendering credits. That’s the plan.

DP: How do you ensure data security between multiple collaborators?
Praxilla: Projects run in a fully encrypted environment, and the storage is encrypted as well. Even if your PC is rendering someone else’s frames, you will never see their files.

DP: Will collaborative rendering earn me credits or render hours?
Praxilla: Yes. The plan is that you can earn render time based on actual minutes your node spends rendering. You can save them, spend them later, or run your machine like a little “GPU piggy bank.”

DP: What are the next 2 – 3 features on your roadmap?
Praxilla: The next big one is the multiple-jobs queue — so you won’t have to babysit projects one by one anymore. After that, expect more addon magic. We already support a handful of favorites, but we know there are plenty more Blender artists are waiting for. And then comes a big leap: Arnold for Maya. Step by step, the render cloud keeps growing up. After that, we plan to add 3ds Max and Cinema 4D with Redshift. We’re moving step by step to make sure each integration is stable before rolling out the next.

DP: Looking into your crystal ball: What will Praxilla look like in 5 or 10 years?
Praxilla: In 5 years, we want Praxilla to be the go-to choice for fast, affordable rendering across multiple 3D tools. In 10 years? We see ourselves as the global GPU network for creative computing – not just rendering, but AI, simulations, maybe even games.

Think of it this way: Netflix streams movies. Praxilla streams computation.

And if you want to know about the pictures in this article: One of the Praxilla Users allowed us to show of the results rendered with Praxilla! Nick is a freelance 3D Generalist based in the US, specializing in product visualization and motion design. He also shares 3D tips and full product design tutorials for Blender on his YouTube channel . Feel free to check his other works on his website www.nickel3d.com or on his Instagram page.

For freelance bookings, Nick can be reached at his email contact@nickel3d.com, or by DM on LinkedIn or Instagram.

The post Next-Gen Cloud Rendering for Blender? Meet Praxilla! first appeared on DIGITAL PRODUCTION and was written by Bela Beier.