BB_DVDATASETELEMENTS

Hi Jeff / everyone

I'm just coming up with problems related to BB_DVDATASETELEMENTS where levels are being created in seed files due to the copy across from the parts.xml. Now, this means we can never use BArch to set up any office standard seedfiles as you always end up with copies of the levels! And it's not simply a matter of compressing out unused levels as some need to be in the seeds.

Just out of interest, I'm guessing this is to replace the similar functionality DEM had when cutting extractions - a non-existent level was copied in at that point. What I'm wondering is why this process can't happen when a DV is created rather than just blindly creating them all when you open a file? We don;t want to have to keep compressing files to remove levels that shouldn't be there in the first place. 

What are the implications of setting BB_DVDATASETELEMTS to 0? Performance decrease or DV's won't turn out right at all?

Thanks in advance

Nigel

Parents
  • Nigel:

    The reason the levels are created in your DGNs is that there are levels assigned in a part definition that do not exist in a DGNLIB that is loaded in your current workspace.  If you don't want the levels to get copied into your DGN's I would recommend correcting your Part definitions to only point to levels from a DGNLIB or create the levels in a DGNLIB.

    The difference between DEM and DV is that DV is processed on your graphics card on the fly and is not being processed on your CPU's memory and output to a separate file/model like an extraction does.  This means, that the level settings need to be available for the graphics card to properly resymbolize the geometry.  I can't tell you how minor or severe setting the variable to 0 beyond telling you that I have not had good results when trying to create DV's without it = 1.  

    HTH,

    Travis



  • That's all fair comment thanks Travis. The second half of your reply is what I was after, and suspected. Thanks.

    The question about the levels existing in a DGNLIB is a wider reaching one for a couple of reasons, and I believe needs further thought:

    1. Project teams need to be able to create Parts on the fly. They may also need levels defining which we wouldn't want created in each and every DGN file. The Families and Parts levels used to give a great workaround to this as they exist for everyone on that project and were created only when the extraction was generated. Unless you're suggesting we open up DGNLIB access to all project members,  we're now stuck with a pre-dgnlib scenario.

    2. Bentley supply out-of-the-box datasets which do not match any company's existing levels. Sure, experienced companies will have their own, but referring to a "system" dataset has always been extremely useful to have templates for the rather complex process of setting up new Parts. Now the way around it is to edit all the Parts XMLs in the supplied datasets so that the levels exist in a DGNLIB or match the company's existing level standards so they are not copied into every DGN file. That isn't going to happen (and shouldn't have to be done) so:

    a) We (meaning us users and you guys at Bentley) need to understand the implications of turning BB_DVDATASETELEMENTS off and advise on it.

    b) Find a better alternative

    or

    c) Never use or load the Bentley datasets

    See where I'm coming from?

    Thanks again

  • Nigel:  

    Thanks for the comments.  We are currently working on dataset changes for Building Designer and we will take this into consideration.  Could you provide the dataset that you are using, and a list of which levels are being created in your DGNs?  You can send to travis.wollet@bentley.com if it is a lengthy list.

    Thanks,

    Travis



  • Nigel,

    One thing we do at our office, is have project specific dgn library for levels.

    The project team creating on the fly parts for the project team can also

    create on the fly project levels if they need.

    This keeps users out of the office wide files while maintaining project specific flexiblity.

    Tom

Reply Children