CRACK Autodesk Revit 2018 Multi Win X64
Christel Malden
Hi Vux Vix,Thank you! for your words, we really appreciate that.Regarding your question, we will consider your idea in the next releases, but for now there is a workaround by use multi join by selection with your custom order.Thank you!
Hi Jorge,Thank you for taking the time to review our Magic Join plugin on Autodesk App Store. We're thrilled to hear that you found it to be a great tool!Regarding your question about the availability of the plugin for Revit 2024, I am happy to inform you that it is already available! You can download the updated version directly from the Autodesk App Store.We appreciate your support and feedback, and please feel free to reach out to us if you have any other questions or feedback.
Hi Murat, Thank you for your interest in our plugin and for leaving a review! We appreciate your feedback and are glad to hear that you found our plugin helpful. To answer your question, we have released a new version of the plugin that will support Revit 2024 to Autodesk QA team. However, it is currently under testing from Autodesk's side to ensure that it meets their standards before we release it to the public. We understand that this is an important feature for our users and are working hard to make it available as soon as possible. Please stay tuned for updates on our progress! Thank you again for your support and for choosing our plugin for your Revit workflows.
Hi Mehlika,Thank you for your interest in our plugin and for leaving a review! We appreciate your feedback and are glad to hear that you found our plugin helpful.To answer your question, we have released a new version of the plugin that will support Revit 2024 to Autodesk QA team. However, it is currently under testing from Autodesk's side to ensure that it meets their standards before we release it to the public.We understand that this is an important feature for our users and are working hard to make it available as soon as possible. Please stay tuned for updates on our progress!Thank you again for your support and for choosing our plugin for your Revit workflows.
I'd love to change join order between concrete and masonry walls in whole model. In revit they are same category. If Switch to front/back will work for previously selected elements it will solve this issue. Picking elements one by one is hard to execute for big group of elements
yes indeed, it would be of great help. at this point, when collegues join, they forget shared generic models also join. this influences the graphic output immensly, with undesired effects. thank you for considering adding this option!!
I am running on an i7-8600k, overclocked to 5ghz on all cores: pretty much as fast as you can get at the moment, but pretty much all wasted thanks to this product. I only see one core being used- the gpu barely moving as well.
Thanks for the links. I know some task are going toward multi-threading but the majority of Revit task are all on the single core processor. This is living in the dinosaur era. Processor companies are no longer going for single core fastest speed it is all about threads. I personally spend hours upon hours just sitting here waiting for Revit to churn. We can't break are models up any further. We have even had Autodesk out, upon getting the answer your pushing Revit to it's limits, it wasn't intended to do this. But yet all we are doing is modeling to the 400 level.
@bdalyZ9ERT - there was another article about how and why Revit uses multiple cores, but I can't find it anymore. I do remember the premisse. It's a bit how the building process itself works. Some things can't be done before something else is done. Like you have to have a foundation before you can put anything else in place. The same thing for Revit - you have to have a wall before you can place a window. It works the same under the Revit-hood.I don't think there's a way you can change that?
It's a bit of a pitty the Intels' and AMD's are focussing on cores, cores and cores. There was a time it was all about MHz, MHz, and MHz. So I think there will be a time the attention will shift to cores AND MHz's.
"Recommend revit editors to improve the use of multi-core CPU! ! Recommend revit editors to improve the use of multi-core CPU! ! As the model gets bigger and more complex, revit gets more monthly cards. However, the CPU utilization rate is only between 25% and 30%. The CPU has a lot of resources to use, but revit is wasted. GPU revit basically not used."
The GPU isn't a magical calculator box; unlike the CPU it is only able to do a very limited set of calculations. Programs which *do* incorporate GPU processing mandate the use of workstation GPUs (and usually NVidia Quadro or Tesla cards), as they can do more and at higher precisions. I don't think many would be impressed if the GPU requirements of Revit changed from "Quadro certified" to "Quadro mandatory".
What Jaques said, Less is not More, in our case, More is More (recall Moore's law? How ironic in this context)...and I'm pretty sure some of us who have been here since the acquisition +-15 years ago have been harping on the speed issue since the technology availed itself. I recall w/great fondness, in the 00's, how absolutely gigantic the "Revit Wish List" grew, and how redundant, and as the list grew, the frustration grew in even greater congruent proportion. Finally, folks just gave up (I know, I'm one of them). Now i just smile, and stand there, looking dumbfounded, because like the great penguin leader stated to his true believers: "Cute and cuddly, boys...just stand there and look cute and cuddly..."
(and I read the link above, but why then, on my brand new custom built workstation class screamer, (water cooled), do I find my box sometimes grinding to a halt on even residential projects, at which time, I must reset to get her back up to speed, and this only happens in Revit??? Mind you, I'm mostly happy, and cuddly, not so cute these days.)
Pls don't post useless links. - That being said, I acknowledge that my request was likely almost as useless. (The link details, albeit indirectly, that revit is not multi-threaded in any useful way. )
This is so common a question that it's pretty much just venting at this point, but honestly I have a hard time wrapping my head around how ugly revit's interface is and how slow its viewport reacts. The interface's look isn't necessarily the most important thing about a BIM platform, but it might be one of those things that could be changed. The viewport and overall speed of the software on the other hand, I'm guessing, is an issue due tied to fundamental flaws in the software - everything is click, pause, selected!
Not everything can be divided into multiple, independent tasks. If you break a large task into a series of smaller ones, if each has to wait for one of the others to complete before starting then there is no benefit to multi-threading. In fact, the overhead of managing the threads can make it take longer. Rendering, for example, can process each pixel independently so a CPU-based rendering engine can use as many threads as it can get a hold of.
Interesting thing is, whether you have an overclocked quad-core, a dual eighteen-core space heater, or something in between, as long as the clock speed and generation are similar single-threaded tasks complete in about the same time.
Not everything can be divided into multiple independent task, but the software that is better able to do so will have a significant edge over the software that can't. When I turn on Archicad, it's immediately obvious that things are running faster and smoother, even though objects are better rendered. If I go to see how many cores are running with a basic scene and I see that almost all my cores(I have 6) seem to be taking part - whereas only one is doing so if I check with a basic Revit scene. It is possible to use many cores for basic tasks and viewport navigation, Archicad and other software proves it. The issue is with Autodesk, not the limitations of software in general. I'm wondering what the hiccup is? What about it's architecture or the way it functions prevents it from achieving what it's direct competitor is able to do. I ask because I have to use this software and it would be great if it could handle large scenes- the processing power is there.
Revit, like many autodesk products - 3ds max being perhaps the worst offender due to its inherent needs- is generally unable to take advantage of new processors. Most of which have several cores. The fact that the cpu and the software seems to have diverged completely points to a fundamental issue with Revit, that autodesk has had ten years to address and done very little about. If autodesk did not have such good marketing and a near monopoly, it would not be able to make these kinds of errors without significant consequences. Nor would it be possible to distract from these issues with the equivalent of - it's a hard thing to do.
If you have a thousand addition problems, 100 fifth-graders are going to be faster than someone with a PhD in Mathematics. But if you're doing Probability or Fluid Dynamics, multi-threading to those 5th graders won't help at all.
Operation speed gets slow down on the large project. So Daiwa-house wants to make the drawing and the Operation fast by considering the program method and the algorithm enough to use multi-core efficiently (indicator: current 2x)
Here are my job we run amd r7 2700x's with 32gbs of ram and Vega 64 gpu's. I just wish that they would at least utilize the GPU more when in 3d, in big BIM projects like hospitals and university buildings my computer just lags. CPU is no more than 10% utilized and dont even get me started on my gpu utilization (3%). It just seems like they dont really care for some of this anymore. Other programs that i have used cant get enough but when i am in revit it just seems like the program doesnt care what i have under the hood. Autodesk needs to re evaluate their standing on what people are using now days. Not to many people are running 4 core xeons with quadro 600's. They need to get with times and get the higher end users what they need to be able to use the program better.
a3c65b3c4b