memory use, 32 bit Linux system, version 2014.10.02
Did you overlap then a little? Unioning things that just touch can fail due
to floating point inaccuracies.
On 7 December 2014 at 04:02, William W Martin wwm@wwmartin.net wrote:
Yes, I did that in an earlier version, but saw a pattern of missing
triangles at the join lines between segments. Just recently
got all the segments exported & into MeshLab, joined them all & dumped out
in .ply format. Hoping to play with SU2 a bit .
On 12/06/2014 02:58 PM, nop head wrote:
It may be faster to build the tube in segments and join then in OpenScad
as well because the slow bit is the result of the for loop is unioned
before the difference.
On 6 December 2014 at 22:30, William W Martin wwm@wwmartin.net wrote:
Well, I have more time than memory to burn...the older release looks
better to me. Building in parts & combining is working, just a few more
segments to render and I will have my perforated tube created. MeshLab is
amazing!
On 12/06/2014 01:21 PM, MichaelAtOz wrote:
Final result, 2014.03 with:
fn1=72;
fn2=32;
Took 3h 23m (no swapping) and 2.85GB.
v's on 2014.12.04, F6 took 1h 28m (some swapping to SSD) and used 5.8GB!
Double memory again...
Support wrote
I didn't need to know that such a tool exists...
Unless specifically shown otherwise above, my contribution is in the
Public Domain; To the extent possible under law, I have waived all
copyright and related or neighbouring rights to this work. This work is
published globally via the internet. :) Inclusion of works of previous
authors is not included in the above.
The TPP is no simple "trade agreement." Fight it!
http://www.ourfairdeal.org/
View this message in context:
http://forum.openscad.org/memory-use-32-bit-Linux-system-version-2014-10-02-tp10374p10408.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
No, and I suspect that was not good. First attempt at this kind of
thing, learning new tricks as I go along. What I did was to render a
12mm section of the perforated tube geometry, write that to a .stl file,
then drop into a loop doing offset(..) & import from .stl until the
overall length was right. I see that this does leave boundaries with no
overlap, that well could have been that issue.
Last night I joined a bunch of tube segments end to end with MeshLab,
and do not see this artifact. Now I have what I initially wanted to
create, but it has been a fun learning exercise along the way. 'Course
I'm still quite ignorant about this stuff... :-[
One thing noticed yesterday re. openSCAD behaviour: It insists upon
hanging on to all the memory used during render...or so it seems. I had
to quit & restart to get my system memory usage back to "idle" conditions.
-bill
On 12/07/2014 04:29 AM, nop head wrote:
Did you overlap then a little? Unioning things that just touch can
fail due to floating point inaccuracies.
On 7 December 2014 at 04:02, William W Martin <wwm@wwmartin.net
mailto:wwm@wwmartin.net> wrote:
Yes, I did that in an earlier version, but saw a pattern of
missing triangles at the join lines between segments. Just recently
got all the segments exported & into MeshLab, joined them all &
dumped out in .ply format. Hoping to play with SU2 a bit .
On 12/06/2014 02:58 PM, nop head wrote:
It may be faster to build the tube in segments and join then in
OpenScad as well because the slow bit is the result of the for
loop is unioned before the difference.
On 6 December 2014 at 22:30, William W Martin <wwm@wwmartin.net
<mailto:wwm@wwmartin.net>> wrote:
Well, I have more time than memory to burn...the older
release looks better to me. Building in parts & combining is
working, just a few more segments to render and I will have
my perforated tube created. MeshLab is amazing!
On 12/06/2014 01:21 PM, MichaelAtOz wrote:
Final result, 2014.03 with:
fn1=72;
fn2=32;
Took 3h 23m (no swapping) and 2.85GB.
v's on 2014.12.04, F6 took 1h 28m (some swapping to SSD)
and used 5.8GB!
Double memory again...
Support wrote
http://libre3d.com/category/569/Hand-Tools/listings/803/Gutting-Tool.html
I didn't need to know that such a tool exists...
-----
Unless specifically shown otherwise above, my
contribution is in the Public Domain; To the extent
possible under law, I have waived all copyright and
related or neighbouring rights to this work. This work is
published globally via the internet. :) Inclusion of
works of previous authors is not included in the above.
The TPP is no simple “trade agreement.” Fight it!
http://www.ourfairdeal.org/
--
View this message in context:
http://forum.openscad.org/memory-use-32-bit-Linux-system-version-2014-10-02-tp10374p10408.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
_______________________________________________
OpenSCAD mailing list
Discuss@lists.openscad.org
<mailto:Discuss@lists.openscad.org>
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
Discuss@lists.openscad.org <mailto:Discuss@lists.openscad.org>
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org