shameful development

[Anonymous]

Hi,

I've been using max since it was first released under DOS. Since Autodesk acquired 3dsMAX, product development never got beyond patchy updates to ensure a robust revenue stream for the company. Today after watching yet another large architectural model constantly freeze, and crash, for no reason, I felt compelled to post to this forum. You can clearly see from the screenshot that this 10+ minute save operation was caused by 3dsmax basically freezing for 10 minutes and then saving to disk. Attempting a region selection causes the program to hard crash (dissapear), whereas using ctrl+c does not. This model behaves like 90% of the large complex architectural models we work on and is no exception. The low standards of 3dsmax are particulalry evident when compared with Unreal (which we use extensively) and is capable of displaying the same models with no problem in realtime. Is Autodesk not ashamed of this lazy, incompetent development, and the countless hours of pain and suffering caused to its thousands of paying users on a daily basis?

just wondering..

[lorddavius]

Sure, you can say "well, this is an artificial scene, not a real world production one".

And I'd reply "that's a fair point".

So here goes a production scene of ours. This file alone is over 1.9 GB on disk. Over 1.5K objects and more than 27 million polys in total.

Here's its performance on video:

Again, please share your file, either here so any user can dive in and help you, or in private with one of the moderators. The simple truth is that ADSK does care about Max (hence people from Max team and Q&A replying to you here).

[companioncube]

example of my performance with 3ds max 2019.3. 

10 objects NOT INSTANCED, 3 million poly each, 30 million poly scene total. quick manipulation with editable poly and decent animation playback with noise modifier. 

[Anonymous]

Hi,

Thank you for your reply and for looking at this. I too can get good VP performance on occasion, but most of the time this just isn't the case.  Please feel free to look at this scene - it is a good example of a real-world process in action, where we have taken an architect-created sketch-up model and  bring it into MAX for preparation for UE4. Generally with these scenes we have found that using an expensive 3rd party plugin (SINI-SOFTWARE) is essential to make the process workable.  We can look at why 3DSMAX vanishes in some cases, a form of crashing that is unique to this application alone, in another post...

In this clip you can see the scene isn't even a million polys, but viewport navigation is unworkable:

https://www.a-vr.co.uk/stream/vpnav_max.mp4

We run GTX 1080tis on our machines....

here is the scene file, just after importing the sketch-up file.

http://www.a-vr.co.uk/downloads/skectup_import_vizblocks.rar

I look forward to your response....

Thanks again

Felix

[lorddavius]

Hi Felix, here's what I did to fix the slowdowns you're having (you might need Max 2019.3 to fully use the collapse utility, not sure it is available in the same in Max 2016).

One thing I noticed is that you have Vizblocks INSIDE VizBlocks. Something like an inception of VizBlocks. I'm not sure this is a good practice or not. At any rate, your worst offending piece of geometry is this guy below.

About the crash straight to desktop, you should, if possible, upgrade your Max and see if it persists. I did stress this scene a bit (indeed TERRIBLE to navigate before colapsing everything) and could not get a crash at all, even coping with the terrible viewport speed.

Hope this helps you somehow.

[Anonymous]

Thank you for looking at our scene. I agree it is weird that they come in that way; We have tried a number of approaches to getting geometry out of sketch-up and into max, but it is impossible to avoid collapsing everything down to poly.

This screen-cap shows how MAX has essentially frozen when trying to perform a vert-weld of that model

https://www.a-vr.co.uk/stream/vert_weld.mp4

As this model is A-typical my suggestion is to provide a bit more control over importing a sketch-up file natively, because people (like me) will use FBX, DWG, OBJ or whatever they can to get a reasonable start point without that in place. Surely by providing native import functionality, we would expect some control over the nasty Geo Sketch-up produces.

The point here is that Sketch-up is an industry standard amongst architects, and this model is about as typical as they come. Also its also not particularly large or complex, so MAX should be able to import it in native form with the option of decimating or condensing the geometry, and there all sorted!

Suggest working on core functionality like this rather than cosmetic Ui changes, demo-friendly features and such-like.

Thanks again,

Felix

[brentscannell]

Hi @Anonymous 

Thank you for that scene file! I'll try to pick up the conversation here and make sure that this gets the attention of the appropriate development teams here, but I imagine this may cross a few functional boundaries as we're dealing with not only Interop induced issued that could potentially be resolved before it hits your viewport, but also overall scene performance issues.

For those of you who stepped up to help defend, thank you so very very much. You don't know how much it helps to keep the development team motivated to see users publicly praising the hard work they do day in and day out. There is absolutely no question that there is still a huge amount of work to be done, but this kind of intermediary feedback is great.

[hagen.deloss]

@Anonymous 

I found that when exporting the scene geometry to obj format, and re-importing into a new scene, the viewport performance is much better. Not sure what data, besides textures and animation, is wiped from the scene, but maybe that narrows the cause down a bit. 

I have attached the revised scene.

[lorddavius]

That sounds simple and straight forward, but it is not. Sketchup is a standard, so Max should naturally open all doors and make all necessary changes to accommodate whatever mesh description and paradigms Sketchup chose to use, right?

Well, now Max team not only needs to maintain their own software, but now they have to be constantly aware of any changes Trimble does to Sketchup in order to keep things working.

Now go ahead and put other softwares in the mix. ZBrush? ArchiCad? AutoCad? Revit? And you start to get a picture that this is not simples and so smooth. And that's the reason they do create some standards like fbx, obj, etc. To have a common ground where all data follow a similar logic and can be digested by all DCCs that chose to.

But even then it's no guarantee. Very recebrec ZBrush did some fancy things on their obj exporter that basically made funky things when you imported those meshes in Max. Enough to say that ZBrush did NOT follow what's supposed to be a good practice by introducing things on the obj file. And we're talking about a long time standard!

Also enough to say users did blame Max for their sculpts not importing properly. Like when users blamed Max 2017 viewport instability when it only happened on GTX 10 series (yes, Nvidia hardware/drivers problems).

I sure see MANY places where Max have to improve, and I'm among the first in line nagging devs and calling attention to problems that DO exist, and have to be dealt with. And at the same time, this kind of talk (shameful development, cosmetic changes, demo features, etc) are not objective (you are not pointing to a specific problem to be solved, hence a Dev can do very little about it) and tends to not attracted users to see what the issue is and try to help you.

I tend to visit this forums from time to time. If I know an answer for a problem, I record a video, I make a script, I share a file with a solution, and if needed I talk to other users to escalate the issue trying to find a solution.

I do this because so many people did the SAME to me when I had roadblocks, bugs, doubts, issues. I did my fair share of rant (still do sometimes), but it's much more useful, fast, productive and friendly if we state the issue objectively, analyze and be open to other solutions, and be patient/polite with the people driving this software behind the curtains. 

I'm not asking to sidestep, or hide away the problems, or throw them under th rug. Far from it. You're a customer, and as such is entitled to complain, to express your concerns and give your feedback, even in a harsh manner if you want to.

Thanks a lot for chiming in, @Anonymous Brent.

[spacefrog_]

I had a look at your scene using 3ds Max2018, and indeed it is unmanagable out of the box

after checking each node inside the scene, i found that the sole node/VizBlock responsible for the slowdown is "Blockproposed" in Layer 0, which is essentially the mainbuilding

I never worked with VizBlocks before, but i understand that they are something like compound objects of several other objects, and try to keep the structure of linked DWG's ( linked via Filelinking feature, not sure if you even care about that in your workflow ? ). Vizblocks are a remnant of 3ds Viz days, long dead and buried ...

On top of that, the Vizblock in question contains OTHER Vizblocks, which again contain Vizblocks themself and so  on. This of course generates a hell lot of interdependency checking requirements for 3ds Max. And thats certainly the thing that slows Max down so much. In one situation i had to track down 4 layers of Vizblocks in the modifier panel ( see screenshot ) to reach down to the linked geometry node.  The scene almost looks like especially produced to bring 3ds Max performance down to a halt ( good borderline testcase on the other hand )

Long story short:

At the point when i reached the 4 stacked Vizblocks in the modifier panel i decided to collapse that one node to editable poly, as i could'nt do anything meaningful else with the whole thing . And voila : the whole scene became pretty manageable again and performance pretty good. i would have loved to keep instances, but as i said, i did'nt find a way to keep that hierarchic dependency intact . Thus the resulting file grew to over 100MB . See it attached ( Max 2016 )

Lesson learned:   VizBlocks containing Vizblocks are horrible for performance

[spacefrog_]

Just wanted to add another observation:

The slowdown seems to be a DISPLAY thing. As long as you keep the node "Blockproposed" hidden, but selected and it's modifie panel open, it can be dealt with pretty quick. so maybe there is a way to collapse it without loosing instances ( otherwise bad performance would make this unlikely ) . If i succeed in keeping the structure/instancing intact i'll post the resulting scene ...

[Anonymous]

It is genuinely refreshing to get such helpful feedback from you all. Since the very start Ive worked with Autodesk software and have watched the company grow from Autocad 1 to the current monopoly. The fact of the matter is that support and development has not been in-line with that of other similar packages, and MAX does have a reputation for instability, illogical development choices and cynical upgrade/pricing strategies. 

That aside I do believe that all things can be improved and your responses here are testament to that possibility.

I agree that it is impractical to ensure flawless cross-platform functionality with all software. What I do expect, however, is cross-platform functionality with other Auto-desk software, with some big-guns added to the mix - Sketch-up is surely the biggest gun out there with respect to AEC. 

At the end of the day everyone 'should' be happy - Auto-desk has a money tree with MAX, and a totally dedicated user-base -- all you need to do in return is start building the beauty back into the program, and we can all be friends...fewer vanity projects more real-world functionality.

My final comment on this is about basic stability and program behaviour which in my view should be priority number one for the team. I know of no other program that will simply vanish when it crashes. And pop-up messages warning that a file cannot be opened when it is not found on a network is just an oversight (a terrible thing for novice users). I could list dozens of things like this if it helps for improving future releases...?

I hope things can get better with MAX, because you owe it to us, we make it a thing...... 🙂

thanks

[membrec]

Hi @Anonymous ,

I'm one of the members of the Max team working lately on AEC workflows. Our recent focus has been on improving Revit import but we've been poking around with SKP a bit, to see if there are any easy improvements we could make there as well. Would you be able to share the original skp model with us, so we have a good real-world test case to work with. Obviously, I can't promise anything here but I would like to see if there's anything we could do code-side to improve your workflow.

Thanks

Chico

[whitebirchstudios]

First will be to allow the import of an SU model that is newer than 2014. Five years behind is insane!

[membrec]

Hi @whitebirchstudios,
 
This is an issue we are aware of and have been investigating the level of effort to update the importer. Unfortunately, it turns out not to be a simple update and if we were to produce a newer importer soon, it would come with other limitations that may or may not be acceptable to you and other users. But please know it’s on our radar and we do consider it in our prioritization efforts. Keep in mind, there are multiple importers that need updating, so these decisions are made in the context of many areas of Max that could or should be invested in.
 
For my understanding, could you provide some details on the limitations around the current workaround, which is to save backwards in SketchUp. I know this is not a “good” solution, but in my experience it’s easy and it works. That said, it would be good to know if there are cases when the workaround will not work - functionality or model detail will be lost when saving to an older SketchUp version. Or are there other blockers to this workflow?
 
Thanks for your feedback.
 
Chico

[whitebirchstudios]

Sure, saving back works, if you own SU. I get SU models 2-3X's a year, so the price isn't justifiable.

[Diffus3d]

Hello @Anonymous ,

Out of curiosity, if you run something like cleanup³ before exporting your model from Sketchup, does it help?

Best Regards,

[membrec]

---

@whitebirchstudios wrote:

Sure, saving back works, if you own SU. I get SU models 2-3X's a year, so the price isn't justifiable.

---

Appreciate your point. Thanks.

[Anonymous]

Hi, If getting files out of sketch-up natively is too tricky can we look at an easy fix instead please, one that can drive a grown man to tears - the slice plane.

Presently the slice plane works by performing the operation in real-time. What this means is that when trying to slice a large model, anything over a few 100 thousand polys, the tool becomes unusable due to update inertia. See this video of a 2.6 million poly photogrammetry model that I am trying to trim - it is like playing a cruel game as I guess where to release the mouse, hoping it will be the right spot.

https://www.a-vr.co.uk/slice.mp4

Can you provide a checkbox so that we can disable real-time updates please?

Cheers,

Felix

[companioncube]

you could turn off the modifier and turn it back on once you've placed the gizmo. 

a performance boost would be nice but it's probably low on the list. 

[hagen.deloss]

Hi @Anonymous 

I would suggest adding this as an Idea to the 3ds Max Ideas forum, it's a great place to make suggestions and changes to 3ds Max, and they often get accepted as "future considerations" like this one here.

I know I would totally vote for that suggested change! I agree that its a little cumbersome depending on what it's being used for. 

You may be able to get the same effect with an animated texture, or this awesome Slice plugin tool that @lightcube made, it really depends what the end result is you want. 

Hope this helps!