PoC for an IFC to BREP converter for BIM in C++ (3D, BIM, cli)
- Is a CLI application
ifc2brep-0, written in C++. - It uses IFC SDK.
- The BREP files are in Novorender JSON format.
- It converts "cylinders", "circular arcs", etc [TBC]
- IFC is partially implemented in the PoC: "cylinders" and "circular arcs", enough to convert certain sample files.
Sponsored by Novorender "The World`s Most Powerful Digital Twin & BIM Platform"
- Novorender: novorender.com (on linkedin)
013cbab0ccd3c7fd21 - Sample files are kindly provided by RISA Norway: risa.no
- IFC viewer: Open IFC Viewer
The BREP files will be in Novorender JSON format.
- IFC
ids are used as filenames, e.g.0f7I2_mxX3JOk$Z$4oj$LI.json
- Uses ODA's IFC SDK
i.e. running this
Everything is automated and version controlled, but you ned to have your secrets file
secrets/
├── OdActivationInfo
└── secrets.txt
Curent contents: of secrets/secrets.txt
# ODA IFC SDK
ODA_EMAIL="...@..."
ODA_PASSWORD="...given to you initially during registration "
IFC_ACTIVATION_CODE="a 245-letter code, from the activation process (involves manual & JIRA)"
ODA_SERIALNUMBER="a 42-letter thing that comes orm your Wine64 dir instance"you will need aa 44 letter "ODA hardware code" in the process of activation, but you dont need that here.
The "OdActivationInfo" file should be placed in secrets/OdActivationInfo
The 143-byte file, created by a second process
- registering
- involves your initiation
- receive email with uname pass
- involves receiveing from their servers
- make note of them
- create a jira ticket
- involvs inputs from outside (process: people & servers)
- involved "owrking days": paused on weekends
- involves your initiation
- involvs inputs from outside (process: people & servers)
- wait for their code gievn to you
- use that in the automated process
- involvs outside servers
- involves your continuation (follow-up "tick" step): manual steps (most complex part)
- There is a chance that it may involve struggle with Wine, etc. But I sovled it, so hopefully my mehtod works without much difficulty for you.
- Note that it expires.
- The ODA team is responsive & proactive expired in a month since (since which step?)
- Outcome: a file you put in
secrets/OdActivationInfo
It is not a one-click solution as I hoped, you need to do things manually & initiate some processes, etc, run scripts, etc at a few points:
- clone the repo
- set the volume folder(s) in the scripts ( I use a separate foldeR)
- run the install scripts (including docker build, also: including: docker insallation, and if necessary docker temp fil to be moved)
- scripts/helpers/helper-change-docker-temp.bash
- more details are documented in scripts/init-setup.bash but may need reverse engineering, and, it is not a script, it is a documentation file pretending to be a bash script
- involves x-windows setup (if like me you use remote)
- but I automated it
- but have not reproduced. So the information & knowhow is there, and auomated in a reasonable amount, but I have not proved it to be reproducible with one click, streamlined, verified, etc. This will happen over time by incremental iterations.
- Initiate the whole activation process
- is rate liminting
- can expire
- required follow-up
- setup the LSP too (on vscode) -- so you need to set up vscode too (you an use it remotely, I do it , this readme is based on such a setup that I made it work)
- run the Script(s) that create the .env files
- run the scripts that run the docker thing (needs to have has its docker built. ..., and hence, u-dependency: to docker instalaltion and temp & volume setup (some
mountstep for my d.o. VPS setup ) * you will have two solutions work at the same time, sol2, sol3, (also LSP can be seen as a third one). You will need to switch between them interactively - The compile3 (sol3)
- The run script (Sol2) to test your execution
- You will need to switch between them interactively.
- There you are. Where you (always) wanted to be.
- Possible extention: (for future)
- automate the compile-run cycle
- improvemens on the interactive
- create terraform etc (but will require provider, so it cannot be multi-cloud uni-cloud ./ cross-cloud out of the box)
- Making CI s for it
- direct debugging (for vscode, etc)
- Put the wine into
- combine sol2 & sol3 (may not be a good idea since heavily involes microsoft visual studio installation)
- The no-do s: No CMake ⛔️
- Use / set up conan.io
- some refactoring of scripts (also into a/the framework)
- needs a big cleanup (the whole thing. Hence, the
.version.txt"cleaning (clean-code-ing)" system with its tag system) - automate the orgL aspects
Steps
cd ......ifc2brep-0
./scripts/bash-stub.bash # creates ./env_common.env
# via ./env_common.env
./scripts/wine_init_sol3.bash # runs (and builds) the docker
〉 ./scripts/inside_msvc-wine/compile3.bash
# only once? scripts/wine_init.bash
# carefule: re-creates the wine env (sol2), so shoul dbe run once, beause it can be slow
scripts/wine_init.bash
# Also goes intide the cmd.exe. May run winecfg, etc
# todo: also: mark the resulting.env file as read-only?
# via: env2_sol2.env
./scripts/wine_run_built_exe_sol2.bashPlunge point: Core part to satart looking at (bypass the big overhead)
- Where to look first:
./src/first_ifcapp.cpp
- todo items for toolchain
- docker build logs to be
--plain - docker buildx usage (done), and installation documentation )
- automate fixing of vscode version guards
- docker build logs to be