Will 3dsmax ever be fixed to handle large amounts of objects?

[pr0eXeler0]

There are other scatter-plugins and stuff that handle instances well, but if you have a scene with a large number of objects that are not instances.. say 40,000 objects..

Just trying to select and move into different layers is such a frustrating endeavour in max that its far more enjoyable to jump of a cliff or be beaten by a gorilla using a sharp rock.

Everyone who has used max knows that it gets "exponentially" slower with growing numbers (meaning that selecting and attaching 100 object 10 times is faster than selecting all 1000 at once).

This limitation must lie deep within the max core or It would probably be fixed by now, but it is soooo frustrating I nearly smash my poor computer every time I need to use max for this kind of stuff... 

On paper, I cant understand how it can take so frigging (im censoring my real words here) long time to simply select a bunch of objects and assign them to another layer on a 64-bit computer capable of billions upon billions of calculations per second with loads of RAM.

Not expecting any official Autodesk comments here (are there ever?), but anyone else sharing my pain here?

/eX

[office]

You have a point and I share your frustration. The problem is that Max still uses just one CPU thread for most of the operations so having a 6 core i7 would be of the same use as having an ancient dual core CPU. This really needs to be addressed by the developers and make Max multithreaded through and through.

[pr0eXeler0]

You're probably right, one issue is surely that you only get the CPU power of a single thread.

Still, I get the feeling that the way max handles large amounts of object is done in an "inherently" stupid way from way back in the late 90s when this wasnt an issue because computing power was too crappy anyway to even consider manipulating such large data sets.

[office]

Seeing this request declined, I thing it won't happen soon. The excuse was that this would introduce instability, though I'm not sure why would this happen when we can already render images with many many cores without any instability whatsoever. To me it looks like it's something that would take a lot of time to do and Autodesk just don't want to bother making Max multi-threaded at this time. And to be honest, sometimes I think there really are other areas of Max that need more attention at this stage - Modern and completely customizable UI, Support for high DPI displays, UXD overhaul etc. etc.

[pr0eXeler0]

It usually boils down to that, yes.. how many users would benefit from this or that.. We all work with slightly different things..

And I'm not so optimistic either about seeing a quick fix for this. As I said in my earlier post, I dont think its just a matter of getting multiple threads, it would still be way slower than "it should be" so I feel that something is rotten at the core and fixing it without breaking anything is probably "nearly impossible".

Every now and then, a piece of software reaches a point where its actually easier to rewrite stuff from scratch rather than trying to fix whats there. Looking at Autodesks track record with AutoCAD, that cycle can apparetly be many decades, but in reality, it should probably be done at least once every 10-15 years simply because the technology around us changes a lot during that time. Max is now pushing 18-something years and its showing its age in several key areas.

Yes its got new and shiny paint in places but when you pop up the hood, you kind of shake your head when you see some of the old parts in there..

[aon.914858227]

So you didn`t see any progress in handling large datasets in the latest releases? Hmm....

Multi-Threading is not the holy grail of all performance issues. Some algorithms even perform slower , some of them can`t be parrallelized at all. For example features that rely on the result of previous calculations.Pflow is such an example.

Others features are almost trivial to parallelize, for example vertex transformations. Simply because each vertex is independant from each other.

Multi-Threading also introduces a couple of problems and challenges like race conditions,dead locks, and synchronisation problems. So is it easy? Depends on the problem you are trying to solve with it.

There is this general rule: First you optimize the algorithm then you can try to parrallelize it.

From a user perspective you shouldn`t care about multi-threading at all. It`s just another tool that software engineers use to solve performance issues. As a user i just want it to perform better. How they do it is their concern.

And that`s the reason why this suggestion was declinde un uservoice.

"3dsmax should perform better with large datasets", "Attaching large amounts of objects is slow and should be much faster","Selecting many objects is slow. Please improve performance in this area."

vs.

"Multithread all functions" is a common place. That`s not helping them to identify the bottlenecks.

Some closing words that i hope you don`t take personal: Please guys stop acting like you where Sen. Software engineers on the dev-team by suggesting them technology or rewrites or what not. Especially if you have never written a single line of code in your entire life.

Thanks!

[pr0eXeler0]

Aon, it seems you replied to *me*, but really, if you read my posts I wasn't the one asking for multi-threadding. I was asking if we'll ever get good performance, not suggesting any specific solution for it. 

Yes, I was speculating about what part of the software probably hasn't been rewritten or fixed, based on experience of using max since ~1999.

(yo.. NURBS, has anyone touched that since max 3.1? 😉 )

Hearing you say that we "try so sound like senior engineers" makes me think you're the one taking this personally. Please don't, lots of users here are fanbois too (despite whining here in the forums, we're the same ppl defending max against maya fanbois etc...  but there's also a reality we need to relate, that is, how well does this tool perform for my everyday tasks..)

Its about users wanting a product to be useful - therefore It's normal for users to have opinions on how the tools they use every day could or should be improved. (Or one day they will stop buying it). After all, the paying customers are the ones paying for the development, right?

Anyhoo, regarding this particular example - If I can find the time and motivation (doubtful), maybe I'll post a youtube video showing exactly how it performs for the world to see then you can explain to me exactly what the code is doing to achive the results we see 😉 I'd actually really want to know what's going on there... 

/eX

[aon.914858227]

Sorry,pr0eXeler0 this wasn`t aimd at you or anyone particular.

Btw, i came across a nice article from Christopher Diggins (one of the main developers that brought us MCG) about efficient array operations in C#.  I guess a result of this research is implemented as 'ParralellMap' operator in 3dsmax2016 MCG.

I love this articles, also his blog post where he explains how they implemented MCG.

A really nice look behind the scene:

http://www.codeproject.com/Articles/451628/Efficient-Map-Operations-for-Arrays-in-Csharp

 and

http://area.autodesk.com/blogs/chris/introducing-max-creation-graphs