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:
- Layers had three controls -- visibility, lockability, and inference ability.
- A locked layer did not interact with new geometry. This should speed up SU on large models.
- Being locked but inferenceable would allow you to use faces and lines as endpoints, as well as sources for making guides.
- A non visible layer did not interact at all.
This doesn't require major programming. Under the hood layers become a form of grouping.
- 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)
- 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.
- 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.