Visual LISP, AutoLISP and General Customization
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

batt insulation hatch

25 REPLIES 25
Reply
Message 1 of 26
Anonymous
43149 Views, 25 Replies

batt insulation hatch

Does anyone have a routine that will draw a insulation hatch around a circle? Thanks
25 REPLIES 25
Message 2 of 26
Anonymous
in reply to: Anonymous

Why not just use the batting linetype? "Caddog" wrote in message news:4101617b$1_2@newsprd01... > Does anyone have a routine that will draw a insulation hatch around a > circle? > > Thanks > >
Message 3 of 26
Anonymous
in reply to: Anonymous

I had it . Please send me a dwg where you plan to use it.
Message 4 of 26
johnypd
in reply to: Anonymous

I would appreciate if you could send a lisp routine which will draw batt insulation on curves. Linetype has limitations: when change ltscale batt insulation linetype width change.
Thanks
johny
Message 5 of 26
Anonymous
in reply to: Anonymous

I have a nicer-looking version of a batt insulation Linetype than AutoCAD's BATTING, if you're
interested, but it's still a Linetype. It has the added advantage that it's defined in such a way
that you merely divide the thickness you want by the reality-to-drawing ratio; with their BATTING,
because of the arbitrary way it's defined, you have to multiply the thickness you want by 5 and
divide by that ratio. Any Linetype-based approach is going to have that "limitation" in relation to
Linetype Scale, because of the way Shapes are used in Linetypes.

But any other approach is going to have more severe limitations, in my opinion. There was a thread
about something very similar, maybe several months but probably less than a year ago, looking at
generating a polyline version with the looping built in, and a Continuous Linetype. I don't
remember whether someone came up with a way to do it, but I wouldn't be likely to use something like
that. If you ever needed to change the shape of the curve, or straighten a curve within a Polyline,
or Lengthen an end, or you decide you want a different thickness of insulation, you'd have to give
up on the original and generate the whole thing all over again. A Linetype approach takes care of
all of that for you.

--
Kent Cooper


wrote...
I would appreciate if you could send a lisp routine which will draw batt insulation on curves.
Linetype has limitations: when change ltscale batt insulation linetype width change.
Thanks
johny
Message 6 of 26
stevelander
in reply to: Anonymous

Try using the attached dynamic block. It's made at a height value of 1 so the scale can be adjusted to suit the height of insulation required.
This is by fay the best way of drawing insulation I have come across.
Cheers,
Steve.
Message 7 of 26
johnypd
in reply to: Anonymous

dynamic block can be used for linear lines only. it does not support for curve lines.
Message 8 of 26
stevelander
in reply to: Anonymous

Who said it did support curved lines?

It does however support repetition of a shape which is how this block works.

Maybe it would be better to look properly at what is being suggested before commenting.
Message 9 of 26
johnypd
in reply to: Anonymous

Hi
I couldnt download the insulation.dwg file. could you please send it to my email - johnypd@hotmail.com. thanks
Message 10 of 26
stevelander
in reply to: Anonymous

I sent it to your email address Johny.

I'll upload the file again also.
Message 11 of 26
stevelander
in reply to: Anonymous

To download, right click and 'Save Target As'.
Message 12 of 26
Anonymous
in reply to: Anonymous

[It's not that anyone said dynamic blocks support curved lines. The issue is that the original
question was about representing batt insultation *on curves*, so something that can't do that is of
no use. To paraphrase: maybe it would be better to look properly at what is being asked before
suggesting something.]
--
Kent Cooper


wrote...
Who said it did support curved lines?

It does however support repetition of a shape which is how this block works.

Maybe it would be better to look properly at what is being suggested before commenting.
Message 13 of 26
Anonymous
in reply to: Anonymous

wrote:

>> This is by fay the best way of drawing insulation I have come across.

I don't know if I can agree with that. The polyline in the anonymous block that holds the geometry for each insertion is copied when you change the length.

When you stretch your block to a length of 10', it produces 60 copies of the polyline in the anonymous block (with the insertion scale at 4.0, that is).

You would have much less baggage in your drawings, if you use an MINSERTed regular block, with 1 row by N columns, where N = the desired length of the insulation. With an MINSERT there is no duplication of the polyline at all.

--
http://www.caddzone.com

AcadXTabs: MDI Document Tabs for AutoCAD 2008
Supporting AutoCAD 2000 through 2008
http://www.acadxtabs.com
Message 14 of 26
Anonymous
in reply to: Anonymous

On Tue, 29 Jan 2008 18:56:55 +0000, Tony Tanzillo
wrote:

>>> This is by fay the best way of drawing insulation I have come across.

>I don't know if I can agree with that. The polyline in the anonymous block that holds the geometry for each insertion is copied when you change the length.
>When you stretch your block to a length of 10', it produces 60 copies of the polyline in the anonymous block (with the insertion scale at 4.0, that is).
>You would have much less baggage in your drawings, if you use an MINSERTed regular block, with 1 row by N columns, where N = the desired length of the insulation. With an MINSERT there is no duplication of the polyline at all.

The "duplication" of the polyline is really insignificant to the benefit gained,
particularly if you first use a "unit" batt symbol to seed the dynamic block and
array it with the stretch action. You in effect get the same efficiency results
of MINSERT with the on-screen stretchability of using DBs. Otherwise you have to
use Properties to change the numbers of row/columns by hand.

But even with polylines, the DB approach works great - particularly in small
scale drawings like details where a batt symbol is most likely to be used.
The main benefit that I see is that you can bound the batt insulation DB with a
polyline and used XCLIP to have it infill nicely, particularly where you have
break lines.

However, for building sections or other larger-scale drawings, probably the best
approach is that taken by AutoCAD Architecture's Batt Insulation tool, which
offers tapering and elegant looking graphics around curves and such. It's still
a polyline, or course, so editing it is a total PIA.

Matt
mstachoni@verizon.net
mstachoni@bhhtait.com
Message 15 of 26
Anonymous
in reply to: Anonymous

"Matt Stachoni" wrote

>>>>>>>
The "duplication" of the polyline is really insignificant to the benefit gained,
particularly if you first use a "unit" batt symbol to seed the dynamic block and
array it with the stretch action. You in effect get the same efficiency results
of MINSERT with the on-screen stretchability of using DBs. Otherwise you have to
use Properties to change the numbers of row/columns by hand.
<<<<<<<<

I disagree. Using a dynamic block for this is essentially like inserting a single block/polyline directly and copying/arraying it.

The anonymous 'proxy' block that is created for each unique instance of the dynamic block reference, contains copies of the unit polyline. Whether it is a polyline, or a block containing a polyline, there is still duplication of the entity in the database, equal to what you would have if you exploded them all.

The only benefit gained from using a dynamic block in that way, is the abiilty to easily stretch the block to change the length of the batting, which is something that LISP routines that use MINSERTed blocks have been able to do for many moons, and without the excess baggage.

The 'excess baggage' is not just a matter of increased file size, it also has greater overhead for things like drawing regeneration, as compared to an MINSERTEd block. An MINSERTed block can optimize drawing, because it only needs to draw the block's defining geometry once, and then transform it as many times as needed.

--
http://www.caddzone.com

AcadXTabs: MDI Document Tabs for AutoCAD 2008
Supporting AutoCAD 2000 through 2008
http://www.acadxtabs.com
Message 16 of 26
Anonymous
in reply to: Anonymous

On Thu, 31 Jan 2008 20:14:43 +0000, Tony Tanzillo
wrote:

>"Matt Stachoni" wrote
>
>>>>>>>>
>The "duplication" of the polyline is really insignificant to the benefit gained,
>particularly if you first use a "unit" batt symbol to seed the dynamic block and
>array it with the stretch action. You in effect get the same efficiency results
>of MINSERT with the on-screen stretchability of using DBs. Otherwise you have to
>use Properties to change the numbers of row/columns by hand.
><<<<<<<<
>
>I disagree. Using a dynamic block for this is essentially like inserting a single block/polyline directly and copying/arraying it.
>
>The anonymous 'proxy' block that is created for each unique instance of the dynamic block reference, contains copies of the unit polyline. Whether it is a polyline, or a block containing a polyline, there is still duplication of the entity in the database, equal to what you would have if you exploded them all.
>
>The only benefit gained from using a dynamic block in that way, is the abiilty to easily stretch the block to change the length of the batting, which is something that LISP routines that use MINSERTed blocks have been able to do for many moons, and without the excess baggage.
>
>The 'excess baggage' is not just a matter of increased file size, it also has greater overhead for things like drawing regeneration, as compared to an MINSERTEd block. An MINSERTed block can optimize drawing, because it only needs to draw the block's defining geometry once, and then transform it as many times as needed.

Drawing regeneration is, for the most part, a problem that has long been solved
with hardware and display list advances. No one worries about regen times
anymore.

And if you do have issues with regen times because of how inefficient and
bloated your drawing is, you have bigger problems than this piddly little
example - your system isn't going to tank just because you use DBs that
implement arrays.

Regardless, I think for almost all instances that the excess baggage of Dynamic
Blocks is simply a worthwhile price to pay for their advantages over MINSERT:

1. You can readily explode DBs, you cannot explode MINSERTS
2. The graphic onscreen grips and UI feedback with DBs is built in; you would
have to specifically code this into a similar MINSERT implementation which still
wouldn't be as easy to use;
3. Most normal human beings understand how to use DBs than MINSERTs;
4. You cannot use MINSERT with Annotative Blocks 😞

Matt
mstachoni@verizon.net
mstachoni@bhhtait.com
Message 17 of 26
Anonymous
in reply to: Anonymous

>"Matt Stachoni" wrote

>>
Drawing regeneration is, for the most part, a problem that has long been solved
with hardware and display list advances. No one worries about regen times
anymore. <<

I think you're misunderstanding what I mean by 'regeneration', which is probably my fault because 'drawing regeneration' is misleading.

Perhaps the term 'object regeneration' is better, because by 'regeneration' I do not mean the need to do REGENs; issue the REGEN command; or regenerations induced by zooming/panning beyond the current extent of the virtual display.

Whenever an object in a drawing is modified, its display graphics must be regenerated. The overhead of that affects the performance of many aspects of usage that have nothing to do with a complete drawing regeneration or the use of the 'REGEN' command.

Just about any operation that involves creation, duplication, modification or erasure of entities requires that the affected objects be regenerated, and the cached display geometry (e.g., the 'display list') updated. For example, issue the MOVE command and select all objects in the current space, and give a displacement. To complete that operation, a regeneration of every object that was moved is required, and the 'display list' neither eliminates the need for it, or makes it happen any faster.

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.

Unfortunately, a 'display list' has no role in how long it takes to regenerate entities in the context of routine operations that involve object creation and/or modification, so yes, 'object regeneration' and its overhead are most definitely relevant, and not mitigated by use of a 'display list'.

>> And if you do have issues with regen times because of how inefficient and
bloated your drawing is, you have bigger problems than this piddly little
example <<

The piddly little example is precisely that - an example (one of many), of 'bloat' that in aggregate, can have a major impact on overall system performance, and for which display lists cannot remedy.

>> 1. You can readily explode DBs, you cannot explode MINSERTS <<

I see no need to explode this particular type of block. For what reason? If for example, I needed to insert an opening in a wall with batt insulation, then I just have to modify the original MINSERT, or replace it with one or more new ones with column count adjusted as needed. No big deal.

>> 2. The graphic onscreen grips and UI feedback with DBs is built in;
>> you would have to specifically code this into a similar MINSERT
>> implementation which still wouldn't be as easy to use.

Right - and I think that's an equitable price to pay in order to avoid the kind of baggage that you presume to be insignificant or irrelevant to system performance.

>> 3. Most normal human beings understand how to use DBs than MINSERTs;

I don't agree with that either. MINSERTs have been around for ages, and most of the users I know understand them, because they've been using them for things just like this all along, long before dynamic blocks showed up. Most of them have already perfected automation for manipulating them, which makes that just as simple and easy as DBlocks, for this specific purpose.

>> 4. You cannot use MINSERT with Annotative Blocks 😞

I don't see a need for it in this case. Batt insulation is not annotative in nature.

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 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.

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

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.

--
http://www.caddzone.com

AcadXTabs: MDI Document Tabs for AutoCAD 2008
Supporting AutoCAD 2000 through 2008
http://www.acadxtabs.com
Message 18 of 26
Anonymous
in reply to: Anonymous

>"Matt Stachoni" wrote

>>
Drawing regeneration is, for the most part, a problem that has long been solved
with hardware and display list advances. No one worries about regen times
anymore. <<

I think you're misunderstanding what I mean by 'regeneration', which is probably my fault because 'drawing regeneration' is misleading.

Perhaps the term 'object regeneration' is better, because by 'regeneration' I do not mean the need to do REGENs; issue the REGEN command; or regenerations induced by zooming/panning beyond the current extent of the virtual display.

Whenever an object in a drawing is modified, its display graphics must be regenerated. The overhead of that affects the performance of many aspects of usage that have nothing to do with a complete drawing regeneration or the use of the 'REGEN' command.

Just about any operation that involves creation, duplication, modification or erasure of entities requires that the affected objects be regenerated, and the cached display geometry (e.g., the 'display list') updated. For example, issue the MOVE command and select all objects in the current space, and give a displacement. To complete that operation, a regeneration of every object that was moved is required, and the 'display list' neither eliminates the need for it, or makes it happen any faster.

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.

Unfortunately, a 'display list' has no role in how long it takes to regenerate entities in the context of routine operations that involve object creation and/or modification, so yes, 'object regeneration' and its overhead are most definitely relevant, and not mitigated by use of a 'display list'.

>> And if you do have issues with regen times because of how inefficient and
bloated your drawing is, you have bigger problems than this piddly little
example <<

The piddly little example is precisely that - an example (one of many), of 'bloat' that in aggregate, can have a major impact on overall system performance, and for which display lists cannot remedy.

>> 1. You can readily explode DBs, you cannot explode MINSERTS <<

I see no need to explode this particular type of block. For what reason? If for example, I needed to insert an opening in a wall with batt insulation, then I just have to modify the original MINSERT, or replace it with one or more new ones with column count adjusted as needed. No big deal.

>> 2. The graphic onscreen grips and UI feedback with DBs is built in;
>> you would have to specifically code this into a similar MINSERT
>> implementation which still wouldn't be as easy to use.

Right - and I think that's an equitable price to pay in order to avoid the kind of baggage that you presume to be insignificant or irrelevant to system performance.

>> 3. Most normal human beings understand how to use DBs than MINSERTs;

I don't agree with that either. MINSERTs have been around for ages, and most of the users I know understand them, because they've been using them for things just like this all along, long before dynamic blocks showed up. Most of them have already perfected automation for manipulating them, which makes that just as simple and easy as DBlocks, for this specific purpose.

>> 4. You cannot use MINSERT with Annotative Blocks 😞

I don't see a need for it in this case. Batt insulation is not annotative in nature.

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 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.

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

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.

--
http://www.caddzone.com

AcadXTabs: MDI Document Tabs for AutoCAD 2008
Supporting AutoCAD 2000 through 2008
http://www.acadxtabs.com
Message 19 of 26
Anonymous
in reply to: Anonymous

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
Message 20 of 26
Anonymous
in reply to: Anonymous

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

Can't find what you're looking for? Ask the community or share your knowledge.

Post to forums  

Autodesk Design & Make Report

”Boost