cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 
Modeling
About Archicad's design tools, element connections, modeling concepts, etc.

Will ArchiCAD have a future?

Anonymous
Not applicable
the topic is a partly answer to Mac Pro or Vista for AC and driven by a pain i feel for years and yes, the topic is discussed over and over in this forum.

i don't understand what's the buzz here: "which from the top workstations would be better?"

NONE

i'm not with archicad from the very beginning, it think it was 6 or 6.5.
sure, every next version up to that point has been an improvement. like 7 to 8.1 or 8.1 to 10. anyway- every version was developed in name of TOOLS we use in managing the project- and here we see a small change in actual way how the architects think and create architecture (except for using software for creatting bubble-architecture, and even here the solution within ac is external- maxonform:). things have become better, but..
but i just don't see (am i blind?) that the ac has been developed in the means of hardware specs, thus giving room for these software tools to work smoothly and delivering top experience. macs & pcs has grown, emmm... SIGNIFICANTLY over last 8 years.
the marginal upgrade in tools isn't reflected in upgrade how ac works with your hardware. archaic code.
i just can't stand the attitude from GS here. i mean the lines "we have to revrite code. it's huge task". no doubt it is.
archicadwiki techsupport

• no multithreading
ok, they say it's "partly". why?
(..) ArchiCAD will not be a fully multi-threaded application at any time soon. This is partly because re-writing the ArchiCAD code to support multi-threading is a huge task, and there are areas where it would not cause a dramatic performance increase. Graphisoft will focus on the areas where multi-threading brings the most benefit.
thus you don't need octocore (or even quadro) mac pro "at any time soon", because it's a big job for them. (if i think that ac on 8 cores would use 1/8 of the resources available- ).
• max 4bg ram
well, and if more is in your system, it craches. you have to use the terminal to switch off the "unneeded" ram. ^£%^$£%$
• 32 bit
nuts
Transferring a 32-bit application to 64-bit requires reprogramming even the most basic functions in the software, therefore the change to 64-bit in business softwares will happen at a much slower pace than the rapid change from 32-bit processors to 64-bit processors in the Personal Computer (PC) industry.
so mainly they are basing the answer once again on excuse, that it requres recoding ac + on a bad market practise "aww, the other business software developers are also slow on this". sorry, but that doesn't apply to other apps i use, ie, c4d, maxwell. yes, they are a different profile, but- whatever harware resources i give them- it's been effectivelly used. and that's the reason they REALLY are top software solutions. and the argument that archicad has 100x more lines of code can't be an argument.

and with the upcoming ac11... they've spent another year on writing code which sooner or later must been rewritten. with the intoduction of windoze vista more and more consumers will upgrade to 64bit systems. mac users are there already (+leopard will also be a push to abandon old g4 boxes (multicore g5 pros are still more than great)).
graphisofts advertising and managment has been pretty good, but they now have to consider answers to "i got top vista pc/i got the new mac pro octocore, but my ac isn't getting faster".
they can choose to lie about ac beeing top level software.
they can choose to get more unsatisfied customers by telling true "yes, we have worked only on tools, forgetting about cpus, bits and rams".
they can choose to sit down and rewrite ac12 as multithreaded, 64 bit application, which would give them further enormous room for implementing top cpu&ram intensive tools. those who would still use 32bit computers will have their maximum ac11 version. if he GS says "we don't have that much programmers", then it's simple as it gets- AC DOESN'T HAVE FUTURE. it's a fact. like the latvian saying "ko nevar celt, to nevar nest"- you can't carry what you can't lift.

i hope someday new ac version wouldn't be a hotfix for the previous one.

i'm sorry if i touched some of GS staff personally. i understand that you work hard, but, in my opinion, only such critism would maybe produce not only thoughts about brighter future for all of us, but you will finaly sit down, say "ok, this is the point we stop. and open new page for starting to code the real future AC version. yes, we trash the 20 year old and so beloved code, but that's the only way we can do it". ACT, please, ACT NOW! and take your time, i can live with 32bit AC11 if you state that there will be ac12 after 1.5years costing more, because you had to pay more programmers. i will buy it and bring flowers.
78 REPLIES 78
Anonymous
Not applicable
here a marvelous greek type silogism;))

• those applications who are 64bit multithreaded have (is) future
• graphisoft isn't able to develop and deliver the application ArchiCAD as 64bit multithreaded
• the application ArchiCAD doesn't have (isn't) future
Anonymous
Not applicable
Wow Kroko Balboa

I suppose you are right, towards the 64 bits.
I think you are asking too much for the guys who can´t even make their website alive, let´s say weekly, or monthly...I have seen no news from GS except invitations for shareholders meetings. GS appears to have no time for rewriting codes, or hiring young Hindu code C+ programmers (who are easy going and very cost effective). This european actitude, of beeing so discret and polite is what we will really miss in the very close future. The Revit and Bentley guys are aware of all of this. In two years, it will be impossible to imagine a construction pack which is not fully integrated with side by side MPE solutions like HVAC, Steelworks, Mechanical and all could be used along its own navigator. Take a look at Navisworks Jetstream, there you can see a bright future. Imagine a world of interconected database and clash detection,,this is the trend. Avoid problems prior to construction works. Simulate problems and work it out

Let´s see how Nemetschek guys deal with a noise like that. The oportunity is now. The train wont stop twice...
TomWaltz
Participant
Just wanted to chime in, I agree GS has a LOT of work to do in a lot of areas..
Tom Waltz
Anonymous
Not applicable
TomWaltz wrote:
Just wanted to chime in, I agree GS has a LOT of work to do in a lot of areas..
well, name ANY software that couldn't be better
but the problem with AC is that the BASE is missing. we always can moan about the decoration, but what's the point if it's on dummy base (nowadays 32bit is a dummy for a 3d modelling soft ). the AC is implenting those new tools and i'm just waiting scared when the fundaments of this soft will crash from the load. other way is that GS will apply smart patches/hotfixes to the core (they are doing this allready). for how long? sooner or later (i think SOONER) the max workload the patched 32bit core can take will be reached which also means death for AC, because the soft who doesn't have any more room for development is a dead one. AC has this strong knowledge base of 3d cad, a glorious history, a strong experience, which is that bonus for them to stay alive. yet. but other 64bit 3d cad solutions will be out soon, where AC couldn't compete anymore.
and my speculation about the lack of programmers in GS is that the actual core is so "unexplainable", it sits only in the existing deveopers heads. they just can't swallow the fact that 1) their baby is dying 2) for getting 64bit they cannot use reainimation 3) for getting new group of coders to work with ac, they have to explain the core code. as they can't do it, the only way is to create a new one.
and who is feeling happy about that (another 32bit version, another year in not stepping forward)
the users? no.
GS coders? no.
the GS shareholders? no (mmmkay, they do have short-run benefit from the next version. smaaaart...)

those who answer to the poll that AC is the top- yes, at this point as for tools- YES. plus- that AC glorification aspect and the past...
but as for that future tech aspect (which is the topic here)- NO.

lives that who changes
.....yeah, sadly it's beyond flogging a dead horse at this point. The notion that ArchiCAD badly needs a code overhaul is something that many have been proposing since 2 or 3 versions ago, when its inability to handle basic modelling tasks ( which, hence have to be done through plugins and third-party add-ons, or worse yet, other software altogether) began to become more than just apparent and really more of a hindrance and inconvenience.

MaxonForm was (and has been) a useful (but not great; and certainly not comprehensive) stand-in solution (read: work-around) to some of these problems. but at the end of the day the lack of bi-directional paramatricity of objects created between MaxonForm and ArchiCAD still underlies the fact that a more integrated and native solution is sorely needed.

And nowadays, as this thread has highlighted, the fact that ArchiCAD still can't ( and indeed still will not, for the foreseeable future, from the sound that Wiki article) take advantage of modern hardware technological advancements like multi-core processing to enhance its functions is something of a joke, to be honest. You can't surely tell me that AC can't benefit from having the use of an extra processor or more to concurrently and simultaneously update inactive S/E, 3D windows as one is making changes in the plan view so that when you do switch to those other windows you don't have to sit through those updating cycles that can take ages sometimes - yiou know, LIVE updates? Or you can't tell me that we also wouldn't benefit from much much shorter loading times when you start up ArchiCAD - something which I seriously think can be seriously aided and sped up by loading (of libraries for example) through background processing via additional cores.

To be of the position that only the rendering functions of AC are the ones that should benefit from multicore processing is somewhat naive, if not considerably misguided IMHO - especially with the likes of Revit and Microstation hot on their heels.

I've always been of the opinion that they really really should skip a version release ( something which I'm hoping the Nemetchseck acquisition can make more than feasible now with additional funding), like say, delyaing the release of version 12 ( since it's obviously too late for AC11 now) so as to allow the programmers to completely overhaul the source code from the bottom up, to facilitate vast functionality improvements and enhancements as well as direly needed modelling tools such as with handling basics like NURBS and free-form/organic forms, which are not too entirely uncommon in Architecture nowadays; even in low-end small-scale architecture. Obviously the progam's ability to capitalise on multicore processing and other processor enhancements that modern chips (including video card chips and GPUs) offer, would only further increase chances of this, but what do I know.

I do know that I personally would not mind not seeing ArchiCAD 12 until 2009 or 2010 knowing that we'll be getting a vastly improved and considerably capable and REAL upgrade (as opposed to a "Service Pack" version fixing, or worse yet, completing the new features of the previous version) to the program. And maybe, that's what the poll should really be asking :-

Would you be willing to skip a version release, in exchange for a more or less complete laundry list check-out of most of the wishes in the wishlist section through an extensive source code re-write?
Anonymous
Not applicable
I voted kroko is right, but:
1-the 64 bit is not the biggest issue for GS because software is bisystem, and as we can see (at least in the Windows Camp) now, even Vista do not promote 64 bits, as it suppose to. So until 64 bit computers and systems are a standard we most likely can't expect that AC will be 64 (unless of course GS will decide to continue with parallel development of 32 and 64 bit versions.
2-everybody complains about a week core, but what do we know about it from the programmer point of view? Or what do we know about a core of Revit or any other software? Maybe AC if compared is not that bad. Recently Revit is more just sanded that really evolving. I don't see any huge improvements there either (looks like ADT Team adds more stuff). I know that Revit Team is trying to develop at the same time Revit Structure and Systems, but what kind of excuse is that for Architects? (and to honest - I think GS should start to think about it too - at least to some extent).
3- my ideal situation would be that AC work a little bit like Maya - you have a core of the system and everything else is a plugin/script (even menus). You need just a Architecture set? There you go. Need MEP (or M or E or P) you're welcome. Need structures calculations? No problem. And so on. And propose different directions for small practices (mostly residential - no need of Teamwork etc) and big Architectural firms (essential Team work - networking - backups - administrative tools - RFI's, DD-s, As-builts, etc) That way they could advertise and position AC as a complete solution.
Anonymous
Not applicable
@Miki Woodie:
1) i don't know what you actually meant by "bisystem", but i suppose it's that AC is parly 32, partly 64bit. (?) i don't agree that it's not a big issue. like Bricklyne Clarence said
You can't surely tell me that AC can't benefit from having the use of an extra processor..(..)
tell me what i gain from 64bit 3daxis add-on (it's just an example) if i sits on 32bit core. you forget, that all that 64bit stuff GS have implemented are tools/decoration, which isn't THE CORE of what WE DO AS ARCHITECTS. rendering, 3d viewing is in my opinion is secondary. we draw plans, make sections, place and modiffy doors and windows, copy, drag, multiply, place, calculate zones, calculate shedules, place drawings on layouts, browse through library, load new elements, and that undoubtly takes the greatest part we spend acually working in this application- all these AC core processes. the time you wait that render to finish IS'T the time YOU are working. it's digits then. take a coffee break. but its abnormal, that there's a coffee break after each zoom in/out of A1 drawing. you'll say- take a more powerful mac. my imac and mbp are maxed out, and ANY further upgrade wouldnt reflect in AC speed growth...
secondary- i have always though of architects, that they tend to have above avarege computer resources (while still having low income:)), which results in faster project times etc. so in my opinion, we are in 64bit target group. if i was on pc, i couldn't imagine not buying (or stealing m$ ) xp64, for gaining all the benefits when using fastest software available.
i understand that every one has it's reasons, so no offence, but i see that you are using AMD 64 3200 with 32bit xp. no offence, really. but ask yourself-isn't that because you don't use any 64bit soft. and then- wouldn't it be great to? and then- others are allready using (flying ) in 64bit maya, 3ds max, cinema 4d r10, maxwell 1.1 a.o.
2)
your argument is like GS in the wiki. "we are not bad, because other are bad too." so what that revit sux more badly (i didn't state that!!!;))? does that make AC better? when the latter wouldn't be, ie, revit, vectorworks but "taking advantages of the newest tech". and 64bit multicore isn't that new anymore.

3)
the modules approuch could be interesting. but as i see ac now, it is so tied together. it probably would be more easy on unix (mac os, linux ver) base, where the core services exists, and then used through modules calls. i don't know much about m$, but i think it's totally different approach.
sure, the rendering engine, 3d fluid modeling brushes/ways could be like modules (like addons/filters/brushes etc in photoshop), but the base (plans, sections, navigator, library, layers, pens etc)... i just don't see a way the current philosophy of how project should be done in AC could seperate that. it's all needed to create the project, even the smallest.
but here- your vision of "maxed out" AC is the current ac+modules (structure calculations (i repeat CALCULATIONS done by cpu). tell me, how much memory & cpu would this assign. 32bit 2GB? ain't it LOL?:)
Anonymous
Not applicable
I agree that core development needs to happen. I have enjoyed the combination of plotmaker and archiCad and yet am so annoyed that we now have double rebuild times. Once in the layout and once in the active view. I am not a programmer, but someone once explained to me that archicad's database seems hierarchial one. To pick a view and then wait for a rebuild is very tedious. And then to wait for another rebuild in the layout is nuts.
Rob
Graphisoft
Graphisoft
quite frankly - stuff all that crap with 64 or 128 or 256 bit cores... it's just another attitude of having a better sport car every other year. I do care about tools that make the process of producing arch.docs much easier and automatic. I believe if it was so easy GS would have already changed the code, but knowing something about programming, it's a bloody major operation that requires humongous testing at the level of basic routines etc.
A lot of big companies are NOT going to switch to new super-duper 64bit operating systems any time soon, reason? money, maintenance, networking, early bugs and so on, but it's been said so many times on this forum... I just save my breath... and I doubt you can do sort of 'clean cut' in the code and reprogramme everything to multithreading based on multicore kernel...

1. we need to solve problems in regards to arch. production first
2. eventually change the code slowly to multithreading (and god knows what new technology we'll have in one year time)
3. bugger all the OS with cat names as well as all the windows crap that lasts couple of months and then it's replaced by some a must have upgrade - it's just a bloody rip off.

a long story short - finish half done features and then you can tune and rev up the engine to the latest and trendy binary digit

your poll is a little bit barmy drivel, sorry....
::rk