A
adrian
Sun, Jan 25, 2015 11:20 AM
The render time is probably at least double as it was before. Can I
reinstall 2014.03 in a separate directory without breaking anything? Also,
don't recall if there was even an option to do so.
Thanks,
A
--
View this message in context: http://forum.openscad.org/OpenSCAD-2015-01-23-has-really-slow-renders-tp11228.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
The render time is probably at least double as it was before. Can I
reinstall 2014.03 in a separate directory without breaking anything? Also,
don't recall if there was even an option to do so.
Thanks,
A
--
View this message in context: http://forum.openscad.org/OpenSCAD-2015-01-23-has-really-slow-renders-tp11228.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
B
Bananapeel
Sun, Jan 25, 2015 11:56 AM
Download the zip files and extract them wherever you want to have separate
versions installed. :)
--
View this message in context: http://forum.openscad.org/OpenSCAD-2015-01-23-has-really-slow-renders-tp11228p11229.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Download the zip files and extract them wherever you want to have separate
versions installed. :)
--
View this message in context: http://forum.openscad.org/OpenSCAD-2015-01-23-has-really-slow-renders-tp11228p11229.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
M
MichaelAtOz
Sun, Jan 25, 2015 12:35 PM
At first I thought the same...I will do some comparative renders...
One I did with 2015.01.13 (unfortunately I cleaned up all the prior interim
versions) v's .23, .23 was noticeably slower, but sample of one is not
statistics...
I also check the memory use BTW.
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.
View this message in context: http://forum.openscad.org/OpenSCAD-2015-01-23-has-really-slow-renders-tp11228p11230.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
At first I thought the same...I will do some comparative renders...
One I did with 2015.01.13 (unfortunately I cleaned up all the prior interim
versions) v's .23, .23 was noticeably slower, but sample of one is not
statistics...
I also check the memory use BTW.
-----
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/OpenSCAD-2015-01-23-has-really-slow-renders-tp11228p11230.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
A
adrian
Sun, Jan 25, 2015 3:41 PM
Yeah, definitely slower. Here's from 2014:
Compiling design (CSG Tree generation)...Rendering Polygon Mesh using
CGAL...PolySets in cache: 12PolySet cache size in bytes: 50432CGAL
Polyhedrons in cache: 97CGAL cache size in bytes: 18954760 Top level
object is a 3D object: Simple: yes Vertices: 892
Halfedges: 3202 Edges: 1601 Halffacets: 1440 Facets:
720 Volumes: 4Total rendering time: 0 hours, 0 minutes, 35
secondsRendering finished.
and here's from 2015:
Compiling design (CSG Tree generation)...Rendering Polygon Mesh using
CGAL...Geometries in cache: 30Geometry cache size in bytes: 84672CGAL
Polyhedrons in cache: 69CGAL cache size in bytes: 30682928Total rendering
time: 0 hours, 1 minutes, 4 seconds Top level object is a 3D object:
Simple: yes Vertices: 1252 Halfedges: 4276 Edges:
2138 Halffacets: 1798 Facets: 899 Volumes: 4Rendering
finished.
This is done on the exact same file, so its definitely due to some change in
the source. Hopefully, it's something as simple as debugging code was left
in.
A
--
View this message in context: http://forum.openscad.org/OpenSCAD-2015-01-23-has-really-slow-renders-tp11228p11234.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Yeah, definitely slower. Here's from 2014:
Compiling design (CSG Tree generation)...Rendering Polygon Mesh using
CGAL...PolySets in cache: 12PolySet cache size in bytes: 50432CGAL
Polyhedrons in cache: 97CGAL cache size in bytes: 18954760 Top level
object is a 3D object: Simple: yes Vertices: 892
Halfedges: 3202 Edges: 1601 Halffacets: 1440 Facets:
720 Volumes: 4Total rendering time: 0 hours, 0 minutes, 35
secondsRendering finished.
and here's from 2015:
Compiling design (CSG Tree generation)...Rendering Polygon Mesh using
CGAL...Geometries in cache: 30Geometry cache size in bytes: 84672CGAL
Polyhedrons in cache: 69CGAL cache size in bytes: 30682928Total rendering
time: 0 hours, 1 minutes, 4 seconds Top level object is a 3D object:
Simple: yes Vertices: 1252 Halfedges: 4276 Edges:
2138 Halffacets: 1798 Facets: 899 Volumes: 4Rendering
finished.
This is done on the exact same file, so its definitely due to some change in
the source. Hopefully, it's something as simple as debugging code was left
in.
A
--
View this message in context: http://forum.openscad.org/OpenSCAD-2015-01-23-has-really-slow-renders-tp11228p11234.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
MK
Marius Kintel
Sun, Jan 25, 2015 3:53 PM
Yeah, definitely slower. Here's from 2014:
Total rendering time: 0 hours, 0 minutes, 35 seconds
Total rendering time: 0 hours, 1 minutes, 4 seconds
Can you share your design?
I know that we’re sometimes slower as we had to sacrifice some speed to ensure stability in some cases, but we might still be able to improve that.
-Marius
On Jan 25, 2015, at 10:41 AM, adrian <adrianh.bsc@gmail.com> wrote:
> Yeah, definitely slower. Here's from 2014:
> Total rendering time: 0 hours, 0 minutes, 35 seconds
> Total rendering time: 0 hours, 1 minutes, 4 seconds
Can you share your design?
I know that we’re sometimes slower as we had to sacrifice some speed to ensure stability in some cases, but we might still be able to improve that.
-Marius
A
adrian
Sun, Jan 25, 2015 6:11 PM
Sure. This is a preliminary for something I'm designing.
Sorry for it being so messy. I only got into this language a few days ago.
:)
A
--
View this message in context: http://forum.openscad.org/OpenSCAD-2015-01-23-has-really-slow-renders-tp11228p11240.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Sure. This is a preliminary for something I'm designing.
Sorry for it being so messy. I only got into this language a few days ago.
:)
A
--
View this message in context: http://forum.openscad.org/OpenSCAD-2015-01-23-has-really-slow-renders-tp11228p11240.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
MK
Marius Kintel
Tue, Jan 27, 2015 5:07 AM
Sure. This is a preliminary for something I'm designing.
My analysis uncovered a few things which trigger differences vs. OpenSCAD-2014.03:
- Your “end cylinders” are duplicated. These overlapping geometries causes very small differences in coordinates causing a lot more vertices to be created, and thus longer calculation time
- When you connect the arm elements together, you put them together so they exactly touch each other. Since “exactly” doesn’t exist in floating point, there’s a chance for a small crack to form. This happens in the latest dev snapshot and, again, causes more geometry to be created. It’s recommended to have a tiny overlap between such components.
I think that if you fix those two issues, the rendering times should be comparable.
We aim to handle such issues better in the future.
The reason why it worked better in 2014.03 was that we did some aggressive snapping of vertices to a grid. Unfortunately, that cause other geometries to break in more serious ways.
-Marius
On Jan 25, 2015, at 13:11 PM, adrian <adrianh.bsc@gmail.com> wrote:
> Sure. This is a preliminary for something I'm designing.
>
My analysis uncovered a few things which trigger differences vs. OpenSCAD-2014.03:
1) Your “end cylinders” are duplicated. These overlapping geometries causes very small differences in coordinates causing a lot more vertices to be created, and thus longer calculation time
2) When you connect the arm elements together, you put them together so they _exactly_ touch each other. Since “exactly” doesn’t exist in floating point, there’s a chance for a small crack to form. This happens in the latest dev snapshot and, again, causes more geometry to be created. It’s recommended to have a tiny overlap between such components.
I think that if you fix those two issues, the rendering times should be comparable.
We aim to handle such issues better in the future.
The reason why it worked better in 2014.03 was that we did some aggressive snapping of vertices to a grid. Unfortunately, that cause other geometries to break in more serious ways.
-Marius
A
adrian
Tue, Jan 27, 2015 12:27 PM
On Jan 25, 2015, at 13:11 PM, adrian <
Sure. This is a preliminary for something I'm designing.
My analysis uncovered a few things which trigger differences vs.
OpenSCAD-2014.03:
- Your “end cylinders” are duplicated. These overlapping geometries
causes very small differences in coordinates causing a lot more vertices
to be created, and thus longer calculation time
- When you connect the arm elements together, you put them together so
they exactly touch each other. Since “exactly” doesn’t exist in
floating point, there’s a chance for a small crack to form. This happens
in the latest dev snapshot and, again, causes more geometry to be created.
It’s recommended to have a tiny overlap between such components.
kintel wrote
> On Jan 25, 2015, at 13:11 PM, adrian <
> adrianh.bsc@
> > wrote:
>
>> Sure. This is a preliminary for something I'm designing.
>>
> My analysis uncovered a few things which trigger differences vs.
> OpenSCAD-2014.03:
>
> 1) Your “end cylinders” are duplicated. These overlapping geometries
> causes very small differences in coordinates causing a lot more vertices
> to be created, and thus longer calculation time
> 2) When you connect the arm elements together, you put them together so
> they _exactly_ touch each other. Since “exactly” doesn’t exist in
> floating point, there’s a chance for a small crack to form. This happens
> in the latest dev snapshot and, again, causes more geometry to be created.
> It’s recommended to have a tiny overlap between such components.
Thanks Marius,
Yeah, I was being lazy about the cylinders. I'll fix that. As for the arm
elements exactly touching, how much overlap should I do? 0.001mm? I'll use
a constant and come back to this thread later.
Thanks again,
A
--
View this message in context: http://forum.openscad.org/OpenSCAD-2015-01-23-has-really-slow-renders-tp11228p11253.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
A
adrian
Tue, Jan 27, 2015 12:41 PM
One other thing that I noticed in 2015 is that if a module doesn't exist and
you call it, it doesn't report a 'warning'. I'm not sure why a warning was
used in the previous one, I would think it should be an error and just bail,
but at least that was better than not reporting anything like the 2015 RC
does. I found that out when I mistyped translate(). :(
Thanks,
A
--
View this message in context: http://forum.openscad.org/OpenSCAD-2015-01-23-has-really-slow-renders-tp11228p11254.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
One other thing that I noticed in 2015 is that if a module doesn't exist and
you call it, it doesn't report a 'warning'. I'm not sure why a warning was
used in the previous one, I would think it should be an error and just bail,
but at least that was better than not reporting anything like the 2015 RC
does. I found that out when I mistyped translate(). :(
Thanks,
A
--
View this message in context: http://forum.openscad.org/OpenSCAD-2015-01-23-has-really-slow-renders-tp11228p11254.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
MK
Marius Kintel
Wed, Jan 28, 2015 3:22 AM
As for the arm elements exactly touching, how much overlap should I do? 0.001mm?
Yeah, smth. like that.
Eventually I think we should look into snapping such elements together. Just don’t want to second-guess any design decisions..
-Marius
On Jan 27, 2015, at 07:27 AM, adrian <adrianh.bsc@gmail.com> wrote:
>
> As for the arm elements exactly touching, how much overlap should I do? 0.001mm?
Yeah, smth. like that.
Eventually I think we should look into snapping such elements together. Just don’t want to second-guess any design decisions..
-Marius
