Hi, it seems g-stl might be using 2 cores (I see two processes in top with roughly the same run time of 500+ minutes, but maybe I accidentally started 2 commands without realizing, or forgetting)... is there any way to get it to use more cores? I have a 22 core machine I'd like to use to speed things up, if possible
All of the converters are single-threaded currently. There's not much technical barrier that would prevent them from running in parallel, but it's definitely something that hasn't been worked on -- area for someone to work on.
@Nathan McCorkle 10+ hours for an export is not typical -- the few instances I've seen that happen are when the booleans are repetitive (lots of wasted recomputation) or when a machine is thrashing because it doesn't have enough memory for the task or when there's been an evaluation bug in the triangle boolean evaluator.
And there's not a real good way to distinguish "really long running" conversions from "running forever" conversions
hmm, the G database was generated in about 15-30 seconds and looks fine, even when I raytrace a few frames
I can post the TCL, give me a few mins
here's the G https://github.com/nmz787/microfluidic-cad/blob/master/BRLCAD/tobacco_mesophyll_protoplast_fusion_device/tobacco_mesophyll_protoplast_fusion_device.g
the TCL:
https://github.com/nmz787/microfluidic-cad/blob/master/BRLCAD/tobacco_mesophyll_protoplast_fusion_device/tobacco_mesophyll_protoplast_fusion_device.tcl
and the Python that generates the TCL:
https://github.com/nmz787/microfluidic-cad/blob/master/BRLCAD/tobacco_mesophyll_protoplast_fusion_device.py
draw the object "slab_minus_bot_and_io" in mged
@Sean so I think I might be wasting computation as you put it... how do I clone an object so it doesn't waste computation? What mged/TCL command?
for example, I have 800 of these similar lines in the TCL:
in brlcad_tcl__tgc1.s tgc 15 350 0 0 0 55 15 0 0 0 10 0 15 10
in brlcad_tcl__tgc2.s tgc 15 390 0 0 0 55 15 0 0 0 10 0 15 10
where only the name and first two numbers change
@Nathan McCorkle that's pretty cool! Screen-Shot-2020-02-26-at-11.04.59-PM.png
And yes, looking at the output database, I suspect that you encountered O(N^3) exponential time
each triangle for each of those tiny cylinders is getting tessellated against the entirety preceding, which gets increasingly slower and slower as it progresses
There are a couple minor changes that would likely speed things up tremendously. First would be to try changing the tree structure so that the tgc's are all grouped together before being unioned into the larger structure.
So instead of "A u B u C u D ..." you have "A u G1" where G1 is "B u C u D ..." which are clusters of those small cylinders.
that way, the tessellation code will resolve the majority of triangles only once against the larger A structure
Hmm, so I see in the TCL it shows after a set of 100 TGCs being created, a line like this:
g bifurcated_posts.g brlcad_tcl__tgc1.s brlcad_tcl__tgc2.s brlcad_tcl__tgc3.s ... ...
So aren't they already grouped before being unioned?
The immediate next line is:
comb funnel.c u lengthened_polygon.c - bifurcated_posts.g
It sounds like you're saying to union all the TGCs instead of grouping them, then make the unioned output a group? But I thought objects had to be touching or overlapping for a union operation to work
I'll give it a try though
does this look any better?
https://pastebin.com/stBH14Qq
I'll need to change my script a bit to further cluster all the groups of sets of small TGCs... at this point there are 10 combinations of the sets of small TGCs unioned
Nathan McCorkle said:
So aren't they already grouped before being unioned?
I thought I saw that they weren't but now you have me doubting what I saw. I have a facetization going now and it's been crunching for hours, so I should have a better idea soon what's going on.
Nathan McCorkle said:
It sounds like you're saying to union all the TGCs instead of grouping them, then make the unioned output a group? But I thought objects had to be touching or overlapping for a union operation to work
It should work either way. It's also possible they simply need to be nudged off of being co-planar so the evaluation doesn't have to guess the intent.
Sean said:
It should work either way. It's also possible they simply need to be nudged off of being co-planar so the evaluation doesn't have to guess the intent.
hmm, this would be destined for semiconductor-style nanfabrication... the resolution of the fabrication wouldn't be atomic for this model but certainly some of the things that I plan to do could be single or say <=10 atom layers thick...
@Nathan McCorkle and that would be fine... I'm referring to the cases where you're combining two shapes with a union, but they're defined as going from |---A---|---B---| to define some |--------------| region that's "A u B". Instead, you'd position the interior face such that they overlap ever so slightly. that way it can distinguish whether you meant two regions that happen to coincide (i.e., |-------||-------| ) or clearly one region by overlapping them (even as little as 0.0000000001).
Last updated: Jan 09 2025 at 00:46 UTC