A port of a port of a port = terrible performance on mac

I was doing a quick project for a friend yesterday, and was really shocked at how bad the performance of flame is on a 2019 Mac Pro.
The shot involved about 6500 instances of an extruded G-Mask. No lighting (was way too slow), and 6500 instances of a colored frame with a G-mask feeding the matte.
On almost every single adjustment, I would get the ‘spinning beachball of death’. I checked the Activity Monitor and flare never went over 100% processor utilization, often hanging at 0% for long pauses, on a machine that has 10 cores (max would be 2000% on this machine).
GPU utilization never went over 1-2%
I’m sure that this is why flame feels ‘great’ on a MacBook pro. It doesn’t utilize any of the hardware on larger systems. And given the relative parity of mac vs linux, I’m not sure things are that optimized on that platform either.
All of this adds up to me to say that flame is desperately in need of another overhaul of the code base. It feels like we’re emulating the linux OS, emulating Irix. It’s time to clean up and bring Flame into the 21st century.
I was tempted to try the same shot in Nuke, or some other program to see if performance was improved. Obviously in Unreal Engine it would have been real time.



While I don’t know enough about Flame’s development to agree or disagree with your thesis, I would argue that it’s a little disingenuous for you to say that Unreal Engine could do that in real-time. Yes, UE would probably ( but not obviously) render that in real-time, but in order to do that, you would need to have an FBX of the model to import into UE and if you had that model to import into Action instead of creating thousands of extrusions, I suspect that Flame would probably be significantly more responsive. Also, rendering something in UE to integrate with a live-action plate, in my limited experience, is a huge pain that would rob you of any of the time gained from rendering in real-time. Nuke would probably also choke on thousands of geos, as well. But there’s always room for improvement with our tools and I do agree that Flame can be annoyingly slow.

1 Like

Wanna upload a setup? Anybody with a Linux box wanna give it a go? @space_monkey ?

I can rock that.

1 Like

I am totally intrigued to see that setup, looking at that frame I can’t see why it would be that complicated but obviously that is probably simplifying it a lot but I am willing to run it through the paces on the Linux

No idea Sam, but 6500 of anything is got to slow it down a lot

My point is that if you’re calculating pixels, it might be smart to utilize the graphics card, and maybe more than one processor core. Much of the time I’m sitting on a spinning beach ball with more or less zero processor activity.
It’s maddening! It feels like we’re emulating an O2 from 1999.

1 Like

There’s only one gmask shape in the scene, instanced 6500 times through multiple axis. Look at the picture attached to the original post. It’s a cross with 12 points.

I suspect that extrusion could be a complex geo. Maybe if you switch it out for 2 intersecting cube primitives.

I am more curious based on the frame , what does the camera do and why do it as geo’s at all?
Based on what I am seeing its like using a sledge hammer to to hit a tiny little nail, bit overkill and not worth the extra effort or render time hit you would expect to see.

Probably didn’t, in the end need the geo, because I didn’t end up using shading. Why? Because it was choking before I got half of them in. I try to always always start out by doing things right, but sometimes schedule and tech limitations make you find a shorter path.

why not just do it as a matte painting or 2d images and shadow casting from that angle and far away you wouldn’t be able to tell the difference, I just want to also say that what is correct is only what looks correct not in the path you take to get there, if you can turn over renders in 5 minutes versus 20 minutes and have it both look the same be sure and choose the 5 min option.

My point was that the software is showing it’s age.
I chose the flame for this still because of the quick perspective matching of the perspective grid.
I challenge anybody to get the perspective that good painting it. This doesn’t change the fact that:
I hate to sit at a machine that has 20 cores available, while a single core chugs away.
I hate that I have a $2500 graphics card that is not doing anything, while I wait.


Setup specifics aside, the point is valid. When I fire up a houdini render it pins all available cores on my machine.

On one hand it’s impressive that Flame can do what Flame does without needing to use all the cores, but on the other Sam’s right that the software shows it’s age in a myriad of ways.


fair point, you make autodesk aware of this?

Hi, I just wanted to add my voice in support of @SamE - it’s very easy to pick holes in the setup, ask for a support ticket, and generally block the conversation - but the point holds - the software is slow in so many key areas - playback being the one that grinds me down every day. That is not to take anything away from what Flame can do that no other tool can, but I agree it is high time for a clean up of the package.


Thanks Gary, I used to tell people that I used flame because it was so much faster than other compositing packages. If it’s still true, it’s not by much.