I would like to show a park as planted, and then in 5 year intervals, but don't really want to do this by replacing each tree with a larger model of each tree for each age change. (And a 10 year old tree is not just a 5 year old tree scaled up.

I've groveled through the topics I could find in this forum, but so far haven't found much.

I'd like to create a dynamic tree that on instantiation would:

• create an internal table of random numbers. These would be used to control the dynamics.
• the tree would take a very small number of variables, such as age, season.
• Internally the tree would be modeled as branch angles, node ratios, diameters.
• With time the model does the appropriate pruning. Leaves only occur on branch tips

Because of the random number table each copy of the tree would be different. The table is large enough to handle an arbitrarily tree, or alternately it creates an extension to the table as needed.

By doing this, the trees are unique, but they don't have to be recalculated from scratch each time.

Is this possible?

Is sketchup the right tool?

Failing this does anyone know of sets of good trees that show the tree at various stages in life?

AFAIK there is no locus command in sketchup.

Eh?

A locus is a set of points meeting a condition. E.g the locus of all points 6 inches from one point is a sphere 12 inches in diameter.

Consider if you had a tool that could create a volume with a surface that was X units away from an object. Essentially it would be a 3d follow- me, but would work more like push pull.

Now build a coarse main branch structure for a tree.

One. Object is grouped. Locus is the envelope of the entire group.

Two. Object is ungrouped. Locus is the set of the envelopes of each element.

Now, consider if you apply a translucent shade to the surface, you end up with a watercolour of the tree.

Workable?

(Now someone will tell me that its been done, it's simple, and instructions are found. . . )

What you are looking for are DEMs. Digital elevation models. Most cities have ones created be synthetic aperture radar, accuracy about 1 meter, or lidar, accuracy about 1 foot. Rural areas are a lot more variable. The shuttle flew a mission that did SAR from orbit, but the grid spacing is about 30 meters, and the accuracy is awful.

If USGS topo data is good enough, I vaguely recall a page on converting topo lines to terrain. Warning: topo data is not very good at the house lot size level. There is typically a semi-systematic error in the horizontal placement of contour lines equal to several times the contour interval. The shape is right, but slope inflections tend to be moved away from the centre of the photographic track.

If its critical to get it right, rent a DGPS, and take a waypoint every 10 meters. If the terrain isn't too bad, you can do a hectare an hour.

Anyone have a pointer to a set of dynamic trees that can be 'grown' semi realistically. I'm trying to create a series of images that illustrate the changes as a landscape matures. Ideally it would show the change in shape at different ages.

I've gotten into trouble a few times working on a small component, on one side of a project. Trying to use the orbit tool makes the object vanish. Zoom out, find the project, zoom in. Try to orbit again, and everything vanishes again. Is there a way to tell sketchup that the current thing I'm looking at is the center of orbit?

The only thing I've found of use is to zoom out, orbit from there, zoom in. When you are working on a 3" molding in a 100 foot structure this is a PITA

Layers & Layer management.

I'm a newbie. Feel free to shoot me full of holes. I come to Sketchup from Mapmaker, a (surpise!) cartography program, with a little bit of experience from adobe illustrator.

At present, as far as I can figure out layers control visibility, and little else.

My wish:

1. Layers had three controls -- visibility, lockability, and inference ability.
2. A locked layer did not interact with new geometry. This should speed up SU on large models.
3. Being locked but inferenceable would allow you to use faces and lines as endpoints, as well as sources for making guides.
4. A non visible layer did not interact at all.

This doesn't require major programming. Under the hood layers become a form of grouping.

4. Layers have a hierarchy, and are not just in alphabetic order. Turning on and off a layer does so for the layer members.

I found in map making that for a given class of features it was useful to have up to 3 layers, one for points, one for lines, and one for areas. So for example when working with the hydrology group, points would include dams, stream junctions, coordinate points of a corners. Lines would be stream courses, areas would be lakes, ponds, swamps. Being able to lock the lakes layer made it possible to trace watercourses through the swamp without snapping to edges, center points and so on.

The topography group had the underlying DEM, which generally was visible only when working with it, a layer for contours, and a layer for contour points (elevation of index lines, and bench mark locations)

5. Layers have alternates depending on resolution.

I'm not sure quite how this translates in SU. In MM I worked with aerial photos as my base layer. Since I was mapping a fairly large area (for a personal project) -- about 200 square kilometers using 1 meter/pixel resolution, and this with a computer that had 500 MB ram and a 1 GHz processor. It was a while ago.

Anyway: MM had a feature where you could turn on/off layers depending on the current zoom level. So I reprocessed my images into 5 sets at 1, 2, 4, 8, and 16 meters per pixel. At large scales, I used the low resolution images. At small scales I used the finer resolution. This meant that at any given view point, only a few megs of phototiles needed to loaded.

If SU layers could have simplified geometery when sufficiently distant, this could speed up the display substantially. (From a sufficient distance a sphere is a cube)

This degree of simplification could apply to certain constructs too. From a view that barely includes a quarter of a circle, 20 sides isn't enough. From a view that includes a hundred circles, a hexagon is sometimes sufficient. The tradeoff would be at some zoom levels you would see artefacts of the simplification.

6. Layers have styles.

This would allow you to do things like turn of textures for the floor surfaces layer, while leaving it on for the countertops and cabinets layer. Or have one layer with hidden edges, one layer in wireframe, and one layer in solid with no edges showing. Or set a layer to have only 15% opacity so it is only ghostly visible.

Zoom behaviour.

As far as I can tell the model of zoom behaviour is that the view point is some arbitrary distance away, and zooming acts like zooming a camera lens. The position of the camera is constant, the angle of view changes.
This makes working with interiors tricky. So far as a newby, I've had to put exterior walls in a layer of their own, and turn them on/off as needed.

I would prefer the reverse: The angle of view remains constant (but setable) and so zooming was handled by moving the point of view. By doing this, as you zoomed closer you would move through the wall into the interior

(Maybe there is some clever plugin that does this.)

I use a 3 button mouse on a wacom tablet, and it takes a lot of middle button rotation to zoom. (At present typically 10-20 clicks out, shift, 10-20 clicks back) I do the zoom out, pick a different point, zoom in. Having a modifier key on the zoom to speed this up would be nice. E.g. Option-Zoom speeds up zooming.

Multicore use. I don't think that this is unreasonable. There is a lot of locality in CAD. Items on the right side of the screen don't interact point wise with items on the left, so it should be possible to parallel-ize a lot of the computation. Dedicating a processor to textures. Dedicating on to shadows Dedicating one to compositing. It should be possible to effectively use a dozen cores.

64 bit is more problematic. In the mac world 64 bit gives a process the ability to address more than 3-4 GB of memory. At least on the benchmarks I've seen it doesn't make the process faster. Not sure if it's the win that many people claim.

I had to move a stud to delete some cruft. Now I can't move it back. The motion of the stud (done as a component to keep it from welding onto everything else) is about 10 times as much as the motion of the move tool cursor. E.g.
I grab the upper left corner of the stud, and attempt to move it 1/8" the stud moves about 2". I've tried zooming in. The amount of motion is independent of zoom.(All measurements are relative to the size of the stud -- e.g. estimates based on fraction of 1.5 x 3.5 inch dimension.

Planning a kitchen. Want to know how much space between the end of a cabinet and the end of the wall.

Dimension tool. Click on back corner of cabinet. Click on edge of wall. Shows distance, but it doesn't stick. Do I have to put an extra line in there so that Dimension has an endpoint to stick to? Seems kludgey

A fix that requires a full reinstall of my operating system is a bit draconian. But, yeah, I suppose I asked for that.

I come from a unix background and generally prefer case sensitive file systems. Historically they are slightly faster (You didn't have to strip off the lower case bit for each character.) but with today's cpu's that's probably not measureable. Certainly as a web writer, I have to be aware of case all the time since the bulk of web servers run Apache on Linux.

Turns out that many scripts refer to other file (either with 'open' or 'require' using camelCase capitalization patterns. However scripts are usually distributed using all lower case.

On a case insensitive file system, parametricGrid.rb ParametricGrid.rb PARAMETRICGRID.RB are all the same.

On a case sensitive file system these are 3 different files.

The bug doesn't bite many people, because not many of us reinstall from bare metal. However, if you are a web developer it will help you catch some things before they bite, and for file intensive applications, it gives a marginal performance boost. (Noticeable for web servers)

Suggested fixes

1. Internally within sketchup, fix the case in the calling scripts and the installer so that the package provided works.
2. Make the existence of this bug more widely known.
3. Add a ruby script to the distribution that checks all the file calls in the plugins folders, and corrects them as needed.
4. Log errors like this to reduce the time to track this down.

I've also posted this on the Google forums and have made a bug report.

How do I find the barycenter of an arbitrary polygon?

Is there an easy way to construct a guide that is perpendicular to the center of a sloped rectangle?

How do you bisect an angle?

I'm a newbie. I downloaded SU three days ago.

I'm already running into things that I wish I had SUPro for, but I can't justify $500 for what amounts to a hobby.

I wish that Google would copy Philippe Kahn's marketing model.

Story time for you young pups who missed the reference.

Back when a hot PC was a Kaypro with DUAL floppy drives and 128K of ram, running a Zilog Z-80 chip at 2 MHz (I'm not kidding...) Pascal was regarded as the best teaching tool for new programers. Microsloth sold a Pascal compiler. For about $750 at a time when $2.50 was minimum wage. One of the universities also had a compiler/OS. It wasn't cheap and ran only on Apple][s

Kahn entered the picture and sold Turbo Pascal for $49. It came on 15 floppies (A floppy was 1.2 MB then -- several times my computer's memory. ) It came with about 6 inches of books. Nobody pirated it. Wasn't worth it. Took way too long to copy 15 floppies. TP ran rings around MS. You could go through the edit, compile, run cycle in under a minute. The integrated editor would even highlight the compilation bugs for you.

Kahn made a mint. For every compiler MS sold, I'm sure he sold thousands. Gates would rant at his director of Programming Tools. "How come THEY can do this and OURS runs so slowly.

Google could do the same thing:

Sell sketchup pro for beer money. No support outside the forums for that. Could buy email support for X dollars a year. Interactive video support for Y dollars per year. Google would make a mint.

So my wish: SUPro for $50.

It's a nice model but it's NOT a pine. Leyland cypress, some cedars, and some columnar juniper look like this. If you put leaves instead of needles on it, it would look much like tower poplar or lombardy poplar.

1. As a group pines tend to be open. Often the shade underneath will be dappled.

2. Typically only the last few inches to a bit over a foot of the twig will have needles on them. Conceptually a pine tree is a bouquet of bottle brushes. This is true of spruce and fir also, but these trees are often so thick you can't see the bare branches on the interior.

3. Most pines will start to shed their lower branches as they get older. Often the bottom third of the trunk in a 50 year old pine will be straight with no side branches.

I like these. I'm collecting trees to use to try out effects. These have a nice appearance, and although thin, they feel far more real than many of the trees I've seen, at least as rendered in the image in your post.

(2 minute pause...)

I just downloaded them. They aren't as convincing just in SU, but then I expect orbits would take forever.

Real trees have more variation. E.g. NO two trees will have the same branch pattern. Modeling this is hard. You need to pick a species of tree, and take dozens of pictures.

I'm still learning SU (I'm a newbie) It would be way cool if these were truly dynamic components. E.g. if I scale the tree, it doesn't just draw the whole thing bigger, but rather, the branches get heavier, and new material is added at the outside. This would also help with the unique aspect.

Several people have commented on color. I'll go a step further: Suppose you provided them as models, but created them in 5 layers. Layer 0 Trunk-Branch-twig. Layer 1 Blossoms Layer two Summer foliage. Layer 3. Fall Folliage. Layer 4 Fruit/seeds.

Certain things tend to be invariant on a given species of tree:
One is twig angle. Some trees have twigs at right angles to the branch. Many have angles of roughly 60 degrees. Most columnar trees (Tower poplar, Swedish aspen, columnar spruce the ONLY genetic difference is the gene that controls this angle.

Another is twig spacing, although this tends to vary with light levels. Many plants distribute the radial angle of the side branch on a fibonacci series. (Corn is a good example, where it's really easy to see.) Others will do whorls of branches. Most conifers do this, and it's really obvious when they are young, and is really hard to see when they get older.

The ratio of daughter branches to parent is also a common constant, as is the ratio of branch diameter to the distance to the next branch point. You've captured this very well in your trees, and I think to me that is a big part of the appeal.

Another is light response. Many shrub willows will send out branches at an angle of about 20 degrees above the horizontal, then as they get out from under the rest of the tree curve up.

A third is raggedness. Some trees when you look at them in winter almost look as if someone pruned them to make a nice smooth outline. Others look like a botched haircut.

Not all characteristics are invariant within a species. One variety of blue spruce has very even length needles. Another has a 30% variation in length on the same twig. Some spruce have very evenly space branches as they get older. Others have branches that droop at various angles.

Many trees have different trunk bark than twig bark. 1 year bark on most poplar is a grey-green. Older bark is pale grey. Trunk bark is dark grey with fissures. Birch twigs are the colour of hershey's chocolate until they are finger thick. Then the white spots spread out and turn the branch paper white with dark markings. Golden willow has yellowish grey branches except for this year's new growth. THAT in winter is schoolbus yellow with orange tips.

I am looking for scalable 3D trees and shrubs. So far the ones I've checked out have one or more of the following flaws:

1. They are 2d.

2. While they are scaleable, they don't don't change, except to get larger. They aren't a true dynamic component.

I would ideally like to be able to render a forest as it develops. So a realistic looking tree at seedling, sapling, pole, mature and senescent stages.

So for example, a birch tree, when young (up to 3 feet tall) has branches every few inches. As it gets older most of the lower branches get knocked off, and a few get thicker.

A white spruce produces a main whorl of branches every year. Each branch tip splits into two or three tips the next year. Needles stay on the tree for typically 3 years, then fall off. Now this level of detail is unwieldy, but it is what is at the core of getting a realistic tree. This in turn means that the model's detail level depends of the effective viewing distance.

Another feature I would like to see is a model whose flexibility reflects natural variation.

Is this even possible?