Ignore invisible entities from dynamic blocks?

[cmurphy23]

The current version of the parser doesn't look for group code 60, which indicates whether an entity is invisible. This causes an issue for dynamic blocks. Basically, when a drawing with dynamic blocks is exported, the resulting DXF seems to have anonymous blocks for each configuration of the dynamic block. Within those anonymous blocks, the invisible entities will have group code 60 set to 1.

My current hacky workaround is to look for group code 60, set a field on the entity object accordingly, and in the ParseEntities function to just not push invisible entities on to the array after parsing them. However, there may be occassions where it's desired for invisible entities to be present on the data structure, but just not rendered?

Let me know what you think is best, if the desired behavior is something I think I can code, I can try to make a PR.

[vagran]

Thanks for your finding! As I see, the parser currently parses this group code here. However, this result is not used in the scene builder code. So yes, I will make it to respect this field and discard such entities. Currently, the library is viewer-only, focused exclusively on fast rendering of the input DXF, so perceiving such entities is not needed now. It would be nice if you could provide some example file with hidden entities for testing.

[vagran]

@cmurphy23 It would be great if you could check if the fix above works for you.

[cmurphy23]

The file is also not my property, so I can't share it directly. However, the code in the ParserHelper is pretty much identical to what I wrote (I just used invisible as the property instead of hidden), and using the _FilterEntity method instead ignoring the entity in ParseEntities works properly when I test it on the file.

We are using a modified version that we forked last year for an internal tool, it doesn't have the ParserHelper yet, though I hope someday we can merge the latest in. We have implemented the ability to programatically change the color of blocks, layers, and entities, and added basic interactivity. Unfortunately, our code isn't very clean, and it also has a bunch of stuff specific to our work, so I don't think we could reasonably open a PR. However, if you're interested in any of the implementations I'd be happy to explain the methodologies and share relevant code!

Thanks again for this awesome project!

[vagran]

it doesn't have the ParserHelper yet

That sounds strange, this file is here from the beginning of the project. Maybe you have refactored that code and deleted it in your fork.

Unfortunately, our code isn't very clean, and it also has a bunch of stuff specific to our work, so I don't think we could reasonably open a PR.

You are right, I actually accept only straightforward PRs with some small fixes or really clean implementation of new simple features. Anything beyond that can be used just as reference for reimplementing it, so that it corresponds to the existing codebase approaches. Otherwise, it might become almost impossible to maintain this project (in more-less acceptable manner) with VERY limited resources (like just me for 1h per week or less).

However, if you're interested in any of the implementations I'd be happy to explain the methodologies and share relevant code!

There was a relevant discussion about possible implementation of such features in potential future major version. You can share experience there or here indeed. Also, it might be useful to inspire someone for a fork with this functionality.