I'm suprised at your timings, as I've seen something different with dblocks verses standard insertions.
MOE is still in the prototype/experimental stage at this point. I'm hoping to be able to get it into shape soon though.
--
http://www.caddzone.com
AcadXTabs: MDI Document Tabs for AutoCAD 2008
Supporting AutoCAD 2000 through 2008
http://www.acadxtabs.com
"Matt Stachoni" wrote in message news:5837102@discussion.autodesk.com...
On Fri, 1 Feb 2008 10:48:29 +0000, Tony Tanzillo
wrote:
>If you think object regeneration is no longer relevant then you have never dealt with the type of drawings that some must. Like for example, 80+ MB municipal utility maps some of my customers routinely work with, which typically contain 200,000 to 300,000 entities in their model space. Operations that might be instantaneous in a file that involves a small-to-medium size architectural floor plan, can take anywhere from 3-10 seconds in one of these files.
>It seems that your points are designed to serve a more general debate on MINSERT verses Dynamic block. Well, that's not the case here. I'm talking only about the specific use of them for batt insulation, or something similar in nature that involves a linear array of a base set of objects, for which MINSERTs are an alternative. And I maintain that using dblocks for that incurrs needless overhead in the form of excess baggage that certainly does affect system performance.
I was trying to make my points relate to this specific scenario, not a larger
issue between DBs vs MINSERTs. I can easily agree that DBs do present more
computational overhead than MINSERTs, but you have to weigh that against
practicality.
And in this particular application we are talking about a specific use. In a
worse case scenario, you would be using batt insulation (to any large extent) in
only small to medium sized architectural floor plans to graphically infill your
walls. In large floor plans, which are typically plotted at "small" scales like
1/32"=1'-0", 1/16"=1'-0" or 1/8"=1'-0", you would never use batt insulation in
the wall graphics - they would immediately get lost. In fact, using batt
insulation in a 1/4"=1'-0" plan is a real stretch.
Of course, one could argue that you would use it in a base plan and freeze it
out of small scale drawings, and thaw it for enlarged floor plans that are
downstream in the process. I would argue that one should add such burdensome
graphics only in the enlarged plans to minimize overhead. But then it could also
be more sanely argued that you are simply better off using an AEC-specific tool
like AutoCAD Architecture, where you have a robust display system that takes
care of this which makes the whole point moot.
So, what we are really discussing is somewhat limited in scope: using AutoCAD,
in very large-scale floor plans that are going to show everything and also in
your sections and details. In which case, the overhead of DBs - which are, I
agree, pretty hideous - can safely take a back seat to end-user usability, which
I still argue is orders of magnitude better than MINSERTs.
>I don't think this needs to be debated. Just take a reasonable size floor plan of a structure with say, a few thousand linear feet of insulated wall, apply the dynamic block to all of it, and then do the equivalent using an MINSERTed normal unit block, and compare the sizes of the resulting files. The result should speak for itself.
I did just that, and taken to the (IMO) extreme, you are correct. But the
resultant order of magnitude is (IMO) not the end of the world.
I created a single batt block, which I MINSERTed into a column that is 1000x
high (about 127'). I arrayed that into 10 columns.
In a second drawing, I created a DB using that single batt block with an Array
action, and inserted that at the same length to give the same amount of
entities. I also arrayed that into 10 columns.
The resultant "MINSERT" file is 194KB. The "DB" file is 282KB. Excessive in
comparison? You bet.
Regeneration time averaged about 10.25 seconds in the DB drawing, and 10.8
seconds in the MINSERT drawings - essentially the same. And I have a nicely
powerful and properly tweaked system, so in both cases we are talking about a
pretty strenuous drawing.
I noticed that when I changed the array from 10 to 100 columns, there was very
little difference in the file size of either file. The DB file grew to 293KB and
the MINSERT file came in right at 195KB.
So, yes, the DB approach does negatively affect file size, which can be expected
due to the anonymous block creation mechanism - which I think we can all agree
is pretty dopey, but I assume done for expediency and backwards compatibility.
FWIW, when I tried to change the 100 DBs from 127' to 1000', AutoCAD (actually,
ACA 2008) froze up. But it also did in the MINSERT drawing as well, but it
finally did complete the operation after some time.
>More generally, dynamic blocks carry a lot of baggage with them that still has me puzzled. For example, an insertion of the standard sample 'Door - Imperial' dblock contains an extension dictionary having several child dictionaries nested 2-3 levels down, one of which contains 19 Xrecords, with each having 6 or 7 data fields.
>For the interested, the 'baggage' I'm referring to in that block is illustrated in this video: http://www.caddzone.com/DBlockBaggage.wmv
Yow. But more importantly, are you going to make that cool MOE tool available?
>In the future, perhaps Autodesk will figure out what's wrong with their implementation of dynamic blocks, and come up with a way to make properties of objects in dynamic block definitions programmable (e.g., where one could use an MINSERT within the definition of a dynamic block, and have the number-of-columns property of the MINSERT driven by an equation or expression that uses the insertion's dynamic block properties). That would make DBs far more powerful and allow them to be used without so much wasteful bloat/baggage.
I agree completely that while the potential for DBs are enormous, they are
currently at best half baked. I use DBs extensively in my work (even under ACA)
and find myself hitting roadblocks left and right.
But in light of better tools that are available (e.g., using ACA for
architectural plans and leveraging the display system), perhaps the scope of
overall DB use is somewhat ameliorated so that any performance impact is kept to
a minimum.
Matt
mstachoni@verizon.net
mstachoni@bhhtait.com