[X Force 2014 X64 Exe Factory Design Utilities
Jamar Lizarraga
That is the big topic between the factory layout design and Revit interoperability. We don't have the recommended workflow to cover this but we will be carefully considering the workflow. Could you please share the challenge you are facing now at your routine work?
And we heard that some users discovered some best practices Revit interoperability with Inventor Factory and Navisworks. Below is the detailed introduction from Autodesk University. Hope that will helpful for you.
If i create a building with walls, and specify WF I-beams as the steel structure and then add a Bridge Crane system supported by the building steel structure, why can I not have that function in one product, instead of creating (3) separate models. Revit for building, Revit STRUC for the steel work, and FDU for the bridge crane.
But they are not linked, so if I need to make a change to the Revit project element, I am forced to open the original Inventor object in Inventor, make my modifications and then go thru the whole export process, load process again.
Thanks for your feedback. Since Inventor can import Revit model into a part file, you can place the part into Factory layout. When you said "FDU does not accept any of my existing data / models", can you provide more details on it? It will help us improve.
I agree with the comments. Import elements in FDU of Inventor does not solve the workflow with Revit. In many projects we have to delivery 2D drawings with a compleet layout ( architectuur + instalation + machines). Link Inventor files in Revit (And vice versa) would Be the optimal solution for project development
Nope. In de development of the architecture/ structural projects, every week of daily modificativos are made in the drawings in Revit. The Factory Layout also changes according with proposal And final configuration of machines at the same speed but in Inventor. The synchronisation of this information has to be verstil, hs to be up to date the hole time. EXport/import demand lot of time and version management, because partner use different programs.
I think I didn't make it clear. I agree with you that the referenced Revit model in Inventor OR Inventor model in Revit should support update instead of re-import. Does it matter to you if your 2D drawing of complete layout is generated in Inventor environment OR Revit environment?
If a person uses Revit to create a facility, there is not a 2D drawing of any kind.
The Revit model is a 3D object. Yes, you can view it as a PLAN view, but the object is nonetheless, a 3D model.
If a person uses Inventor to create a part or fixture, then you use a 2D 'sketch' to begin, but then it becomes a 3D object after extrude or whatever other modeling operation you do.
The issue was that an Inventor created part or fixture, can not simply be "opened" or "added to a Revit facility model, without a series of conversion steps and operations.
But once converted, then if anything needs to change in the Revit model where the converted Inventor object has been added, then you must go back to Inventor and modify the original model and go thru the whole conversion process again, in order to get it updated back into Revit.
sage
The perplexing aspect of the issue is how can a bldg design software program (REVIT) and an EQUIPMENT DESIGN software program (FDU), that creates equipment systems, that presumably are located in a BUILDING, do not interface with each other???
In Inventor 2021 Beta release, it supports associative reference to Revit model. If the referenced Revit model is changed, it can be updated in Inventor. Please check it out in Inventor 2021 beta to see it it helps.
if I have a whole structure created in my BIM s/w of choice, it seemed unacceptable that I could not use that and was forced to recreate a new building structure in FDU, to be able to create an equipment layout.
Description: When describing a concrete structural model in Revit, the model contains elements used in constructional projects and exported to Graitec Advance Design solution to apply loads and perform structural finite element analysis. The export process will take care of the required properties of elements such as material, sections, and geometry. Using the powerful mesh engine and finite element solver of Graitec Advance Design, the internal forces will be calculated based on the applied loads. Then the required area of reinforcement in elements will be calculated, considering the concrete design code and localization. Next, the model will be exported back to Revit. Graitec GTCX format can also transfer internal forces and rebar areas to Revit using the Powerpack tool. Based on the calculated forces and steel area, we will present how to perform 3D rebar placement in Revit for several structural elements. The process of model synchronization between Revit and Advance Design will also be covered.
Description: Discover how implementing building information modeling (BIM) innovative concepts in design and build projects can greatly improve project efficiency and accuracy. By using the latest construction technologies such as mixed reality, LiDAR scans, and parametric design, construction teams can better visualize and plan projects, reducing errors in the construction phase. This class will showcase practical examples through projects delivered by LEVIATAN and UBITECH, major engineering offices in Romania that use Autodesk and GRAITEC software. Additionally, the use of these technologies can increase safety on construction sites and reduce the amount of time required to complete projects. Ultimately, these benefits lead to improved quality, reduced costs, and better outcomes for both construction teams and clients.
We are a best-in-class VAR and Autodesk partner. GRAITEC has ranked as one of the largest Autodesk partners in the world since 1997. Today, we are an Autodesk Platinum Partner in Canada, Europe and the U.S. with the acquisition of Applied Software. GRAITEC also has a team of 200 developers providing software for architects, structural engineers and more.
By "Factory method pattern", I mean both static factory methods inside an object or methods defined in another class, or global functions. Just generally "the concept of redirecting the normal way of instantiation of class X to anywhere else than the constructor".
This sounds nice (and indeed often the best solution), but is not a general remedy. First of all, there are cases when object construction is a task complex enough to justify its extraction to another class. But even putting that fact aside, even for simple objects using just constructors often won't do.
Which, instead of constructors, leads me to usage of static factory methods... which essentially means that I'm implementing the factory pattern, in some way ("the class becomes its own factory"). This looks nice (and would suit this particular case), but fails in some cases, which I'm going to describe in point 2. Do read on.
another case: trying to overload by two opaque typedefs of some API (such as GUIDs of unrelated domains, or a GUID and a bitfield), types semantically totally different (so - in theory - valid overloads) but which actually turn out to be the same thing - like unsigned ints or void pointers.
Cool? Often, indeed. But then- this forces the user to only use dynamic allocation. Static allocation is what makes C++ complex, but is also what often makes it powerful. Also, I believe that there exist some targets (keyword: embedded) which don't allow for dynamic allocation. And that doesn't imply that the users of those platforms like to write clean OOP.
What? We can't overload by the return type? Oh, of course we can't. So let's change the method names to reflect that. And yes, I've written the invalid code example above just to stress how much I dislike the need to change the method name, for example because we cannot implement a language-agnostic factory design properly now, since we have to change names - and every user of this code will need to remember that difference of the implementation from the specification.
Well, usually. But sometimes it does not. When creating Foo, we actually depend on the compiler to do the return value optimisation for us, because the C++ standard is benevolent enough for the compiler vendors not to specify when will the object created in-place and when will it be copied when returning a temporary object by value in C++. So if Foo is expensive to copy, this approach is risky.
First of all... I sincerely dislike the concept of two-phase construction and I feel guilty when I use it. If I design my objects with the assertion that "if it exists, it is in valid state", I feel that my code is safer and less error-prone. I like it that way.
I believe this point is incorrect. The complexity doesn't really matter. The relevance is what does. If an object can be constructed in one step (not like in the builder pattern), the constructor is the right place to do it. If you really need another class to perform the job, then it should be a helper class that is used from the constructor anyway.
But the good thing is that you can immediately see what coordinate type you're using, and at the same time you don't have to worry about copying. If you want copying, and it's expensive (as proven by profiling, of course), you may wish to use something like Qt's shared classes to avoid copying overhead.
As for the allocation type, the main reason to use the factory pattern is usually polymorphism. Constructors can't be virtual, and even if they could, it wouldn't make much sense. When using static or stack allocation, you can't create objects in a polymorphic way because the compiler needs to know the exact size. So it works only with pointers and references. And returning a reference from a factory doesn't work too, because while an object technically can be deleted by reference, it could be rather confusing and bug-prone, see Is the practice of returning a C++ reference variable, evil? for example. So pointers are the only thing that's left, and that includes smart pointers too. In other words, factories are most useful when used with dynamic allocation, so you can do things like this:
795a8134c1