General

[vagran]

Place for any project-related questions and discussions.

[jdh-invicara]

This is a fantastic project. Thank you very much.

I think I already know the answer to this but... How much work would it take to make this a 3D viewer?

I'm guessing the answer is "a lot" / "too much for this project"? The only reason I'm asking is that I note that you're basing the rendering on three.js and using WebGL - so that gives me a glimmer of hope...

FWIW, I'm extremely impressed by the performance of the viewer. Using your example viewer project and a 400MB dxf (produced from a Rhino file) and it renders quickly (quicker than AutoCADs DXF TrueView desktop viewer!)

(Posting this as a discussion rather than an issue - is that kosher?)

[vagran]

Thanks for the nice feedback! Yes, the project is based on three.js but currently it is designed with 2D-only mode in mind. May be it would be feasible to support 3D-mode, but currently it is not clear for me, how much wanted is that use case, and what 3D-design should look like. So far I have seen just a few examples with just 3D-meshes. It should not be difficult to display just the mesh without all the rest entities, but is that what you want? Displaying all the DXF entities in 3D may be challenging and will require some significant effort. If you have any project in 3D, it would be nice if you could share some screenshots to see how typical DXF entities should look in 3D. Another problem is lack of example files. It is quite difficult to find some representative examples for 2D project, finding some publicly available for a 3D one seems to be impossible, especially regarding the fact that open-source/free CADs supporting DXF format are mostly 2D-only (like QCAD and LibreCAD).

In general, I am currently gathering all the feedbacks and use cases, preparing to start work on a next major release, where I want to migrate the project to TypeScript, at the same time fully rewriting some components to achieve new capabilities, and refactor some core code to a certain degree, to make it possible to add future features with less effort, keeping in mind all missing features reported so far. I will think about 3D mode as well. However, this process is not quick, since I am working on this project just in my free time, so unfortunately I cannot commit on any timeframe.

It is OK to post in discussions, they are created exactly for that use.

[jdh-invicara]

Hi @vagran -

I completely understand about your timeframe. I'm capturing all this here for future consideration - with no expectations of when or if you consider it. However, if you have any commentary or suggestions I'd love to hear it.

Discussion of 3D feature

IMO, just displaying the mesh would be a big start (along with still being able to hide/show the layers as per your demo app). And then being able to orbit as well as pan and zoom. I also agree that many of the other features aren't as applicable to 3D.

The 3D feature I would like to add to dxf-viewer is to be able to display the 3D model and have the ability to orbit the camera. Additionally, the ability to optionally show a navigation cube (see below) would be a "stretch goal" :-) (ideally the navigation cube would be provided as a separate widget)

3D view from Autodesk DWG TrueView 2024 (What I would like to see from a 3D version of dxf-viewer)

Discussion of my use case

FYI, my use case is that I want to take DXF files saved from BIM tools (like AutoDesk Revit) or design tools (like Rhino), review the full file with the viewer and then the user would select a subset of layers and then create an output file with info from the "layers of interest". The output file would initially be a JSON file to import into other tools in a workflow. I want to use your viewer because it's easier for the user to visually identify the "layers of interest" rather than having to know layer names - and we often don't receive the source model just the DXF export of the complete thing. I can also create a UX focused on this simple workflow rather than telling them to use the complete CAD tool.

Additional capabilities of this tool which would be added later could be (a) to save a valid DXF file with just the "layers of interest" and (b) be able to select subset of geometry from a layer and (c) using attribute data to "auto select" the layers that contain "entities of interest" (e.g. This layer contains things labeled "walls" and this layer contains things labeled "doors").

Your example project covers all the "heavy lifting" required for my use case (parsing and viewing) - I only have to create my output JSON :-) Now, if only you'd written it using React not Vue... (Just kidding - I know I have to do some work myself!)

Attachments

Tiny office - dxfs.zip

[jdh-invicara]

FYI - I'm going to be sticking to 2D DXF files for the proof-of-concept for my use case described above.

[jdh-invicara]

FYI - I was able to successfully deliver for my project using a modified version of dxf-viewer. Many thanks!

[vagran]

@mirh1 I have seen your recent issue in three-dxf project. You can check this package instead. It renders your example file correctly, you can check it on the demo page.

[jdh-invicara]

FWIW I've created a React sample - here: dxf-viewer-react

There are still a few kinks to work out.

I'm not sure how best to "publicize" this for folks who prefer React than Vue. Some possibilities:

• Add to README.md of dxf-viewer and dxf-viewer-example-src
• Create a Discussion on dxf-viewer called "Apps using dxf-viewer" and encourage the community to list what they're working on
• Do nothing. If they want it they can find it. :-)

To be clear - I only want to "publicize" this React version so as to help potential dxf-viewer users get started with this awesome package. And I can't figure out how to submit a pull request for a new example app :-)

[vagran]

Cool! I can add the link to the README file indeed. Do you plan to deploy your example on Github pages?

[jdh-invicara]

I wasn't planning to deploy the example - unless you think I should? My thinking was that they can use your "official" example to see if DXF Viewer works for them. And then, if they prefer to develop in React, they can clone my project as a starting point.

Also, what would you think about me creating a dxf-viewer-react package with just the DxfViewerWrapper and DxfViewerWorker.js files in it. Then they could npm install dxf-viewer-react - which would be cool. I'd list dxf-viewer as a peer dependency. Thoughts? (If I did a package I'd rename my current repo as dxf-viewer-react-example)

[vagran]

I wasn't planning to deploy the example - unless you think I should?

It is up to you, I just asked for a case if I need to wait for it to include its link into dxf-viewer readme. I can just add the link to your repository if the deployment is not planned.

Also, what would you think about me creating a dxf-viewer-react package with just the DxfViewerWrapper and DxfViewerWorker.js files in it.

Sure, sounds good. It has already been several times when people asked about React examples in issues.

[jdh-invicara]

I'll create a dxf-viewer-react package and publish it - but I'll need to add font handling before I do that (my current example skips fonts).

However, at the moment I'm working on a proof-of-concept to convert DXF files into an intermediary format (JSON) to use in downstream tools.

[jdh-invicara]

In my application that uses DxfViewer I want to be able to highlight an entity in the rendered view.

This is how I'm thinking of approaching the problem:
1 Use GetDxf() to get the parsed DXF object and present lists of entities to the user
2 User selects an entity from the list
2.1 Calculate the bounding box of the selected entity from the coordinates in the entity in the parsed DXF object
2.2 Insert a bounding box into the rendered scene in a contrasting color

All the above is straightforward for me - apart from the last step (2.2). My question is how would it be best to insert a bounding box into the scene?

I can think of three general approaches:

1. Direct drawing onto a canvas object. This seems like the worst approach. A non-starter.
2. Using the three.js objects to manipulate the scene on the DxfViewer owned canvas. This seems like it would work but might be a lot of work and be recreating work that DxfViewer has already done. This could also be done independently of DxfViewer.
3. Create a new method for DxfViewer something like AddDxfFragment(fragment) - the fragment would be an object with the same schema as the parsed DXF file that would be merged into the existing dxf object. This command could create a new layer or add to an existing layer (depending on the entities in the fragment)

I think option 3 is the best approach. Do you agree?

With the implementation of this option, I could "brute force" things I think, and tear down the scene, merge in the new fragment and rebuild the scene from scratch. However, it strikes me one could be much more "surgical" in the approach and would only need to add to the pre-existing scene. Also, the more surgical approach might allow for dynamic drawing on the scene with the mouse (this isn't a requirement for my initial app but would be cool for "lassoing" objects in later versions)

I'm going to go ahead and start work on the brute force approach to option 3. This will allow me to complete my proof-of-concept app and my initial test files are small anyway!

I'd love to hear any and all input on any of the above - especially alternative approaches (in case I'm looking at the problem all wrong!)

[jdh-invicara]

All of what you say makes sense and makes me think that my approach (that I've already implemented) won't have much value to the general library.

It works for me because
(a) I have a limited use case (creating copies of entities on a new layer) &
(b) I am working with DXFs that have lots of layers but only a small number of entities per layer &
(c) my test file for proof-of-concept is particularly simple (so the tear down and re-render is not noticeable)

That last one is the most worrisome - so I'll also need to get a more representative DXF to work with.

FYI: My implementation is here (it's quite naive - but it works for my use case):

AddDxfFragment

Because of its limited usefulness I don't plan to submit a pull request.

[jdh-invicara]

Regarding this:

However, it is now clear, that people want to have each entity in DXF be somehow selectable and identifiable, this issue is about that. Current architecture does not store any information about source entities when preparing rendering batches, everything is optimized for maximal performance

We have a unique handle for every DXF entry. However, there's not a 1:1 mapping between the threejs created objects and the DXF entities. The most obvious example (for me) is how all the LINEs on a layer are combined into one LineSegements object. I'm not sure where the optimization comes from - reducing the number of batches or reducing the number of primitives (from 16 LINES to 1 LineSegment). I suspect it's the reduced number of primitives. In which case there seems to be a fundamental opposing goal i.e. "Do you want it fast, or do you want it individually addressable?"

I think it would be OK to reduce the separate LINEs in a block to a single LineSegements threejs primitive. That would be like saying "you can only select blocks as a single entity you can't select the individual parts of a block" - that might be a reasonable compromise?

These are just some observations I made while researching this issue. You may already have a better handle on this.

[vagran]

I'm not sure where the optimization comes from - reducing the number of batches or reducing the number of primitives

In terms of 3D pipeline, this is reducing number of batches. Each line segment is a rendering primitive, but the bottleneck is draw calls number, we want to upload all data to GPU, and draw by minimal number of calls.

However, there's not a 1:1 mapping between the threejs created objects and the DXF entities.

In which case there seems to be a fundamental opposing goal i.e. "Do you want it fast, or do you want it individually addressable?"

Yes, this is exactly the challenge which will need to be solved. I'm not gonna to make trade-off with the performance, it is one of the current key features of the dxf-viewer, changing this approach will most probably make it unusable with huge real-world files. So these batches will mostly be left unchanged. My initial idea is to add some additional data (CPU only) aside these batches, to make it possible to extract particular entity geometry from all batches produced by that entity. Then it will be possible to create a separate three.js geometry upon request, to draw it on top with a different shader, e.g. to highlight the entity, or use it to calculate bounding box. Thus the cost is only used CPU memory. For entity picking feature, additional GPU data (with entity IDs) will be added and additional rendering pass created, to render selection buffer. This will affect performance indeed, but I expect this effect be not so significant, and it should not be dependent too much on file size (not more than current rendering). Also these features will be controlled by options, to make it possible to opt-out increased memory consumption and lower performance for those who do not need it. One of the questionable topics is dealing with blocks for both entity picking and high-lighting. In AutoDesk viewer, they are selected and highlighted as top level block instantiation entities only (INSERT). There is no way to select nested blocks, or separate entities the block consists from. This is the easiest way, but still need to think if dxf-viewer will be able to offer something more advanced.

[jdh-invicara]

A few thoughts:

1. Glad to hear that no trade-offs for performance will be considered and that any possible impacts will be behind options.
2. Given the first point then as an easy first step could there be a "no optimization" flag that would simply preserve the 1:1 relationship between DXF entity and threeJS primitive? Sure, it would suck for big DXFs - but it would be beneficial for simpler files.
3. I think the redesign should continue to reinforce a good separation of concerns. As this is a DXF viewer I think the only thing this library should do after the DXF has been first rendered is to allow the user to reference a DXF entity by its handle and change the entity attributes or to add new valid DXF entities (including new layers). The viewer would then be responsible for figuring out what to change in its representation.
4. I have a concern that the "drawing on top" method you describe won't work very well for hiding entities (in 2D or 3D) and I'm not sure if it will work well with 3D (so this might be a decision point for this library to remain strictly 2D rather than add 3D support - although I vote for 3D support 👍 )

Regarding point 3: In other words, I don't think there's a "draw bounding box" function or a "highlight function" in the DXF viewer. As a library user I already have all the information I need to interrogate the DXF and with the existing pointer events - I can find what entities are under a mouse click (for 2D anyway - for 3D it will be trickier but it's just a more complex algorithm). Same for adding things like bounding boxes etc.

You mentioned in another thread that using the current internal representation of the parsed DXF will be difficult for more advanced features - that may be true but (a) that's the responsibility of the viewer library user not the viewer library & (b) if we need a better data representation that should be a separate "dxf manipulation library" (I stumbled over the python library ezDXF so maybe something like that for JS).

Just my 2 cents worth. Inflation adjusted.

[vagran]

Given the first point then as an easy first step could there be a "no optimization" flag that would simply preserve the 1:1 relationship between DXF entity and threeJS primitive? Sure, it would suck for big DXFs - but it would be beneficial for simpler files.

I will think about it. However, it should not end up in maintaining two different quite big branches of code paths. May be it would be enough to have API, which would be able to create separate three.js geometry by entity ID from rendering batches, as I described above. Then, if needed, whole the file can be converted into this representation, iterating all entities one by one. Quite suboptimal, but this is anyway suboptimal approach in general.

I think the redesign should continue to reinforce a good separation of concerns. As this is a DXF viewer I think the only thing this library should do after the DXF has been first rendered is to allow the user to reference a DXF entity by its handle and change the entity attributes or to add new valid DXF entities (including new layers). The viewer would then be responsible for figuring out what to change in its representation.

Changing attributes which affect visual representation would be tricky. The problem is that this significantly affects rendering batches structure. A batch groups primitives which share the same rendering state (one can call it "material", however there are also some other concepts like instanced rendering, which also result in separate batches). So changing entity attributes will cause its primitives to migrate from one batch to another, causing to rebuild the affected batches. However, I think, it will be possible, if combining this feature with this additional metadata which I mentioned above. This would be quite heavy operation, currently batches are built from parsing result in a web-worker. May be these rebuild operations may be moved in the web worker as well, to prevent UI (micro-)freezes on such requests. Entity hiding implies batches rebuilding as well.

Regarding point 3: In other words, I don't think there's a "draw bounding box" function or a "highlight function" in the DXF viewer. As a library user I already have all the information I need to interrogate the DXF and with the existing pointer events - I can find what entities are under a mouse click (for 2D anyway - for 3D it will be trickier but it's just a more complex algorithm). Same for adding things like bounding boxes etc.

Still the library can have some built-in "bells and whistles" for quick usage by library users which do not want to implement it and builtin functionality suits their needs. However, may be it is worth to create plug-ins functionality for that. From the other hand, designing good plugins API, providing all necessary extension points, is far from being trivial task, especially on this quite early stage of project evolution. One more point to think about.

You mentioned in another thread that using the current internal representation of the parsed DXF will be difficult for more advanced features - that may be true but (a) that's the responsibility of the viewer library user not the viewer library & (b) if we need a better data representation that should be a separate "dxf manipulation library" (I stumbled over the python library ezDXF so maybe something like that for JS).

Working on the library, I realized that this logic of converting parsed DXF into renderable geometry description is quite complex but very useful in some other possible tasks, for example, converting DXF into GeoJSON, SVG or whatever format. This is one of the factors affecting current design, DxfScene is actually such separated abstract geometry description, being then converted into three.js objects. Lack of strong typing is one of reasons why it is not somehow published and well known. May be it is worth to move it into a separate package, as well as plain parser (which was not initially done to simplify development, I am still not sure if it is already the time to do it and complicate the development, this is quite important factor for a project maintained by very limited resources).

[jdh-invicara]

Regarding migrating the next release to TypeScript. Please don't. I'm sure your mind is already made up. If so, then of course, that's cool. If you're on the fence - please don't.

Look at it this way - by not adding TypeScript you'll be able to put that extra time into new features. Are you convinced that implementing DxfViewer in TypeScript will bring a net productivity gain (over time).

I'm just a sample of one - but if this project had been written in TS I probably wouldn't have taken the time to contribute to it (I know they're only small contributions!)

I realize I'm swimming against the tide on this one!

[vagran]

My story is that I am mostly C/C++ programmer, so working with plain JS is quite uncomfortable for me because of lack of strong typing. I have started this project in JS because of two reasons - first, I was not familiar with TS at that moment (because as I mentioned, I am C/C++, not web at all :) ), second, it was initially written as a component for large corporate project which is JS only, and after that I asked my employer to open source it as a pay back to open source community, for literally thousands of open source npm packages used in that corporate project dependencies. Initially, when I had whole the code base in my mind, it was quite easy to modify the project, maintain and add new features (having JSDoc comments also helped) . But with a project grow, and working on it on irregular basis, when I do not longer remember well all the details of the implementation, it became quite difficult to modify some parts without breaking something, mostly because of dynamic typing nature of JS. Making some big architectural changes while maintaining high-quality of the code (I mean minimising probability of run-time exceptions) now looks almost impossible for me. Now I have some experience with TS and I think its a way to go, if we want this project would reach feature-wisely level of the AutoDesk viewer.

It is a good point about time wasting on refactoring instead of new features. That's true, however there is one more circumstance for me - I am working on this project while it is a fun for me. I am resting from my corporate tasks while working on it. It is a fun for me to try to make it ideal in terms of code quality in my humble opinion, and refactoring is part of that. And trying to maintain big JS codebase, rushing with new features, which somewhere conflict with current architecture, so requires some dirty hacks and quirks, this sounds more like corporate projects approach which is not longer so funny :). So I am just trying to maintain proper balance between personal fun and the project value for the community.

[jdh-invicara]

TL/DR; It's great you'll be converting to TS because that's what you want to do. Only read on if you want to understand more of my counterpoint. No persuasion intended.

---

My story is I'm (quite literally) a grey beard :-)

I started professional work with C and then transitioned to C++. I've done a lot of Delphi (Object Pascal) and Java too. The last decade has been web / JavaScript. I've done a myriad of other languages as well.

The balance of concerns when developing an open-source project should most definitely be heavily weighted by contributor preference - and as you've donated 99.9% of this then if you want TS then TS it should be. IMO, you don't have to justify it. I just raised the TS question in case you were more like "I suppose I should convert to TS" rather than "I want to convert to TS".

So read on only if you want to hear more of my views on TS. It helps me to write this stuff down for my own satisfaction. It's not meant to persuade you - I'm just sharing a point of view. And I love discussing points of view.

IMO, this library is in fact a better use case for TS than a lot of TS projects I come across. You have created a complex library (and it needs to be complex to achieve the results you have - it's no mean feat to be able to render a 400MB DXF file in less time than it takes AutoDesk's desktop viewer to do the same!). The more complex the code base the more it benefits from strong typing. There are more likely bugs that can be introduced and also there are different meanings to object names dependent on context so knowing types will help.

However, IMHO, TS won't help a newcomer to your project understand much. They need useful diagrams and descriptive commentary for that. One of my quirks is I love reading codebases and figuring out what they do and how they work. If you make the code less readable by adding TS types everywhere then that understanding becomes harder. Quite frankly I'd prefer it if you used reverse polish notation than TS!

So, I mostly dislike TS because it (a) reduces code readability, (b) requires yet more tooling to support & (c) is more verbose/finicky to code with.

I think I know all the standard arguments in favor of TS. However, the gains of TS don't seem to materialize much in the code that I write (which are front end apps that mash up other people's libraries :-) ). As a front-end developer of JS, I have a very tight code-compile-test-fix cycle - so common errors manifest quickly.

Here's an actual example. While refactoring code yesterday I wrote dxfViewer.addDxfEntities(entities) when what I needed was dxfViewer.addDxfEntities({entities}). Yes, a sophisticated enough TypeScript type definition would have caught that bug for me (but a naive TS adoption could have hidden it). However, it only took me 2 minutes with the debugger to figure it out (OK, I lied - It did take 2 minutes but I didn't bother with the debugger - just a console.log :-) ). And that's the thing - adding the addDxfEntities in TS along with making sure the type definition was correct would have taken me a lot longer than it took me to debug the problem. Although, I suppose, that's essentially a selfish world view - the type definition helps everybody whereas my l33t debugging skillz (heavy sarcasm) only helps me.

I don't like linters; I don't like the overuse of ===; and I don't like ; at the end of every line of code. Sure, all those things can help avoid unexpected errors - but just forcing people to use them doesn't teach them as much about what the errors are.

So, yeah... I'm one of those guys...

But I am trainable (just selfish!) - I finally shifted to VS Code (an IDE) rather than a text editor and the command line because it started to save me time.

It's all good though :-)

I love this library; I am incredibly grateful to you for its existence - and it might be the vehicle that makes me tackle learning TS so I can continue to contribute in some small way...

Peace, love and code.

[vagran]

Thanks for your story! I am always interested in different opinions, they usually have something to take away. And yes, code readability is my top priority as well. Further modularizing, and commenting all the internal stuff is one of the objectives for this library codebase refactoring.