OctaneRender® 2026.2 for 3ds max® v26.5

[remKa]

Octane lights should have a complete rework indeed, I've posted several posts on that matter, hope you guys will work on it.

Octane for Houdini is a good exemple, you can tweak spot/gradient/alphas in the light options.

[coilbook]

Can octane render tyflow 2 zenith fire and smoke ?

https://youtu.be/YNcHMUtH-EI?si=uNzWsX8ITkIGn9I5

[coilbook]

In this version samp/s stays at 0 in octane preview sometimes

We think motion blur somewhere is causing it. As soon as it is off it works

[coilbook]

Could you please render 150 frames instead of just one frame? You’ll see the evaluation time go up to 1–2 minutes, and the RAM gets clogged when using tyFlow particles.

During our render with 20 GPUs, the time per frame increased from 2 minutes to 7 minutes (During 150 frame rendering), and about 60% of that was just evaluation time per frame. VRAM usage also increases significantly.

With 10,000 particles, VRAM usage was 8 GB. Without tyFlow, VRAM usage was only 1 GB. This proves that tyFlow renders them as COPIES, not INSTANCES. I also think MB slows down rendering a lot.

UPDATE: For some reason in some scenes tyflow renders as instances but sometimes as copies clogging vram and increasing eval times.

Hi coilbook,

I've investigated your scene for memory leaks and performance, rendering frames from 0 to 250, and got those results:

-The main reason of memory usage and performance reduction is the use of the 3dsMax Boolean object !
It has a memory leak, and should not be used, especially for animation !
I rendered your scene with Arnold and Scaneline, with Octane un-installed, and got similar results:
Around 10 GB are lost after the render. Even after a File/Reset, there are still ~7 GB lost.

-Another issue comes from tyFlow. but it's not exactly a memory leak. It seems more like a memory fragmentation:
When we render all frames after loading the scene, no frame is in the particle cache
For each frame to be rendered, tyFlow calculate the simulation and store the particle data in a cache memory, and keep it for further use when editing the scene.
But this cache memory is not continuous because other things are allocated each frame. That may cause performance issues.
To avoid this, you could disable the tyFlow cache when rendering, or make tyFlow calculate the full simulation and create the particle cache efficiently, by setting the timeline to the last frame, before rendering.
(eg with maxScript: slidertime = 250)

-There was a small memory leak in some Octane objects. Even small size leak is bad as it makes memory fragmentation worse. This will be fixed in the next release.

So the main issue is the Boolean objects (Bar to cut001 .. Bar to cut010)
There are several ways to replace this Boolean object.
The simplest I can think of is to use an Octane proxy:
-move 'Bar to cut001' to x=0, and y=0 (that help to use the resulting proxy object)
-select 'Bar to cut001'
-Use the context menu to open "Export to Octane Proxy"
-Enable Animation export, set frames from 40 to 300, Export
You'll get a 'Bar to cut001.octprx' file (~200 MB)
Create a Octane / Proxy object, and set the file to this octprx file
Move it and create instances to match all your Bar to cutxxx objects, then you can delete those Boolean objects.

Another way is to use Octane Vectron objects and operators.
but I could see some issues when trying to combine several objects (like 2 Torus) to link them to a Vectron Subtract, or creating a custom subtract osl.
I'll fix those issues soon, as it might be the best alternative to Boolean object.

Thanks

Hi,
I think there is a memory leak with tyflow particles that finds target to path deform (WSM) (like a mesh that is streched along path deform spline)