Google Summer of Code 2014

classic Classic list List threaded Threaded
47 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Google Summer of Code 2014

kintel
Administrator
Hi all,

OpenSCAD, in collaboration with BRL-CAD, has been accepted into Google Summer of Code 2014!
In short: If you’re a student enrolled at a college or university, you have a chance of getting a USD 5K grant for working on OpenSCAD over the summer.

We’re aiming on taking one student this year, but may choose more if we find candidates who have already proven involvement, ability to work independently and are likely to communicate well with the community around their chosen project. I would strongly urge candidates to get their feet wet early, get OpenSCAD compiled and perhaps fix a bug or add a test, as well as sign up to the mailing list and hang out on IRC.

We’ve populated the wiki with some project ideas: https://github.com/openscad/openscad/wiki/Ideas:-GSoC-2014
Feel free to expand on any of those ideas or discuss new suitable ideas.

Some links:
o Google Summer of Code homepage: https://www.google-melange.com/gsoc/homepage/google/gsoc2014
o News entry for sharing: http://www.openscad.org/news.html#20140224
o BRL-CAD ideas page with more info about how to apply: http://brlcad.org/wiki/Google_Summer_of_Code/Project_Ideas

Cheers,

 -Marius

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: Google Summer of Code 2014

Alan Cox
On Wed, 26 Feb 2014 01:46:14 -0500
Marius Kintel <[hidden email]> wrote:

> Hi all,
>
> OpenSCAD, in collaboration with BRL-CAD, has been accepted into Google Summer of Code 2014!
> In short: If you’re a student enrolled at a college or university, you have a chance of getting a USD 5K grant for working on OpenSCAD over the summer.
>
> We’re aiming on taking one student this year, but may choose more if we find candidates who have already proven involvement, ability to work independently and are likely to communicate well with the community around their chosen project. I would strongly urge candidates to get their feet wet early, get OpenSCAD compiled and perhaps fix a bug or add a test, as well as sign up to the mailing list and hang out on IRC.
>
> We’ve populated the wiki with some project ideas: https://github.com/openscad/openscad/wiki/Ideas:-GSoC-2014
> Feel free to expand on any of those ideas or discuss new suitable ideas.

Is supporting a fixed point representation worth adding specifically to
that along with the generally 'making performance not suck' work for
of CGAL - bounding boxes to avoid excess automatic unions etc

Other ones I can think of are perhaps

- Correct support for binary stl (with ambiguity correcting)

- Experiment with other output formats, including pure geometry exporting
  to a slicer (this strikes me as good a university project)

- rounded unions

- plugins for things like 'upload to thingiverse'

On the UI

pick object in 3D window and as well as highlighting the code allow the
absolute co-ordinates/translation matrices to be seen

pick module in the code and allow the object occurrences to be seen in the
GUI (very handy I think for understanding someone elses model)

option to see differences and intersections as the actual object with a
mostly transparent differencing object/other areas of the intersect
(preferably a keyboard option too so you can just hit Fwhatever while
debugging)

Bigger ones

- solid colour support

- texture attachment

Alan

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: Google Summer of Code 2014

Jeff Keegan
In reply to this post by kintel
Hi Marius,

I've got a few suggestions for your OpenSCAD Google summer of code list, if you also think they're worth adding:

1) SpaceMouse Pro support
Work with people at 3dconnexion.com to get APIs to allow someone to write SpaceMousePro support for OpenSCAD

http://www.3dconnexion.com/products/spacemousepro.html

(Multiple people have mentioned this on their forums and they haven't responded - maybe the popularity of a Google summer of code project would motivate them to provide an API - then any of us could write the support even if a student didn't pick it).

2) GUI-based object inspection/manipulation
For certain object types, allow GUI manipulation of the objects' dimensions. For example, if there was a single cube, a user could click on an edge and drag it in a direction.. Depending on the camera angle you could figure out which primary axis they intended to move it on, and during the drag you adjust that side of the object. You could also have a hovering on-screen display at the same time specifying the dimensions as they change.

For certain primitives this should be do-able and quite useful.. You start getting into trouble when you're nested below other nodes like rotate - you could either disallow GUI manipulation at that point (less credit) or tackle actually handing it somehow (have a small visual tree on-screen hovering with the transforms above the object, and showing your guess as to which variable they were trying to change).

You could also allow on-screen rotations etc. Plus you could allow Sketchup-like snap-to suggestions, so if you were dragging one boxes edge and it came near a taller box, it could snap to those dimensions. Again it gets really difficult because that other box might be in a transformation tree of its own but you could just move the dimension to where the other one ended up after transformations (e.g. That other object in its transformation tree ended up with a west face at x=48.2, so just use that result for the snap).

When starting a drag you could also bring up a popup menu to disambiguate which node was being manipulated (did you want to change the translate node above this primitive cube, or did you want to change the translate node 4 levels above that in the hierarchy that also included other nodes? Did you want to change the value in this scale node, or in another? Etc.

Another approach might be to enter a GUI-manipulation-mode with some key, which then somehow renders visual representations of all translate, rotate, and scale nodes. Selecting one could scroll down to the text for the code, but also bring up a slider in some GUI panel. You could then slide that value left/right, changing the numeric value (to translate or scale or rotate), and then allow the snap-to behavior suggested above. This would eliminate some of the confusion about which object was being manipulated (and how), but would feel a little less intuitive, maybe.

Lastly, even if manipulation were deemed too difficult, it would be interesting to click on an edge and see its resulting dimensions, what nodes above it caused that, etc.

3) OpenSCAD Simulation Engine
Create a framework for simulating machines built with OpenSCAD. allow someone to design a machine in OpenSCAD (as we do now), but tie programmatic interfaces to rotation and translation nodes to simulate servos, stepper motors, and linear actuators. Perform collision detection (that could be its own high level suggestion actually). Let someone programmatically tie their control code to this OpenSCAD simulation engine to simulate their device.

If someone can run their RepRap firmware in an emulator of their own and tie the stepper motor commands (and optical/mechanical sensors via collision detection) to this OpenSCAD simulation engine, they should be able to test their virtually constructed RepRap design homing itself, moving around, and seeing when things would crash into each other.

There's my $0.02. :)

..Jeff Keegan
[hidden email]

Sent from my iPhone

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: Google Summer of Code 2014

Whosawhatsis
If you want to try the visual manipulation thing (which doesn’t appeal to me, personally), you should look at CoffeeSCAD’s implementation for ideas and/or a place to steal and port code from: https://plus.google.com/112899217323877236232/posts/gzfEGhHaS8w

On Wednesday, February 26, 2014 at 7:22 AM, Jeff Keegan wrote:

Hi Marius,

I've got a few suggestions for your OpenSCAD Google summer of code list, if you also think they're worth adding:

1) SpaceMouse Pro support
Work with people at 3dconnexion.com to get APIs to allow someone to write SpaceMousePro support for OpenSCAD


(Multiple people have mentioned this on their forums and they haven't responded - maybe the popularity of a Google summer of code project would motivate them to provide an API - then any of us could write the support even if a student didn't pick it).

2) GUI-based object inspection/manipulation
For certain object types, allow GUI manipulation of the objects' dimensions. For example, if there was a single cube, a user could click on an edge and drag it in a direction.. Depending on the camera angle you could figure out which primary axis they intended to move it on, and during the drag you adjust that side of the object. You could also have a hovering on-screen display at the same time specifying the dimensions as they change.

For certain primitives this should be do-able and quite useful.. You start getting into trouble when you're nested below other nodes like rotate - you could either disallow GUI manipulation at that point (less credit) or tackle actually handing it somehow (have a small visual tree on-screen hovering with the transforms above the object, and showing your guess as to which variable they were trying to change).

You could also allow on-screen rotations etc. Plus you could allow Sketchup-like snap-to suggestions, so if you were dragging one boxes edge and it came near a taller box, it could snap to those dimensions. Again it gets really difficult because that other box might be in a transformation tree of its own but you could just move the dimension to where the other one ended up after transformations (e.g. That other object in its transformation tree ended up with a west face at x=48.2, so just use that result for the snap).

When starting a drag you could also bring up a popup menu to disambiguate which node was being manipulated (did you want to change the translate node above this primitive cube, or did you want to change the translate node 4 levels above that in the hierarchy that also included other nodes? Did you want to change the value in this scale node, or in another? Etc.

Another approach might be to enter a GUI-manipulation-mode with some key, which then somehow renders visual representations of all translate, rotate, and scale nodes. Selecting one could scroll down to the text for the code, but also bring up a slider in some GUI panel. You could then slide that value left/right, changing the numeric value (to translate or scale or rotate), and then allow the snap-to behavior suggested above. This would eliminate some of the confusion about which object was being manipulated (and how), but would feel a little less intuitive, maybe.

Lastly, even if manipulation were deemed too difficult, it would be interesting to click on an edge and see its resulting dimensions, what nodes above it caused that, etc.

3) OpenSCAD Simulation Engine
Create a framework for simulating machines built with OpenSCAD. allow someone to design a machine in OpenSCAD (as we do now), but tie programmatic interfaces to rotation and translation nodes to simulate servos, stepper motors, and linear actuators. Perform collision detection (that could be its own high level suggestion actually). Let someone programmatically tie their control code to this OpenSCAD simulation engine to simulate their device.

If someone can run their RepRap firmware in an emulator of their own and tie the stepper motor commands (and optical/mechanical sensors via collision detection) to this OpenSCAD simulation engine, they should be able to test their virtually constructed RepRap design homing itself, moving around, and seeing when things would crash into each other.

There's my $0.02. :)

..Jeff Keegan

Sent from my iPhone

_______________________________________________
OpenSCAD mailing list


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: Google Summer of Code 2014

MichaelAtOz
Administrator
Perhaps a documentation task, a process to version the wiki to enable new features to be documented without confusing users of previous versions. ?
Admin - email* me if you need anything,
or if I've done something stupid...
* click on my MichaelAtOz label, there is a link to email me.

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.
Obviously 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/ time is running out!
tp3
Reply | Threaded
Open this post in threaded view
|

Re: Google Summer of Code 2014

tp3
MichaelAtOz wrote
Perhaps a documentation task, a process to version the wiki to enable new features to be documented without confusing users of previous versions. ?
That's unfortunately not possible. The FAQ specifically states the assignment must be coding, not documentation only. Mediawiki-fu probably does not count as coding :-).

https://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2014/help_page#12._Are_proposals_for_documentation_work
-- Torsten
RGH
Reply | Threaded
Open this post in threaded view
|

Re: Google Summer of Code 2014

RGH
This post has NOT been accepted by the mailing list yet.
In reply to this post by kintel
A relative novice here, I'd really like to see a way to do rounded edges, or bevelled/chamfered edges.

The workarounds that I've seen seem to be REALLY complicated, or at least non-obvious.

If I'm missing a way to do them easily, maybe someone can point me in the right direction.
RGH
Reply | Threaded
Open this post in threaded view
|

Re: Google Summer of Code 2014

RGH
In reply to this post by tp3
A relative novice here, I'd really like to see a way to do rounded edges, or bevelled/chamfered edges.

The workarounds that I've seen seem to be REALLY complicated, or at least non-obvious.

If I'm missing a way to do them easily, maybe someone can point me in the right direction.


Another idea would be for partial (angle) rotate_extrudes.
Reply | Threaded
Open this post in threaded view
|

Re: Google Summer of Code 2014

drxenocide
RGH, You can do those with a minkowski(), but it takes forever. The work arounds are complicated, because they have to do it without the minkowski() function. I made code for a rounded block and rounded wedge in http://www.thingiverse.com/thing:129904/#files. It is complicated, but I think I commented it well, if anyone wants to make it a standard function with OpenSCAD, I will donate the code to GPL.


On Sat, Mar 8, 2014 at 11:19 AM, RGH <[hidden email]> wrote:
A relative novice here, I'd really like to see a way to do rounded edges, or
bevelled/chamfered edges.

The workarounds that I've seen seem to be REALLY complicated, or at least
non-obvious.

If I'm missing a way to do them easily, maybe someone can point me in the
right direction.


Another idea would be for partial (angle) rotate_extrudes.



--
View this message in context: http://forum.openscad.org/Google-Summer-of-Code-2014-tp7014p7156.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: Google Summer of Code 2014

ednisley
In reply to this post by RGH
On 03/08/2014 11:19 AM, RGH wrote:
> a way to do rounded edges

Given the radius of the rounding, put spheres (with suitable $fa $fn
$fs) at the block's vertices (inset by their radius), and then wrap a
hull() around the spheres.

This example fell out of a discussion here a while back, so it's not
original with me:

http://softsolder.com/2014/01/29/rounded-rectangles-in-openscad-mold-positives/

As long as it's a convex brick, you can make it any shape you want, and
the edges need not have the same radii.

I think that gets you most of the way to the goal and it's quick and
relatively easy.

--
Ed
softsolder.com
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
 --
Ed
softsolder.com
RGH
Reply | Threaded
Open this post in threaded view
|

Re: Google Summer of Code 2014

RGH
Hi Ed,

I've been implementing something similar although I didn't think to write a separate module (duh). Although in my defence when I was really stuck, I was trying to do it for a parametric extruded polygon. In this particular case a decagon made up of triangles with a for loop.

I would still think that in terms of improving the functionality of OpenSCAD during the summer of CODE, this would be something nice (and easy?) to implemement as a function. Some of the mathscad libraries (e.g. curves) might be nice as functions too. Basically I was trying to suggest improvements that might be relatively trivial, but from a user standpoint are very useful (although they might be kind of boring to implement from a coder's standpoint).


I also find using the hull() function and spheres to take a LONG time to render, although I have no idea if this would improve if it was a function.


Ari thanks for your link to the door. I've downloaded it, and I'll take a closer look at the code.

RG





On Sun, Mar 9, 2014 at 9:20 AM, Ed Nisley <[hidden email]> wrote:
On 03/08/2014 11:19 AM, RGH wrote:
> a way to do rounded edges

Given the radius of the rounding, put spheres (with suitable $fa $fn
$fs) at the block's vertices (inset by their radius), and then wrap a
hull() around the spheres.

This example fell out of a discussion here a while back, so it's not
original with me:

http://softsolder.com/2014/01/29/rounded-rectangles-in-openscad-mold-positives/

As long as it's a convex brick, you can make it any shape you want, and
the edges need not have the same radii.

I think that gets you most of the way to the goal and it's quick and
relatively easy.

--
Ed
softsolder.com
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566



--
----------------------------------------------------

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: Google Summer of Code 2014

ednisley
On 03/09/2014 07:59 PM, Robert Harris wrote:
> a decagon made up of triangles with a for loop

Do you prune duplicated vertices? If not, perhaps all those
not-quite-coincident spheres produce a gazillion overlapping faces that
slow down the hull() operation.

It's programming as an experimental science... [grin]

--
Ed
softsolder.com
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
 --
Ed
softsolder.com
RGH
Reply | Threaded
Open this post in threaded view
|

Re: Google Summer of Code 2014

RGH
Actually my hull with spheres on just a cube took about 5 minutes. Admittedly I was using $fn=75. Anything else still looks as if it has facets. Admittedly I have not tried to print anything similar yet, so I can't tell what is necessary for the resolution of my printer, but I know that $fn=20 for example is insufficient on cylinders.

Now, admittedly 5 minutes isn't really a long time in the grand scheme of things but I worry about objects that are significantly more complex. I have a spiral marble track that uses a for loop to essentially extrude a U shape down a spiral path. That takes about 20+ minutes to render.
With the decagon I actually have to add a +0.1 fudge factor to the two non [0,0] point of the triangle to make sure the adjoining faces actually overlap, or it won't render at all (and actually can crash OpenSCAD - in Linux 13.1 version. I can't seem to find anything newer (the 13.6 I am having problems compiling, but that's probably me)).

So how do I prune Vertices? I'd love to save time!

Admittedly I am using a "thin and light" laptop that, while it is fairly new is probably low on Graphical power.

Incidentally I'm not a coder by any stretch of the imagination. I was fairly handy (in a very basic way) with a language called modula 2 (think TurboPascal), but that was 20 years ago, and bears no relation to the C-type code I've been told OpenSCAD uses. (More importantly I don't know how to program "efficiently", or the tricks one can use. My OpenSCAD files are probably brute force!)

On the other hand I am an ( experimental) scientist by training so I really like the way OpenSCAD works. I much prefer using trigonometry than trying to draw something with a mouse!

RG





On Mon, Mar 10, 2014 at 8:48 AM, Ed Nisley <[hidden email]> wrote:
On 03/09/2014 07:59 PM, Robert Harris wrote:
> a decagon made up of triangles with a for loop

Do you prune duplicated vertices? If not, perhaps all those
not-quite-coincident spheres produce a gazillion overlapping faces that
slow down the hull() operation.

It's programming as an experimental science... [grin]

--
Ed
softsolder.com
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566



--
----------------------------------------------------

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
tp3
Reply | Threaded
Open this post in threaded view
|

Re: Google Summer of Code 2014

tp3
RGH wrote
I can't seem to find anything newer (the 13.6 I am having problems compiling, but that's probably me)).
You can have a look at the generic Linux release-build 2014.03 released yesterday :-).

http://www.openscad.org/downloads.html#linux

The distribution packages are in the works (The one for Arch-Linux is already updated too).
-- Torsten
Reply | Threaded
Open this post in threaded view
|

Re: Google Summer of Code 2014

ednisley
In reply to this post by RGH
On 03/10/2014 09:04 AM, Robert Harris wrote:
> using $fn=75

That's probably excessive. For 3D printed things, anything under about
0.5 mm gets lost in the noise, so you might want to set $fs to that and
see what comes out of the nozzle.

Chunky polygons-as-circles suffice for most of what I do, so I generally
set $fn (not $fs) to multiples of 4. That means the equators have the
same number of faces in each quadrant and the vertices / edges line up
neatly on the axes.

> With the decagon I actually have to add a +0.1 fudge factor
 > to the two non [0,0] point of the triangle
 > to make sure the adjoining faces actually overlap,

Splicing stuff together requires an overlap to ensure the result becomes
a manifold object, which is why I've come to love hull().

Because you know the coordinates of all the vertices, you can position
little teeny weeny cubes at those points, then shrink-wrap them with
hull() to get a single, guaranteed-manifold solid. For a regular
polygon, I'd iterate an integer, compute the angle, generate the
coordinates, and translate the cubes, but the smarter folks around here
use fancier methods.

Or you could define a 2D figure with polygon() and extrude it to make a
3D solid.

> I much prefer using trigonometry than trying to draw something with a mouse!

You've come to the right place... [grin]

--
Ed
softsolder.com
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
 --
Ed
softsolder.com
Reply | Threaded
Open this post in threaded view
|

Re: Google Summer of Code 2014

nophead
For a regular polygon, I'd iterate an integer, compute the angle, generate the
coordinates, and translate the cubes, but the smarter folks around here
use fancier methods.
cylinder(r = 20, $fn = 10);
 
:-)



On 10 March 2014 14:58, Ed Nisley <[hidden email]> wrote:
On 03/10/2014 09:04 AM, Robert Harris wrote:
> using $fn=75

That's probably excessive. For 3D printed things, anything under about
0.5 mm gets lost in the noise, so you might want to set $fs to that and
see what comes out of the nozzle.

Chunky polygons-as-circles suffice for most of what I do, so I generally
set $fn (not $fs) to multiples of 4. That means the equators have the
same number of faces in each quadrant and the vertices / edges line up
neatly on the axes.

> With the decagon I actually have to add a +0.1 fudge factor
 > to the two non [0,0] point of the triangle
 > to make sure the adjoining faces actually overlap,

Splicing stuff together requires an overlap to ensure the result becomes
a manifold object, which is why I've come to love hull().

Because you know the coordinates of all the vertices, you can position
little teeny weeny cubes at those points, then shrink-wrap them with
hull() to get a single, guaranteed-manifold solid. For a regular
polygon, I'd iterate an integer, compute the angle, generate the
coordinates, and translate the cubes, but the smarter folks around here
use fancier methods.

Or you could define a 2D figure with polygon() and extrude it to make a
3D solid.

> I much prefer using trigonometry than trying to draw something with a mouse!

You've come to the right place... [grin]

--
Ed
softsolder.com
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: Google Summer of Code 2014

drxenocide
Wow! Using Ed's suggestion of hull() instead of union() on my design that I linked above, F5 rendering went up from 0 to 2 seconds, but F6 rendering went down from 0:5:04 to 0:0:54. Vertices went down by about 60%, edges went down by about 40%, and facets by about 30%, and it's manifold!

Now, knowing this, why would I use union() instead of hull() ?


On Mon, Mar 10, 2014 at 11:04 AM, nop head <[hidden email]> wrote:
For a regular polygon, I'd iterate an integer, compute the angle, generate the
coordinates, and translate the cubes, but the smarter folks around here
use fancier methods.
cylinder(r = 20, $fn = 10);
 
:-)



On 10 March 2014 14:58, Ed Nisley <[hidden email]> wrote:
On 03/10/2014 09:04 AM, Robert Harris wrote:
> using $fn=75

That's probably excessive. For 3D printed things, anything under about
0.5 mm gets lost in the noise, so you might want to set $fs to that and
see what comes out of the nozzle.

Chunky polygons-as-circles suffice for most of what I do, so I generally
set $fn (not $fs) to multiples of 4. That means the equators have the
same number of faces in each quadrant and the vertices / edges line up
neatly on the axes.

> With the decagon I actually have to add a +0.1 fudge factor
 > to the two non [0,0] point of the triangle
 > to make sure the adjoining faces actually overlap,

Splicing stuff together requires an overlap to ensure the result becomes
a manifold object, which is why I've come to love hull().

Because you know the coordinates of all the vertices, you can position
little teeny weeny cubes at those points, then shrink-wrap them with
hull() to get a single, guaranteed-manifold solid. For a regular
polygon, I'd iterate an integer, compute the angle, generate the
coordinates, and translate the cubes, but the smarter folks around here
use fancier methods.

Or you could define a 2D figure with polygon() and extrude it to make a
3D solid.

> I much prefer using trigonometry than trying to draw something with a mouse!

You've come to the right place... [grin]

--
Ed
softsolder.com
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
RGH
Reply | Threaded
Open this post in threaded view
|

Re: Google Summer of Code 2014

RGH
In reply to this post by ednisley

Thanks for the advice.
I might try the thing with the cubes. The decagon was for a sprocket for a chain link conveyor belt (imagine links lying flat on each side). I wanted it to be parametric so I could define the number of sides (decagon versus octagon versus dodecagon or even nonagon), the side length rather than diameter and the width, so I calculated the angle based on the number of sides required then made the appropriate number of triangles then extruded the whole thing to get the width. Getting overlapping triangles so it extruded properly was where I ran into problems. I can see how cubes could be adapted easily to the same method ( which I think was what you were suggesting). Then using hull to make sure it was all solid.

The problem with using $fn=10 is that I wasn't sure exactly how diameter related to face length in this case (there's more than one diameter to choose from).

Anyway thanks for the responses!

On 10 Mar 2014 10:58, "Ed Nisley" <[hidden email]> wrote:
On 03/10/2014 09:04 AM, Robert Harris wrote:
> using $fn=75

That's probably excessive. For 3D printed things, anything under about
0.5 mm gets lost in the noise, so you might want to set $fs to that and
see what comes out of the nozzle.

Chunky polygons-as-circles suffice for most of what I do, so I generally
set $fn (not $fs) to multiples of 4. That means the equators have the
same number of faces in each quadrant and the vertices / edges line up
neatly on the axes.

> With the decagon I actually have to add a +0.1 fudge factor
 > to the two non [0,0] point of the triangle
 > to make sure the adjoining faces actually overlap,

Splicing stuff together requires an overlap to ensure the result becomes
a manifold object, which is why I've come to love hull().

Because you know the coordinates of all the vertices, you can position
little teeny weeny cubes at those points, then shrink-wrap them with
hull() to get a single, guaranteed-manifold solid. For a regular
polygon, I'd iterate an integer, compute the angle, generate the
coordinates, and translate the cubes, but the smarter folks around here
use fancier methods.

Or you could define a 2D figure with polygon() and extrude it to make a
3D solid.

> I much prefer using trigonometry than trying to draw something with a mouse!

You've come to the right place... [grin]

--
Ed
softsolder.com
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: Google Summer of Code 2014

G. Wade Johnson
In reply to this post by drxenocide
On Mon, 10 Mar 2014 11:30:48 -0400
Ari Diacou <[hidden email]> wrote:

> Wow! Using Ed's suggestion of hull() instead of union() on my design
> that I linked above, F5 rendering went up from 0 to 2 seconds, but F6
> rendering went down from 0:5:04 to 0:0:54. Vertices went down by
> about 60%, edges went down by about 40%, and facets by about 30%, and
> it's manifold!
>
> Now, knowing this, why would I use union() instead of hull() ?

Because they are different tools for different jobs?<grin/>

More seriously, hull() cannot be used by itself to generate a concave
shape. Using union() can generate one. (Try creating an "X" shape, it
will be obvious that hull() doesn't give what you want.)

That being said, there are many places where hull() gives a simpler
representation than a union. YMMV.

G. Wade

> On Mon, Mar 10, 2014 at 11:04 AM, nop head <[hidden email]> wrote:
>
> > For a regular polygon, I'd iterate an integer, compute the angle,
> >> generate the
> >> coordinates, and translate the cubes, but the smarter folks around
> >> here use fancier methods.
> >
> > cylinder(r = 20, $fn = 10);
> >
> > :-)
> >
> >
> >
> > On 10 March 2014 14:58, Ed Nisley <[hidden email]> wrote:
> >
> >> On 03/10/2014 09:04 AM, Robert Harris wrote:
> >> > using $fn=75
> >>
> >> That's probably excessive. For 3D printed things, anything under
> >> about 0.5 mm gets lost in the noise, so you might want to set $fs
> >> to that and see what comes out of the nozzle.
> >>
> >> Chunky polygons-as-circles suffice for most of what I do, so I
> >> generally set $fn (not $fs) to multiples of 4. That means the
> >> equators have the same number of faces in each quadrant and the
> >> vertices / edges line up neatly on the axes.
> >>
> >> > With the decagon I actually have to add a +0.1 fudge factor
> >>  > to the two non [0,0] point of the triangle
> >>  > to make sure the adjoining faces actually overlap,
> >>
> >> Splicing stuff together requires an overlap to ensure the result
> >> becomes a manifold object, which is why I've come to love hull().
> >>
> >> Because you know the coordinates of all the vertices, you can
> >> position little teeny weeny cubes at those points, then
> >> shrink-wrap them with hull() to get a single, guaranteed-manifold
> >> solid. For a regular polygon, I'd iterate an integer, compute the
> >> angle, generate the coordinates, and translate the cubes, but the
> >> smarter folks around here use fancier methods.
> >>
> >> Or you could define a 2D figure with polygon() and extrude it to
> >> make a 3D solid.
> >>
> >> > I much prefer using trigonometry than trying to draw something
> >> > with a
> >> mouse!
> >>
> >> You've come to the right place... [grin]
> >>
> >> --
> >> Ed
> >> softsolder.com
> >> _______________________________________________
> >> OpenSCAD mailing list
> >> [hidden email]
> >> http://rocklinux.net/mailman/listinfo/openscad
> >> http://openscad.org - https://flattr.com/thing/121566
> >>
> >
> >
> > _______________________________________________
> > OpenSCAD mailing list
> > [hidden email]
> > http://rocklinux.net/mailman/listinfo/openscad
> > http://openscad.org - https://flattr.com/thing/121566
> >


--
An expert is a person who has made all the mistakes that can be made in
a very narrow field.                                    -- Niels Bohr
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: Google Summer of Code 2014

ednisley
In reply to this post by nophead
On 03/10/2014 11:04 AM, nop head wrote:
> cylinder(r = 20, $fn = 10);

All the world's progress comes from smart folks with one-liners...

--
Ed
softsolder.com
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
 --
Ed
softsolder.com
123