SVG and STL output quality

[nmz...@gmail.com]

https://raw.githubusercontent.com/nmz787/microfluidic-cad/master/implicitCAD/output/tobacco_mesophyll_protoplast_fusion_device.jpg

(for some reason it doesn't render for me unless I download it then
open it in my browser, or inkscape)
https://raw.githubusercontent.com/nmz787/microfluidic-cad/master/implicitCAD/output/tobacco_mesophyll_protoplast_fusion_device.svg

https://raw.githubusercontent.com/nmz787/microfluidic-cad/master/implicitCAD/output/tobacco_mesophyll_protoplast_fusion_device__3D.png

and the source code:
https://github.com/nmz787/microfluidic-cad/blob/master/implicitCAD/tobacco_mesophyll_protoplast_fusion_device.escad

The 3D STL snapshot created is 50MB. Both the STL and SVG have flaws... the posts are still not well-defined everywhere, and the STL particularly looks bad.

[nmz...@gmail.com]

On Monday, December 29, 2014 12:24:05 AM UTC-8, nmz...@gmail.com wrote:
> The 3D STL snapshot created is 50MB. Both the STL and SVG have flaws... the posts are still not well-defined everywhere, and the STL particularly looks bad.

I just bumped the $quality up to 1400 from 400 and let it render when I went to bed. This morning I have a 145MB STL file, and a weird 'skin' effect where the extrusion seems to have only had the 'difference()' operation applied to the bulk but not the surface.

Here are 4 snapshots from meshlab that try to show the strange outcome:
http://imgur.com/sXVkRnL,si4Rp2r,sraO5Va,EHoZ5XB

I also experienced this at some lower quality settings (around 50), and was able to slightly change the quality setting to a nearby value (say 60) and the problem would disappear. I guess I will try bumping up the quality and re-render, for now.

[Reinoud Zandijk]

Hi!

On Mon, Dec 29, 2014 at 11:16:10AM -0800, nmz...@gmail.com wrote:
> On Monday, December 29, 2014 12:24:05 AM UTC-8, nmz...@gmail.com wrote:
> > The 3D STL snapshot created is 50MB. Both the STL and SVG have flaws...
> > the posts are still not well-defined everywhere, and the STL particularly
> > looks bad.

> Here are 4 snapshots from meshlab that try to show the strange outcome:
> http://imgur.com/sXVkRnL,si4Rp2r,sraO5Va,EHoZ5XB

Are you sure its not a side effect of z-fighting? i.e. are you substracting a
big enough part and not `just right'? it might explain the ragged and/or
massive oddities in the output.

Have you tried to render the file in OpenSCAD? What is the result in that?

With regards,
Reinoud

[Nathan McCorkle]

On Mon, Dec 29, 2014 at 11:21 AM, Reinoud Zandijk
<rei...@13thmonkey.org> wrote:
> Are you sure its not a side effect of z-fighting? i.e. are you substracting a
> big enough part and not `just right'? it might explain the ragged and/or
> massive oddities in the output.

I considered that, but don't know how implicitCAD works well enough.
The 2D to 3D code is essentially this:

difference()
{
linear_extrude(io_height)
{
pdms_slab(distance_output_port_from_center);
}
union()
{
linear_extrude(protoplast_chamber_height)
protoplast_bottom_layer_2d(args);
linear_extrude(io_height)
protoplast_io(args)
}
}


I was thinking maybe I should do the difference on the 2D versions
with the slab (before extruding), then extrude and merge the two
extrusions together (so the extruded slab would never exist in 3D by
itself).

> Have you tried to render the file in OpenSCAD? What is the result in that?

I have not, this is pretty much my first foray into programmatic CAD,
and 3D CAD in general. Is .escad really that well back-wards
compatible? I thought the implicitCAD docs mentioned openSCAD not
being able to do for loops or something like that. Maybe I'm wrong.


Thanks for your thoughts!

[Christopher Olah]

I think Reinound is right that the issue is z-fighting. To
ImplicitCAD, depending on how things line up, it could very easily
look like there is still a boundary on the z=0 plane.

Try something like this:

difference()
{
linear_extrude(io_height)
{
pdms_slab(distance_output_port_from_center);
}
translate([0,0,-1]) union()
{
linear_extrude(protoplast_chamber_height + 1)
protoplast_bottom_layer_2d(args);
linear_extrude(io_height + 1)
protoplast_io(args)

}
}


> I thought the implicitCAD docs mentioned openSCAD not being able to do for loops or something like that.

They have for loops. The issue (which might be fixed now, I don't
know) was the semantics of reassigning variables, especially in loops.
As I recall, all use of a variable in your program gets the value the
variable was last set to in your program. OpenSCAD isn't really an
imperative language, despite appearances.

> --
> You received this message because you are subscribed to the Google Groups "ImplicitCAD" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to implicitcad...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[nmz...@gmail.com]

On Monday, December 29, 2014 11:28:15 AM UTC-8, Nathan McCorkle wrote:>
> difference()
> {
> linear_extrude(io_height)
> {
> pdms_slab(distance_output_port_from_center);
> }
> union()
> {
> linear_extrude(protoplast_chamber_height)
> protoplast_bottom_layer_2d(args);
> linear_extrude(io_height)
> protoplast_io(args)
> }
> }
>
>
> I was thinking maybe I should do the difference on the 2D versions
> with the slab (before extruding), then extrude and merge the two
> extrusions together (so the extruded slab would never exist in 3D by
> itself).

Here's what I am trying now:

union()
{
linear_extrude(protoplast_chamber_height)
{
difference()
{
pdms_slab(distance_output_port_from_center);
protoplast_bottom_layer_2d(args);
}
}

linear_extrude(io_height)
{
difference()
{
pdms_slab(distance_output_port_from_center);
protoplast_io(args);
}
}
}

[Christopher Olah]

I think that will fix the issue, although you don't have to do it that
way. As long as you subtract a big enough part, you can do the
difference after the extrusion.

Either way should work.

Chris

[nmz...@gmail.com]

On Monday, December 29, 2014 11:36:17 AM UTC-8, Christopher Olah wrote:
> I think Reinound is right that the issue is z-fighting. To
> ImplicitCAD, depending on how things line up, it could very easily
> look like there is still a boundary on the z=0 plane.
>
> Try something like this:
>
> difference()
> {
> linear_extrude(io_height)
> {
> pdms_slab(distance_output_port_from_center);
> }
> translate([0,0,-1]) union()
> {
> linear_extrude(protoplast_chamber_height + 1)
> protoplast_bottom_layer_2d(args);
> linear_extrude(io_height + 1)
> protoplast_io(args)
> }
> }

Ok, I will try that next. Do you think this will mitigate the issue, or just confirm that it is most likely z-fighting?

[Christopher Olah]

I think that will mitigate the issue, though it's obviously possible
I'm wrong or that I've misunderstood something. (You can change 1 to a
more appropriate scale, if that's really big/small.)

Chris