-
Notifications
You must be signed in to change notification settings - Fork 52
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
More exports in rendering code or better save functions #35
Comments
After writing that up, I took a deeper dive and realized I'd made a couple of mistakes. One was that I'm talking about an encoder pattern, not a writer pattern, but that's mostly just nomenclature. They are both very similar. The other mistake is that I made some assumptions before realizing that part of the My proposal as written does not work very well. I'm going to have a think on it and see if I can come up with a fix. |
You are not really proposing an io.Writer, but rather something that is io.Writer-like. It's like an io.Writer that deals with triangle slices rather than byte slices. You've also identified the post write header fixup problem which further complicates the stateless "crank out the bytes" model. It's not clear to me why you have two interface methods for 1 triangle vs a slice of triangles. The slice method can do all the work. Counter proposal: The marching cubes functions conceptually take an sdf object and a few parameters and generate a stream of triangles on a channel. One of them (the octree renderer) actually does that. The slow renderer could (and probably should) do that also (thereby getting rid of SaveSTL vs WriteSTL). Doesn't that achieve your goal? ie- plug the triangle stream into anything you like? We'd have to expose those MarchingX functions, but that's not a problem. |
Yes, that would solve my problem. Some of the urgency of the solution, though, goes away because of the nature of the STL format. That solution doesn't provide a straightforward win by just trying to generate an STL file I can stream out. I'm still going to need to write an STL file. My purpose was wanting to quickly stream the STL from a web server backend to a web frontend and I still need the STL. If I'm creative, though, I suppose I could still do that if I streamed the triangles to the frontend without the header and then send the header as a footer and let the front-end rewrite it or even just infer it by dividing the bytes received by 50 and rewrite it itself. Though, it would also open up the ability to produce OBJ or 3MF files as alternate outputs, which could be an advantage. |
I have rewritten |
Well, there are a few things to process ...
Agreed!
Not agreed. Yes - it get's tedious. It was done this way because: a) I want functions to either do what you tell them, or tell you they can't do it. No changing parameters under the covers. |
Agreed on your second point- pretty ambitious goal but awesome to say the least. As for the other changes it'd be great for you to take a look at the One thing that may be a harsh change is the replacement of the There are some other changes I think are well deserved in the library:
|
I think recent changes have adressed your concern. Line 21 in fe19a07
Line 27 in fe19a07
Line 135 in fe19a07
Line 185 in fe19a07
Conceptually the rendering code writes to an interface implementation that can do whatever it likes with the triangles/lines. At the moment the only implementation of this interface is a buffering object that subsequently writes on a channel that gets read by a file writing routine but of course, it could be anything. |
I want to use this library in a situation where it would be better to save the output directly to an
io.Writer
than to be forced to save directly to disk. However, there's noRenderXXX
function that takes anio.Writer
as an argument. I was going to see if I could create my own writer using one of the sampling methods directly, but the sampling methods are not exported. So, basically, I'd have to do something convoluted and slow (write to disk, close, read from disk to write somewhere else) or copy and paste the sampling code to create my own render package.I'd like to propose that the
RenderXXX
functions really ought to be handled in two phases:io.Writer
The existing functions that combine these two functions should remain, but exist as a convenience.
I'd also like to eliminate the duplication between the two different file writing paths eliminated. The differences between
SaveXXX
andWriteXXX
can be combined without sacrificing the performance gained by the async writing performed byWriteXXX
. Just definerender.XXXWriter
that provides aWriteTriangle3()
method and then provide a constructor that returns that when given anio.Writer
.Finally, it might be nice to have more access to the rendered triangles directly. You never know when someone might want to do their own post-processing on the triangle mesh to perform some specialized work. Splitting the steps up makes that possible.
There's no reason the existing render API needs to change. It could all be implemented in terms of this new API. Anyway, without filling in the functions, the new code for STL could look something like this:
I'm going to see about working on a PR to flesh that out, if you're interested. Otherwise, I'm going to fork the render package because I don't want the overhead of writing to disk and then reading it again for what I'm trying to do.
The text was updated successfully, but these errors were encountered: