ISO10303: IFC exchange format design and usage

Rami // Apr 17, 2012 12:41:36 AM

IFC is one of the oldest standards for data exchange within the AEC industry. It became one of the most supported exchange formats available. Using a standard which was started about ten years ago, brings with it obsolete ways for defining objects and exchange files. Example to that is usage of EXPRESS language to define the schema and use of ASCII as the format of the file.

While it is great to have a format that is being adopted by a growing list of publishers, issues with the schema and its implementations makes it hard to adopt and rely on. Below are some of the issues that I guess are mostly visible, and a possible solution to consider!

Highly Typed: The IFC schema (ISO 10303-21) has an object definition for each type of object defined in the AEC industry. This results in a huge schema; instead of having one type of data object. The attributes of the objects are based on the object type, thus producing a complex exporter and reader of the file. As a developer, the highly specific format of the objects makes the specs your best friend while writing a parser, reader or an exporter to this format.

Mapping vs Correctness: This issue is mainly a problem with the usage of the format. The generosity of options in describing a single object or part of objects, is that a publisher usually chooses one path of representation which is usually the simplest to map too or the first option they see (since it’s a huge schema). This has the risk of losing data quality and/or having bad representation of the data. As an example, a circle can be defined in lots of ways: like IfcCircle, IfcArc between 0 degrees and 360 degrees, IfcTrimmedCurve of an IfcArc (between 360 and 0) trimmed at 0 and 360. The last one might seem odd, but I have seen it a lot. The three options give a correct result but it’s an over kill, and in my view wrong. Another example to fast routes taken is exporting all the geometry as triangle meshes losing all the quality…

Readability: There exists an XML version of the format, Part-28, but it’s not much used. ifc file (part 21) format is an ASCII file, where each object is a line by itself. Parent-Child relationship and associations are defined by #object_number that acts as a link between objects, which makes tracking an object in a text editor practically impossible.

Predefined Data fields: each object type found in the file has a predefined set of properties that should be available. The problem with this restriction is that when a publisher doesn’t have the required fields they include bogus data just to conform to the schema of the object, which sometimes makes the whole dataset bogus. This is also found in the required predefined hierarchy of the object definitions. Example: most design systems set the building name to be the filename or some string, when it’s not available!

A call for Conformance Level: Changing the schema is a very optimistic approach, since the time frame required for the industry to support it and implement it is long. What would be nice to have is a test suite where publishers are asks to run to check the quality of the data sent. Then publishers will consider updating their implementations to get a higher ranking on the conformance. In my view, with such test suites we will see less publishers producing files with geometric cache-triangulation (a very common observation) instead of the actual CAD data.




Back from Revision 2012 :) It was a blast to say the least....

// Apr 15, 2012 2:07:06 PM



Back from Revision 2012 :) It was a blast to say the least. I’ve met so many interesting people from all over Europe, I’m still flashed by all those overwhelming impressions. Definitly coming back there next year. As on last years Revision I had again prepared an entry for the PC 4k (executable size has to be <=4096 bytes) called “Hartverdrahtet”. Nearly took me two month to prepare. Technically speaking it’s more or less an enhanced version of what I’ve already done last year, but this time the shader does not only use up every ALU peformance ur GPU has to offer but also goes quite heavy on the texture units to render some nice post-effects (e.g. god-rays). I guess the crowd really liked what I did in 4k, so I eventually placed 1st (take a look at the voting slices). Placing first also got me a little bit attention press wise, thus heise.de and 4players.de mentioned the production (sorry, german only). My buddy tokra with whom I was awarded the “Newcomer Award” last year, also released stg for the VIC20 called “VIC can again” (a new interlaced graphics mode). After Revision I took the liberty of doing some chillout for a couple of days, but stay tuned as I’m currently working on a JOGL port of “Hartverdrahtet” …




Spam incoming :) … another nine fractal bitmap orbit...

// Apr 1, 2012 7:10:22 PM



Spam incoming :) … another nine fractal bitmap orbit trapping variations: #1, #2, #3, #4, #5, #6, #7, #8 and #9. Enjoy!




As I can’t get my fingers off these flare bitmaps, here is...

// Mar 10, 2012 5:38:10 PM



As I can’t get my fingers off these flare bitmaps, here is yet another one in the series …




And here we go with another one in the series …

// Mar 10, 2012 5:34:56 PM



And here we go with another one in the series …




And another one in the Julia-Set fractal bitmap orbit trapping...

// Mar 3, 2012 3:28:15 PM



And another one in the Julia-Set fractal bitmap orbit trapping series …




The logical consequence of my last six postings: Julia-set...

// Mar 2, 2012 8:08:41 PM



The logical consequence of my last six postings: Julia-set fractal bitmap orbit traps. Same codebase as the last six times ofcourse …




Jogl/JogAmp RC6 Beta / Linux Armv7 Builds

Sven // Feb 28, 2012 3:05:42 AM

Besides adding proper Mac OS X support (10.5.8 – 10.7.*, incl. OpenJDK7),
OpenGL 4.2 and latest EGL, ES1 and ES2 extension updates and lot’s of stabilization’s,
Xerxes Rånby and myself worked on a proper Linux ARMv7 support.
Both were able to test on Omap4 (Pandaboard ES), Tegra2 (AC100), where Xerxes also tested on other machines, eg. Nokia N9 MeeGo.

Even though GlueGen and JOGL in general support EGL and ES1/ES2 since 2008 incl. the GL profile selection,
we figured we need better support for multiple GL implementations on one platform, Mesa3D software and the hardware EGL/ES ones.
Without tweaking your default configuration, JOGL chooses the right implementation for the desired profile,
e.g. hardware accelerate GLES2 for the desired common GL2ES2 profile on your mobile device, even though Mesa is installed.

Besides tiny big fixes and workarounds the biggest amount of work was to attach the Linux ARMv7 job to Jenkins.
We use a cross-compile and cross-test environment, where the build host cross-compiles and makes the Pandaboard ES
fetch the artifacts via rsync and execute the tests. Later the build host pulls the results and forwards them to the Jenkins master.

All JogAmp modules are now build for Linux-Armv7,
a test release is made available here.
You may like to try the test Applets.
Note: This week RC6 will be released under the usual location and the above test URL will cease to exist.

I dared to test browser support via OpenJDK and the IcedTea Plugin,
and for some reason .. it just works :)

Please feel welcome to join the discussion.

JOGL on Linux-ARMv7-Omap4

JOGL on Linux-ARMv7-Omap4




JogAmp Release v2.0-rc4

Sven // Dec 2, 2011 9:56:56 AM

After tons of bug fixes and Mac OS X, Solaris and Android platform support
we finally have v2.0-rc4.

Besides many important bug fixes this release supports
Mac OS X 10.6.4 and 10.7.

The Applet browser plugin is also enhanced and validated
on all platforms for FF, Chrome, Safari and IE where supported.

http://jogamp.org/deployment/jogamp-current/jogl-test-applets.html

+++

We have to thank each other for our ongoing support,
bug reports, inspiration and pushing for results.

Thank you.

+++

The following aliasing of URL location has been made,
ie. all are aligned to v2.0-rc4 for now.

http://jogamp.org/deployment/

  • v2.0-rc4 -> archive/rc/v2.0-rc4
  • jogamp-current -> v2.0-rc4
  • jogamp-next -> v2.0-rc4
  • webstart -> v2.0-rc4
  • webstart-next -> v2.0-rc4

Developer downloads at:
http://jogamp.org/deployment/v2.0-rc4/archive/

Git repositories have been tagged w/ v2.0-rc4.

+++

Planned for RC5 so far:

RC5:

  • Maven2 integration (I know .. a bit late it is already)
  • Mobile/Android autobuilds / release
  • More bugfixes
  • Update the graph package

+++

Please join the discussion in our forum.

You may like to comment on this release here.

Cheers, Sven




JOGL Test Statistics (Linux, Windows and OS X)

Sven // Oct 14, 2011 12:27:02 AM

To conclude my today series of blog entries, I thought it might be a good idea to show our automatic test statistics.

Here are the latest good and failed test charts for all platforms:


Test Stats 20111013 All

Test Stats 20111013 All - Errors Only


Test Stats 20111013 All - Failure Chart

And finally the progress on OS X with all tests included:



Test OS X 20111013 Overview


Test OS X 20111013 Count


Test OS X 20111013 Runtime

Besides adding running all unit tests to OSX, we also made sure that it’s performance is now equal to the other platforms, ie. around 4 minutes runtime for all tests.

But be aware that these features will be promoted to the next release RC4,
so you would need to wait or use the autobuilds, see Downloading the latest automatic build.




« Previous Page | Page (5 of 6) | Next Page »