Ronaldo wrote > An implicit union is present in both codes of Line and Rod. Under F6, as > the union process time is much greater than the hull, it is irrelevant if > you make the sticks with cylinders or hulling spheres. That makes sense. Thx. ----- $ Runsun Pan, PhD $ libs: scadx , doctest , faces ( git ), offline doc ( git ), runscad.py ( 2 , git ), editor of choice: CudaText ( OpenSCAD lexer ); $ Tips ; $ Snippets -- Sent from: http://forum.openscad.org/

Ronaldo wrote > Rod as is and a third case where the hull in Rod is dropped. I got ... Our purpose is to test the speed of line drawing. In the Rod() case, it IS the hull() that makes it a line. By dropping the hull, the outcome is no longer a line. Which means it is comparing a "translation of 2 pts" to a "drawing of line." That doesn't make sense to me. ----- $ Runsun Pan, PhD $ libs: scadx , doctest , faces ( git ), offline doc ( git ), runscad.py ( 2 , git ), editor of choice: CudaText ( OpenSCAD lexer ); $ Tips ; $ Snippets -- Sent from: http://forum.openscad.org/

Upon further studies I realized the mistakes I made in previous test. First of all, I shouldn't have claimed it a comparison between hull and cylinder, 'cos that's a mis-representation of my intent. My intention is *user experiences*, in which process other than hull and cylinder also take place (including the implicit union upon rendering). By claiming it's a comparison between the two, I misled the readers. I believe that's what made the discussion between nophead and myself look like on different channels. My apology for this mistake. A somewhat more proper claim would be "Using hull vs using cylinder," but it is still not quite there. The second mistake is what Ronaldo points out in the test code, i.e., *Rod()* uses more vertices than *Line()* did. A new module, *Rodc()*, is created by replacing the spheres with cubes : hull() { translate( pts[i] ) cube(r*2); // <===== using cube() instead of sphere() translate( pts[i+1] ) cube(r*2); } This gives both Line() and Rodc() the same # of vertices to handle. The result shows that "Using hull" is actually faster than "Using cylinder" and it's very significant : Render Time (sec) n Rod Line Rodc20 7 2 2 40 20 8 575 66 24 17 That is, *a rejection to my original observations. * This is somewhat understandable (I assume), 'cos, by "hulling cubes" in *Rodc()*, some of the vertices from cubes are hidden inside the hulled object, while *Line()* needs to handle all vertices of participating cylinders. This can be verified by comparing the vertices count after rendering ( Rod: 475 , Line: 375, Rodc: 253 when # of pts = 20). In terms of [preview], I have hard time understanding the purpose of introducing "render()" as what Ronaldo and nophead proposed. The [preview] is to see what it is, and if both with or without "render()" reaches that goal, there's no reason to add it. But again, my misleading claim might be a contributing factor to this approach. Nonetheless, a new module *Rodcr()* is created by adding a "render()" before the "hull" and here is their preview times: Preview Time (sec)n Rod Line Rodc Rodcr1000 2 0 2 22000 10 0 3 3 It shows no effect of "render()" and also support that, in [preview], "using hull" is still slower than using the Line() approach. But this is seen with >1000 objects, so the difference would be insignificant in most cases. ----- $ Runsun Pan, PhD $ libs: scadx , doctest , faces ( git ), offline doc ( git ), runscad.py ( 2 , git ), editor of choice: CudaText ( OpenSCAD lexer );&nbsp;$ Tips ;&nbsp;$ Snippets -- Sent from: http://forum.openscad.org/

I use render() for several reasons: When you have a large assembly to preview, like a 3D printer, OpenCSG slows right down because it has hundreds or thousands of differences to fake. Any intersections really slow it down as well as they cause the OpenCSG products to explode. So by adding render all OpenCSG then has to do is draw lots of polyhedrons, so it draws faster and is much more responsive to the mouse. Shame it can't draw as fast as a game engine when it has no CSG ops to fake. Another issue is that all the negative objects are drawn in OpenCSG, so if you put parts close to each other their negative objects can interfere and cause Z-fighting. With a large assembly of lots of parts this is almost inevitable with screw holes, for example. Negative objects add the to size when View All is used, so if they are large they can make the result far too small. If you zoom too close they don't get drawn, so holes in your object can disappear. On individual parts if you have faces that line up you get Z-fighting. I generally avoid that, but sometimes, rather than adding a small offset that might actually end up in the final part, I simply render it because CGAL can handle coincident faces, if they are exactly coincident, OpenCSG can't. When you do use a small offset it fails to stop Z-fighting if you zoom out far enough. You don't have to worry about convexity if render is at the top level. I.e. it doesn't matter to all the operations below it because they are done with CGAL. If you have OpenCSG ops on the rendered object then you do need to set the convexity in the render. The downside is when I open a design it can take several minutes to preview the first time. It is fast after that. I don't have render in my 3D parts, so that I can display them on their own and preview modifications quickly. I do however render them at the point of use in my assemblies. On the other hand vitamins all have a render at their top level for each colour, and so do things like polyholes that get used many times. That forces them to be cached as a polyhedron and reused. On Sat, 12 Jan 2019 at 00:42, runsun <runsun@gmail.com> wrote: > Upon further studies I realized the mistakes I made in previous test. > > First of all, I shouldn't have claimed it a comparison between hull and > cylinder, 'cos that's a mis-representation of my intent. My intention is *user > experiences*, in which process other than hull and cylinder also take > place (including the implicit union upon rendering). By claiming it's a > comparison between the two, I misled the readers. I believe that's what > made the discussion between nophead and myself look like on different > channels. My apology for this mistake. > > A somewhat more proper claim would be "Using hull vs using cylinder," but > it is still not quite there. > > The second mistake is what Ronaldo points out in the test code, i.e., > *Rod()* uses more vertices than *Line()* did. > > A new module, *Rodc()*, is created by replacing the spheres with cubes : > > hull() > { translate( pts[i] ) cube(r*2); // <===== using cube() instead of sphere() > translate( pts[i+1] ) cube(r*2); > } > > This gives both Line() and Rodc() the same # of vertices to handle. > > The result shows that "Using hull" is actually faster than "Using > cylinder" and it's very significant : > > Render Time (sec) > > n Rod Line Rodc > 20 7 2 2 > 40 20 8 5 > 75 66 24 17 > > That is, *a rejection to my original observations. * > > This is somewhat understandable (I assume), 'cos, by "hulling cubes" in > *Rodc()*, some of the vertices from cubes are hidden inside the hulled > object, while *Line()* needs to handle all vertices of participating > cylinders. This can be verified by comparing the vertices count after > rendering ( Rod: 475 , Line: 375, Rodc: 253 when # of pts = 20). > > In terms of [preview], I have hard time understanding the purpose of > introducing "render()" as what Ronaldo and nophead proposed. The [preview] > is to see what it is, and if both with or without "render()" reaches that > goal, there's no reason to add it. But again, my misleading claim might be > a contributing factor to this approach. > > Nonetheless, a new module *Rodcr()* is created by adding a "render()" > before the "hull" and here is their preview times: > > Preview Time (sec) > > n Rod Line Rodc Rodcr > 1000 2 0 2 2 > 2000 10 0 3 3 > > It shows no effect of "render()" and also support that, in [preview], > "using hull" is still slower than using the Line() approach. But this is > seen with >1000 objects, so the difference would be insignificant in most > cases. > $ <http://forum.openscad.org/mailing_list/MailingListOptions.jtp?forum=1> *Runsun > Pan, PhD* > $ *libs*: scadx <https://bitbucket.org/runsun/scadx>, doctest > <https://github.com/runsun/openscad_doctest>, faces > <http://forum.openscad.org/A-faces-function-for-simple-polyhedrons-td12809.html> > (git <https://github.com/runsun/faces.scad>), offline doc > <http://forum.openscad.org/Use-openscad-offliner-for-offline-documentation-td13096.html> > (git <https://github.com/runsun/openscad_offliner>), runscad.py > <http://forum.openscad.org/Animating-gif-with-3D-rotation-tp14011p14029.html> > (2 <http://forum.openscad.org/Symmetrical-Rotation-tp14062p14075.html>,git > <https://gist.github.com/runsun/995250a8002386ab9abc>), editor of choice: > CudaText > <http://forum.openscad.org/Syntax-highlighting-tp23247p23258.html> ( OpenSCAD > lexer <http://www.thingiverse.com/thing:1237864>); $ Tips > <https://github.com/runsun/OpenSCAD_Tips>; $ Snippets > <https://github.com/runsun/OpenSCAD_Tips/blob/master/snippets.md> > > ------------------------------ > Sent from the OpenSCAD mailing list archive <http://forum.openscad.org/> > at Nabble.com. > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >

Thx, nophead. That helps, a lot. ----- $ Runsun Pan, PhD $ libs: scadx , doctest , faces ( git ), offline doc ( git ), runscad.py ( 2 , git ), editor of choice: CudaText ( OpenSCAD lexer );&nbsp;$ Tips ;&nbsp;$ Snippets -- Sent from: http://forum.openscad.org/