Autodesk Shape Modeling Plugin For Rhino 5 Crack
Nico Sadiq
Blender can produce accurate architecture models. It is a very capable modeler. If you haven't learned how to do precision mesh modeling (making extensive use of local axis, snapping, and numeric movement), you might need to practice your modeling a bit first, though. If you are expecting drag-and-drop BIM object libraries, you will find some in the Archipack Add-on, but nowhere near to the commercial BIM offerings right now.
If your definition of BIM is whether it is capable of authoring and consuming ISO-standard BIM data such as IFC, BCF, and more, then yes. In fact, it is much more advanced than most other proprietary offerings.
If your definition of BIM is whether it can produce drawings, the answer is "not yet". The features are slowly being implemented. Here is an example of drawings produced with the BlenderBIM Add-on. It supports sections / plans / elevations, scales, titleblocks, view styles, and so on. That view is also created with "sketch-up style" simple output. However, the support is still very basic, as it is a relatively new feature. Therefore, it is not yet ready for production use without headaches. For example, it doesn't yet support geometry-associative annotation.
If the definition of BIM is the integration into all the other ecosystem of tools required for building coordination, like clash detection, issue management, structural analysis, environmental analysis, MEP systems design, and so on, the answer is also "not yet". There are some very advanced features built for clash detection, and a very advanced set of features built for (currently read-only) issue management. However, in contrast, there is very, very basic support for structural analysis and environmental analysis (well, it depends on the type), and zero support for more MEP specific tasks.
Welcome to the early days. The BlenderBIM Add-on didn't exist less than a year ago, and only being developed part-time by volunteers. You might find the BlenderBIM Add-on Roadmap enlightening. You may also be interested to see how much progress we've made so far from zero.
Keep in mind that although there is talk about code, almost everybody in the OSArch community is a professional. For example, I am trained as an architect and am currently working in the AEC industry, designing and building buildings. I develop not as a coding exercise or with a "software vendor" mindset, but to solve real industry problems, design, and deliver a building. I believe most of the others in this forum will say the same in their respective fields.
Also, Blender could be a real BIM tool if Dion can solve the geometric modeling (kernel) issue which I don't think it is hard if Dion and his friends have enough knowledge in the geometric modeling field
As we know Blender is polygonal mesh based when the industry prefers NURBS and Solids and BRep
Idonno exactly what you are doing. Because there is code on pure python, wich is slow, some nodes are slooooow. But some have numpy support, it depends on your layout.
I.e. boolean is too slooow
Sverchok has Math surfaces, coded from scratch by Portnov.
@ReD_CoDE said:
Also, Blender could be a real BIM tool if Dion can solve the geometric modeling (kernel) issue which I don't think it is hard if Dion and his friends have enough knowledge in the geometric modeling field
As we know Blender is polygonal mesh based when the industry prefers NURBS and Solids and BRep
The allegation that a better geometric modeling kernel is required to do BIM is false. Take a glance at the gaming industry, and tell me if you think they don't have a the right tech to create a digital twin of an entire city. Of course they do - they create entire worlds with very rich data with ... well, meshes. Take a glance at the CG industry and ask a professional modeler to do their job without meshes. They'd quit. You think a small fraction of the AEC industry only "prefers" NURBs because that's what they been fed tools by vendors and their communities and they never had the full time to train how to do more complex 3D modeling that the real 3D modeling industry expects. It's almost shocking that we have the entire process of clash detection because half the modelers only know how to extrude profiles and people struggle to stop two simple boxes from colliding. Architectural modeling isn't hard - you'd never come across these problems in a properly trained 3D studio. Thank goodness this only represents a small subset of the industry: here's a list of trades who don't care about NURBs and Solids, some who don't even know the word NURBs exists:
When it comes to builders doing construction and fabrication, nobody says "oh, thank goodness, you have NURBs / CSGs, now I can accurately build this thing, without it I'd have no idea how to join these two I-Beams or pour concrete or build long curvaceous railway tracks". That's not how construction works.
The majority of building construction is not the same as a parts manufacturer. Parts manufacturers are highly isolated, decoupled processes from the rest of construction. The rest of construction is simply the assembly of off-the-shelf parts. Therefore, whether the geometric tesselation of the rounded edge of a part results in a 1% boundary deviation has zero impact on the quality or utility of the designer or engineer, because any actually important information that derives from geometry is already supplied by the component supplier in a fully decoupled process.
I'm not making the claim that meshes are the be-all and end-all. There is a time and place for a more parametric solid modeler (mechanical parts manufacturing, for instance). One program cannot support all geometric paradigms. There are ways to support lossless transfer, and that's what we should aim for. FreeCAD can help fill in the geometric gaps that Blender has.
@ReD_CoDE go take a sabbatical and learn some programming and some 3D modeling before making unsubstantiated false claims about what is "wrong" with the technical decisions behind the industry that might mislead others who might not have the full background to judge. Blender can output BREPs and Solids in IFC.
@Moult Dion, we have the same view but see things from different directions
Also, I don't need to learn some programming and some 3D modeling, this is not my job, I don't spend my valuable time in these things
FreeCAD if could after years of development wasn't here, for me FreeCAD is a failed open-source movement, however, maybe it survives, I don't know, but I don't want you all after years have something like FreeCAD, if you want, continue, good luck
@Moult is half-true, I don't say what Dion says is wrong, but is not totally true
Dion says VFX, CG, ..., all produce a virtual world, so it's true. BUT what's the virtual world? The desired virtual world should have which characteristics?
Dion has a big mistake, he constantly repeats each software should not be a Swiss Army knife, but he's totally wrong, today is NOT 1980s, 1990s, today is 2020s
When all the world work on Industry 4.0 and some technologies and methodologies that Dion even can't think about them, let alone build something for
As mentioned before all kernels use a hybrid approach, so I like meshes, solids, NURBS, ..., which in reality in the low-level layer all of them are mathematical things and you can solve an equation in different ways
The main issue is that nobody want change until finds lost the game
buildingSMART doesn't want change, because needs a lot of effort, software vendors as well, it doesn't matter it be Revit, FreeCAD or even BlenderBIM or even IfcOpenShell
I talk about Data-Oriented approach today, that needs even IfcOpenShell changes/shift all the code they built during the time to a new paradigm
@MahmoodMohanad I am saying that the majority of tasks in the industry is an assembly of pre-built components, not the fresh design of new components. For that task, similar to a game developer who assembles geometry, whether it is a mesh or otherwise has no impact. We don't re-invent the I-beam every time we design something. I'm not saying meshes are better for it (apart from scalability, which it objectively is when it comes to a city scale), I'm saying it doesn't matter what you use. Therefore, investing a huge amount of time into a new geometry kernel yields little benefit. Most of our library is pre-made. We've assembled complex buildings with hand-drawings: does the fact that our pencil lead has a 5% deviation from the true fabrication matter?
When we do model new things from scratch, architects model boxes and simple extrusions due to fabrication limitations. There is no topology to worry about. We don't need to worry about topology as there is minimal concern for texture unwrapping or shape deformation. A single n-gon extruded along an axis is equally simple in mesh-land as in Solid/NURB modeling land. When the shape is actually complex and requires fabrication level non-mesh representations, that process is completely de-coupled from the architect, and remodeled by a dedicated fabricator who knows what the fabrication machines can and cannot do.
I am trained as an architect. I have delivered buildings. The claim that "mesh modeling is quite annoying for architects" clearly doesn't apply to everyone. If you find it annoying and feel more comfortable with modeling these simple shapes with NURBs / Solids, go for it. If others feel comfortable extruding a mesh plane, they can go for it too. It makes no difference, because for the majority of applications, it doesn't matter. It has never mattered for decades. Does DXF/DWG support NURBS? No. Because it doesn't matter.
The conclusion I am pushing here, is not that meshes are better or NURBs are better. The conclusion is that whereas meshes and NURBs have their time and place for different tasks - for the majority of the construction process, the debate is meaningless. I made a list of trades who couldn't care less in my previous post. If we do clash detection in software that doesn't support NURBs, does it matter? Does it make any difference? No. The geometry kernel does not determine the utility to the majority of the industry.
b37509886e