Will ArchiCAD have a future?

[Anonymous]

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.

[Anonymous]

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.

sure. is that an excuse?

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

sure. but meantime, why others have done that with a success?

and I doubt you can do sort of 'clean cut' in the code and reprogramme everything to multithreading based on multicore kernel...

sure.

eventually change the code slowly to multithreading (and god knows what new technology we'll have in one year time)

how? slowly? if

and I doubt you can do sort of 'clean cut' in the code and reprogramme everything to multithreading based on multicore kernel...

which further means rewriting from near blank those

tools that make the process of producing arch.docs much easier and automatic

finish half done features and then you can tune and rev up the engine to the latest and trendy binary digit

so you actually do agree that this bit conversation should take place? i just cannot see logic in finishing those tools you need.. and then rewriting them once again and testing them once again. this is not a development, but hotfixing, addoning, patching the product so you feel happy about that on the surface.

quite frankly - stuff all that crap with 64 or 128 or 256 bit cores... it's just another attitude of getting work done more faster, smoother, having ability to push greater workloads on your AC, having real need for a good desktop stack.
you talk about fancy sport cars. right now you are riding outside polished, cilimat controled, max electronized, puff seated, 5.1 audio system patched car with a 110hp 1.6L engine.

[TomWaltz]

Rob wrote:
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 agree that Graphisoft has a number of architectural concerns. At the same time, if I buy a newer computer, I expect my CAD/BIM software to take advantage of the better hardware. There was a time when CAD was thought to be the most demanding of applications on hardware. It's kind of pathetic that Archicad can only use 1 processor at a time when most new machines have at least 2.

[Anonymous]

krokoO wrote:

you talk about fancy sport cars. right now you are riding outside polished, cilimat controled, max electronized, puff seated, 5.1 audio system patched car with a 110hp 1.6L engine.

To continue this analogy, there are plenty of racing cars with 1.6L engines that perform round a track with far more precision and agility than many 5.8L monster V8's. The point is good design and matching of ALL the components (and of course implementing the best technology)

It is true that lots of AC functions (not just rendering) would benefit hugely from the improvements that have been discussed and it is no excuse to say the programming required is too big a job. If you sell a substandard product on the basis that it's too expensive to make it as good as it could be, you are heading towards a dead end.

On the other hand, it is reasonable to say they need time to develop the product, make a commitment to do so within a time frame AND at the same time, keep the current customers being productive by ensuring that you do develop the current product as well as possible.

[Anonymous]

i knew that someone would come up with such analogy about cars;)
you're absolutely right, but none of these cars have 110hp and 20year old design 1.6L engine:)) they are top tech.
anyways
1) we need that supermuscle sportscar with 300hp (and i don't care about my electricity bill- let those 64bit burn) because in AC the physical load (tools) is getting more massive every day. i name- dawing placement in layout with redrawing, scaling- it monsterous load if you have 5 drawings, each containing 4000m2 plan in one A1 layout, plus some of them are rotated etc. YES, this tool is GREAT for printing my project, but give me engine for to run it. i don't think it is the right policy to complect a medium car with top notch weight (and look) discs, if the engine cannot turn them.
2) or we need superligt components to apply to that engine. but this isn't happening- AC gives us top power-hungry tools, none of them are slim. and it should be that way- because those tools just need that power. i think GS slimmed them as best as they could.

If you sell a substandard product on the basis that it's too expensive to make it as good as it could be, you are heading towards a dead end.

YESSSS! thats exactly why i ask if AC has future or dead end is approaching.

and

On the other hand, it is reasonable to say they need time to develop the product, make a commitment to do so within a time frame AND at the same time, keep the current customers being productive by ensuring that you do develop the current product as well as possible.

exactly! but GS in that techwiki link has clearly stated: they don't have resources for that. therefore the question about the future remains. if they have resources only for continuing in the way they are now then "you are heading towards a dead end."

[Rob]

Quote:
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.

sure. is that an excuse?

do you want to pay extra $$$ just for this to be done in one go? it's not realistic considering today’s prices on the AEC market. You would virtually ask GS (or anyone else) to commit a marketing suicide.

so you actually do agree that this bit conversation should take place? i just cannot see logic in finishing those tools you need.. and then rewriting them once again and testing them once again. this is not a development, but hotfixing, addoning, patching the product so you feel happy about that on the surface.

this is a completely different cup of tea mate - I need to deliver today and I need to use finished tools, speed comes second as you can still time yourself up, knowing the speed of AC as oppose to unfinished tools where you have to rely on workarounds, staff training becomes fucking nightmare and production is about compromising on standards of a hand drawn documentation - it's fucking ridiculous.

At the same time, if I buy a newer computer, I expect my CAD/BIM software to take advantage of the better hardware

Tom, that is actually stuff I was talking about, racing cars... a bit lame excuse.

Once again I doubt it is viable to switch to a whatever binary number kernel in one go (meaning release) from the price and resources points of view. Yes, we should switch to new kernel but gradually and priority should stay at tools side.

[Bricklyne Clarence]

Rob wrote:
do you want to pay extra $$$ just for this to be done in one go? it's not realistic considering today’s prices on the AEC market. You would virtually ask GS (or anyone else) to commit a marketing suicide.

Paying extra $$$ for a clearly better product is an inevitability of any successful business model - whether it be in one go or over a long period of time. And the suggestion that it be done in one go ( and hence skip one of their future version releases) is as a result of the fact that the alternative method ( i.e doing incremental piecemeal improvements over a long period of time via building upon an aging 20+ year old code) is not only beginning to expose its flaws, but more seriously, to outright fail in delivering to architects a lot of the tools they need in their daily practice - tools which, I might add, are readily available ( and have been for the longest time in some of them) in competitor products and other software altogether.

Secondly, it doesn't have to be marketing suicide if it's done right and the software development management is done responsibly and astutely . A clear example of this is McNeel Software's latest release of Rhinoceros v4, which underwent probably the longest Alpha- , WIP and Beta-testing and development phase of any software I have ever seen, as they revamped an already robust program (while still managing to release regular service packs and maintenance releases for Rhino v3 during the same period of time) over an extensive 2-3 plus year period and sought ways to upgrade the program's core to handle a vast array of new functions and tools and fixing any residual bugs from the previous versions. The result is that they now have a program that considerably transcends the "niche modeler" label, it once had and can even be considered an affordable full-featured CAD drafting software ( meaning even more customers not willing to line Autodesk's pockets and hence more $$$ for McNeel), while still maintaining its position as the best NURBS modeling software available. It also probably doesn't hurt that it's probably the most stable and crash-free software (that I've ever seen, anyway) you can find anywhere.

And the kicker;..... like Graphisoft ( pre-Nemetschek acquisition), McNeel is not by any means, a large company with endless financial resources to spare, ( ala the Autodesks and Microsofts which can spend ages on software development for new versions if they wish). They are a small employee-owned company run out of the Pacific Northwest, but with smart resource management allowing them to pump out completely revamped and overhauled software version that challenges and even puts the likes of Autodesk and their AutoCADs and MAX modelers to shame.

Are you suggesting that even with the new Nemetschek resources ( presumably) at their disposable, Graphisoft are still incapable of giving their flagship software a similar revamp and badly needed overhaul without suffering some sort of fiscal collapse? I would hope they are better run than that

this is a completely different cup of tea mate - I need to deliver today and I need to use finished tools,

......do you mean finished tools like Profile Manager which cannot do profiles of curved paths ( like say, cornices and baseboards in a curved room) or profiles of sloping elements (like custom roof fascia boards, or maybe even custom stair-rail handles)? Or perhaps you mean finished tools like that modeling juggernaut we all love - Stairmaker - with its unparalleled capacity to model stairs to fit any conceivable situation?
No, wait, you surely must mean finished tools like the ability to model custom yet completely parametric doors and windows without the assistance of GDL programming, and to do so using a graphical visual interface and workflow, the way that architects (and not, oh I don't know, programmers?) think and work.

Yeah, I also need finished tools like those......

....speed comes second as you can still time yourself up, knowing the speed of AC.........

You've got to be kidding....

....Once again I doubt it is viable to switch to a whatever binary number kernel in one go (meaning release) from the price and resources points of view. Yes, we should switch to new kernel but gradually and priority should stay at tools side.

.........because, as we all know, this has worked sooooo well for over 20 years now, when you consider the fact that there are wishes in the Wishlist section for basic bugs and lack of simple functionality of basic tools dating back as far as ArchiCAD 6.5, which have yet to be addressed with any degree of seriousness, 4 versions later. Right.

But then again we do have Add-ons, plugins, and niggling annoying multiple-step work-arounds that need probably two, three or possibly even more, external and completely separate software to do what, in a serious world, ought to be possible to complete from within ArchiCAD.

So I guess we should be fine.

It's not nearly as complicated ( or even as expensive) as you want or are trying to make it sound. Graphisoft have essentially done a similar thing in the recent past, when they released version 8.1, which was essentially a version-fixing version ( from the debacle that was ArchiCAD v8.0 and version 9 shortly afterwards ( which was short on new features but was meant as a performance and functionality enhancing version).

What's being proposed is essentially a combination of the above 2 steps ( don't forget that they didn't charge for version 8.1, so one could assume that they released a full version while losing money - even though it was their fault to begin with), with the key point being that they would be giving the program a brand to engine that would take full advantage of modern processor and hardware technological advancements, that would allow it to efficiently handle all the new features they can throw at it without having to resort to future versions to fix "new features and tools" from previous versions that did not work as expected, as has been the case with a lot of their most recent list of "new features". Again, if a company like McNeel could do essentially the same thing, then there's no way you can convince me that GS, - especially with all its new resources - can't do the same without losing money.

[Rob]

......do you mean finished tools like Profile Manager which cannot do profiles of curved paths

No, wait, you surely must mean finished tools like the ability to model custom yet completely parametric doors and windows

...and revision/issuing engine and simple cross-referencing and door/window drawn schedules and better labels and...

Quote:
....speed comes second as you can still time yourself up, knowing the speed of AC.........
You've got to be kidding....

No, I am not. If you want to talk to your boss about getting (and paying) for new 64bit AC, the first question would be is it going to make our production easier in terms of Q/A, training etc. ...ehm it's faster, ok, how would you quantify the speed in regards to time and money? I do not believe you could. And I am not going to mentioned the fact oh, we need another 30 licences of 64bit windows and server and email exchange and photoshop and... it's crazy.

with the key point being that they would be giving the program a brand to engine that would take full advantage of modern processor and hardware technological advancements, that would allow it to efficiently handle all the new features they can throw at it without having to resort to future versions to fix "new features and tools" from previous versions that did not work as expected

what is the modern processor and hardware technological advancements today? they are already old having said that..the problem with current tools is not the speed but fundamental workflow issues. The point is if we could speed up tools/workflow to the max and then get them upgraded. As you have mentioned Rhino's testing took 3 years but I have to produce some drawings efficiently today and pay the mortgage during that time. Is 64bit technology going to have so dramatic impact to productivity? as oppose to a smooth workflow and training based on perfected tools? What we do in the area of architecture is not the rocket science... Is it not just 'keeping up with Johnses' because they have the magic 64 on their logo?

Recent past has exposed some of the 'aspirations' of AC:
Plotmaker to be a sort of Illustrator - we all know where PM has gone to
Rendering software - it does not work as photorealistic rendering has become completely new profession outside of the architectural world
NURBs modeling - give me a break I need to build it (do not get me wrong I don't like to work on suburban pre-fabricated homes)

it is all speculative theory based on too many unknowns as we don't know anything about
1. Nemetschek resource availability to GS
2. the kernel status

[Anonymous]

Well, if it makes you guys feel better there's a lot of similar talk over on the Revit forums. The developers have said (at least for Revit anyway) that there's no easy way of coding the CAD part of Revit to be multithreaded. Rendering is different -- no prediction required (or at least, not in the same way your CAD app needs). It's apparently going to be quite a challenge to make that happen. But you gotta give the programmers something to do for the next 10 years, eh?

[__archiben]

Rob wrote:
...and revision/issuing engine and simple cross-referencing and door/window drawn schedules and better labels and...

you're right of course rob, but then krokoO and bricklyne also have a valid point too . . . you must feel - as well i and many others do - that archicad's feature development over the past years seems cobbled together and built on top of existing technologies that weren't originally designed to accommodate them. hence they get released unfinished, quirky, inflexible, etc, etc, etc . . . sometimes simply downright unusable.

whether 32 or 64bit code is in question, archicad is in desperate need of a new engine to drive all this stuff - one that's designed to accommodate a proposed feature set well into the future as well as pick up the shortcomings of the current feature set. and for that to happen, well maybe 64bit code should be on the cards . . ?

my own opinion is simply that 64bit is not a "feature", it's just something that has to happen 'behind-the-scenes'. this is pro software and i expect it to perform on pro hardware: don't tell me your problems, just sort it. i don't expect to pay more for it and i couldn't care less how much work needs to go into it.

anyways. something to think about for the next couple of weeks mate.

ben

[Andy Thomson]

Rob wrote:
finish half done features and then you can tune and rev up the engine to the latest and trendy binary digit

Ha do feat, what ar y talki abo? Whe?