Rob Snyder for Bentley hero?

Do we have heroes in the Bentley world?

The inventor of Accudraw C1994 - Rob Brown - was one, without doubt, apparently with much input from MS-teacher hero Keith Little - but all that happened a bit before I entered.

Robert Aish seemed the next star, but somehow 18yrs on his GC is still an unimplimented potential, which maybe Adesk will do more with, since Robert jumped ship. In 2008 Volker Mueller's brief to develop on-the-fly or what-if assessment tools (similar to IES's building energy tools maybe) seemed to me to be an ideal 'generative' use of a GC extended to script non-graphical attributes as well as physical elements. But Bentley seems to have dropped that ball too. Acquisition of Hevacomp is NOT it!

Now, I'd draw attention to Rob Snyder, if everyone doesn't already know; see Rob Snyder's Blog, and http://dagsljus.wordpress.com, and just look at http://youtu.be/kQPxPF-lf5I! This is hot stuff, which if implimented would put Bentley way ahead and answer many of the present grumbles about the multiple fussy, undocumented, geek's-delight, unintegrated bolt-ons that has lately made MS into a fragmented, overweight dinosaur, while competitors race ahead in the useability stakes, for example

Unknown said:
You mean like Revit? Revit DBLink? Revit Ideate BIMLink? etc etc

Mstn has tags, fields, Feature Solids / DDD's variable table, GC, AecoSIM has its DGS, F+P, PCS,PFB.... and they all don't talk to each other. To echo Emil, Bentley needs to round up all those little coders working in isolation and get them working on ONE 'parametric' platform for this stuff. They will probably need to knock up something like Revit's user-parameter-centred change management system... so that when something is changed somewhere... it gets 'revised instantly' elsewhere else. The change management system tests and marshals the updates centrally, and does not rely on each coder to 'manually' dictate the steps from their little module's perspective, which is the same as pre-ordaining that none of them will 'talk' to any other module or tool.

Revit even has a Dynamic Update scheme that organises how third party tools propagate their changes amongs themselves and the host platform.

Back to http://youtu.be/kQPxPF-lf5I, about 14mins in, fantastically wonderful dynamic clipping, such as SpaceClaim and others already have.

Rob writes dense but clear stuff that crystalises what I've been longingly groping towards, or somehow hoped grandaddy MS/AECOsim would already have, when I re-bought-in a year ago.

Bentley pioneers amazing research vision but in the end delivers so little, too late.

  • Yea... but even Bentley does them.

    They don't make easy reading either :-)

    Maybe its about obsfucating the idea enough so that your ideas are protected but you don't give your implementation away for those guys in Outer Mongolia to copy.

  • Dominic,

    Understood. And I was just commenting on the ambiguity of the paper.

    On your comments: “Its very computationally expensive... so why do it?” and “If eveyrthing can be linked to everything else and the user or third party developers are allowed to define their own dependencies... then at some point you need an overarching 'traffic cop' to manage the way things propagate... so that everything can 'revise instantly'.”

    You are absolutely correct.

    I’d like to add…

    If you try and parametrically connect everything to everything else, at some point you move something or delete something and everything goes sproing, like someone opened a box of compresses springs and your design becomes some cubist expression!

    Even if you have the ability to parametrically control things off of any other object, it becomes the designer’s responsibility to control what is connected to what and how. So it’s easy to imagine that the task of assigning parametric controllers could overwhelm a designer. It is better to offer sets of tools, such as a curtain wall object, in which a given set of methods are exposed for the designer to control. I’m not a big believer in the goal of everything being parametric even if it were achievable today. And so often when systems offer automatic parametric, such as the relationship of one wall to another, it doesn’t represent how a designer would build the relationship.

    Don’t get me wrong, I like parametric objects. I just don’t like it when they are arbitrarily assigned as they are on Revit (or even on AECOsim at times although in AECOsim we have a tendency to ignore them because we have other ways of manipulation the objects). When I copy a set of beams 2’-0” (600mm) o.c. I don’t want them individually tied to each other with that spacing, I want them spaced at on center spacing. So parametric objects or method which can be applied to objects in ways that mimic the real world make more sense than senseless parametrics for parametric’s sake. An all-encompassing, all knowing parametric god isn’t likely to be able to discern the heuristics, at least on today’ state of computational capability.

    And if this begins to hijack the intent of giving Rob hoodoos, then please accept my apology!

  • Tom,

    Horses for courses. I think that there is a lot of room for parametric versus dataflow (GC) versus constraints solving (DDD, Civil Cells, PCS, PCM) versus rules-based (D++ or iLogic or CityEngine) versus ArchiCAD's Priority Based Connections versus T-Splines Sub-D's cage modeling versus Siemens/LEDAS/CoCreate's Direct Modeling etc etc to co-exist.

    The problem is that we are faced with the need to manage, control, sculpt more and more information. A lot will need to be given over to 'fly-by-wire'. Yes, the more you automate, the more can go sideways... but do you really have a choice long term?

    Every approach or paradigmn will have its limitations. At some point you will need to change gears. You may start something out using GC to quickly script something in the initial stages is exactly what you need. Or, you may very likely find that the pre-packaged compartmentalised parametric objects that PCS create are good enough for most things... or you may find that the bi-directional constraints solving is the only way to go. You may even find your tasks worth investing in a KBE expert system like D++, and fully automate stuff like Robertson Ceco did with its prefab metal buildings.

    You may not be a "big believer" but that is beside the point if you are developing a 'platform' tech like Mstn. Revit and others have taken parametrics very far, and few Revit users will go without parametrics even if they moan constantly about its faults... and even learn to use constraints sparingly to limit conflicts and speed problems. With Dynamo, they are now adding the GC-style 'dataflow' paradigmn to its portfolio of tools.

  • There always seems to be a divide between the CAD drafting perspective and the engineers / designers perspective.

    CAD drafties like to keep things simple and manageable. They are often at the end of the line of the design / documentation process and don't like surprises.

    Engineers and designers on the other hand need to automate as much as possible because they need to 'form-find' and generate and evaluate a lot of potential solutions. They need to have a lot of automation, propagative relationshps etc etc

    They need to be able to change all storey heights using parameters for example... especially during the front end design phase. But as the elements pile up, it gets harder and harder to manage... that's when the parametric 'smarts' need to be suppressed or superseded y a different means of holding everything together.

    Ideally, we need to identify the type of smart tools or objects that are or should be 'persistent'.  Grids for example? Or storey levels.

    We also need to ensure the smarts that we use in one stage can be handled by the following. A plant design using Plantwise or GC will ideally need to be able to 'hand-over' to one another or coexist without having to deal with too much 'zombie-ness'.

    As a design develops more and more detail will need to be added... which means more parametrics to keep things productive. For exmaple, Structural modeler doesn't have much in terms of connection design smarts or productivity tools.. compared to Prostructures or Power Rebar.

    The schema for the connections used in SM will need to be expandable by PS. And where PS has smarts like its 3d Workframe, then SM should be using the same tool upfront.... as it is a 'persistent' and common to both stages of design and documentation.