AcDb3dSolid & Save / Load Drawing Filing - Not Working?

[jason.teagle]

I'm using an AcDb3dSolid as an embedded object so that it can't be selected independently of the parent object. Thus, I am manually passing on calls such as worldDraw(), transformBy(), etc.

I'm also filing it out and in by calling its dwgOutFields() and dwgInFields() at the approriate time. I can confirm that it calls the dwgOutFields() method and returns eOk, and I can confirm that on loading the rawing back it calls dwgInFields() and returns eOk - and yet the body has zero volume after loading.

There *doesn't* seem to be a problem with undo filing - I can move entities with embedded solids and U moves them back; I can erase them and U brings them back.

The bodies remain in the drawing after saving so it's not as if they're being obliterated by the save or anything weird.

Any idea why trying to save a drawing and load it back brings them back with no body? I can't see the point of having filers for the object if they don't do anything in a drawing file.

[jason.teagle]

An exra piece of information: if I go back to having the solid as a database-resident owned object, filing *does* work - but it is now using its own internal means of filing the object in and out (we just file in / out a soft pointer ID and it does whatever it does internally).

So it seems to be that it is not database resident that is the problem. Why should filing out a non-DBR solid with a valid volume file it back in with zero volume? That seems to break the contract of filing in, which should be to reconstitute the object exactly as it was filed out.

[owenwengerd]

Just a guess, but you might try setDatabaseDefaults() and/or copyFrom(your-main-entity) before filing the solid out.

[artc2 · Accepted solution]

Which version of AutoCAD are you using?  In Acad 2013 there is a bug that causes the solids data to not be saved for embedded solids (i.e. solids that are not database resident).  I am currently working on a fix, but do not yet have it done.

[jason.teagle]

I should have mentioned... I was trying it in 2013... that explains it! Thanks for the reply.

[jason.teagle]

On a somewhat related note, I have a test drawing with roughly 3500 of these solids (as DBR objects owned by other custom objects) and something like another 5000 other objects. In the real world for our line of business customers could easily have drawings of this magnitude and worse.

The problem is that on loading the drawing, it takes about 9 seconds to reach 93% (perfectly acceptable), and then it sits there for 150 seconds(!) doing what appears to be memory management. This is not so acceptable for a customer.

If I try to create a representative equivalent drawing using plain solids directly inserted via AutoCAD (3500) and ~5000 lines representing our other custom objects, it takes 66 seconds to get to 93% but only another 12 to finish that last bit. Quite why our drawing takes so much longer at the end, or why the pure AutoCAd object one takes longer to reach 93% is a bit of a mystery since this timing is before the load has finished and to my knowledge no extra work of ours was being performed during that time (I would have to check more closely to be sure), but even for a pure AutoCAD object drawing (no custom objects), over a minute is still a little excessive.

Closing the drawings produces a comparable wait while (presumably) it manages the memory being cleaned up.

Any suggestions as to what might be causing so much memory management? From a layman's point of view I would have expected most of the memory allocation to be done while making room for filing in the objects.

If I load the pure AutoCAD object drawing first, then close it, and in the same AutoCAD session try and load our drawing... it takes upwards of 8 *minutes* after that 93% point, implying that it is struggling to allocate memory (possibly because it has become very fragmented from the previous load?). If there's anything we can do to help alleviate this problem I would be grateful to know.

[jason.teagle]

For comparison, using AModeler::Body as an (almost) drop-in replacement for AcDb3dSolid in our test drawing with our objects, the load time is 7 times faster. Which is a shame, because AModeler::Body was *so* prone to throwing ErrorCode exceptions all over the place, whereas tests indicated that AcDb3dSolid is 100% more robust - which is why we tried to use it (that and the fact that it follows proper entity semantics).

[owenwengerd]

I expect that interobject references account for a lot of the differences you notice between the AcDb3dSOlid vs. Amodeler scenarios. I can think of some possible things to try in order to reduce the effect, but I think your best bet is to use a profiler (GlowCode is the only one that works as far as I know) to see if you can pinpoint the worst bottlenecks.

[jason.teagle]

Thanks for the GlowCode recommendation - I will give it a try. It may be useful even if it can't solve this problem, as speed is an issue for our customers as always.

Can you possibly explain what you meant by the interobject references? I wasn't quite following. The solids version was a DBR AcDb3dSolid whose ID was referenced by the parent object. The modeller version was the same parent object, but it simply held a Body object (so no ID in this case). They were #defined throughout the parent object's code to ensure one didn't get in the way of the other. Is it this one layer of ID stored in the parent that you think is the problem?

I would love to stick to the non-DBR solution (since it solved the selection set issue) but given the informtion about the problem with 2013 we cannot use it until a service pack is available. Well... we could, but we'd have to rebuild the body on filing in and that would only add to the speed hit {:v(

[owenwengerd]

Yes, I did mean the reference from the owning entity to the owned DBR solid. There are other ways to work around the filing problem (too involved for a forum like this). Based on all you have said, I would pursue a non-DBR approach rather than impose on your end users all the direct and indirect costs of using DBR solids.

[fenton.webb · Accepted solution]

The full solution is posted here http://adndevblog.typepad.com/autocad/2012/08/my-custom-entity-embedded-acdb3dsolid-not-displaying-a...

[jason.teagle · Accepted solution]

Thank you very much.