USER FORUM
(you are viewing a thread; or go back to list of threads)
extruding sketch to a single point instead of a second plane (by cmpxchg)
I enjoyed Eric Buijs' tutorial on making / approximating involute gears with solvespace:
https://peertube.linuxrocks.online/w/91BKHZs9KT3DPm2pK19UxL
I can extrude the 2D gear sketch, and also extrude it to a helix and it all looks and works great when 3D printed.
But I did not find a sensible way to make a reasonable compact representation of a crowngear with current solvespace (3.0) features.
My idea of a crowngear is one that extrudes each point of the 2D gear sketch, from the source workplane, to a single destination point, which lays along the extrusion normal. This could be either a one- or two-sided extrusion in the solvespace userinterface.
To complete the crown gear to a reasonable flat shape, I would use difference and union operations with large objects around it, lathed, to limit the shape to the final object.
But the extrude-to-point feature is not present. I believe that, conceptially, it could be just a variant or checkbox of a normal extrusion, just like revolve and lathe (=360 degree revolve) are variants.
The resuling lines connecting upper and lower plane will not be perpendicular to the sourceplane anymore, but that is also not the case when skewing an extrusion described in the documentation: "It is possible to extrude perpendicular to a workplane other than the one the sketch is drawn in by selecting the other workplane prior to creating the extrusion. This can be used to create skewed extrusions. "
So I believe it should be possible for me to modify the C++ sourcecode to add this feature with relative ease - what pitfalls should I avoid or what I ideas do you have to prevent me from going such route ?
https://peertube.linuxrocks.online/w/91BKHZs9KT3DPm2pK19UxL
I can extrude the 2D gear sketch, and also extrude it to a helix and it all looks and works great when 3D printed.
But I did not find a sensible way to make a reasonable compact representation of a crowngear with current solvespace (3.0) features.
My idea of a crowngear is one that extrudes each point of the 2D gear sketch, from the source workplane, to a single destination point, which lays along the extrusion normal. This could be either a one- or two-sided extrusion in the solvespace userinterface.
To complete the crown gear to a reasonable flat shape, I would use difference and union operations with large objects around it, lathed, to limit the shape to the final object.
But the extrude-to-point feature is not present. I believe that, conceptially, it could be just a variant or checkbox of a normal extrusion, just like revolve and lathe (=360 degree revolve) are variants.
The resuling lines connecting upper and lower plane will not be perpendicular to the sourceplane anymore, but that is also not the case when skewing an extrusion described in the documentation: "It is possible to extrude perpendicular to a workplane other than the one the sketch is drawn in by selecting the other workplane prior to creating the extrusion. This can be used to create skewed extrusions. "
So I believe it should be possible for me to modify the C++ sourcecode to add this feature with relative ease - what pitfalls should I avoid or what I ideas do you have to prevent me from going such route ?
(no subject) (by Paul)
A few years ago I did some work on frustum extrusions. The idea was to not only allow tapering of an extrusion, but skewing as well. You can see what I did here:
https://github.com/phkahler/solvespace/tree/frustum
The specific commit is here:
https://github.com/phkahler/so...11148414066b174cc32fb8315111e3
If I recall correctly it requires selecting a point prior to extrusion. Everything is scaled relative to that point (origin). I don't know if the skewing is there, and I don't recall if it overrides the extrude funciton "X" or how it's invoked - I don't see a hotkey in the patch.
Your idea to extrude to a point (pyramid) is interesting and would avoid the need to copy entities with a new copy-type. On the other hand, it would create surfaces with a singularity at that point which could cause some issues. When you cut the top off, you won't get entities to constrain to either. But it is an interesting idea.
I don't know why I wasn't happy with the frustum extrusion. I think doing it gave me insight into how to make things like that and I decided there was something wrong with my approach. It is something I'd like to get back to, but feel free to experiment and ask more questions. Even create a pull request (WIP) to discuss specifics of your work. We'll take it if it turns out good!
https://github.com/phkahler/solvespace/tree/frustum
The specific commit is here:
https://github.com/phkahler/so...11148414066b174cc32fb8315111e3
If I recall correctly it requires selecting a point prior to extrusion. Everything is scaled relative to that point (origin). I don't know if the skewing is there, and I don't recall if it overrides the extrude funciton "X" or how it's invoked - I don't see a hotkey in the patch.
Your idea to extrude to a point (pyramid) is interesting and would avoid the need to copy entities with a new copy-type. On the other hand, it would create surfaces with a singularity at that point which could cause some issues. When you cut the top off, you won't get entities to constrain to either. But it is an interesting idea.
I don't know why I wasn't happy with the frustum extrusion. I think doing it gave me insight into how to make things like that and I decided there was something wrong with my approach. It is something I'd like to get back to, but feel free to experiment and ask more questions. Even create a pull request (WIP) to discuss specifics of your work. We'll take it if it turns out good!
(no subject) (by cmpxchg)
I just generated my first frustum-based pyramid and involute-gear (crown gear), and ready to print - much easier than I thought. Very clean C++ code - great.
I just went through your commit and integrated it into 3.0, and it seems to be working after minor symbol interfacing-related changes.
I added a new icon/toolbar/menu too and provided initial translation for the texts.
But have to test and understand a bit more before I can submit a WIP pull request - hopefully within a few days, have to select a name and setup a git repo for it etc.
Open things:
- Top plane is missing, I see the red inside of the object, walls seem ok. I have to compare the extrude code to see how to add this. Slicing the STL works fine though.
- Constraints and extra 'guiding line' color./interaction Perhaps make it green instead of white ?
- When saved, will this feature create file-version issues, how to address this ?
I just went through your commit and integrated it into 3.0, and it seems to be working after minor symbol interfacing-related changes.
I added a new icon/toolbar/menu too and provided initial translation for the texts.
But have to test and understand a bit more before I can submit a WIP pull request - hopefully within a few days, have to select a name and setup a git repo for it etc.
Open things:
- Top plane is missing, I see the red inside of the object, walls seem ok. I have to compare the extrude code to see how to add this. Slicing the STL works fine though.
- Constraints and extra 'guiding line' color./interaction Perhaps make it green instead of white ?
- When saved, will this feature create file-version issues, how to address this ?
(no subject) (by Paul)
That was unexpectedly fast!
- Top plane is missing,
I dont know. Did you make the "new" end larger or smaller than the original sketch? Larger may not work, as the surface is not enlarged so the trim curves might be outside the U,V range of [0..1]. Really not sure, I thought it worked.
- Constraints and extra 'guiding line' color.
White is consistent with all other extrusion methods.
- When saved, will this feature create file-version issues, how to address this ?
You should be able to save/load fine with your version of solvespace. Others will fail to load your file since they have no understanding of the SCALE_TRANS copy type for entities and no understanding of the new group. This is why we try so hard to "get it right" before merging new features. The implementation has to be kept for compatibility even if we later make a new way to do it.
I personally want to be able to twist the frustum and have a scale-rotate-translate prototype (SRT) on another branch somewhere. Used it in a mirror group experiment.
- Top plane is missing,
I dont know. Did you make the "new" end larger or smaller than the original sketch? Larger may not work, as the surface is not enlarged so the trim curves might be outside the U,V range of [0..1]. Really not sure, I thought it worked.
- Constraints and extra 'guiding line' color.
White is consistent with all other extrusion methods.
- When saved, will this feature create file-version issues, how to address this ?
You should be able to save/load fine with your version of solvespace. Others will fail to load your file since they have no understanding of the SCALE_TRANS copy type for entities and no understanding of the new group. This is why we try so hard to "get it right" before merging new features. The implementation has to be kept for compatibility even if we later make a new way to do it.
I personally want to be able to twist the frustum and have a scale-rotate-translate prototype (SRT) on another branch somewhere. Used it in a mirror group experiment.
frustum-prototype (by cmpxchg)
See attached a patchfile with your and my changes combined (github seemed broken for me)
There are obviously still many things wrong, but the concept seems to work and it exports usable geometry and hasn't crashed on me.
I changed the versionnumber to 3.001, please undo when integrating.
There are obviously still many things wrong, but the concept seems to work and it exports usable geometry and hasn't crashed on me.
I changed the versionnumber to 3.001, please undo when integrating.
experimental frustum assembly (by cmpxchg)
Attached an experiment with my frustum feature/patch. The files should load in a normal solvespace 3.0 binary as well, the frustum Type was assigned 5110 by me.
Top-level object is center.slvs
It is an 8-faced solid object, consisting of:
4 x hexagon_triangle_combo.slvs (along various axes puzzled together)
Each hexagon_triange_combo.slvs has two frustum-extruded 2d linkedobjects:
- hexagon_2d.slvs
- triangle_2d.slvs
both sliding around an axis, and have a additional DOF rotating around that axis.
Ideally the objects would shape themselves towards a working solid object with 8 faces.
Could such feature work, and if not, how could solvespace be adapted to make such way of working possible ?
Top-level object is center.slvs
It is an 8-faced solid object, consisting of:
4 x hexagon_triangle_combo.slvs (along various axes puzzled together)
Each hexagon_triange_combo.slvs has two frustum-extruded 2d linkedobjects:
- hexagon_2d.slvs
- triangle_2d.slvs
both sliding around an axis, and have a additional DOF rotating around that axis.
Ideally the objects would shape themselves towards a working solid object with 8 faces.
Could such feature work, and if not, how could solvespace be adapted to make such way of working possible ?
(no subject) (by Paul)
@cmpxchg
That polyhedron you tried to make can be created as an intersection of 2 tetrahedrons, or 4 slabs of equal thickness. I'm attaching one made with 4 slabs. I started with one square slab, constructed a tetrahedron on top to get the angles right for the next 3 workplanes, and extruded 3 more slabs with equal thickness as intersection. See attachment.
The sketches are not fully constrained, but that could be done leaving one DoF to make it resizable.
The key was to notice that each triangle and the opposite hexagon are parallel, so it's just an issue of getting the right cutting planes.
That polyhedron you tried to make can be created as an intersection of 2 tetrahedrons, or 4 slabs of equal thickness. I'm attaching one made with 4 slabs. I started with one square slab, constructed a tetrahedron on top to get the angles right for the next 3 workplanes, and extruded 3 more slabs with equal thickness as intersection. See attachment.
The sketches are not fully constrained, but that could be done leaving one DoF to make it resizable.
The key was to notice that each triangle and the opposite hexagon are parallel, so it's just an issue of getting the right cutting planes.
(no subject) (by cmpxchg)
@pual
I like your approach since having 'just 4 steps' might making a software-assisted CAM program to mill / CNC the solvespace-drafted parts easier.
However, the result produces only surfaces, and does not feature constrainable edges or datum points everywhere.
I was able to add these by creating 3D datum points and constraining them to 3 resulting faces each, and then I could also add/overlap the construction lines between them (see attached shape2.slvs in the zip).
I also want holes in the middle of each face. Constraining hexagon-contructionlines with equal length and locked to the face, and then creating a new workplane from two constructionlines and a dot to extrude a circle from.
But now the fun part: My intended polyhedron happens to have a irregular shaped hexagon, with a mix of 3x 13 mm (sibling hexagon edge) and 3x 26 mm edges (each triangle edge), which is a variant that I would like to generate ideally using only 2 length-constraints on the two of the 6 edges in the base of the design - feasible ? :)
I like your approach since having 'just 4 steps' might making a software-assisted CAM program to mill / CNC the solvespace-drafted parts easier.
However, the result produces only surfaces, and does not feature constrainable edges or datum points everywhere.
I was able to add these by creating 3D datum points and constraining them to 3 resulting faces each, and then I could also add/overlap the construction lines between them (see attached shape2.slvs in the zip).
I also want holes in the middle of each face. Constraining hexagon-contructionlines with equal length and locked to the face, and then creating a new workplane from two constructionlines and a dot to extrude a circle from.
But now the fun part: My intended polyhedron happens to have a irregular shaped hexagon, with a mix of 3x 13 mm (sibling hexagon edge) and 3x 26 mm edges (each triangle edge), which is a variant that I would like to generate ideally using only 2 length-constraints on the two of the 6 edges in the base of the design - feasible ? :)
(no subject) (by cmpxchg)
I just found out that there is already a ratio in your base model, but I think my intended shape does not have an exact 1:2 relationship between the 13 mm and 26 mm edges - I get 13.53 and 26.27.
(no subject) (by Paul)
You can make the ratio in my sketch 1/3 to get the correct shape for your strange hexagons. I should have built it a little differently, including having it centered at the origin.
You're right about not having anything to constrain to on the resulting solid. Finding the right places to constrain datum points to might do the trick. The issue is that all the resulting edges are created by the intersection of NURBS surfaces during boolean operations and we don't create sketch entities for them.
You're right about not having anything to constrain to on the resulting solid. Finding the right places to constrain datum points to might do the trick. The issue is that all the resulting edges are created by the intersection of NURBS surfaces during boolean operations and we don't create sketch entities for them.
Additional patch with working two faces (by cmpxchg)
Attached a second patch and sample frustum-extrusion file (frustum_cylinder.slvs) that correctly renders both faces. However, there are still additional constraints needed to make it all work. Slowly learning...
intial frustum GUI support (by cmpxchg)
Now also with changeable relative size and scale (latter should be removed, just like the 'two sided frustum extrude) in the property browser.
https://github.com/mjbastian/solvespace/ for others to try.
It is far from stable, but I was able to generate a frustum extrude from the parametric involute gear with it.
Tips: when creating a frustum, make the target 3D point offset, for a skewed frustum. Then start moving and constraining it to approximately 0,0,n
Constraining the top of the extrusion to two workplanes will create an invalid form with a negative relative size.
Now, how to make it more stable ... it complains and crashes during load/save about an unknown entity type - perhaps the new POINT_SCALE_TRANS entity support needs a thorough check.
Now: would it be feasible to have a new constraint-type, for example, a generic 'positive only' or 'quadrant 1' constraint for points ?
This way ambiguity with a sketch with 1 DOF resulting in 2 underconstrained points would be resolvable to a consistent solution, also when starting geometry happened to end up in a wrong quadrant.
The remaining DOF could then get assigned a name (can solvespace list DOFs and underconstrained points?) and you can then work towards a system with input parameters for a linked object.
https://github.com/mjbastian/solvespace/ for others to try.
It is far from stable, but I was able to generate a frustum extrude from the parametric involute gear with it.
Tips: when creating a frustum, make the target 3D point offset, for a skewed frustum. Then start moving and constraining it to approximately 0,0,n
Constraining the top of the extrusion to two workplanes will create an invalid form with a negative relative size.
Now, how to make it more stable ... it complains and crashes during load/save about an unknown entity type - perhaps the new POINT_SCALE_TRANS entity support needs a thorough check.
Now: would it be feasible to have a new constraint-type, for example, a generic 'positive only' or 'quadrant 1' constraint for points ?
This way ambiguity with a sketch with 1 DOF resulting in 2 underconstrained points would be resolvable to a consistent solution, also when starting geometry happened to end up in a wrong quadrant.
The remaining DOF could then get assigned a name (can solvespace list DOFs and underconstrained points?) and you can then work towards a system with input parameters for a linked object.
(no subject) (by Paul)
My original version allowed you to use a length ratio constraint, or set angles, or whatever to de define the ratio. It is preferable and more flexible than having a ratio in the text window.
Having said that, helix groups allow both. You can drag the length or angle, but can also use a fixed pitch parameter in the text window (in git master, not version 3).
Another thing I recall is that dragging my frustum would never change the ratio. That was due to the way force-to or something in entity.cpp handled the copy type. It would probably behave better if you added a very short fixed length segment to a point for dragging (a little handle). That bypasses the forced drag function and will let the solver use all degrees of freedom when dragging.
A lot of this I learned after trying to implement frustum.
Having said that, helix groups allow both. You can drag the length or angle, but can also use a fixed pitch parameter in the text window (in git master, not version 3).
Another thing I recall is that dragging my frustum would never change the ratio. That was due to the way force-to or something in entity.cpp handled the copy type. It would probably behave better if you added a very short fixed length segment to a point for dragging (a little handle). That bypasses the forced drag function and will let the solver use all degrees of freedom when dragging.
A lot of this I learned after trying to implement frustum.
heart-gear puzzle design attempt in solvespace (by cmpxchg)
Find attached a sample object to test the performance of the half-working frustum feature. It is a heart-shaped puzzle, inspired by the various heart gears available on thingiverse.
It does not work with the 3.0 and 3.1 builds, use https://github.com/mjbastian/solvespace/ for opening the .slvs files. The STLs are included too for a quick preview for the goal I was trying to accomplish.
The top-level sketch top_assy.slvs links the shape, its 8 pinholes, a sample-pin, and the 8 gears together, four 18t gears and four 9t gears. The outer shape is defined by a final intersection object heart.slvs.
The meshing of the gears is not done properly yet (1 DOF), hard to rotate the linked objects interactively.
However, it is very slow and crashes when not supressing the solids of all butup to 2 18t gears. Nevertheless, I was able to generate the STL files sequentially for a kind-of-working (not properly aligned-yet) puzzle.
Note that the heart-shape itself is very hard to model accurately with solvespace. I might design it in another triangle mesh tool and link it in as a binary STL file (text STL files not supported yet?). Ideas to model such puzzles in a better way are welcome!
It does not work with the 3.0 and 3.1 builds, use https://github.com/mjbastian/solvespace/ for opening the .slvs files. The STLs are included too for a quick preview for the goal I was trying to accomplish.
The top-level sketch top_assy.slvs links the shape, its 8 pinholes, a sample-pin, and the 8 gears together, four 18t gears and four 9t gears. The outer shape is defined by a final intersection object heart.slvs.
The meshing of the gears is not done properly yet (1 DOF), hard to rotate the linked objects interactively.
However, it is very slow and crashes when not supressing the solids of all butup to 2 18t gears. Nevertheless, I was able to generate the STL files sequentially for a kind-of-working (not properly aligned-yet) puzzle.
Note that the heart-shape itself is very hard to model accurately with solvespace. I might design it in another triangle mesh tool and link it in as a binary STL file (text STL files not supported yet?). Ideas to model such puzzles in a better way are welcome!
Post a reply to this comment: