I recently had the opportunity to dig in a little deeper to the sandbox tools, particularly the stamp tool. Visions of all the time I’ve wasted over the years not having an understanding of that!
One thing, though, and I’m hoping I’m simply missing something, but the stamp tool doesn’t seem to use the inferencing engine in SU. I was placing building pads in a sloping terrain model and had modeled a plane at the elevation I want the surface of the pad. Thinking I could inference a corner of the plane. But stamp wouldn’t do that, I had to just “eyeball” it to the elevation.
Is this the behavior of the tool? Seems odd that it wouldn’t inference similar to push/pull etc.
I see that, too, Bob. Not sure why it is like that but you’re right. Inferencing doesn’t seem to be active with Stamp. Have a look at this, though.
It looks like the intent is not to have the stamped terrain faces moved to meet the slab or whatever. The expectation is that you set the height of the stamping and move the slab or whatever down to meet it.
Still, it seems like inferencing would be useful here since there’s no way to set a height like you could with Push/Pull
Yea, I read that too. Problem is, that when you have a height envelope to stay within and floor to floor heights, you arrive at a calculated elevation for the building pad. It’d be great if you could set the stamped pad at that elevation. I wasn’t too far off eyeballing it - about an 1/8". The guys in the field aren’t going to get it that close.
I wonder if that’s something one of the plug in geniuses could look at?
I know@TIG wrote an extension (CutNFill) that does building pads and lets you estimate cut and fill volumes. It’s over at SketchUcation. Search on “Cut Fill”.
Encountering the same thing.
Tutorials of previous versions show automatic inferencing to surface of TIN.
Seems like there should be a way to stamp the pad into the terrain at least with numeric input instead a freehand eyeballing it.
Instead the pad to be stamped appears in space with no known height value at all and no way to set a specific quantified height.
Well, now not sure I have interpreted correctly what I was seeing on my screen.
Wondering if someone would take a look at my file.
When I use the stamp tool I see no mesh attaching to the “pad” that I am stamping upon the mesh.
It seems to float in space yet controlled by the cursor waiting for me to place it.
I’m wondering if there is a setting I have missed that is making geometry invisible?
I am also having difficulty controlling the appearance of the terrain/mesh/contour object itself.
I have turned the contours into a closed faced object but a smooth shaded surface does not appear, I only see the original contours. In addition, when I view hidden geometry I only see it within the surface of the road and not in the larger mesh object itself.
I’ve gone through all styles in the file and the same conditions hold.
The contours aren’t connected to the rest of the geometry. This is what I get when I triple click with Select on a border edge. I would expect all of the contours to be selected, too.
There are no faces in your main contour terrain model.
Different contours are in different groups, even when there appears to be the possibility of a closed face or faces, so faces can’t form. However, the shaded area in the image below is a surface within a Group with Instance name Contours / Faced, and shows smoothed - it’s tagged SP_Contours Faced.
The rectangle in the group with instance name Structure, and tagged ‘structure’ is above the terrain that has no faces, and hence no mesh to stamp, as far as I can see.
Not quite sure what you are expecting to happen.
It generally is not a good idea to tag edges or faces directly, but you have done that with all the contour lines in the ‘white’ part of the model. Not sure why - as DaveR says, it may have imported that way, or you may have done it deliberately in order to know what height to raise an originally 2D contour map.
Sort out the contour grouping, and use the Draw/Sandbox tool to create a surface From Contours, and that may get you started.
But follow Dave’s advice first to clean up your model before going further.
Here I’ve made the surface from the contours to give Stamp something to do and Stamp works as designed. I do agree that it would be nice to be able to enter a number for the depth or height of the stamped face but then what number would you enter? Measured from where?
Whoa!
Thank you, thank you.
All of these things you two have pointed out to me I’ve had no idea about.
In fact the screen shot DaveR posted with the two contours side by side I’ve never seen before - ouch.
I did not think the faces of the mesh were missing. I thought they were appearing in a few places and not appearing in most others - it was a mere assumption of course.
This may have happened when I switched the linetype of the contours from solid to dashed.
The GIF from DaveR is great and a relief to see. I have NO idea how I managed to group those two terrains models together like that. Gheeze.
Will work on this and let you know how things go.
You two have been a big help.
Here’s a revised and slightly cleaned up version of the file. DLH_Site1 purged.skp (1.6 MB)
One thing you really need to pay attention to is how stuff is getting nested. It’s easy to let that get out of hand and you end up with excessive nesting that makes it plain old hard to get anything done. If you do use nesting, make sure you don’t have loose geometry mixed in with groups and/or components.
The nesting thing is on my list to look in to. I don’t understand yet how that is happening, but I’ll will make it a priority now.
BTW - have not opened the purged file you sent but did you copy and transform that contour terrain side by side or is that in my original file? I can’t seem to find it in the original. Or maybe you brought the original contours down from above where I’ve got them.
Any how - all is good and I’m grateful
That was in your original file. I opened the top level group and just moved the group inside off to the right. I moved it back for the file I uploaded.
One thing that could account for some of the nesting is related to using From Contours. If you open the contour lines group, select the contours and run From Contours, it creates a group containing the terrain surface. So at that point you have the loose geometry for the contours and the terrain group inside the Contours group. Probably the best thing at that point is to cut the terrain group (Cmd-X), exit the group edit mode, and paste in place. If you need to you can then select both groups and put them into a nested group. That can make it easier to handle them as a unit but you can tag them separately so if you want to show the contours as dashed lines, you can give the Contours tag a dashed style while the terrain tag doesn’t have dashes.
I don’t think so now, after first wondering about that. I thought at first that the dashed lines were in the original contour import, as individual edges, but then saw that the line type was Dashed. That only affects the appearance in SU - the lines are still continuous geometry.
It imported that way and for some reason I thought it was cool to be able to control each contour .
This is a bad idea because tagging edges of faces separately makes for a huge file size - right?
… am I correct about that?
Wrong. That’s not the reason and as far as I know it makes no significant difference to file size.
No, the reason for not tagging raw geometry (edges and faces) is to prevent confusion that can (and often does) arise, for beginners in particular, who think that different tags somehow keep geometry separate. They don’t, unlike other programs that use tags (formerly called layers in SketchUp - the name was changed to tags in v 2020 and later, to reduce the confusion).
Only groups and components separate geometry, not tags. They act as containers for geometry, and/or other sub-groups or sub-components.
Tags ONLY control visibility. So leave the default tag as Untagged (Layer0 in earlier versions of SU), and apply tags only to groups or components, or non-geometric objects like dimensions, text, section cuts, etc.
OK, yes I’ve learned the difference between Tags and Groups/Components amd like most users coming over from the world of AutoDesk it was confusing at first.
I still, however, consider myself a SU beginner whose one learning edge at present is how to find the most efficient relationship between Tags and Outliner. I find myself spending more time in Outliner than
Tags and I got a feeling that should be inverted.
As a rough rule of thumb, but not hard and fast, use Outliner while modelling, to get things out of your way by hiding them temporarily.
But use Tags and Scenes when you want to control viewpoints, camera ‘zoom’, view styles, what’s visible, and a range of other things you can control within a Scene, and want to be able to return to at will.
