About OSC, Viewports, Sheets, Paper Space, Printing...

[dlabz]

Hi!

First of all, thanks for this awesome project. I've spent last two days playing with the master branch, and only now noticed all the great progress.

1. I only glanced the OSC specs, but it seems to be the same idea that's used in IfcAxisPlacement. If it's the same, I already have a working implementation to share.

2. As for the Viewports, Sheets and PaperSpace, it seems it's the same approach as used in the Autodesk DWFx and Forge f2d format. The viewport is actually square, but cropped.

3. I've started to modifying dxf-viewer to render SVG. It great for prining (how to print model space? #22), allows inspecting the DOM of the rendered drawing (Question: How to determine whether the drawn content is a whole？ #73) and interacting with it, and renders as a static reusable file. I'm not sure if that's in the scope of this project for you, but wanted to mention it.

4. It occured to me that there might be a better way to render Hatches. Both SVG and Canvas support using a tiled textured fill as a shape fill, which would avoid the need for clipping the hatch lines (though current code does work quite nice and certainly does the trick).

5. I was working on streaming reader/parser today, but will need to see how it relates the new version. Also, it's using node streams, so I'd need to rewrite it to WHATWG Streams Standard to also work in the browser.

6. Writing the parser for binary version is also in my skill set.

I can prioritize any of those tasks, or help with something compleatly unrelated, so feel free to nudge me in the direction that works best for you.

Thanks again,
and keep up the good work.

[vagran]

Hi!

1. Here is the fullest known to me description of what OCS is in DXF. Currently, dxf-viewer just checks extrusion vector Z-component sign, and apply mirroring transform if it is negative. Proper way is to calculate exact transform as described in this article. However, I have never seen any example with extrusion axis other than just -Z. Also, some entities seem not following the general approach and rendered incorrectly if that transform is applied, so they currently have some quirks to mitigate that. This should be somehow generalized, properly implemented, and tested with all currently accumulated examples - that's the plan for this area.
2. This feature is more or less clear, but needs implementation, making several rendering passes with different camera and viewport parameters for paper space (when paper-space full support is introduced).
3. Yes, this application is one of intended ones, so I want to make clear API for obtaining scene building result, to use for rendering not only to GL context, but to other formats like SVG, GeoJSON, STL, etc. It should also include some metadata about original DXF entities, now it is completely lost after rendering batches are built. Other formats rendering functionality itself probably out of scope of this library, and should be implemented on top of it in some dependant libraries.
4. Yes, before this feature was implemented, I thought about different approaches, making it in vector form looked the most suitable approach finally, as far as I know, it is used in most CAD applications, including AutoDesk online viewer which I use as the reference viewer to compare rendering results with. Rasterizing hatch into a texture will have a problem with a limited texture resolution, which will be visible when zooming. Also, hatching patterns may be quite arbitrary (and dxf-viewer now supports importing custom patterns in .pat file format), so selecting proper resolution and bounds for pattern rasterization and tiling may be a non-trivial task. Some patterns may require a lot of memory for texture of sufficient resolution.
5. Actually, there is already work in progress on a new parser in 1.1.x branch. Streaming is not a problem here and is already implemented. What I am currently experimenting on is implementing a generic parser (not bound to DXF format), based on declarative grammar description. I am going to release it in a separate library when done. Also, a DXF parser built on top of it will probably be released separately. The only possible concern with this approach may be a potential poor performance, but I want to check this experimentally when done. Maybe it will be possible to optimize it and have acceptable performance. Otherwise, will have to switch to less generic approach.
6. I had a look on binary DXF format description. It should not be a big deal to add support for it, when parser is done. It looks like we just should have an alternative tokenizer implementation for the binary format.

In general, the work is in progress, although quite slow. However, I am quite happy with that, and help is mostly appreciated in form of information about unclear parts of DXF specification and various sample files. The current library implementation is mostly open for bug fixes only, and some isolated small features implementations which will be easy to port into the new version. Bigger features and customizations are recommended to be done in forks created for that purpose.