What if I want to select only specific blocks?

[dotoritos-kim]

The web browser sometimes freezes when opening a file with too many blocks. It was my mistake. So, I would like to ask how can I render only certain blocks. Looking forward to your kind reply from Mr. Vargan :)

[vagran]

Probably this is follow-up of this issue in the example repository. Sorry, I was a bit busy with other projects so did not have much time to spent on dxf-viewer. Hoping, I will get back soon. Regarding this issue, assuming you want to select specific sheets (or layouts, may be blocks, do not yet know what is proper term) to render. As I mentioned before in other issues, it is quite fundamental change. First, need to analyze all details about representation in DXF file and all related coordinates transformations. There is a separation between model space (what dxf-viewer is currently drawing) and paper space which is not currently implemented. There may be entities defined in the paper space, and also so called "viewports" to the model space which also is a thing which requires some implementation. It is also possible, that this functionality is quite overkill for dxf-viewer library which was supposed to be a simple dxf rendering library, but with the requests like this it is moving towards some CAD-like application which it was not intended to be initially. However, when I will have some time, I will try to do some feasibility study on this feature.

[dotoritos-kim]

No need to be sorry. You are working really hard!

[dotoritos-kim]

@vagran

may I help you with this issue? While you're working with renderer of #36, I glampsed this a little bit. After reading some histories related to this, first I'd like to wrap up everything clearly.

1. block is some group of entities #ref
2. There are two types of blocks: one related to Model Space and the other related to Paper Space.
3. dxf-viewer wants to render Model Space only
4. The problem are too many entities (which is part of block) to render, so he wants to hide some group of entities i.e. blocks.
5. There is layer-level toggle function in dxf-viewer so user may think: why not for block?
6. I need to render Paper Space part is not clear (I'll ask him later), but as you said it's seems to be out of scope as for now.

Therefore I'd like to ask followings:

1. Is it possible to toggle the visibility of blocks, which are related to Model Space only?
2. If it's not possible due to current parser sturcture (or whatever), then how hard is to fix such structure?
3. Does it conflict lots to the development of hatching?
4. If it's not practical to fix this directly, are there any alternatives like performance optimization using LoD approach?

Also thanks for your elaborations- I think there is no alternative to handle dxf rendering for opensource scene, which makes this project shiny.

p.s. I'm also thinking for solid fill :)

[vagran]

So what is your final intention? Do you want to hide entities which are defined in paper space? I am not sure if they are currently shown since, as by my current understanding, they are referenced only by blocks which instantiated from layouts which are currently not processed. So currently I think only model space entities are shown (may be I am wrong and still do not fully understand how paper space is organised in DXF). However if there is a file where paper space entities are currently shown together with model space ones, showing only one type is not difficult, but I doubt that this is exactly what you want to achieve, because as I mentioned before, full printable layout (sheet) consists of combination of some paper-space entities like frames, and one or more viewports to model space, which is currently quite difficult to implement. This is the feature I will consider, working on the next major release.

I think it should not conflict with hatching.

P.S. I plan to work today on hatching and hope to have some first result.

[dotoritos-kim]

So what is your final intention? Do you want to hide entities which are defined in paper space?

Oh nevermind what I've said above. they want to alter between model space and paper space... Yes, they want to render paper space also (but just one by one, not both at the same time)

full printable layout (sheet) consists of combination of some paper-space entities like frames, and one or more viewports to model space, which is currently quite difficult to implement.

Can you explain the reason of this? Maybe I can assist for it.

[vagran]

Can you explain the reason of this? Maybe I can assist for it.

Main reason is that it will require quite significant changes across all the code, as well as data structure changes, separating paper space and model space entities, introducing layouts with some convenient API for library users, introducing viewports concept. For example, hatch feature is quite complex to properly implement, but it is still localised, overall architecture and approach is not changed, it is just one more DXF entity to parse and render. For now, I have a project development plan, which states that the current implementation will not receive any really big features like this, just bug fixes and some smaller features, while all the rest is postponed for the next major release, where I want to migrate the project to TypeScript, modularize, refactor and clean up whole the code with all these new features in mind. Having TypeScript will decrease risk of introducing new bugs and making it unstable with such major changes, I already feel difficulties to make changes with JavaScript without breaking something. So implementing this feature now sounds like undesired risk of making the library unstable or/and less performant while this feature does not look really very wanted by the community. As well as prioritising this work over, e.g. working on the project refactoring, I believe not worth it if we are speaking for usefulness for whole the community. However, I still plan to implement it in the next major release.

On the other hand, it is a common approach, when some specific changes are wanted by some company for an open source project, to make a fork and implement them there. So I suggest you to stick with this approach for this feature now. I can consult you on any questions about current implementation of rendering pipeline, or my vision on overall changes needed to be done for this feature (however my vision may not be proper enough since I had not yet really made a detailed research on this topic).

[dotoritos-kim]

Thank you for your explanation. I understand your precedence and plans. I also thought about forking, but in point of view of future doubt I think waiting for your major update would be nice to each other.

[hansireit]

I would also be interested in the model/layout space feature. Has someone already started implementing this?