Shouldn't elements created on a particular floor height recognize that the floor hieght has been adjusted ?

Thanks, John.   We can continue on the other thread...

Yes, sorry about straying off topic here everyone.  I had another thread going about my issues but somehow I wandered into this one.  Steve, please see the thread "communities.bentley.com/.../204603.aspx

John K.

Hhmmm

This thread does seem to reflect quite a bit of the discussion taking place in this one

communities.bentley.com/.../74801.aspx

Back to the original topic..

I know when I used Archicad that everything could and generally was tied to the floor level. And it was good, except I didn't link the top of the wall because when I deleted an obect above the linked element it did wierd things So I just linked the bottom as it was easier in the long run.

I have been rethinking the floor manager and now I to am thinking that If you place an element using floor manager active it should stay relative to that floor manager level IMHO. Put an option under element propeties of which FM level it is linked to the object (with a relative height above/below that level - like doors windows have) so you can adjust it later.

Steve, I don't remember changing anything in the delivered GB Floormaster file.  Just in case, I will re-download it.

Damon, I just use the dialog box to change the floor settings.

Did you manually change the shapes in the file? Or just use the dialog box?

Ah.. gotcha, thanks.  

Is there a specific change you made to the delivered GB Floormaster file that we can try here?   As it is, whever I use the GB dataset the floor units are always displayed in mm; i.e., I don't see any unusual behavior.

I tried the floor master that came with the GB dataset but I also tried the ABD delivered imperial dataset which is the one that I needed to modify to mm/mm.  I didn't change the GB one.

OK, thanks for checking.    It seems that *something* is stuck on M as the master unit, and that "something" is messing with the reference planes as well.

One question... you stated previously that you had "set both the floor master working units to mm/mm and the file that I am in to mm/mm".  In the Floormaster.DGNLib I have with the GB dataset, it's already set to mm/mm.   What file did you start with?

It's listed as " <Units master="mm" sub="mm"/> ".  That's under the "Dataset_GB" directory.

Hmmm....  Browse to your ..\WorkSpace\BuildingDatasets\Dataset_Name\datagroupcatalogs folder and open the Floors.xml in Notepad.  What are the units defined up top?

One more thing:  If I add a reference plane to one of the floors things get really wacky.  For example: If I add a sub-reference plane of -1.85 to the floor elevation of 135.00 (keep in mind that these should be 13500 and -185) I get the proper resulting elevation of 133.15.  However, after I exit then re-open, the relative elevation changes to -133.6685 and the elevation changes to 1.3315.  Very strange.

Hi Steve,

I tried what you suggested but I'm still having issues.  Even though I set both the floor master working units to mm/mm and the file that I am in to mm/mm, it still changes the floor elevations after I exit the Floor Manager.  For example, 13500 becomes 135.00.  Is there some other configuration that could be causing this?

John, assuming you hadn't already done so, can you try using the delivered Floormaster.dgn from the ABD commercial release as a template for a new Floormaster.dgn?   I found a few Save related issues that were resolved along the way during ABD's development.   Could be a worth a try...    If that does not resolve the issue, please provide your current floormaster file so that it can be used for troubleshooting the ST.

I can't get even get floor manager to work properly with the metric (GB) dataset.  Eventhough I set the floor master dgnlib's working units to mm/mm (the same as my models) it still won't retain my floor elevations.  If I set them all then exit and re-open floor manager, almost all of the elevations change to strange elevations.  I filed an ST (8001354975) but I haven't heard anything back yet.

John K.

One file can hold all your floor settings.  Each building get's it own group.  A little combersome if you ahve many but you could have differing workspaces that refer to a project model for the floor space like we do.

It is usefull as a 3d drawing tool it jsut needs to go much farrrrrrrrrrrther.

OK, we agree on some things.

Some of the windows move because there is an option in Allplan to constrain the 'lintel' edge to the top of the wall. For a lot of cases, this is the preferred result.

But, I take your point. BA would be more immune as the windows are 'dumber' or do not have this dependency. But, resigning yourself to having to fence stretch everything all the time is not the way forward, IMO.

This is an example of a dependency which is 'hidden', which is one problem. OK. Developers will probably tell you that there is nothing to stop the user undoing the change and modifying the unwanted behaviour.

Maybe,  Allplan should walk through every element nested or associated to the walls, pop up the corresponding dialog and ask for clearance to go ahead element by element. I guess, it could even ask if the modifications should be applied to rest of the elements of the same type, like Windows' Explorer asks the user when he copies some files and finds duplicates. Too complictated? I agree.

Lets stay with the BA/Mstn way of doing things.The Association and Group lock has been around for ages. And BA has its Relationship lock. Take your pick, I can't always tell anymore how these locks modify behaviour, or which tools are even aware of them.

You could make the tool modify the way it treats dependencies via the locks. If the Relationship lock is off, then anything that is dependent on the wall height is broken. I guess the Allplan window will have to gracefully switch to an defintion that is not dependent on the upper wall edge with the equivalent dimensions. And you would have the fine-grained 'no surprises' modification you have currently have with BA.

The other really powerful tool/concept that Mstn has is the propagation settings that Named Groups have. I guess you could tag the elements or the variables themselves accordingly. This seems to availble to all elements, and could be used to give the user a lot of bulk but fine-grained editing muscle that does not rely so much on built-in parametrics.

If you wanted to move the hosted/secondary element like a window/door in wall, the window/door would have a 'passive' NG attribute. The way that NG filters propagation is pretty powerful. By controlling how variables propagate either by ignoring an incoming 'put' or selectively not propagating changes, depending on whether a lock is on, you could do a lot very quickly.... in theory.

OK, straying back into parametrics. Maybe one way of looking at this is exploring what a fine-grained locking mechanism can help offset the speed advanatge of doing things parametrically. You probably use fence stretch a lot, to do bulk editing as well as tunneling into cells / grouped elements to modify nested elements. Fence operations are pain to set up. Would be great if you could just lock stuff down, using all kinds of criteria, and at any nesting level.

Say you want to change the door knobs on a particular door type, other the way a wall butts up against all those new beams the structural engineer has changed... again! Don't want to do this parametrically, because you never know what you end up with... so....

you probably need to go down the Just-in-Time, Live Rules-based super-selection route. Apparently uses some real-time patent-pending coding voodoo to select all co-planar faces automatically, and works on dumb geometry. You would pick the top face of the wall you want to edit, the rules base voodoo goes out and selects the top of the walls that are similar enough and dynamically displays the changes. No annoying hidden fallout or dependencies. No messy view rotations to get a clean shot for the fence tool.

What about changing those door knobs without dealing with parametrics and dependencies? I guess you could have a blob of dumb geometry in cells as doors. But, if you use the fence or any other manual editing technique, you would need to move from door to door, re-align the view and stretch and repeat.... I guess it should be possible to do this once in the cell and replace. You would have to ensure the cells are re-named properly. This is pretty straight forward and accepted practice, but it is also the start of the parametric component-based way of doing things that will only grow and grow once it 'takes root'. I think its inevitable that we will need to deal with 'parametrics' at some level.

Manual editing has a lot of advantages, but to achieve a step change in productivity, it needs to grow out of its 'visual' drawing board analogue. I think one limitation of thinking this way is the way things have to be viewed and manipulated using one coordinate system at a time. How do you amplify this... to make this way of working scalable?

Not sure... one guess is that you need to transform all those changes to fit each door, and repeat the operations, emulating the way you would do things 'on the drawing board' automatically. You could use parametric/procedural tools like GC to select all doors by type or elevation/floor and rotate the view to suit, transform the fence to match the new coordinate system, pause to ask the user to make the changes, before moving on quickly. This way the user will be in the loop and able to eyeball stuff. This removes the need to rely on parametrics which it going to be set up 'wrong' anyway.

The other thing about the visual world analogue is that certain information is really better of not strictly graphic. Things like floor elevation levels and grids are better off treated as scalar values or other data types that drive their graphic markers. It's far easier to edit things by changing a parameter or handle rather than doing things visually by snapping on screen. WYSIWYG 'dumb' editing needs to be able to defer to parameteric 'data-centric' ways of doing things when it suits. This means dealing with dependencies if the power behind the 'algebraic' substitution, propagation side of things are to be harnessed. I think the challenge will be how to 'visualise' this 'invisible' inbtween world of relationships between elements, including their variables.

A  "plane" (=planar surface, Z=1234) is a far to simple thing to use for this.

It needs to be a group of slabs with possibly different Z and slopes. Walls connected  to a Named Group of slabs would be fine.

I didn't say there should be no further investment in parametrics in BA. In fact I'm all for it, but the investment needs to be considered, and implemented to keep it flexible yet productive. As I said, for now I'd settle for top and bottom of walls to associate to underside/top of slab or plane, which should be pretty simple to implement if the ends can associate. Embedded objects is another story - can get pretty messy The Allplan video is a good example. The slab moves, some windows stretch, some don't, and on a project this small, pretty easy to control. Many projects aren't this small and contain a lot more than a few walls, windows and some fluffy sofas and with that a lot more project participants with varying skill level and when this gets out of hand with "spaghetti dependencies".... well.

Brian,

Linking objects with planes: What apps have you used?

Revit, ArchiCAD, Allplan, Speedikon, Vectorworks etc all have the floor plane as a simple constraints plane that objects can define offsets to. Most users have no problems with this whatsoever. In fact, it's pretty much got the point that most users expect to have their elements constrained to a 'floor level'. Compare this to BA, where you need to know / select the corresponding ACS, make sure its the one by looking at some dialog box because there are no useful clues on screen before you can place or modify a wall. Even ACAD's UCS  appears at the cursor and gives the user much better feedback on where the next point is going. If BA is going to argue that you are faster by bypassing parameterics and doing things 'by hand'  then this kind needs to be super polished.

Sure, Revit can get out of hand wrt constraints and many users learn to user them sparingly. But, as mentioned above, most elements have at least one constraint. It's really a question of having the option, and being able to use it ergonomically.

Catia/DP has a more general system where extrusions can be 'delimited' by defined planes, coordinate systems or even faces of other elements. All pretty standard MCAD stuff, that has been used for ages. Yes, you can argue that this can also get out of hand, and needs a proper solver which can slow things down.... but I think it is again a question of how it is implemented. Allplan allows the user to define what it calls a 'plane mode', which includes 'custom planes' in space which can be associated with elements such as walls, slabs etc. A bit more flexible than just assigning a level attribute, but pretty well thought out to be useful to most users. Constraining to 'priveliged' elements reduces the risk of spaghetti dependencies that you can get with Revit et al, which allows to elements to be constrained to their 'siblings'. This is heirarchial 'referencing' is called 'skeleton modeling' in the MCAD world.

Look at the way, the walls react when the 'custom plane' is placed over/under them. It reminds me of the way HUD dims work, or Accusnap works pre-emptively. There doesn't need to be a link built in. All the tools are already there... fence select using the plane as the shape, collect the TF walls, and run them thru the Extend Form to Plane tool. If the plane defines a floor then the tool may need to do two groups of walls.

Look at the way slabs work in Vectorworks, and tell me why there would be problems when the slab is linked to the walls. They have obviously taken some care to 'architect' the tool a bit.... across elements/tools. The slab and walls were upgraded together. The walls had enough intelligence built in to allow the slab edges to be associated to specific wall leaf edges. The wall leaves also have options for individual offsets vertically.

All of this would need to be done by hand in BA. This is unsustainable. The amount of info is only going to grow, and we are always going to have to do more with less and in shorter time frames. Some 'smarts' is needed, and there needs to be a range of 'tools' to ensure the right type of smarts are availble. I think Triforma has a good history of being 'dumb' but flexible, but there is a limit to this. Making things dumber or staying dumb isn't going to bring more productivity gains.

Interesting post Dominic. Lots of options there. I'd settle for the top and bottom of forms having a relationship with other objects right now. It gets a bit complicated for most people when you need to figure out if the top of the window goes with the top of wall or whether it remains in place or whether the whole window moves or whether .............. ??????I love parametrics but in my experience linking objects with planes, whilst being a nice to have, can often be more disasterous than beneficial.

No, I think that there are a lot of different types of 'data-centric' working. I don't think Bentley are that far off.

Revit is pretty MCAD style, history / feature based. I think GC is similar but more powerful. But, it is also much harder to learm as a result. Fair enough...

I think a lot of the things Revit can do, already exist in Mstn / BA, in the form of Feature Solids and DDD. The problem is that these tools haven't been improved in awhile and are too isolated from each other. Revit in contrast has a consistent 'family' of components that work together.

A lot of people don't think parametrics will help that much with what they do. OK, even if you leave all the fancy parametrics aside, things like editing cells in place become very important, but has been missing for ages.... as you have mentioned previously.

There is a backlash against big parametrics in the MCAD world that started with 'Direct Modeling', Driving Dimensions etc... and is pushing back towards and complementing the old parametric world. Yes, its more 'fly-by-wire' stuff that needs a whole lot of code to make things 'intuitive'. I guess you need to buy in a bunch of math geeks like IntelliCAD did with LEDAS, recently ...

I would settle for an update of DDD that will provide simple driving dimensions and some constraints.... that will work with GC. BA's HUD dimensions already do some of this, and would have a big impact if they were developed a bit more.

ArchiCAD? It's not that parametric compared to Revit. But, it has most of its CAD elements exposed as a procedural language that it pretty well integrated UI-wise with the rest of the app. Select any geometry and ArchiCAD will 'promote' it like GC into script form. Actually, it's probably more of a read, not translate. It also dialog-boxes the script fairly well, presenting the scripted info in preset tabs like 'parameters', 'components'. '3d', '2d', 'materials' etc. GC does this as well in its own way. Hot points are also definable and exposed as in the scripts, and everything is that is manipulated on screen is saved to the GDL script. Again, GC does some of this already. And now with 'SmartParts', GDL's usuability has really been given a boost. SmartParts has exposed its parameters as 'hotpoints' that are manipulatable on screen via the cursor. Again, GC can do some of these with its '3d controllers'.

A lot of it is all mostly about packaging to present a unfied 'usable' UI, not just a 'hackable' one. Tedious, but it does make a big difference.

The other aspect of 'data-centric' is to do with non-geometric info and its relationship with the geometric model. I think all the major 'BIM' apps are really geometric modelers, but really 'information' modelers. Again, Bentley has a lot of know-how here.... but mainly from its OpenPlant experience... IMO.

dwy.seah@gmail.com:

We need to be able to look at things in a 'data-centric' way. I guess its not unlike the old debate about how we should be dealing with 'wall' objects and not two lines standing in for walls..............

All I can say is that (from my personal veiwpoint) Bentley strategically have are trying not to go this way. If you really want a data-centric way of doing things then Revit/Archicad is the offering at the present time. I cannot see mstn moving away from the base it has right now, which is a solids model based package.

I still think Autodesk Architecture has better tools for modeling walls, doors, windows and curtainwalls. If mstn had tools that worked like theirs then we would have a programme that can rival revit/Archicad.  Unfortunately we have PCS. Which IMHO is a terrible programme when compared to other tools in the marketplace.

OMG here I go again.. rant.rant.rant.. I need a holiday I think.

Yes. I agree with Danny. Whether FFL move very much or not is beside the point.

We need to be able to look at things in a 'data-centric' way. I guess its not unlike the old debate about how we should be dealing with 'wall' objects and not two lines standing in for walls.

We need to be able to 'grasp' the info at the appropriate 'abstraction level' or criteria ....or leverage the 'few' to drive the 'many' to gain productivity...?

The old way of doing things was to plug all kinds of parameters into the base objects and manipulate them to suit. If you want to isolate the door handle from the door cell, you have to plan in advance and put the door handle on a different level or you are out of luck.

I think there are big limits to this way of doing things, especially with this age of 3,4,5,6d BIM planning, where everybody and his brother has a parameters wish list.

Hello all

Good to hear your comments

I must say I agree with initial statement/question

In a 'modern' building modelling application (who cares what it's called, .... parametric, generative, smart, intelligent), ...... then if you place an object at a FFL of SSL, or U/SSL (the acronyms may change from country to country) that should be a recognised 'feature' or property of that building object.

Though I do feel that should be an option when you place the object.

Damon, I appreciate your comments ....... all I can say on this one though is that construction projects in NZ (I think that's correct?) must be a whole lot better managed than in the UK. Certainly over here, the FFLs, SSLs, FCLs will be constantly changing. Not just during the concept/sketch stage, right the way though the Design Development, through to Tender and quite often AFTER they have started building the thing on site. The bigger to projects are often the worst offenders!

The problem is especially acute when working on large scale refurbs/remodelling of existing buildings. Certainly in the UK, the majority of such projects start (on site!) based upon what is a pretty low accuracy survey. As the design/project develops, more and more site surveys are carried out and the levels (and lots of other stuff as well) will be constantly updated.

There is a potential issue about what to do when one area of the 'Floor' gets raised, in which case you would need to create a new 'Floor' in the Floor Manager. Does the object that was previously linked/associated to the old FFL, automatically get moved to match the new FFL in that area of the building?

I guess then in such cases, IIMHO, the object should not automatically move (you might now want it too!), but something should indicate/highlight, objects that are no longer 'aligned' with it's original FFL (which now no longer applies to that are of the Floor/building.

Overall, the implementation of a 'Floor Manager' type utility is part of the way forward. Though I agree at the moment it's quite basic and a bit fiddly. If you're already quite familar with Accudraw/ACSs then IMHO you don't really need it, or won't find it to be that much of an advantage. Though it would become more viable with a large team, involving several architects/designers that are not too familar with Microstation 3D

I guess we have all worked out some approach over the years and have different strategies for navigating/modelling in 3D and how this relates to 2D 'planes'.

I would like to see the 'Floor Mangager' revamped, ...... indeed expanded upon so that it becomes and cental hub/repository for all the building 'Levels and Workplanes' (including location/orientation of Elevations and Sections). This needs to be lined to the Dynamic Views strategy/mechanism (it's about halfway there at the moment)

My 2P for now, ...... but yes, ....if you place a builidng element at a certain FFL, it's usually because you indeed want it to be on the FFL (not particualrly 52.600 above ground Level, or whatever, you just need to know that it is at the FFL). Generally speaking it should stay at that FFL, unless you, as the designer decide that you want to move/remove/amend it in some way

All the best

I think its really to do with having the flexibility, when you want it.

GC is very explicit. You will have to have a build the script to allow this.

Other apps like Allplan and Catia/DP use planes to 'trim' walls vertically. Pretty flexible.

I think as BIM gets going, there will be enough info to allow an 'after the fact' algorithm to select the walls and move them.

Solibri can already select walls by floor because IFC requires walls to be tagged with floor / storey info.

I guess you could then write a script or dialog to get MStn to select all walls on a a floor, look for the base of the wall, move that wall to the new story level, then extend the wall to the slab above.... wall element type can stay 'naive'.

I too agree that linking of floors to the model components is definately not a big problem at all. Pretty much RL's are set faily early on and don't change very often. When they do change it only really happens at sketch design stage where you dont do very much detail in your model anyhow. It should just be spaces and external block windows and walls.

If you wish to have dynamic floors and walls then i suggest Generative Components is geared exactly for this.

I really like floormananger and uses it on all my projects, the idea that objects isn't attached to any floor is main reason why i like it.

We have other softwares at our office that uses the feature where every object is linked to a floor. This is a nightmare to work with because when you insert floors or change a floors height you will spend the next hours to check if everything has gone right. As a structural engineer we often use braces and columns that go through more than one floor. Having objects that keeps moving around or stretching itself is nothing i can work with.

/Andreas

I don't use Floor Selector much but I do set it up for the other team members as they like to use it. I also set up the floors in ACS's because Accudraw has the GA keyin. Great for selecting floors on the fly. I tend to use objects already in the model and use Accudraw keyin O to go from there.

Your problem is a very easy one to solve so I am quite perplexed as to why not use it.

But I do understand that a UCS tool extension would have been a much neater one to the floor manager. I remember there was a big discussion when Floor manager was put into a beta copy of BA ages ago and the concensus from the community that an ACS based aproach would be better than the new Floor manager workaround tool that popped up. And yes the interface is very clunky.

I myself have never used UCS's in 3d as I find them really hard to set up and use. The dialog just makes no sense to me The other annoying thing is that accudraw seems to ignore that fact that you have set a UCS altogehter. I have fouind UCS very good in 2d drawings, but in 3d I totally avoid it.

At least with floor manager I know I'm at the correct RL.

I seldom use Floor manager because it needs project configuration, i.e. it needs t find correct dgnlibs.

I would very much preferred if it had used  simple references.

I have tried to use _DGNDIR in the cv for Floor manager. it worked most of the time, but failed a few. May depend on the order cvs are loaded.

I also found the dialog difficult to understand and clunky tools.

I understand it so it doesn't do more than sets a bunch of acs? Would have better then to have the acs-dialog reworked. 

I seldom use Floor manager because it needs project configuration, i.e. it needs t find correct dgnlibs.

I would very much preferred if it had used  simple references.

I have tried to use _DGNDIR in the cv for Floor manager. it worked most of the time, but failed a few. May depend on the order cvs are loaded.

I also found the dialog difficult to understand and clunky tools.

I understand it so it doesn't do more than sets a bunch of acses? Would have better then to have the acs-dialog reworked. 

Hi Dialupjunkie,

Loved your wiki entry on the difficulties of placing spaces.

Would be great if you shared your workflow on associative updates, even if it didn't work fully....?

Space planner covers a really important task, especially at the beginning of projects. I know a lot of users bypass BA for the competition because SP is so clunky.

Regards

Dominic

I have got associative dimensioning to work, but haven't tested it at production level, so I'm disappointed to read about your experience.

That adds to quite a long list of things BA appears to offer, but which turns out to be flawed. I expended an obscene amount of time trying to devise a workflow which would allow space elements to update associatively with 3d building elements, to realise this is way too ambitious.

And what about those building views...?

WOW. Never use floor manager???

I am speachleess that someone doesn't find floor manager useful. I came from a structural background and i have always used it and found it very usefull. especially to set top of steel beams, conc beams etc.

Very interssting to hear that Andreas. And very surprised. but then i have seem some weird ways that other people work and that is the beauty (and problem) of Microstation. There a 10 ways to do anything. Which is a boon and a pain.

I think its down to the fact that Bentley haven't provided a platform level dependency management system.... or have too many of them.... or have one which the BA team ignored because they eloped with PCS all those years ago.. :-)

There are parametric tools that can replicate this but in usual fashion, they don't work with each other.

1. If you build your building in PCS and never come out unless to export to dwg etc, you could probably work like that.

2. There are DDD cell and Feature Solids tools that let you define offsets from an origin. Support for the DDD cell stuff seems to have died after Mstn J or XM. Fosters are big on DDD and supposedly have their own inhouse mdls.

3. GC: probably easy peasy in GC. But, having everything in GC is a pain. The idea that the design can be frozen and 'baked' by lone wolf scripter and throwm 'over the wall'  to a bunch of BIM monkeys is flawed. Case in point here. What happens if you need to change the floor height after GC has left the scene? Down to manual edits.... just as the info starts balloning during the CD stage.

GC elements also choke if you have an associate dimenion linked to it. I guess its dependency graph gets consused about what to update next when a node is linked to a associative dim or hatch etc. ... last time I looked.

4. Speedikon: Has a German style floor manager... but is DB based. Just uses Mstn to display stuff. Totally separate vertical.

5. ...?

V9??

The Good thing about Bentley products is that they are not rigid in proporting a work method like other programs.

The program is however written to suggest a sort of best practice procedure for designers which you may or may not choose to follow.

I dont think associateive dims are supposed to update in that sense.  I didn't appreciate the power of associative dims until I saw someone else use them to monitor (rather effectively ) changes in the drawing, if someone else on the team (ME !! ) moved or deleated something that they shouldn't have.  Personally however they drive me nuts so I avoid using them.

The floor manager on the other hand as mentioned above combines features of the Saved Auxiliary Coordinate System as well as the  Set Active depth tool.  ( One which I find not a lot of people use or are aware of.)  The floor manager saves you the Agro of having to reset the active depth to lock to a new plane because you can preset several active depths in one model. Setting the active depth can be a "mare" if you have lots of elements in the drawing but I loved the control it gave over placement of elements.  Combined with the view clipping planes it can be a real bundle of party tricks.

if you have lots of working planes on a floor level ( which you normally would) It also allows you to create sub levels within a level, (a feature Andreas may find very useful).  for example if you had to include a lift pit within a slab then top of the slab, the base of the lift pit and the base of the sump would all be levels and sub levels within the floor level. Additionally you can have several buildings within a complex all with there own levels and sub levels.  I cannot however defend Bentleys omission of dynamic linkage of objects to the floor manager but seeing as it is a tool that evolved from a view settings point of view I can see why this happened.

I've just tried Floor Manager once, and I didn't find it useful at all.

On the other hand, I don't understand how you guys are working with floor heights at all. On the models we are working at I'd struggle even to find a reference plane which I could use on the. Maybe the top of the floor is the same all over a floor, but the floor construction often is not decided until much later in a project. In addition architects tend to want different floor constructions in different parts of the building, so I'd have to adjust slab positions and thicknesses quite often.

Right now I'd think the Floor Manager would make things more complicated that working without it. I can live with the fact that walls don't update automatically. The only thing I know in Microstation which should update itself automatically - associative dimensions - doesn't work at all and we don't use it.

Yes this is a major drawback in BA.

In other cad packages the top and bottom of walls can be linked to floors, but not in BA. in BA they are just 3d objects that float in space.

Once a wall is placed in a model that is where it is, unless you move it.

If you change the RL of a floor you have to move all the objects accordingly that have already been drawn.

Microstation and BA are a solid modelling cad package and not database type parametric building model.

Walls and objects are not dynamically linked to the floor manager in any way. The floor manager is basically an extension of a Saved Auxiliary Coordinate System(ACS) and that is all.

John I'm afraid you might be in for a slight surprise.  I set up the floor elevations using the Floor manager and as all designers do I changed my mind and decided I wanted a particular floor at a different height.  This left the walls and furnitre floating in the air.  Howwver I admit that I may be doing something incorrectly

Regards

J.

I would hope that if you took the time to set the elevations of your floors then any element you would place on the "active" floor should know where it is supposed to go, right??  I haven't played around with that yet but I had assumed that that is what would/should happen.

John K.

It is great that it  is so easy to adjust the levels of floor heights in the Floor level manager, but a complete nightmare having to adjust the base elevation of walls, slabs and other elements such as toilets and urinals to suit the new levels.  It is criminal that the elements don't recognize that the floor level has changed and are not tied in intelligently to the level they were created on.  . . . . . Unless of course I am wrong  and there is something I have not switched on or done right.  Or is this a new one for the wish list?