AnsweredAssumed Answered

TBC v5.0 - Handles blocks a lot better

Question asked by Patrick L'heureux on Nov 30, 2018
Latest reply on Dec 7, 2018 by Patrick L'heureux

Like • Show 1 Like1
Comment • 10

I just wanted to verify that TBC v5.0 seems to be handling blocks a lot better. I used to battle blocks because I would get a lot of blocks that had nested entities on the 0 layer, so when you exploded blocks you would get a bunch of data on the zero layer that you would have to manual sort through. I am surprised that this didn't make the release notes, if so, but I do understand there was probably a lot to cover. I went through 6 old projects yesterday (importing the original CAD files and running through the standardize function) and could not replicate the issues I used to have with versions earlier than TBC 5.0.

Thank you TBC team!!!! This has made the standardize process a lot faster and smoother.

No one else has this question

Outcomes

10 Replies

Alan Sharp Nov 30, 2018 4:11 AM
Mark Correct
Correct Answer
Awesome

Glad that we are doing some good stuff for you all in Development. Thanks Pat for sharing this, the developers love an Attaboy from time to time, and it is better coming from users that appreciate what they are doing

Really appreciate your efforts on the Forum Pat

Alan
Like • Show 2 Likes2
Actions
- Patrick L'heureux @ Alan Sharp on Dec 6, 2018 8:44 AM
  Mark Correct
  Correct Answer
  I did some in depth testing on this today and it appears that you end up with a lot more block entities on the 0 layer or "prefix" 0 layer when you had a prefix when importing a dwg. I tested this four times; raw file from from engineer, raw file from engineer with adding prefix to layers, converted file from civil 3D, converted file from civil 3D with adding prefix to layers and in both cases where I added prefixes to layers I ended up with substantially more entities going to the "prefix"-0 layer.
  
  I am going to request a macro to relayer block entities that have either a 0 layer for the entities or "prefix"-0 layer to make this process quicker.
  
  Could this be look into in the future for the import process?
  
  Thanks!
  Like • Show 0 Likes0
  Actions
  - Patrick L'heureux @ Patrick L'heureux on Dec 6, 2018 9:21 AM
    Mark Correct
    Correct Answer
    The dwg with the prefix "ACAD-" is the "clean export I did from civil 3D. The other is the original CAD drawing I received from the engineer.
    Attachments
    BC Blocks Demo.zip18.2 MB
    20181205_W2157-CG-DSGN.dwg8.2 MB
    ACAD-20181205_W2157-CG-DSGN-Model.dwg709.2 KB
    Like • Show 0 Likes0
    Actions
Alan Sharp Dec 6, 2018 9:03 AM
Mark Correct
Correct Answer
Please add your test file to the posting so that our QA team can validate and comment

Alan
Like • Show 0 Likes0
Actions
Alan Sharp Dec 6, 2018 2:17 PM
Mark Correct
Correct Answer
Question
I have been looking at the issue here and have discussed with development.

1) We use a library product to do the "AutoCAD Stuff" in TBC. so the "Exploding" is done in the library - we send things to it and it returns the data to the database so it isnt quite so easy to do what you are asking about relayering block entities that would end up on Layer 0 to the Layer of the Block. However it would be possible to write a separate command that serves up the blocks one at a time to the engine and then relayer the data on return to the Block Layer so we could potentially write a second Explode command that behaves differently - we may be able to combine the two into the existing command but we need to evaluate that.

2) When you prefix the Layers, we could treat Layer 0 differently and not prefix that layer. This we think would solve the issue with more objects showing up on Layer 0 after the Explode command - we are going to test that to see if that would at least result in the same behavior and we are looking at what specifically is causing this effect that you are seeing. We think it is because data drawn on Layer 0 and Blocks that are created on Layer 0 have different operational characteristics so we have to be careful we dont break something here. Main challenge with this approach is that all Layer 0 data from all imported DWG files would end up on Layer 0 - that is OK if you Relayer all that stuff after import to other Layers thereby leaving Layer 0 Empty after each round of Import, however if you did not do that you would now have layer 0 data from various batches of import all on the same layer because that is not getting prefixed.

Let me know what you think on this question. As with all these types of request the devil is in the details and I want to make sure that if we do something here that we do it the best way possible.

Again no promises - the team is busy right now and if this is a bigger deal than a "quick fix" it will end up on the request list with many other things sitting out there.

Alan
Like • Show 0 Likes0
Actions
- Patrick L'heureux @ Alan Sharp on Dec 7, 2018 3:23 AM
  Mark Correct
  Correct Answer
  Alan,
  
  This sounds good to me. If the import takes a little extra time (I believe we would be talking seconds correct? might even be unnoticeable) that is fine with me if it saves manual manipulation. Or would this command be a separate command in BC such as a command in Project Cleanup.
  This sounds good as well.Currently everything is going to my "Prefix"0 layer, so if we can send it to the 0 layer but reduce the entities that end up there, I have no problem with that. I try to keep nothing on the zero layer anyway. I treat this as a "broken" catch all. After I import a file I try to get all of the data on logical layers and clean up the linework. If I can't think of where to associate data, I will usually through a z in front of the layer and assign this to a misc view filter for later use. So the work flow you are presenting would fit into this without any serious alterations to my workflow.
  
  Thanks,
  Pat
  Like • Show 0 Likes0
  Actions
Alan Sharp Dec 6, 2018 2:37 PM
Mark Correct
Correct Answer
We have a test file now that ;eaves Layer 0 alone

1) There are only 66 Objects on Layer 0
2) All the other Blocks that are on other Layers are still invisible when you isolate Layer 0
3) When you explode the Blocks you end up with objects on Layer 0
4) All the Block Data that was defined on other Layers is now on the other prefixed Layers after explode

This is as per the import without Prefixing. This would minimize the number of objects that you have to relayer until we can address the Explode option. DOes this help / Make sense.

Alan
Like • Show 0 Likes0
Actions
- Patrick L'heureux @ Alan Sharp on Dec 6, 2018 3:28 PM
  Mark Correct
  Correct Answer
  I believe I follow you. 3 and 4 are throwing me off a bit though.
  
  3) When you explode the Blocks you end up with objects on Layer 0. - Does this mean you ended up with no objects on the 0 layer?
  4) All the Block Data that was defined on other Layers is now on the other prefixed Layers after explode - here you mention prefixes, below you mentioned this process was executed without using the prefixing import on. If you wouldn't mind clarifying this.
  
  If the standard import was able to address blocks and bring this to reasonable minimum (like you mention above) if not zero, this would save me a lot of time and I wouldn't mind scarifying prefixes on import. Maybe a macro (short term fix) or a command (long term depending on the complexity of this issue) could be written to take layers in BC and add a prefix (Gary wrote a great macro that copies linework and adds a prefix to the layers for things such as phased projects :TML - Copy Layer Group Members ) this would do the same thing as what I am doing currently but in a different series of events and saving me quite a few steps and manual manipulation.
  
  My biggest use for prefixes is so that the engineer's data does not flood in with my layers and I use prefixes to keep track of revisions.
  
  Thank you.
  Like • Show 0 Likes0
  Actions
  - Alan Sharp @ Patrick L'heureux on Dec 7, 2018 7:26 AM
    Mark Correct
    Correct Answer
    We made a minor change to the TBC DWG / DXF Importer. That when you say
    Prefix Layers all layers except Layer 0 get prefixed. Because Layer 0 has
    special meaning in the AutoCAD world, prefixing it changes the meaning of
    data assigned to Layer 0 and the way that it behaves. Of course sometimes a
    user deliberately uses Layer 0 and sometimes they use Layer 0 by mistake -
    we will never know which they intended of course.
    
    When we prefix all layers except Layer 0 then we get the exact same
    scenario that you have in your video when you dont prefix the layers. There
    is little data specifically drawn on Layer 0, and when you explode blocks
    you get some data that falls out of Blocks inserted on other layers that
    have lines embedded on Layer 0, but it is the same amount as you had in
    your example of non prefixed layer import.
    
    That means that today I have to clean up those 500 or so items not the 2500
    or so items. I would have to clean out Layer 0 after each import so that
    the next import with different Prefix would then start the process over
    again.
    
    We are going to look at how fast a process would be where we send the
    selected Blocks to the Exploder one by one so that we can control the
    layering of the data coming back.
    
    The question we had though is that if the Block was placed on a Layer
    called Block, and has embedded linework on Layers 0, Fred, George and
    Harry, when we relayer the data coming back should we leave all but Layer 0
    as is and relayer the Layer 0 data to the Block Insert Layer, or should we
    relayer all of the data coming back to the same layer as the Block Insert
    Layer?
    
    We are thinking that because the current Explode Command behaves the same
    way that AutoCAD behaves we should leave it as is and if we need an Explode
    Block Command for Data Prep that behaves quite differently that we likely
    should do that as a separate process.
    
    Alan
    
    On Thu, Dec 6, 2018 at 4:29 PM plheureux@severinotrucking.com <
    Like • Show 0 Likes0
    Actions
    - Patrick L'heureux @ Alan Sharp on Dec 7, 2018 8:50 AM
      Mark Correct
      Correct Answer
      Alan that sounds great. Thank you for addressing this. I would much rather work with 500 entities vs 2500 entities.
      
      In regards to the blocks that have a mix of entities on different layers, I would recommend only relayering entities that are on layer 0. The entities on layers are essential "smart data" where as entities on the zero layer are "dumb" data. I would rather the layered entities go to their intended layer and then I can decide later if I want to change these using the Standardize tool or relayer tool. Sometimes the separation of layers is useful. Every now and then I will receive xrefs as blocks and if everything was relayered this block would become useless.
      
      Another example would be for instance on a cistern, there is some linework that I will need and my field crews will need for design and build purposes. There is some linework that is unnecessary such as mechanical joints. If the blocks are prepared correctly(cross your fingers), those different style entities should go to different layers making it easier to cleanup versus everything getting dumped to a cistern layer and manually deleting components over deleting layers.
      
      I understand there may be a use for relayering all the block entities to the block's layer but I would recommend this as a separate command because I think it has the potential to create more work in certain situations if this was integrated into the import process.
      
      Like • Show 0 Likes0
      Actions

TBC v5.0 - Handles blocks a lot better

Outcomes

Attachments

Related Content

Recommended Content