Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
Show only
|
Search instead for
Did you mean:
This page has been translated for your convenience with an automatic translation service. This is not an official translation and may contain errors and inaccurate translations. Autodesk does not warrant, either expressly or implied, the accuracy, reliability or completeness of the information translated by the machine translation service and will not be liable for damages or losses caused by the trust placed in the translation service.Translate
The modifiers that we use every day, and result in heavy wait times; specifically those with the ability to add LOD. Turbosmooth, Meshsmooth, etc., need to be multithreaded. Going between levels can require a user to sit and wait while max thinks about it, using as little as 6% of the CPU.
Yes, TBB it faster but not too much, in my tests its ~30%. You can check it by yourself. But Magic's version much faster Max's opensubdiv modifier without TBB that because it uses mesh instead of poly.
This post is a bit broad for us to complete in a given timeframe. What I would suggest is folks start to split out the individual modifiers they would like to see have better performance and we'll see how they get prioritized by the community. We have done some preliminary work on multi-threading other areas of 3ds Max only to find out that the overhead of cross talk between threads can have a negative impact on enabling multi-threading.
First I would search this forum for ideas related to modifiers you'd like the performance increased for, vote for them, and post the link in this thread.
If you can find one related to a particular modifier, then create one, and post the link here as well.
We'll split out some of the votes from this Idea to the ones linked here after a couple weeks and Archive this one.
@electrotoast_old I don't think anyone here expects you to "complete in a given time frame". What we want to see is an effort to *start* the process. There's a lot of modifiers in max, and YOU should go through and assess them individually to see a) if they are multithreaded or not, b) if there is any benefit to doing so. Obviously, not all modifiers really matter, because they'll always be fast regardless.
Make a list internally, don't offload it to us to try and craft a list. This should have been done as a matter of course over the development of max, not as a "demanded for 15 years, but always ignored because we're never adequately specific" problem.
In other words we want that classics modifiers would be faster no matter multithreaded or not. As example Conform Space Warp can be much faster... take a look at Thinkbox Genome : https://www.youtube.com/watch?v=Rh18JqSvrHE
@RGhost77 I have to agree with you on that. I only used the "Conform Space Warp" modifier once, and only once because of how slow it was. This was back when I was only working with low poly models. Sure, it may have been my computer, or my video card or whatever, but I remember it took 45 minutes to apply a simple plane (road) to a terrain mesh. --- I'm very certain that modifier can do better.
Maybe it's just me, but MeshSmooth, TurboSmooth, and OpenSubdiv, seem to slow down the performance in the viewport the more instances of them active. Even if all of their instances are on "subdivision level 1". It'd be nice to see a preview in the viewport of what the render would look like without running at 10 fps, though that could be my system as well. (3ds Max 2019 has improved this a lot, but it still slows down when there's multiple instances of the modifiers in the same scene.)
Conform is untouched since in implemetation 20 years ago, so comparing it to Genome is a bit unfair. You can use MCG to build an already better performing solution then legacy Conform SpaceWarp.
Conform is untouched since in implemetation 20 years ago, so comparing it to Genome is a bit unfair. You can use MCG to build an already better performing solution then legacy Conform SpaceWarp.
True, IIRC it'a basically bruteforcing the intersections, no real acceleration structure in place to speed up the lookup with complex meshes, simple k-d tree would go a long way and make many people happy - even more so if it became a part of the SDK and would be reausable (and reused) elsewhere.
We shouldn't really be limiting the topic to be about multithreading here, more a list of modifiers in dire need of revamping. For example, parts of Unwrap are already multithreaded but it could still benefit from a speed increase - though more in the editor performance section.
@Swordslayer You're right about the unwrap tool. When I use it, it does feel like it could be a bit more responsive. Although, it is much better than it was a couple years ago. I also agree that a lot of the modifiers need to be modernized, as a lot of them feel like ancient relics from a very old 3ds Max; I think another thread idea is on order for that?
If you end up creating one, let me know because I have a lot to say about that!
@AnonymousOf course I can use MCG, also I can use C++ but we talk about Max components from the box.
Also take a look what doing Maya's team. They improve deformers with GPU. In Max we have only GPU accelerated modifier is Opensubdiv (which is broken :-D). To get comfortable and productive workflow we need that the modifiers work more faster. Not matter how it would be achieved by Max team.
MCG IS a core component of 3dsmax.I was trying to suggest an intermediate solution for a faster Conform. Starting with the 2017 release, 3dsmax features a GPU accelerated Meshbuilder, so it`s not like they did nothing here.
Hi everyone, I wanted to add to Chip's reply, and give a bit more context about what is going on with this idea. We are currently working on performances in 3ds Max, but unfortunately, it's not as simple as multi-threading modifiers.
I really like gandhics picture! If you don't multi-thread things properly, the performance gain is actually not significant. Truth is, some of the popular modifiers *are* multi-threaded! There are also a lot of other things that can be done to improve performances, without multi-threading Max.
What I'm hearing from replies to this thread, and others similar to it on the forums, is that everyone wants 3ds Max to use be more responsive, faster overall and be confident that we leverage modern hardware features, regardless of whether or not "Multi-threading modifiers" is the right solution or not.
What I propose, to make this idea more actionable, is that we change its title to "Improve 3ds Max Performances". We will also modify the original post to detail what we are thinking or doing on our side, while keeping the original text as a reference.
Making sure 3ds Max is performant and modern is key to its long-term effectiveness, so we are dedicated to making this a reality! Please let me know your thoughts, and we will make the changes if everyone seems on board. David
Sometimes it would already help if the GUI wouldn`t be blocked by longer running processes.
For example open up Slate->wait for material-previews being rendered->work. This just makes for a bad user experience. I think (from my limited perspective) that some clever caching of results and moving calculations away from the main GUI thread would help a lot. It's sometimes really this unresponsive 'Application not responding/busy cicle spinning' that makes users think 3dsmax is 'slow'.
I have a question, on something I would like it to become faster !
it is the "preparing lights" step when you run the rendering process
I've found that despite using several machines with distributed rendering, this phase of the rendering doesn't seem neither multithreaded or dispatched. Am I wrong? May be it couldn't be multithreaded? I don't know ... but It would be a very nice improvement if it could be faster !
Or maybe employ a genius programmer Tyson Ibele who created tyFlow? He alone, made the very complex ParticleFLow multi-threaded. He even improved it. Particle Flow is much more complicated than 90% modifiers and other single-threaded free functions 3ds max. I think that if you could give him problematic pieces of 3ds max code with a significant impact on performance, he would make them multi-threaded or at least considerably optimized that he would gain the entire 3ds max kernel. 🙂
We have been putting a lot of effort into improving the performance of Max in the last few years. Hopefully you have noticed, because several modifiers have been improved, and we plan on continuing this trend. I just wanted to add that while multi-threading does seem like a obvious and reasonable request, it doesn't always improve the performance. In some cases it can significantly slow things down. That isn't to say that we aren't threading where we can. We are doing a lot with threading while we are working, but it's not something that can just be turned on. At the end of the day, we all want performance and the ability to manage massive amounts of data.
