BIM for SketchUp - again?

brewsky

I think SketchUp is at its most powerful in the design process when the building is still simply a hollow shell. No thickness in walls and all openings as self-cutting-components.

The best addition to basic SketchUp for me I think, would be "thick-faces". This would make parametric elements a whole lot easier to make, and in the process exporting to meaningful building parts. The greatest difficulty lies in how these faces connect...

Making building parts in that way could be

draw a building as a hollow shell.
Select faces that need thickness, and start the "thick-faces" function.
Label the thick elements "wall" or "floor"(and holes as window/door).
Export to IFC(or maybe even better, sync with bimserver.org)

Wouldn't this workflow be really SketchUp like?

This is how I'm trying to build the next version of my bim-tools plugin. I've got something basic working, but it will still be a hell-of-a-lot-of-work to make it fully functional
Topic: http://forums.sketchucation.com/viewtopic.php?t=34007

I also think IFC really is the key! Although it does have it's weaknesses, I think it's the only really open and interchangeable solution we've got.

Cheers!
Jan

brewsky

@bigstick said:

Recently I have experienced an interesting situation which gives me reason to hope (again) that someone will implement a BIM framework for SketchUp using IFC.

I've been thinking on this BIM-framework.
The most simple(simple to implement, simple to agree on to get to a sketchup wide standard) way for cross-plugin usage of BIM data would just be to use Attributes to label SketchUp-objects in a uniform way. This uniform way should lie as close as possible to the official IFC notation.

By example:
you could give every BIM object an AttributeLibrary called "ifc". And then fill it with IFC properties.
The AttributeLibrary for the bim-project(Sketchup.active_model) could get all properties as officially available in the IFC specs http://buildingsmart-tech.org/ifc/IFC2x4/alpha/html/ifckernel/lexical/ifcproject.htm

AttributeLibrary "ifc" for Sketchup.active_model could contain:

IfcProject_GlobalId = Globally unique id number for the project(even after exporting en importing)
IfcProject_Name = Test Project name
IfcProject_Description = Test Project description

http://buildingsmart-tech.org/ifc/IFC2x4/beta1/html/ifcsharedbldgelements/lexical/ifcwallstandardcase.htm
AttributeLibrary "ifc" for a wall group(or component) could contain something like:

IfcWallStandardCase_Name = Wall name
IfcWallStandardCase_Description = Wall description
IfcWallStandardCase_IfcQuantityLength_width = 300.mm

Every BIM-plugin can then add and read possible labels according to the agreed standard.

Please comment....

bigstick

I think the 'thick faces' approach sounds great!

There are a number of ways you could create them though. Tools which specifically create the wall and slab objects would automatically set up the relevant tags/labels sound to me to be the most efficient solution.

However - ultimately there may be more complex wall types to build though. Angled, curved, stepped, tapering walls are all not that unusual. It may be that the 'thick faces' approach won't quite work with stepped, angled or tapering walls. If you could maybe allow each wall to be created in native SU geometry, and made into a group and tagged with an attribute, it gives you the benefit of modelling however you want, with flexibility to do pretty much what you want.

If you extended the attribute tagging principle and defined an open schema, any of the plugin authors here could build an integrated set of tools for all sorts of BIM elements, based on some of the plugins that they already have. A true community approach!

Someone would need to create an IFC export script though.

I have just checked out bimserver, sounds great! Would it work with large/complex models?

brewsky

@bigstick said:

I think the 'thick faces' approach sounds great!

There are a number of ways you could create them though. Tools which specifically create the wall and slab objects would automatically set up the relevant tags/labels sound to me to be the most efficient solution.

However - ultimately there may be more complex wall types to build though. Angled, curved, stepped, tapering walls are all not that unusual. It may be that the 'thick faces' approach won't quite work with stepped, angled or tapering walls. If you could maybe allow each wall to be created in native SU geometry, and made into a group and tagged with an attribute, it gives you the benefit of modelling however you want, with flexibility to do pretty much what you want.

You are right, for new geometry a button "create wall" would be best, that could create the geometry AND add the labels. But the reason I think the approach of selecting faces would also be great is with complex shapes and for upgrading an existing design to BIM. Check the example image(made with my demo plugin, still need to solve corners)

@bigstick said:

If you extended the attribute tagging principle and defined an open schema, any of the plugin authors here could build an integrated set of tools for all sorts of BIM elements, based on some of the plugins that they already have. A true community approach!

I would like that very much! Some opinions from other plugin developers or IFC experts would come in handy!

@bigstick said:

Someone would need to create an IFC export script though.

I'm also working on that, the previous version of my plugin DOES IFC export, but it only makes walls and windows.
For the future version I would like to work together with http://ifcopenshell.org/, if that works we don't have to build the full IFC framework in sketchup/ruby but just the translation to SketchUp! And even better, all contributions to that project would also be usable in blender and the like!

@bigstick said:

I have just checked out bimserver, sounds great! Would it work with large/complex models?

bimserver.org is a great project! I think it does work on large models because the principle is simple, as far as I understand it.

TIG

To make separate 'solid' 3d sides look at the shell tools by Jim and Thomthom [also Fredo's JointPP].
You'll get the two 'shells'.
Then you find all of the vertices of one and find the nearest corresponding vertex of the other Draw edges between them and add faces to the internal partitions.
[JointPP can do this for you with appropriate settings].
Then separate out each pair of faces and their edges as '3d facet - distorted cuboids' - each in their own groups/instances...
Erase the original geometry.

brewsky

@tig said:

To make separate 'solid' 3d sides look at the shell tools by Jim and Thomthom [also Fredo's JointPP].

Thanks! I'll check them out.
The way I'm building it right now(even the parts in the image are no push-pulls)is:
Get the plane of the "base"-face, offset this to bottom and top, calculate a perpendicular plane for every edge(and I need to improve this to "half the angle" between this and the connecting face). Then intersect the planes and create vertices(and faces) on the intersection points. That way I think I can generate the entire geometry in one go.

What do you think? (I hope my ramblings make sense )

TIG

JointPushPull copes with adding thickness to a 'shell'. It can also copes with adding internal partitions ['sides'].
You just need a way to extract the 'parts'...
Good luck

Pout

brewsky and others

Based on your comments, there are two possible pathways:
BIM as in: be able to attach BIM properties and parameters to an entity. That's it, these parameters do not influence the entity when changed.
BIM as in: when changing IFC parameters/properties teh entity is changed accordingly, even more, when adjectent entities are influenced they also change if needed (bit like Revit)

As you can see, the first option is easy, but what is the added value?

brewsky, can you pm me your contact info, I'm located in Belgium, maybe we can have a chat.

brewsky

@pout said:

Based on your comments, there are two possible pathways:
BIM as in: be able to attach BIM properties and parameters to an entity. That's it, these parameters do not influence the entity when changed.
BIM as in: when changing IFC parameters/properties teh entity is changed accordingly, even more, when adjectent entities are influenced they also change if needed (bit like Revit)

I agree, the more information you've got, the more usable it becomes...
This goes for every bim-plugin, but also for a basic common framework...

But even if you just have 4 labels; "width=100", "length=6000", "height=3000", ifctype="IfcWallStandardcase" AND the default sketchup information of a group/component; "placement point" and "placement vector", can tell you a whole lot about the wall!

The more "standard definitions" we as plugin builders can agree on, the better it gets. You could even agree on a basic Sketchup::Ifc module that contains a few classes for maybe ifc-export/import, generating globally unique id's(guid) and managing ifc-units...

bigstick

The added value of the first approach, is that SU can be integrated into an existing (or new) BIM workflow.

So users can use SU in conjunction with Revit, Microstation, Archicad, Vectorworks etc.

TIG

On the question of 'GUID'... like
af8f4bfc-2604-43ec-acf1-489b153db0d6
To make a unique GUIDs I'd use a method that does something like this:

def new_guid()
  guid=''
  (0..35).to_a.map{|a|
    rand(16).to_s(16)
  }.each_with_index{|e,i|
      e='-' if[8,13,18,23].include?(i)
      guid << e
    }
  return guid
end

The reference you get from guid=new_guid() is now a unique GUID following recognized standards for any GUID...
You should never get two the same!

brewsky

@tig said:

You should never get two the same!

That sounds great! When i saw the guid guidelines for IFC it looked like a difficult thing to get to work on both Mac and PC... There seems to be some kind of standard, made by "open group"?
http://buildingsmart-tech.org/implementation/get-started/ifc-guid
http://buildingsmart-tech.org/ifc/IFC2x4/alpha/html/ifcutilityresource/lexical/ifcgloballyuniqueid.htm

But if your method is equally random(and i don't really see the difference between one random string of characters and another) it should not be a high priority task to try and make an "official" guid...

TIG

My GUID example was a general one [as required for Revit .addin files etc] - a typical type of 'Standard' [DWF] GUID.

DWF GUID = 60f91daf-3dd7-4283-a86d-24137b720ed1
IFC GUID = 1W_HslFTT2WwXj91DxSWxH

The IFC GUID is 'identical' to the DWF GUID in Revit.
It is simply encoded in a different format to create a shorter text representation to save a few bytes in a text-based IFC file.

The simplest way of making a random compliant IFC GUID text string is this:
guid='';22.times{|i|guid<<'0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz_$'[rand(64)]}
giving you id's like
puts guid >>> O8lUvCXkuWi1_9ntMidtBk
or perhaps
Y25qn6yMgfCFj9yD$nPhgY 7FBtUWbd28V7Xn3D_20fCm _Rjg3mwn1Ev_PHtYfByEQh
etc
Note also how IFC uses _$ and not the expected +/ Base64 standard as the last two possible 'numerals'...
You can invent a way of translating between the two... BUT I can't see why you need to [at this stage] if the IFC format is the intended medium used to swap data - use the same code for both the SKP guid's and the IFC ones ? Comparing 'strings' is slower in Ruby than numbers, so converting a number SKP guid to an IFC one might be preferable ?
So convert the 16 digit integer [perhaps made from ((rand+Time.now.to_f)*1000000).to_i ?] [Bignum] SKP guid to a string, then an array, then pack it using 'm' to make it base64 [string], adjust non-compliant characters in it to suit IFC _$.
(eval):155
` ifcguid=2223334441110009.to_s.to_a.pack('m')[0..21].gsub(/[^0-9A-Za-z]/,'_')

MjIyMzMzNDQ0MTExMDAwOQIn the other direction reverse adjust the IFC base64 string and then unpack that string again as 'm' back into an integer [Bignum]... skpguid='MjIyMzMzNDQ0MTExMDAwOQ'.unpack('m')[0].unpack('q*')[0].to_s[0..15].to_i
3761687883756483` finally adjusting it back to 16 didigts...
Or something along these lines ?

d_e_x

@pout said:

Based on your comments, there are two possible pathways:
BIM as in: be able to attach BIM properties and parameters to an entity. That's it, these parameters do not influence the entity when changed.
BIM as in: when changing IFC parameters/properties teh entity is changed accordingly, even more, when adjectent entities are influenced they also change if needed (bit like Revit)

@brewsky said:

I agree, the more information you've got, the more usable it becomes...
This goes for every bim-plugin, but also for a basic common framework...But even if you just have 4 labels; "width=100", "length=6000", "height=3000", ifctype="IfcWallStandardcase" AND the default sketchup information of a group/component; "placement point" and "placement vector", can tell you a whole lot about the wall! The more "standard definitions" we as plugin builders can agree on, the better it gets. You could even agree on a basic Sketchup::Ifc module that contains a few classes for maybe ifc-export/import, generating globally unique id's(guid) and managing ifc-units...

@bigstick said:

The added value of the first approach, is that SU can be integrated into an existing (or new) BIM workflow. So users can use SU in conjunction with Revit, Microstation, Archicad, Vectorworks etc.

The solution is to associate "parametric modeling" with the "generic 3D modeling" offered in SketchUp. And then, maintaining a "behind-the-scene" analytical model with SketchUp's graphical model. In this case, the "parameters" associated with the SketchUp entities can be stored internally with the entity. When you change the entity, these parameters are adjusted automatically using entity observers etc. and visa-versa, the graphical output is adjusted if these parameters are changed.
Then, when you import/export IFC data into the SketchUp model, you can simply modify these internal parameters, hidden inside the SketchUp entities; which will consequently and automatically change the graphical model in SketchUp.
To me, changing adjacent entities is the next natural step in the development cycle. It is an enhancement to the above work-flow; but first, (1) and (2) need to be bolted in solid!

Dex
http://forums.sketchucation.com/viewtopic.php?f=323&t=41840

bigstick

The problem with parametric modelling is that you are adding another layer of complexity, which may never have been part of the original plan. The big drawback to it, is that implementing complex features such as curved, tapered or sloping walls becomes almost impossible unless you create typologies for them, together with mechanisms to connect them. It's worth remembering that even Revit didn't have these things in the first couple of versions!

In addition, let's say you have even a simple shape as a rectangular room with a curved bay, it's easy to model the slab and ceiling, but making these both parametric and associative with the adjacent elements is a really huge undertaking. Much, much bigger than simply tagging geometry or building some tools to create appropriately tagged geometry.

There are so many examples of this kind of complexity (floors with holes for staircases are another example) that it is easy to see how the project could get bogged down with making a very complex plugin that can deal with associative geometry, but can only deal with the very simplest of building types! In that respect, it could have very little usability in real world situations. When I played around with version 2 of Revit, before Autodesk bought it out, I found that this was the case for me.

One could deal with some things (partition walls, doors, windows, arrays of joists and framing) with dynamic components, but other elements could be created by plugins, and others built from scratch and tagged. It seems to me to make sense to have more than one way to make geometry, for flexibility.

brewsky

Hi everyone,

I have made a small video that shows the current progress on my bim-tools plugin.
It shows basic ability to create "thick-faces"(filled with the needed BIM-data) from an existing SketchUp model.

http://youtu.be/ozci5OH8Rj0

I think the plugin now has a solid and extendable data-model, ready for the next steps!

A lot of work needs to be done but I would like some comments on things like:

would anyone like to work in this way(draw a model as flat faces(shell) and when a design becomes somewhat "real", select faces that need to be converted to (exportable) BIM objects.
do you think this is a good approach to BIM-modelling? The method differs somewhat from revit and the like
can it be done this way? A lot of difficulties lie ahead(solving corners, conversion to IFC)

Please comment!

Cheers!
Jan
http://forums.sketchucation.com/viewtopic.php?t=34007

P.S. made the video on ubuntu Linux!

pbacot

@brewsky said:

Hi everyone,

I think the plugin now has a solid and extendable data-model, ready for the next steps!

Hi Brewsky,

I don't understand exactly what the video is doing and its relation to BIM DATA, but I like the quick manipulation of shells that is apparent. I think the above statement is most impressive. Is the object a solid. or is the model just "solid", and what is the link to data? Are walls identifiable for further description or something like that?

Great work! Thank you!

Peter

brewsky

Hi Peter,

You are right, the video needs some clarification.

@pbacot said:

I don't understand exactly what the video is doing and its relation to BIM DATA, but I like the quick manipulation of shells that is apparent.

The video shows the first visual part of the re-builded plugin: converting SketchUp faces to builing elements. What's still missing is an interface, and a way to show the created building data.

@pbacot said:

I think the above statement is most impressive. Is the object a solid. or is the model just "solid", and what is the link to data? Are walls identifiable for further description or something like that?

The basic idea is to use pre-drawn sketchup elements(faces/edges) as source for the building elements. Apart from the source-face, a group holding the complete wall-geometry is created.
These are linked through a new building-element-class. The source face remains the basis, and holds all attribute data. This way the geometry can always be re-created from the source.

I have created a set of new classes parallel to the common sketchup elements, among others:

A project-class, that manages a separate library of building elements, and will take care of things like IFC-export.
A planar-class(for walls/floors/roofs, might be needed to add separate classes), linked to the source face and the created wall-geometry. And contains all object data, like width, height, material-properties.
A lineair-class(for columns and other profiles), linked to a source edge and the created geometry.

Cheers,
Jan

fionmacool

@unknownuser said:

The big benefits of SketchUp are its ease of use, affordability, massive user base and thriving community of developers.

Amen to that!

@unknownuser said:

@fionmacool - There doesn't seem to be a lot on your site right now. Are you familiar with Secom's IFC2SKP (http://www.ohyeahcad.com/ifc2skp/index.php) plugin?

Yes I forgot about that one- I have included it now thanks. In relation to the amount of content- I don't have a lot of time to put into it, but the site is just meant to be a means of directing people towards content.

@unknownuser said:

I'm a bit intrigued as to why you had such a negative reaction to what sound to me like very useful ideas. I'm reminded of the famous quote by Henry Ford, "If I had asked people what they wanted, they would have said faster horses."

I am reminded almost every time I mention something interesting that there are vast numbers of people who don't want interesting things to happen.

@unknownuser said:

@mitcorb - I think you have made some very valid points about the formalized input in Revit. It concerns me that the inflexibility of the tools might get in the way of elegant design. I do think SketchUp needs to evolve in terms of its geometry handling because working with large models can be painful, but I don't think any SU BIM solution need be anywhere near as complex as Revit. As far as I have seen, Autodesk buy applications that threaten their business model, then screw them up in an attempt to integrate and rationalise functionality with their existing products.

The business model of high cost software cannot survive. Unless legislation like #SOPA, #PIPA, or #ACTA get enacted and destroy the internet.

bigstick

@fionmacool said:

The business model of high cost software cannot survive. Unless legislation like #SOPA, #PIPA, or #ACTA get enacted and destroy the internet.

Try telling any of the major CAD/BIM vendors that! Despite the whole argument surrounding legality, it's often easier to get pirated software than legitimate stuff. I once ordered an AutoCAD upgrade that took 2 weeks to get an authorisation code for. I could have downloaded a pirate copy and installed it within a couple of hours!

I'm not an apologist for software piracy by any means, but for some companies it actually enhances their market presence. I accept that this is an a controversial thing to say, but if you look at Photoshop, and the cost, and the number of users around the world, the fact that is is the market leader I suspect is down to piracy. Not many people can afford to pay for the full application, yet a disproportionately larger proportion have used it extensively.

So - even in the content of internet piracy or 'copymism' (Google it) these companies still make a lot of money. I'm not advocating software theft (the term 'piracy' is a romanticised euphemism for theft) for a second, just highlighting how considering how prevalent it is, it won't kill high cost software any time soon.

Sorry about that the original response just quoting your previous post! I must have had a timeout (our web access in the office is, let's call it 'variable') which meant that my actual reply didn't get posted when I resubmitted the page.