CoffeeSCad
CoffeeSCad copied to clipboard
kaosat-dev
Do a major re-factoring pass
Just curious. When will you be done with it? I thought about contributing, but if the code base is still in a state of flux, I probably won't touch it until you're done.
Hello ! Normally should be done before the end of January. Things have been progressing nicely, app structure is getting there, the biggest missing part is unit testing, and I am working on having that done, so the time estimate seems fine.
I will keep you posted if you want (also, you will see when I close this issue aswell:)
Ok, yes. I'll be watching this thread. When you close it, I'll know that you're done with the refactoring.
I've been looking at what you did with the CSG kernel. I had been thinking about getting it to be faster, and I see you did some optimizations. Did you measure what the percent speed up was?
As I am still changing lots of things (and fixing some others) in the CSG kernel, I have not yet measured the speedups. I have started replacing a few "map" function calls with list comprehensions here and there though, which should be faster theoretically (at least according to this http://jsperf.com/coffeescript-list-comprehension-vs-filter-and-map) .
As far as more general speedups go, I'll soon tackle the task of moving the csg kernel processing to web workers. (first only to one worker, to avoid blocking the ui, and further down the line, each CSG "part" (independent csg object) might be processed in a separate worker as well , and that potentially the greatest source of speedups.
If you have any other ideas /implementations about speedups , they are very welcome of course:) (I think there are lots of places where optimizing could be done in the CSG code itself, but I don't plan to deal with that just yet)
Alas, that link is broken.
I was wondering about using map in the CSG kernel in some places. It didn't make sense at first, since the code didn't use the array map returned--until I realized that it was just using it as a loop.
I'm currently interested in a faster kernel, but I don't have specific ideas, beyond looking for parallel tracks the data goes through. In addition, it might also be advantageous to have partial results streamed, so ideally, a user can see the results as the CSG executes, which cuts down on the impression that things are taking a while. That way, the 'real-time' CSG rendering might work even if it's a complex assembly.
A quick question: for the PolygonNodeTree, can you clarify something for me? It seems like there's a PolygonNodeTree in place of a Polygon, and once a polygon gets split, you get the split polygons added as children. So then, are there just references to the specific PolygonNodeTree containing a split polygon in the resulting BSP tree?
Iamwilhelm : I am really short on time this week so just a heads up : to make this disussion more public and go on after the current issue is closed , I created this one : https://github.com/kaosat-dev/CoffeeSCad/issues/66 specifically for speed related stuff :)
About the link : weird, I checked again, it works fine ...;
Yeah map is used as "function" map , as in "apply this function to all elements in an array. Hmm I had not thought about any sort of streaming, that is way above my head to be honest: I thought about it and do not quite know how it would work with the current system (which is rather "all or nothing" as far as csg processing goes), but this could be a great thing to implement!
About the polygonNodeTree : yes that is exactly right : PolygonNodeTree in place of a Polygon, and once a polygon gets split, you get the split polygons added as children. For the second part of the question I'll reply in depth tomorrow :)
Awesome. As for the streaming, I mean for CSG to return polygons as it's processing. Do you intend the kernel to be run in the browser, on server (through node.js), or both?
I'm interested in running the CSG kernel on the server, but I wouldn't mind helping out with adapting it for both. Currently, I have an exploratory repo that implements the core CSG kernel that returns the polygons as it's processing with tests. I'm not done with it yet, but will post an update on the speed thread when I'm done.
And oh, I eagerly await your in-depth reply.