Open dotoritos-kim opened 1 year ago
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.
No need to be sorry. You are working really hard!
@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.
block
is some group of entities #refblock
s: one related to Model Space and the other related to Paper Space.dxf-viewer
wants to render Model Space onlydxf-viewer
so user may think: why not for block?Therefore I'd like to ask followings:
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 :)
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.
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.
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).
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.
I would also be interested in the model/layout space feature. Has someone already started implementing this?
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 :)