I'm pretty new at solidworks!!
But I've been able to create a solid from a stl files. It's a Truncated tetrahedron shape.
Now I wanted this shape to be hollow (for 3D printing and adding threads).
So I've searched for a while and found a tutorial for the shell tool. This didn't work out because it gave me an error. That the faces may offset in adjacent spaces.
So I thought if I had one part and then a the same part but scale it 3mm. Place them on the same spot and then subtract them of some sort. It would give me the same shelled shape I want.
Would this work and does anybody know a way to do this or has a better way to hollow out my solid.
STL & PART upload.
Files Google Drive
If you have SOLIDWORKS Professional or Premium, you can use ScanTo3D to turn the part into a Solid / Surface body. At that point, you can manipulate the geometry as you would anything else in SOLIDWORKS.
Here's a video showing both turning on ScanTo3D and how to use it.
https://youtu.be/ZjzqWCfNfmQ
"So I thought if I had one part and then a the same part but scale it
3mm. Place them on the same spot and then subtract them of some sort.
It would give me the same shelled shape I want."
use the move/copy body command to copy it
use the scale command to scale it
use the combine feature to subject the smaller body from the main body
Alternatively use the check geometry feature to find any faulty faces and ALWAYS run import diagnostics on an imported body. if you can find and fix a faulty face try the shell tool again. If the minimum radius is too small then you will need to manually offset faces using the offset surface command
Related
I am using the Edit2D extension on an svf created from a 2D dwg file and have a question about transforms. The Autodesk.Edit2D.Polygon's that are created have a getArea() method which is great. However it's not in the correct unit scale. I tested one and something that should be roughly 230sf in size is coming back as about 2.8.
I notice that the method takes an argument of type Autodesk.Edit2D.MeasureTransform which I'm sure is what I need, however I don't know how to get that transform. I see that I can get viewer.model.getData().viewports[1].transform. However, that is just an array of 16 numbers and not a transform object so it creates an error when I try to pass it in.
I have not been able to find any documentation on this. Can someone tell me what units this is coming back in and/or how to convert to the same units as the underlying dwg file?
Related question, how do I tell what units the underlying DWG is in?
EDIT
To add to this, I tried to get all polylines in the drawing which have an area property. In this case I was able to figure out that the polyline in the underlying dwg was reporting its area in square inches (not sure if that's always the case). I generated Edit2D polygons based on the polylines so it basically just drew over them.
I then compared the area property from the polyline to the result of getArea() on the polygon to find the ratio. In this case it was always about 83 or 84 times smaller than the square foot value of the polyline it came from (there is some degree of error in my tracing system so I don't expect they would be exact at this point). However, that doesn't fit any unit value that I know of. So remaining questions:
What unit is this?
Is this consistent or do I need to look somewhere else for this scale?
Maybe you missed the section 3.2 Units for Areas and Lengths of https://forge.autodesk.com/en/docs/viewer/v7/developers_guide/advanced_options/edit2d-use/
If you use Edit2D without the MeasureExtension, it will display all coordinates in model units. You can customize units by modifying or replacing DefaultUnitHandler. More information is available in the Customize Edit2D tutorial.
and https://forge.autodesk.com/en/docs/viewer/v7/developers_guide/advanced_options/edit2d-customize/
BTW, we can get the DefaultUnitHandler by edit2dExt.defaultContext.unitHandler
Ok after a great deal of experimentation and frustration I think I have it working. I ended up looking direction into the js for the getArea() method in dev tools. Searching through the script, I found a class called DefaultMeasureTransform that inherits from MeasureTransform and takes a viewer argument. I was able to construct that and then pass it in as an argument to getArea():
const transform = new Autodesk.Edit2D.DefaultMeasureTransform(viewer);
const area = polygon.getArea(transform);
Now the area variable matches the units in the original cad file (within acceptable rounding error anyway, it's like .05 square inches off).
Would be nice to have better documentation on the coordinate systems, am I missing it somewhere? Either way this is working so hopefully it helps someone else.
I created Forge viewer app w/ Transformation Extension based on GitHub sample "forge-extensions", for unknown reason, gizmo is not visible after I click on element, only very small yellow dot after zoom in, I believe it's element center point and gizmo size is too small, so my question is how to control it? in fact, all the coding is copied from that GitHub sample "forge-extensions", I must miss something simple!
Have you tried your code with different types of models, and does it behave the same for all of them? I believe it may have something to do with the scale of the particular model, especially when looking at these lines of code from the viewer extension:
_transformControlTx.setSize(
bbox.getBoundingSphere().radius * 5);
Try and put a breakpoint there, and see what the radius is. Or try adjusting the hard-coded value.
Situation: Trying to output and also manipulate an indexed image.
Problem: When using ind2rgb(image, colormap(x)), we received an error saying that the indexed image contains colors outside of colormap, where x is the colormap option.
Question: How to work around this?
Additional information: I used imshow(image, colormap(x)), where I used every colormap available on Octave in substitution of x.
I believe this happens because you have more indexes than colors in colormap. Just make a bigger colormap. You can do that with the sysntax colormap(x(size_of_cmap))
ind2rgb(image, colormap(viridis(max(image(:))))
Alternatively, create the colormap and interpolate it. Caution: this can create artifacts in the color due to HSVs circular behavior.
m=max(image(:));
cm=colormap(x);
hsv=rgb2hsv(cm);
cm=interp1(linspace(0,1,size(cm,1)),hsv,linspace(0,1,m));
cm=hsv2rgb(cm);
ind2rgb(image,cm);
I suggest using the first solution if possible.
I am now using ITK library to image registration. I wonder, when setting initial parameters for ImageRegistrationMethodv4 type registration, shall I use SetMovingInitialTransform and SetFixedInitialTransform like in the tutorial, or just SetInitialTransform??
The "transform" in SetInitialTransform means transform for moving image or for fixed image? Thank you:)
(Please read this with caution--I do not have the library with me to test this answer; it's based on memory only.)
I believe SetInitialTransform() refers to the transform which is actually optimized by the registration method. In other words, it is a collection of transform parameters that specify an "initial guess" for the optimization process; these parameters will then start moving around at each iteration. (They are therefore applied to the moving image.)
I think SetMovingInitialTransform() and SetFixedInitialTransform() refer to static initial transforms which do no change at all during the registration process. They merely "set up" the moving and fixed images to desired starting locations, if you are not satisfied with their default positions in space.
If you have some simple 2D images, try testing this answer out with simple initial transformations, like a 5-unit translation transformation or something.
You could try reading the ImageRegistrationMethov4 documentation for a little more info.
After some wrestling, I have managed to put together a JSON file that can draw me a map of London and its boroughs. It's here http://graphitti.org/admin2/files/experiments/03_scaledTM5.html
Apart from the fact that the boundaries aren't perfect, the map seems OK but there's a problem in that some, but not all, of the paths apparently take up the whole SVG space. So when I inspect them in the DOM, I end up selecting the whole area. Likewise if I were to colour them in with a fill, I'd turn the whole space that colour.
I've noticed that this tends to happen with the larger boroughs, and the smaller ones are selectable through the DOM. That's not always true, but is there some limit to the number of coordinates that D3 can handle here? Or is there something else up with the code?
the JSON is here http://www.graphitti.org/admin2/files/experiments/EWNI2.json if anyone wants to inspect it. City of London is a "good" borough, as are Hackney and Tower Hamlets. Most of the others, eg Barnet, Barking, are "bad" in that they fill the SVG.
Some of your paths are "inside-out" as far as the d3 mapping functions are concerned. The order of points in a path or sub-path has to be clockwise for it to get mapped properly.
Counter-clockwise loops are interpretted as "holes" within a larger shape, the bounds of which are assumed to be outside the map. As a result, when you colour in the shape, everything except the area within the path gets coloured.
The docs recommend running your GeoJSON file through this utility to re-order the vertices in the correct structure. Of course, you could also write your own utility to reverse the order, and just manually go through and figure out which ones are incorrect.