Mats_Knutsson wrote:thx for testing trapezoid corner window we use it in everyday practiceRob wrote:egg-sack-tli
I do not think you are answering Mat’s point here and that is: How to implement the free-form modeling into a BIM model. Yes I agree that you do not have to be ZH or FG to find yourself in a need for free-form shapes. The question is how to implement them. Should we have a free-form modeling mode with dumb (in terms of BIM) surfaces (aka Revit) or tool based free-form modeling methods?
Personally the first one is not the way to go - there are much more sophisticated applications for this - a good parallel would be GS’s aspirations to make Plotmaker Illustrator-like (or desktop publishing -like) software. They had learnt their lesson that the scope for this is far beyond the purpose of their software.
Second option based on tool modeling enhancements is more appealing (at least for me) as it preserves BIM ‘awareness’ of a created object. However this option will be facing inevitable limitations because of its very principle - eg. a slab cannot behave (meaning symbolic plan presentation, dimensioning, listable properties etc) like a wall even if they are modeled to the very same shape. The only complication but the fundamental one is that basic AC tools (slab, wall, beam etc) have to accommodate symbolic representation which does not always work with free-form shapes when they interact with surrounding elements as apposed to library parts which are self-contained and isolated blocks on a plan.
Just to shine some light on the difficulties with "BIM"-objects.
We're currently testing trapeziod corner windows with the GS programmers and even that seemingly simple object raises complicated constructional issues since it can be solved in so many ways (IRL that is and BIM modeling should be like IRL). It's pretty simple to make it "manually" but would be more BIM to have one object.
Concerning simple "non-BIM" objects I agree totally with Bricklyne and I would also like a Maxon-like tool set integrated and with AC UI.
I know AC13 will, amongst other things, continue to bring improved workflow (how boring does that sound...however professional) that will shorten the time from start to finish = money/time in your pocket.
/Mats
cmon, thats last thing that i wish to be in AC13
Put maxon like tool and i will shut up
As i read i can see that BIM is limiting u and something that sould give us better workflow is now stoping u to develop new features... I dont want all to be BIM. It dont have to be 100 % BIM...
I agree u can develop walls, beams, windows, doors, roofs etc in BIM
but give us what we ask for, not what u think that we need, kapishi
As i read i can see that BIM is limiting u and something that sould give us better workflow is now stoping u to develop new features... I dont want all to be BIM. It dont have to be 100 % BIM...Is it enough to be 93.4% BIM for you?
Seriously this is not a winning solution in a long run mate.
... such 64bit to enable AC to address unlimited RAM to load the entire model into memory and avoid all HD access. Full multi-core awareness another. The hardware required is now a realistic option .. the software just has to catch up.Owen, I do not think it is just hardware. I believe that the underlying layer of maths and geometry is already built in AC. I reckon the UI design is a tremendous task - how to deal with 3D modelling in 2D plan/S/E (meaning editing hotspots, methods, material mapping and whatever you can think of). Each individual instance has to be addressed carefully. A good example would be CW - I hate the fact you cannot edit it on plan and I can tell you GS would be probably the happiest punter among all of us users to get it done just to avoid all that abuse we have given them for this (which I have done with a pleasure and satisfaction at the same time
). The point is that apparently there is a big problem to solve 'duality' of architectural representation with current AC resources.Revit tries to solve this problem by introducing a large number of dedicated building element tools. Again, I am not sure if this approach is the good one either.
I'm not saying it is just a hardware problem ... but as i see it AC has always relied on 'workarounds' to represent 3D elements in 2D (mainly plan views) without the overhead of having to calculate their true appearance in plan relative to the plan view point (FPCP recently). This was required as the hardware just wasn't up to the job of calculating all this model information in real-time. It still probably isn't quite there (soon) and even if it did the software itself has to be able to make use of it.
Traditionally AC has made pretty good use of the hardware resources available to it, however we are now at the point where the hardware is rapidly pulling away from what the software is capable of using (i.e the RAM limitation and multi-core support). I think this means many of the hardware capability issues AC developers have faced are now significantly reduced and are doing so quicker than GS can react to them.
I do understand that the UI itself would potentially be a much bigger thing to resolve than getting AC performance to scale better with hardware capabilities. But i think my point is that if the underlying AC engine is overhauled so in X years it will make full use of my 128GB RAM, 64-core machine, then many of the hardware/software performance-based design constraints they previously had to deal with when designing the UI will become increasingly irrelevant. A relatively clean sheet of paper if you will.
But i know, if only it were that easy ..
PS. Its good to know we have people like you involved in the GS development process 'telling it like it is' ... even if the results do make you wonder if they have their ears open
Traditionally AC has made pretty good use of the hardware resources available to it, however we are now at the point where the hardware is rapidly pulling away from what the software is capable of using (i.e the RAM limitation and multi-core support). I think this means many of the hardware capability issues AC developers have faced are now significantly reduced and are doing so quicker than GS can react to them.
I do understand that the UI itself would potentially be a much bigger thing to resolve than getting AC performance to scale better with hardware capabilities. But i think my point is that if the underlying AC engine is overhauled so in X years it will make full use of my 128GB RAM, 64-core machine, then many of the hardware/software performance-based design constraints they previously had to deal with when designing the UI will become increasingly irrelevant. A relatively clean sheet of paper if you will.
But i know, if only it were that easy ..
PS. Its good to know we have people like you involved in the GS development process 'telling it like it is' ... even if the results do make you wonder if they have their ears open
Rob wrote:Rob, it's the ultimate dream - the app that reads my thoughts and formats them in a buildable way without me having to enter anything but the fun part! It's really what we all want, in the end.Try to implement BIM functions to a free-form app. Visualize Rhino with archicad's plan- section representation, story handling system and scheduling functions. That would be tempting.Petros, this is the actually the most difficult way how to do this. How would you extract all this information from a blob of play dough which the model in Rhino or similar virtually is? how would you identify, transform and chop up whole model to pieces which make a sense to a builder / subcontractor / quantity surveyor etc? It would be a tremendous task to address this with current UI. Do you really think this would be possible over one, two or even more years of development? ... and actually can you give me an example who has done it successfully? You have to be kidding yourself mate. We do not have finalised tools for a simple documentation in AC12... get real.
Still looking?
