Referencing i.dgn's versus dgn's

Currently working on a project with 300+ 3d models, totalling about 1.5GB. Architectural, MEP and structures are about evenly split in terms of numbers of models/file sizes.

The problem is that we have come to the point that we can not Ref a lot of the other disciplines models. AecoSim memory max'es out about 3.2-3.5GB.. then all kinds of ugly things happen. We obviously need to have the other disciplines models Ref'd so that we can avoid clashing with their works.

Q1: Would converting the dgn's to i.dgn's help? I remember reading somewhere that the user can control the accuracy of the model elements to make them less resource intensive.

Q2: I note that the i.dgn's are only slightly smaller in size than the originals.  I see that that there are a number of config variables that can be tweaked...

MS_PUBLISHDGN_BUSINESSDATA

(not applicable)

Disables the publishing of business data into the i-model. This may be useful in models where these is a large amount of business data and the i-model is intended for visualization only. Values are 0 (OFF) or 1 (ON). The default setting is ON.

MS_PUBLISHDGN_CONVERTTOXGRAPHICS

(not applicable)

Disables the conversion of model graphics into an optimized viewing format in the i-model. This is rarely necessary and is typically only used for testing purposes. Values are 0 (OFF) or 1 (ON). The default setting is ON.

MS_PUBLISHDGN_MESHBSURF_MINORDER

(not applicable)

Defines a numeric value that specifies the minimum order for which B-spline surfaces will be converted to meshes during publishing. If specified, B-spline surfaces at or above this order will be converted to meshes to optimize visualization performance in the i-model. If not specified, the default value is 6. Most users will not need to change this value.

PUBLISHDGN_ECPROPERTIES_NOT_TO_FILTER

(not applicable)

Used to define the names of the business properties not to filter out while publishing an i-model. Any property listed in this configuration variable will always be published.

The format for defining multiple business property names is: <property_name_1>;<property_name_2>;…

PUBLISHDGN_REMOVEATTRIBUTEIDS

(not applicable)

Used to remove attribute linkages from i-models. This variable should not be changed by users.

MS_PUBLISHDGN_DESIGNLINKS

(not applicable)

If on, turns on the Publish Linked Design Files check box by default.

_EMBEDFILE

(not applicable)

If the packaged i-model contains embedded references, this configuration variable will resolve the name of the current embedded reference file. Otherwise, it will have the same value as _DGNFILE.

_PACKAGEFILE

(not applicable)

If the packaged i-model contains embedded references, this configuration variable will resolve the name of the current packaged file. Otherwise, it will have the same value as _DGNFILE.

What's the best combo if all you want is to view the Ref's?

  • PS:

    MS_PUBLISHDGN_BUSINESSDATA

    Disables the publishing of business data into the i-model. This may be useful in models where these is a large amount of business data and the i-model is intended for visualization only. Values are 0 (OFF) or 1 (ON). The default setting is ON.

    Does this mean if the Value is 1 (ON) then this ' Disables the publishing of business data into the i-model' ?

    Confusing.

  • Mstn's Ref Attachment dailog could do with more options.

    1. We now have the option to load the Ref as a CVE. We have also had the option to use Design History, which makes the file 2.5x larger on average. DH makes a 'History State' copy of the elements and there is some 'churn' on top of that.

    I am wondering if there shouldn't be an option to flip to a 'Cached Light Weight' or 'Cached Viewing Optimised' version of the Ref under the Dynamic/CVE/Legacy dropdown.

    DH stores the extra copy of elements with the original file. CVO would be cached with the original file as well? It could use a a variation of DH to help it selectively sync only those new/modified/deleted elements in the original model. Sort of an internal Delta Transfer? Presumably, Mstn only loads the individual model (and its children) that is selected in the Ref box, not all of the models in the dgn?

    It looks like converting B-spline surfaces into meshes (solids as well?) is the main tool for simplifiying geometry. Why stop there? You could store a further representation of the model in a format that is GPU Cache-friendly. How does XVL and other formats like JT or U3D do it? Maybe the nearest Refs to the viewer will automatically be replaced by 'full fat' representations dynamically like Decartes' STM's? Might be useful for making Navigator quick enough to keep up with NW?

    2. There should be an option in the Ref Attach box to load the dgn:model without the attachments. The model would be loaded with all the Refs listed in the Ref dialog, but greyed out? This would then allow the user to select the nested Refs be really needs... for loading.

  • PS: Interesting to note that Lattice's XVL originators are Japanese and XVL is based on Gregory patches. One of the main authors also worked on Ricoh's Designbase solid modeling kernel... used by Fujitsu's ICAD... which claims to be the worlds fastest CAD engine.

    Lattice's patches also remind me of GML's subdivision surfaces, multi-resolution way of producing 3d surfaces.

    Maybe Lattice's XVL is now mature enough to be used as a base for a super-scalable, infrastructure project-ready... next gen Mstn ? Maybe combined with SQLite?

  • Dominic,

    We work with large projects - very complex projects. In general, we have not reached the limits you mention. I wonder if that is because of our model management -- how the models are modeled. For example, we model equipment in the simplest terms.

    Anyway. To your original question, What about imodels? Yes, they work very well as references! We often attach them because they are light to attach and if the have been generated for project reviews using Navigator they already have the entire project packaged together. We generate imodels from our .dgn models using batch methods nightly for use with Navigator. However, the disadvantage to that method is that they are a day old.

    Hope this helps.

    Tom

  • Tom,

    How large are your models in total? One problem we have is the project is essentially one large building with two main levels.... not a collection of smaller discrete ones.

    64bit is overdue I think.... similar problems here  here

    It's not just being able to load the models, which is bad enough, but also doing something else like publishing an i-model, or as mentioned in above batch plotting or prepocessing for Luxology or doing all those DV/BV stuff.

    It would be awesome to have a JT or XVL-like format that is an order of magnitude smaller than the competition that loads super fast because it speaks GPU etc... even if they are read only. Like the Maya example, you could flip to the editable representations when needed.

    Navigator is much slower/ less responsive than NW. One reason we don't use it. I suspect one reason is that NW's geometry format is less precise and more 'game' tech oriented. Maybe Bentley should trial it out with Navigator first.

    PS: What format does all these ipad apps use.. must be more compact? Navigator Mobile omim files loadable in Mstn/AecoSim on the desktop?