Drawings & Documentation - Donation proposal
Hi guys,
Last three months I was working on a couple of projects to test Bonsai for professional use in our company.
We still produce many drawings and I must say though much is possible, we're not there yet to completely unsubscribe from you know who ;)
So I wanted to propose a donation project for the Drawings & Documentation part! I intend to oficially start it in about a week or 2.
This is what we think is essential so if you want ot change something or have other things you want to add, comment under this post or paste it directly in the file.
The goal is to have the items of phase 1 done in a year (as much as possible), and create a donation project for phase 2 after that.
Of course if it's completed earlier that would be awesome!
I look forward to your reactions!
and 8 others.
Comments
This is a really great idea. Can you please file individual bugs for each issue? That would allow us to track them, assign them, prioritise them, and most importantly, not forget about them :)
Yes will do! And again, if someone wants to add/change something, let me know!
Nice initiative!
I have a lot i could add. :) But I'll only add one--which is currently a showstopper for me.
Okay, i lied, here's one feature request to add to the list. :)
...
Would suggest using the following funding mechanism. That way, OSArch can match any funds that come in.
https://community.osarch.org/discussion/1741/have-an-idea-youd-like-to-get-funding-for-or-see-realized
Perhaps to get a better pulse of what people would like to prioritize, and thus provide a more potent or attractive campaign, maybe, in this thread, peeps could add one feature per post. That way people can 'like' the post, indicating their 'vote' for that feature.
Like following...
Fixing the ability to tab into annotations.
Join projection planes that are coplanar
maybe Blender isn't the place to 'put drawings together'. An online app and/or desktop app) may provide a better user experience that could even be part of the 'OSArch's own GIT hosting service' also being discussed on this forum. I watched a YouTube video about Rayon (proprietary CAD) and it shows how good online apps can be.
The problem I see is Blender doesn't do Print and why should it, it is not what it needs. But most/many who are working in AEC on Bonsai still need to produce drawings, printed and/or PDF. Our drawings are usually hybrid, bringing together PDFs, vector drawings, images, formatted text, spreadsheets, hyperlinks (within the set and to websites) and so on. These are multi page sets that need to be revised and shared.
I imagine the app could bring together all the external stuff around various views of the Bonsai IFC while allowing the user to design room labels, opening schedules, QTOs etc. while sourcing content from the IFC data. Perhaps IfcAnnotation objects could be formatted in the app producing the users preferred 'look and feel'. Maybe that sort of formatting could be a node-based process providing an easy set of office standards.
It's sort of like the Sketchup layout thing but liberated ;)
@Nigel
I was about to write the same :)
for those who do not know Layout, it's a sister app that can be called within Sketchup and allows editing of output pages where views from SU can be imported, scaled, and syncronized, allowing quite a nice editing of the.. layout with lines, styles, text, hatches, tables, etc.
It would be a game-changer to have something similar in Blender/Bonsai, I don't know if it's possible to hack Inkscape to get something similar?
cheers
I belong to the other group that abhors a disjointed workflow, but as long as your proposal keeps both apps in live sync, that should be fine. Otherwise, the current Bonsai ---> Inkscape --->Bonsai ---> Inkscape fragmented workflow is Stone Age and irritating. Or maybe I am spoilt and have not successfully purged out all the Revit in me :).
@Owura_qu
:)
Layout allows import of "viewports" from SU that live dynamically (icon to press) in the document, not sure it can be actually implemented in Bonsai/Inkscape but who knows..
Was going to post a big long comment arguing, but realised it was derailing the intent of this thread. Instead I'll post a feature I'd like:
Have a crease threshold
With an emphasis on my comment.
This sounds like a great initiative, I'd definitely be wiling to chip in.
I'm on the same bus, the least "jumping around" several applications the better, but I have to admit I have a hard time imagining Blender having decent page layout capabilities. Not saying it is not viable, but It'll probably take some effort.
If we could somehow extend the IFCOpenShell web interface to include page layout and organization UI, maybe would be acceptable., those are as far as I know always in sync already.
Me too!
Yeah I also believe having everything in one place is better then to have to use 2 different programs. That supposedly are working together perfectly. There is room for documentation etc. in the IFC Schema and the basics/intermediate drawings are already possible (e.g. look at drawings by @theoryshaw , amazing!). With everything in Bonsai/ IFC you can save / send the model and see the complete building/picture, drawings included. This is the goal of IFC right? Complete interoperability?
The less dependencies the better ;)
However I do understand that for now it might be hard to go for a complete drawing module in Bonsai itself and that other programs are (far) more advanced. So using a live sync or something might be better for now so you can make use of their strengths, but I believe the goal should be to fully integrate it into Bonsai itself...
Seems like you put together what I wanted to say (but forgot to post) very well ;)
Okay after quite some time an update!
The table below is the updated version of phase 1, with the corresponding issues (as @Moult suggested). I've waited waay to long to do this but these have finally been posted as individual issues ;)
Now for the funding part: I'd like to do it via this initiative as @theoryshaw suggested https://community.osarch.org/discussion/1741/have-an-idea-youd-like-to-get-funding-for-or-see-realized.
So the project write up is a bit hard as there are multiple issues and some are way harder then the others. The first will be the biggest I believe so a deadline of 6 months from now might be adequate? Too long might just result in postponing ;)
For the others, I hope to contribute myself, like #6426, and also that other people contribute to these problems.
Maybe somebody has a good idea for funding these solutions relative to how much work they cost or something?
I'll post the other phases as seperate issues and donation if this initiative gets off the ground!
Of course feel free to suggest other items you want to see in this series.
For now our company will start with a donation when this is live on opencollective ;)
Cool, i'll set up these projects, in our open collective site, in the next could days or so.
Awesome, thanks!
Okay I created individual open collective campaigns for all these projects:
See link inside each github issue: https://github.com/IfcOpenShell/IfcOpenShell/issues?q=sort:updated-desc author:jes-r D&D Phase 1
Thanks, made a donation for item 01. Hope it helps
Awesome!!
Great to see this taking shape. Also made a donation towards item 07, will probably do more in the future
A number of these bugs probably need careful consideration on how they're implemented as they could be part of a bigger system.
I'd like to investigate a few avenues at least first before figuring out what a longer term solution is: Blender, Inkscape, Web, and Other. Ive reached out for inkscape https://mastodon.social/@thinkMoult/114230927580652602
From what I gathered, SVG
<path>elements have anacommand to describe ellipse or circle arc segments. As far I'm aware, Inkscape doesn't support editing those, and under certain circumstances they may be lost (converted to bezier) when saving as an svg file, and also don't translate to other formats like DXF as far as I've seen. Even SVG<circle>elements are converter to splines when exporting DXF. See example at Mozilla .Not sure if this is an incorrect assumption of mine, but could this be problematic for us if we intend to use Inkscape as middleman to get data out?
Arcs and circles are desirable for technical data, because the have an explicit center point, and a radius/diameter property, whereas a bezier based approximation do not. Centers, radius and diameters are important for annotation purposes, as well as for machining and fabrication.
@Moult, Mentioned using metadata to get certain data for annotation purposes in another thread
Would that data only be available as drawing metadata, or could it be preserved in the geometric representation itself if we go through Inkscape?
Inkscape is only a possible editing mechanism, it has no impact on the data we store or generate.
@Moult said:
True of course, better a good working solution that takes a little more time than a bad quick one. Though I believe fixing these problems could greatly help Bonsai as an complete and professional tool, appealing to (much) more people! Like if the drawing view in Bonsai would be fixed, this would make it way easier for newcomers to learn this tool.
Use cases
In my view there are three use cases to this:
1. 2D drawing annotation (showing other people what the dimensions are)
2. 3D Design tool (input/output for the designer when moving stuff around)
3. 3D coordination (in a meeting looking at the model, showing someone distance between some objects)
Examples
Bonsai
Achieving #1 Lvl 2 and #2 Lvl 2 (as Revit has) is almost impossible (neither building a complete modelling UI in the web interface nor WYSWIG in Blender viewport is realistic)
For designing by hand is #2 essential. Right now if I want to set my corridor to 1300mm I have to add a dimension, calculate the difference, move my wall, move my dimension.
My typical "KISS" (*) approach would usually be something like :
(* keep it stupid simple)
As I can't remeber complex sophisticated Tool Workflows or Short keys across Apps - or in general.
Mostly 3D only here, never really needed/created serious 2D Plans ... so likely off topic ....
Where do Dimensions really belong to, Model or Paper Space ?
In 3D (Model Space), associated Dimensions, that work both ways, are great ! (but reliable ?)
Move the Wall and the Dimensions updates. Select the Dimension Value and a reference point - set a new Value - makes the Wall move .....
If I got that correct, in some Apps, Dimensions in Paper Space, means in the Annotation Space of a Viewport, are meant to be also associative Dimensions (one way). If the Viewport is regenerated/updated, associative Dimensions should recognize the changes and also update !? (never tested that. A miracle for me. Stability/reliability ?)
And there are "temporary" dynamic Dimensions to check or edit geometry. In Bricscad, when you select a Solid (by a certain Face), it will automatically offer dynamic Dimensions, which reach to the next neighboring Object's Faces, vertically to that initial Face's Plane. You can edit their values to easily check distances or to enter a new value to move the selected objects.
In 2D CAD you usually have Dimensions in Model Space in their own Layer to control visibility. In 3D (better typical 2.5D BIM Apps) with generated Plans, you may often have them in Model Space - for Top Plans, while for Sections and Elevations you often need them in Annotation Space anyway.
Changes in Model in a pure 2D Workflow and correcting all Plans is tedious. But I think deviations in 3D generated Plans Annotation Layers is at least as much error prone to keep in sync.
Even Dimensions alone are already a quite complex thing.
So I would agree to :
Where need generated Drawings to reside, inside or offside the BIM App. Is it easier to keep both Apps and Data in sync or to offer needed features in the main App. I have no clue but think both is not totally unlikely.
There's also a view concept in all modern Bim applications and this is exactly where annotations sit. So you have a single model, which is referenced in multiple views, which are annotated and put on layouts.
this is a little off topic but important (IMHO) to structure thinking about developing drawing outputs. Also, it is no criticism of anyone using these terms. Now the preamble is out of the way :) I think we could drop terms like 'Model Space' and 'Paper Space', reasoning is these terms can frame and restrict our thinking to just mimicking other software like autocad. We could think in terms of inputs and outputs, the former are plans, sections and elevations if the Ifc 3D, spreadsheets, images, dxf (and other vector files) PDFs etc. and the latter (the output) is PDFs, Images, dxf (and other vector files). I hope I'm making sense?