BlenderBim - Tutorial - Phases - in 20mins
A brief Video tutorial on how to create custom Phases in BlenderBim
This is still a clunky process at the moment but it's the best way I've found some far to get proper 3d and 2d phasing in BlenderBim, this is not really Beginner but it is the simplest it can be explained right now.
If you have questions or anything just drop it here
Comments
Thanks for your deep dive into this work-around.
For the actual work with IFC using different types for different phases shouldn't be necessary and IMHO not even allowed. A 100mm gypsum board wall will always be of the same type, either way if it's existing, newly constructed or to be demolished. I know the schema allows it, but I think an IfcWallType should not be allowed to be assigned a PSET_WallCommon/Status property. At max it should get a Status=Unset property by default. Only the concrete instance should have a Status property.
As for the development roadmap of BlenderBIM in regards to phases this should be one of the objectives - making working with phases not require different types, but derive the visual representation of an element from the status, maybe via view filters / modifiers or something like that.
Hey @doia I agree with most of what you are saying, this is just the current version of the work around hahah.
I expect a lot of people will say the same regarding the Ifcschema and the right way to do it, but phasing is something we need to deal with now haha
This is really to show how to get an expectation of the result of phasing, hopefully we can find a common sense way to simplyfy and align the process with the ifc Schema, in the meantime we work at it
@Ace as always, you've done a great job with this video! :-)
Just 2 sidenotes:
there is also another way (one of many i guess) to archive different colors for different phases, look at the last comments in this discussion.
With this method, it's not necessary to define different material for different phases, because the CSS is responsible for phases styling.
I think that this is more "conceptually correct" but, on the other hand, the method showed in the video is more "robust".
also the class "IfcStairFlight" hasn't the "Pset_*Common" and it is necessary to assign the "EPset_Status.Status" in order to assign the status to an object. I used it for a project because i needed to style a stair as demolished... i mention it here because maybe it's useful for somebody else...
Thanks @Massimo I have literally participated in that convo and didn't realise there was an alternative, I'll see if that process is easy to control, it definitely sounds more aligned with how Ifc should work
And noted on the stairs
So as an update / alternative:
Using this process @Massimo has mentioned
You need to:
1) Set the Pset status
2) And create unique materials/hatch/ patterns for each type
But the downside, as far as I can tell is that all "NEW / DEMO / EX" of the same class seem to share the same hatch pattern generically
so if you have two new walls,
1) masonry (brick)
and another:
2) concrete
they would share the pattern if they have the same Status:
So it seems we lose the fine control of having separate types @Massimo if I'm doing something wrong here let me know
I like to use just the 'EPset_Status' pset, instead of using the various Pset_.*Common Psets. Reasoning here.
As hinted above, I would avoid using different types and different materials, and just stick with a 'status' pset, and change the resultant svg color/fill/etc, with a css rule.
video: https://www.dropbox.com/scl/fi/z1u91b6ip88y6064nvz9y/2024-02-12_10-42-53_blenderBlenderblender.mp4?rlkey=booochfhvsa5q8ohotln332zx&dl=0
I would imagine adding a Pset_*Common with Status=New to each newly created element by default during creation (BlenderBIM behind the scenes action), just like Revit does it with the Phase created = New property. This would keep it schema compliant and thus interoperable, instead of using some unofficial custom Pset.
@Ace well, i guess you got the point ... i tried to archive that but this is the best i can do:
The problem is the fill, if i could change the color of the fill without change the pattern, the problem would be solved.
Btw i think that the problem is only about css/svg so a person more expert than me in this field could certainly help ...
I attached the files ...
It's pretty close to ideal, but we need that functionality. if the tint/colour of the fill could be set in the .CSS file to colour the pattern without having to edit the pattern file it would be ideal
Is it this what you want to achieve?
Hi @Bimlooser
For my local standards we want to see the hatch pattern, not just a block of colour)
Ex = Grey or black
Demo = light blue or grey dashed
New = red or material colours
New material colours:
masonry = red
concrete = green
timber = yellow
steel = dark blue
This is the desired result (for my local standards):
This is what you can get if you use the status at the moment to set the css:
Hi @Ace , too hard for me.
The only workaround to preserve the "ifc compliance" is use another parameter to override the hatch. In this case i've added wrongly "FireRating" but should be any parameter
and then applied to the class the colored hatch (in this case the wood hatch)
Sure more clicks than yours.
I hope it is clear but i'm in a hurry.
I think you've got a good idea though! This is pretty promising, I'll have a go to see how simple this is, maybe we could use the actual material as the reference in the metadata somehow, thanks @Bimlooser
Well you can definitely do this:
.material-concrete.status-new and replace the pattern:
https://stackoverflow.com/questions/3772290/css-selector-that-applies-to-elements-with-two-classes
I still think there should be an even cleaner solution without having to have all fills in three colours though.
I wonder if something like dynamically created css and pattern rules could be developed upon svg creation.
Would allow us to address the problem stated above, as well as a way to dynamically change patterns based on drawing scale, drawing rotation and objects that are skewed or curved relative to the view.
Now it works without the added parameter. Thanks
@JanF thanks, it definitely works! Maybe there is a more elegant way to archive that, but this is already a good result!
@Bimlooser thanks, can you share also the patterns.svg file?
So basically, if i understand correctly, it is possible to add a second class to the material (in this case PsetCommonStatus) and add the relative pattern with the desired style
style.css
.material-brick.PsetCommonStatus-DEMOLISH {fill: url(#brickdemolish); stroke: red; }patterns.svg
<pattern id="brickdemolish" width="3" height="3" patternTransform="rotate(45 0 0)" patternUnits="userSpaceOnUse"><path style="fill: transparent;" d="M 0 0 3 0 3 3 0 3" /><line x1="1" y1="0" x2="1" y2="3" style="stroke:red; stroke-width:0.25" /><line x1="2" y1="0" x2="2" y2="3" style="stroke:red; stroke-width:0.25" /></pattern>and here is the result
i attach also the files
Is the same attached by @Ace
This is definitely closer to perfect!
@JanF What I meant to say is, this is perfect hahaha, you can get just as much control without the added labour of separate types and it works with how the Ifc schema wants it to
I need to remake the video, hahahahah