BCF Support GSoC Proposal

Have some feature requests, feedback, cool stuff to share, or want to know where FreeCAD is going? This is the place.
Forum rules
Be nice to others! Read the FreeCAD code of conduct!
User avatar
bernd
Posts: 8486
Joined: Sun Sep 08, 2013 8:07 pm
Location: Zürich, Switzerland

Re: BCF Support GSoC Proposal

Postby bernd » Fri May 31, 2019 9:08 pm

@Yorik:
we should may be allow to add bcf files to the forum ?
User avatar
hardeeprai
Posts: 167
Joined: Sun May 23, 2010 2:41 pm
Location: Ludhiana, Punjab, India
Contact:

Re: BCF Support GSoC Proposal

Postby hardeeprai » Sun Jun 02, 2019 3:54 pm

bernd wrote:
Fri May 31, 2019 9:04 pm
Normally one can edit a comment of an issue, but it will remain in the history of the issue that the comment was changed.
IMO, this is the desired behaviour.
--
H.S.Rai
User avatar
pPodest
Posts: 71
Joined: Sat Feb 16, 2019 3:18 pm

Re: BCF Support GSoC Proposal

Postby pPodest » Sun Jun 02, 2019 4:01 pm

yorik wrote:
Fri May 31, 2019 6:26 pm
...
But comments should still be editable because you could make a mistake writing it and would want to correct without having to rewrite it all over again.
...
bernd wrote:
Fri May 31, 2019 9:04 pm
Normally one can edit a comment of an issue, but it will remain in the history of the issue that the comment was changed. At least it is the way BIMcollab handles this.
Jep I get your point. For comments it is useful, but without an additional file it would not be possible to store more than the information about the person who changed the comment and the time at which it was changed. Otherwise I think a complete history of every comment would be a bit overkill, but then again I don't really know if people who work with this format extensively wish for such a feature. If that is so I could open a channel to the authors of the standard and suggest this addition.
bernd wrote:
Fri May 31, 2019 9:05 pm
Attached an simple example bcf generated with BIMCollab zoom which contains a clipping plane. If the bcf is reloaded in BIMCollabZoom viewer the clipping plane is restored. The pic shows the clipping plane.

bernd
Thank you very much for your answer on IM regarding the clipping planes. Now the whole story makes more sense to me! Also thank you for the examples provided :)


P.S.: I am sorry for the radio silence since Friday on the forum :/
User avatar
saso
Posts: 1337
Joined: Fri May 16, 2014 1:14 pm
Contact:

Re: BCF Support GSoC Proposal

Postby saso » Sun Jun 02, 2019 4:21 pm

Here are just a few videos for the example of how it is implemented inside Archicad, the "Mark-Up Tools"

https://www.youtube.com/watch?v=yCM5WM4k0XI
https://www.youtube.com/watch?v=r-OzsFADZJg
User avatar
pPodest
Posts: 71
Joined: Sat Feb 16, 2019 3:18 pm

Re: BCF Support GSoC Proposal

Postby pPodest » Mon Jun 03, 2019 12:02 pm

Thank you @saso, this helps a lot!
The first video showed a pop up window for a comment with various controls. I think this would be a better option since it would make the design clearer, although maybe a little less intuitive. I imagine that it would be hard to display a button in the current mockup for viewing an attached viewpoint.
I will come back on this with more detailed mockups. Right now I am still writing unit-tests for the bcf-reader module...
User avatar
pPodest
Posts: 71
Joined: Sat Feb 16, 2019 3:18 pm

Re: BCF Support GSoC Proposal

Postby pPodest » Thu Jun 06, 2019 4:17 pm

Over the last days I was in contact with Matteo Cominetti and Paul Deckers from the BIMcollab Support Team regarding the topic of non schema conform BCF files.
Here a short summary of the answer Matteo had:
He suggested to just expect some inconsistencies with the schemas and that I could contact the vendors directly and ask whether they write BCF file schema conform or if they use some specialties.

Paul on the other hand advised me to use the information I have and don't worrying about stuff that is not conform to the schema. Thereby suggesting that the elements that are not conform should just not be read in, which would bring the disadvantage of losing exactly this data when writing the file again, at once that is.

As both answers were very helpful and much more elaborate I attached both mailchains to this post.

My plan on handling such files, however, is the following: When reading a BCF file I just ignore the parts that won't be successfully validated, as Paul suggested. But every time the user changes the internal state of the data model (adds/updates or deletes some item) the extracted BCF file gets updated too, in place (this approach was already suggested by @hardeeprai in the context of not implementing a save button and instead automatically saving the state every time). This has the disadvantage that the user of our plugin cannot operate on the invalid data but this data does not get lost when the user is finished with his or her modifications. So it still can be imported into the original tool too.
Since issuing a write systemcall every time the user changes something is kind of resource intensive I already design the writing module with batch processing in mind.

Do you think this is a good approach to this whole problem?
Attachments
paul_decker_mailchain02.pdf
(198.89 KiB) Downloaded 13 times
paul_decker_mailchain01.pdf
(198.6 KiB) Downloaded 12 times
matteo_cominetti_mailchain.pdf
(31.54 KiB) Downloaded 13 times
User avatar
yorik
Site Admin
Posts: 11584
Joined: Tue Feb 17, 2009 9:16 pm
Location: São Paulo, Brazil
Contact:

Re: BCF Support GSoC Proposal

Postby yorik » Fri Jun 07, 2019 4:13 pm

The plan looks good. Good conversation with those guys! That might be useful.

I would also say, don't worry about non-standard stuff now, just ignore it. But keep gathering test files, if we see important non-standard stuff that should be supported, we see what we do later...

About not having a save button and saving on-the-fly automatically: There are pros and cons there. This means every error a person would be doing (deleting or modifying a comment for ex) will also be recorded immediately. There should be a way to undo errors. That's the advantage of a save button, if you did something wrong, you cancel without saving. If you implement another way to handle undoing errors, though, that's fine.

I think there isn't really a need for history for comments modifications. But I see the need to modify or delete comments anyway, as you might re-read your comment and find it unclear or wrong, and would like to modify it.
User avatar
pPodest
Posts: 71
Joined: Sat Feb 16, 2019 3:18 pm

Re: BCF Support GSoC Proposal

Postby pPodest » Sun Jun 09, 2019 4:54 am

The actual way I want to implement the writing part of the plugin also has the ability of batch processing. I am thinking of lists that gather all changes made since the last read or write and then write the whole list. The point I wanted to make with the updating is that the plugin adds/deletes/replaces contents in the file directly and does not replace the whole old file when writing. The nice part of the file-updating approach, with the mentioned lists that gather all the changes, is that it also supports "save-button-functionality". Therefore it would just gather all changes made during the lifetime and, at the click of the button, write them all out.

But I think I should explain how the "changes" are represented in the plugin: A change for me is an object of a class that represents part of one XML-File. Every class inherits a member flag that says whether the current object is in its original state, if it was added by the user, modified by the user or deleted by the user. Every object that is flagged different than "original" should be added to the "modification-lists" of the writing module. At some point in time (when the user clicks a button, or some other event occurs) the lists are processed and the corresponding XML elements are added/replaced/deleted.

To your point regarding errors and undoing actions: the updates will not be written after every keystroke of the user, I was rather thinking of instant when the user submits a form, like when he or she presses enter after finishing a comment. If an error was made and he or she edits the comment again then a new updating-write operation would be issued and the ModifiedDate and ModifiedAuthor alongside the comment itself would be updated (in case of the comment now). However, the handling of errors in viewpoints, after they were submitted, is a bit tricky. Because viewpoints are assumed to be not changeable (according to the standard). I still don't have a clear picture of how I might implement the creation of viewpoints in FreeCAD, this will change in the future!

For now I am concentrating my efforts on the writer module :)
User avatar
saso
Posts: 1337
Joined: Fri May 16, 2014 1:14 pm
Contact:

Re: BCF Support GSoC Proposal

Postby saso » Sun Jun 09, 2019 8:13 am

Few bcf sample files are in this project ... https://github.com/openBIMstandards/Dat ... pendomlaan
User avatar
yorik
Site Admin
Posts: 11584
Joined: Tue Feb 17, 2009 9:16 pm
Location: São Paulo, Brazil
Contact:

Re: BCF Support GSoC Proposal

Postby yorik » Sun Jun 09, 2019 5:51 pm

Okay, looks good! I'm not really worried about how you implement it exactly, but I'm happy you have a clear view of the issue.

Browsing through your code now, looks like everything coming along very well, and the code is specially nicely formatted and very readable and understandable by other people. Excellent! Keep that way! :D

I'm also learning a thing or two in python from your code...