Onko Autodesk herännyt?

Maailmassa tapahtuu kummallisia asioita.

Kummallinen asia 1:
Navisworks 2014 osaa lukea IFC-tiedostoista värejä:

Hienoa. about 8 vuotta siinä meni, mutta parempi myöhään kuin ei milloinkaan.

Kummallinen asia 2:

Revit 2014 tekee välillä hyvää IFC:tä kustannuslaskenta- / energialaskentanäkökulmasta (spaceboundaryt melkein ok)

Kuulin, että käytössä onkin add-on Revitin päälle (ei siis revitin mukana tuleva ifc-export), jonka toimittaa Autodesk:

http://apps.exchange.autodesk.com/rvt/en/Detail/HelpDoc?id=appstore.exchange.autodesk.com%3aifcexporterforrevit2014%3aen&mode=live

Sitten kuulin, että se on sama softa, jota kehitetään vapaaehtoisvoimin (vrt. blog:

http://tietomalli.blogspot.fi/2011/09/revit-ifc-rajapinta-open-sourceksi.html )

http://sourceforge.net/projects/ifcexporter/

Joo, Autodeskin linkin takana lukee, että on open source, mutta jotenkin on hauskaa, että vapaaehtoiset koodarikaverit linux-tyyppisesti itse tekevät toimivaksi sen, mihin Autodesk ei miljoonillaan pystynyt. Tai halunnut.

Arkkitehdit, ladatkaapa tuo open source ifc-export, niin elämänne ifc-mallien maailmassa helpottuu.

Pitänee kehittää jokin tukiorganisaatio open source -kavereille, ei voi olla pelkää freewarea, hyvästä työstä pitää palkita. Paypal -donaton jos olet tyytyväinen softaan?

Viikon kuva:

Standardin mukainen IFC malli

Nyt on maailmankirjat sekaisin.

Sain viime viikolla toimivan ja periaatteessa kaikin puolin kunnossaolevan IFC -mallin joka meni energia- ja olosuhdesimulointisoftaan (Riuska) heittämällä. Eikä ollut mikään nakkikioski  vaan ihan oikea rakennus.

Spaceboundaryt siellä missä pitääkin, relaatiot melkein kunnossa ja jopa huonenumerot ja tilanimet oikeissa kentissä.

Ja sitten se suurin ihmetys.

Malli oli tehty ja exportattu Revit 2014 versiolla.

Käsittämätöntä.

Revitissä on ollut perinteisesti kaikista huonoin rajapinta - nyt muuttui minullakin prioriteettejä.
Autodeskin miljoonat taalat kehitystyössä näyttävät auttavan - saisivat kuitenkin korjata myös sen, että käyttäisivät kansainvälisesti sovittua tapaa ääkkösten esittämiseen, ne olivat saadussa mallissa hepreaa tms. muinaissanskriittia.

Ihan ensimmäisellä kerralla tämä malli ei toiminut, mutta selvitystyön jälkeen kun tietomallikoordinaattori laittoi Revitissä ruksit oikeisiin paikkoihin, niin alkoi homma toimia.

Eli arkkitehti oli tehnyt mallinnuksen hienosti, vain oikeat export -asetukset ja IFC speksin mukaisessa kunnossa.

Jaa mitkä ruksit? Sitä kannattaa kysyä Tietoa Finland Oy:stä.


Viikon kuva:

Nämä ovat helppoja korjattavia. Menee jakeluun kaikille, että päällekkäin on kaksi seinää.

Kesälukemista: IFC Guide

Eipä ole näkynyt vielä ArchiCAD versiolle 17 tehtyä IFC-tietopakettia, mutta ei se mitään, version 16 ohjeillakin pääsee pitkälle

http://download.graphisoft.com/ftp/techsupport/documentation/IFC/IFC%202x3%20Reference%20Guide%20AC16.pdf

Tässä kaikille kivaa kesälukemista IFC:n hienouksista.

Muistakaa lukea / oppia kaikki mahdollinen space boundaryistä ja niiden tarpeista energiasimuloinneissa ja kustannuslaskennassa.



IFC, energialaskenta, Spaceboundaryt

Hiljaista on ollut bloginpitäjän kirjoitustahti, mutta jotain tekstiä sentään syntyy töissä...

Aika usein kysellään miksi arkkitehdin tekemä IFC ei mene sisälle energiasimulointisoftaan oikeantyyppisesti.

Tässä eräs kokemusperäinen syy asiaan. Kyseessä osa erästä sähköpostia, jonka kirjoitin kun asiaa kysyttiin. Pientä editointia on sisältöön suoritettu:

---

Vaikuttaa haasteelliselta projektilta saada toimivaa ifc:tä ulos energialaskentaohjelmistojen näkökulmasta.

Kun pelataan ifc:n kanssa, niin pitäisi juuri päästä eroon tuosta miljoonasta ohjeesta eri sovelluksille. IFC:n toimivuus energialaskentaohjelmistoissa (huom, ei siis Riuskan, Riuska seuraa IFC:n speksiä) vaatii sen, että mallissa on tiloja sekä ns. SpaceBoundaryt luotuna.

SpaceBoundaryt luodaan ifc exportin yhteydessä automaattisesti sovellusohjelman toimesta. Toiset ohjelmat luovat ne paremmin, toiset huonommin. Jotta SB:t yleensä voivat syntyä, tarvitaan malliin tilaobjektit (Space) jotka ovat olleet "peruskauraa" jo kauan arkkitehtisovelluksissa. Tilan tulisi myös rajautua ympäröiviin rakenteisiin (aika normaali vaade tuokin kun oikeaa tietomallia tehdään). Yleensä sovelluksissa on käsky, jolla "klikataan" tilaa ja se klikkaus luo tilaobjektin siten, että ohjelma tunnistaa ympäristönsä.

Suunnittelu on tietenkin muuttamista, ja kun tämän "klikkauksen" jälkeen siirretään esim. seinää, niin sovelluksesta riippuen se joko osaa liikuttaa myös tilaobjektia tai sitten ei. Ja osa sovellukista osaa kyllä suurentaa / pienentää tilaobjektia, mutta hajoittaa sisäisesti tilaobjektin ja ympäröivien objektien relaatiot (jotka ovat elintärkeitä spaceboundaryjen syntymiselle).

Joissain ohjelmissa on "Space Update" -tyyppisiä käskyjä joka tsekkaa tilaobjektit uudelleen ja luo relaatiot kasaan jne. "korjaa" sisäisen rakenteen kuntoon. Jälleen sama virsi: toiset ohjelmat toimii paremmin kuin toiset.

Eli suomeksi: olemme sellaisessa kehitysvaiheessa varsinkin xxx -firman tuotteiden kanssa, että ark sovellukset eivät osaa tehdä IFC-speksin mukaista ifc-tiedostoa "oikeassa elämässä". Demoilla saadaan homma toimimaan, mutta harvemmin todellisissa suunnittelukohteissa.

---

 

Ym. viestin sanoma on siis se, että kun pystytään tekemään "kerralla oikein", niin IFC-tiedosto tuntuu olevan kunnossa. Kun taas ark mallia käytetään normaalisti, eli muutetaan, viilataan ja pyöritellään tiloja, niin se tuntuu ajan saatossa sekoavan sisäisesti siten, että sieltä ei saada toimivaa IFC:tä ulos. (vaikka olisi saatu esim. jollain alkuversiolla onnistumaankin).

 

Ja toinen esimerkki, joka konkretisoi ark sovellusten ifc-kirjoituksen puutteellisuuden on kerroksellisuus. Spaceboundaryjen kautta ifc-speksin mukaisesti pystytään tutkimaan esim. vesikaton päällä olevat lämpimät tilat (vrt. IV-konehuone tasakaton keskellä). IV-konehuoneen alla olevat tilat osaavat ymmärtää spaceboundaryjen kautta, että päällä on lämpimää tilaa. Ja jos IV-konehuoneen seinä katkaisee allaolevan tilan, niin tilan katto jakautuu kahteen tai useampaan lohkoon, joista toinen on kylmää pintaa ja toinen lämmintä. Tai siis näin on ifc-speksissä.

 

Erittäin harva (jos yhtään?) ark-sovellusta osaa luoda kerrosten välille oikeanlaisia spaceboundaryjä. Eli laatan (lattian / katon) läpi ei tunnu tieto siirtyvän.

 

Minä tulkitsen tuon siten, että softafirmat vasta harjoittelevat SB:n käyttöä seinien ja ikkunoiden kanssa.

 

Taustatietona vielä sekin, että spaceboundary -speksi ifc:ssä on ollut olemassa jo about kymmenen vuotta... voiko joku softafirma oikeasti väittää, että heitä kiinnostaa energialaskentamallin tuottaminen?

 

Kuukauden kuva:

Sinisellä ne pinnat, joiden spaceboundaryjen luonti epäonnistunut (ei relaatiota).

Eli tuo määrä seinä, ikkuna tms. pinta-alaa puuttuu rakennuksesta energialaskentaohjelmiston näkökulmasta.

 

Muutoin kohde on "ihan normaali" mallinnuskohde ja navikset, bimsightit jne. pystyvät käyttämään mallia ongelmitta, koska niitä ei spaceboundaryt / relaatiot kiinnosta.

 

 

 

 

 

IFC iPadille

Kaikkien omenahärveleihin perehtyneiden kannattanee seurata firman SVSinnovations kehitystä.

Firman taustalla on vankkaa markkinaosaamista sekä riittävästi propelipäitä tekemään ratkaisuja, joiden uskon olevan todellakin innovatiivisiä firman nimen mukaisesti.

http://www.svsi.fi/

Koska olen vieläkin pystynyt välttelemään Applen tuotteita, en ole päässyt katsomaan, onko heidän iPadille tehty IFC-tiedostojen katseluohjelmisto jo julkaistu (pitäisi löytyä imurointipalvelusta, jos kaikki on mennyt kuten Strömsössä).

Demoja olen nähnyt / kokeillut ja hienolta vaikuttaa. Kenties ei ole tarkoitettu rakennuksia suunnittelevalle insinöörille, mutta jos on kiinteistönvälittäjä tai pitää esitellä kohdetta rakennusalaa tuntemattomalle, niin softa on lupauksia antava.

Miksei sovellu suunnitteluinsinöörille...? Siksi, että se on liian hyvän näköinen. Pintamateriaaleja, varjoja, värejä. Ei näitä asioita ketään viitsi / halua suunnittelumalliin laittaa. Mutta jos katselijana on tilan mahdollinen vuokralainen, niin tottakai pitää olla pientä realistisuutta mukana mallin pyörityksessä.

Yksi kokonaisuuden hieno juttu oli, kun minulle demottiin iPhonen ja iPadin yhteistyötä. Pystyt pyörittämään mallia iPadilla, ja kuvaruutu siirtyy verkkoja pitkin iPhonen näytölle. Kerrankin voitaisiin demota tilanne, että urakoitsija on työmaalla ja katselee omaa iPhoneaan (tai iPadia). Suunnittelija pyörittää konttorilla mallia iPadilla (joka näkyy siis urakoitsijan puhelimessa) ja kertoo samalla, että mitä pitää tehdä jne.

Ehkä pieni reality check pitää tässä tehdä, eli että urakoitsijalla olisi ammattitaito katsella iPhonen ruutua (tai että hänellä edes olisi se olemassa), mutta teknisesti tuo on siis jo nyt mahdollista.

Veikkaan, että tämä on muutaman vuoden päästä realimaailmaa.Uskon vakaasti (ainakin vielä) että 3-5 vuoden sisällä tabletit alkavat vallata työmaita. Ei siis siniset pillerit, vaan kädessä kannettavat Win8, Android, iPad -tuotteet.

Hauska juttu tämän softan kehittäjien asenteesta oli se, että kyselin heiltä "Lisätyn todellisuuden" (AG, Augmented Reality) käytöstä softan yhteydessä. Kommentti oli vähän sen suuntainen, että se on jo nähty, ei ole kiinnostavaa.''

Kuten todettua, välillä propeli voi pyöriä markkinamiehen näkökulmasta väärään suuntaan... tai olla liikaa aikaansa edellä.

Revit IFC rajapinta Open Sourceksi

Nyt kuuluu kummia Autodeskin tehtaalta.

Revitin IFC rajapinta on aukaistu ja jokainen pääsee koodaamaan omia lisäyksiä siihen:
http://sourceforge.net/projects/ifcexporter/

Tämä ei ole mikään krakkeriversio, vaan Autodeskin virallinen aukaisu:
“For several years now, our customers have been asking for greater flexibility with the Revit IFC file format output,” said Jim Lynch, vice president, Building and Strategic Technology Group, Architecture, Engineering and Construction Solutions, Autodesk. “The decision to release the Revit IFC exporter code as open source furthers our ongoing commitment to support the IFC standard, and marks the latest demonstration of the Autodesk drive to encourage full data exchange within a Building Information Modelling workflow.”

Suomalaiset "Isot Pojat" latasivat kehitysympäristön - ensimmäinen kommentti oli, että "ei siellä DLL:ssä mitään ollut". No, voipi olla pojat ei vaan osanneet... seurataan mielenkiinnolla kehitystä.

Mielenkiintoiseksi asian tässä tekee myös se, että tunnetusti Revitissä on ollut ehdottomasti huonoin rajapinta IFC-exportissa verrattuna muihin isoihin bim-softiin.

Sanooko Autodesk vuoden päästä, että, "Sorry, ei mahda ongelmille mitään, koska se on open sourcea ja vaikea valvoa jne. käyttäjät ei tee tarpeeksi hyviä rajapintoja..." vai jatkavatko he itse ifc-rajapinnan kehittämistä?

Oletan, että tottakai adesk jatkaa kehittämistä itse, muuten menee pohja pois koko touhulta. Tällä tavalla he saavat hienosti selville, kuka koodari osaa IFC:tä (ja rekrytoida heidät), ja he saavat kenties toivottavasti vihdoinkin toimivaa koodia - ilmaiseksi.

Tunnettuahan on, että AutoCAD Architecturen IFC-kehitystiimi on erillään Revitin IFC-rajapinnan kehitystiimistä. Tai tiimistä on vaikea puhuia, jos yksi kaveri on tehnyt sitä... kohta niitä lienee siis 3-5 kaveria.

Väittäisin tätä systeemiä jopa nerokkaaksi.

Ja voipi olla mahdollisuus jopa siihen, että me loppukäyttäjät jopa hyödymme tästä.

Viikon koodi:

Tämä kuuluu kuulemma IFC-tiedostoja lukevan ohjelman ensimmäisille riville:

"If Revit then End"