SU 9 Wishlist

pbacot

Would like to see View Sections and Section Planes be dissassociated from Styles. Make it a scene choice only.

jeff hammond

i know i've seen this request before (and probably in this thread) but...

please make a toggle key to lock direction of the move tool (or line etc..) in any direction you wish.. it seems like such a no brainer to have it work like that instead of holding the shift key down to lock.. and even then, you can't lock in any direction.. only if it's an axis or along a line..
you should be able to move to a point, click the toggle, and you will be locked on the vector from the original point through the secondary point.

pbacot

I would like a command to dock all floating windows collapsed, (except the drawing window and the colors) in Mac. For example take the top most window (in screen position) as an anchor and move all open windows to be attached under it, in collapsed form (not collapsed could be an option).

Changing monitors makes keeping the windows straight a pain.

I wish the Colors window would go away when the bucket tool is deselected. It serves no purpose being open.

utiler

Here's my wishlist... had a little fun putting it together.

SketchUp-MyLowHangingFruit.pdf

utiler

Not sure what happened to that one; something wrong with it apparently... try this one.

SketchUp8-MyLowHangingFruit.pdf

luke catt

A component tool like the material tool.

Instead of painting the face with a material, it changes it to your selected component. ie brick etc.

sgbotsford

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.

numerobis

@sgbotsford said:

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

and this is how it already works... maybe you tried to zoom with the field of view tool

dsarchs

sgbotsford, I'll try to answer some of these as I can.

@unknownuser said:

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.

Layers do have visibility and lockability, although being locked just means it can't be edited or deleted, still inferred to, though. I'm not clear on why turning off the inferencing of locked objects would be desirable. If I need to I just hide an object. Also, I tend to use groups or components (depending on if it will be instanced or not) the way I think you use layers. I usually put all of a type of thing in a group and then edit that group (graying out the rest of the model) when I need to edit it. Nested groups are not a problem.

@unknownuser said:

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

This does sound nice and you might already be able to do through the outliner (which I have never bothered to use). Also, you could do a similar thing with nested groups, as above.

@unknownuser said:

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.

I don't think I understand the purpose of this one. As an aside, SketchUP doesn't use points (at least, they're not selectable natively).

@unknownuser said:

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.

It sounds like you're talking about mip maps -- sketchup doesn't do this. It might be a nice feature but I would just as soon export to some other program for visualization.

@unknownuser said:

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 is useful and might be a nice add. I think you would need to either build a low res model yourself or every now and then have SU calculate (I image huge problems/errors resulting from this) the low res models for you. A better solution would be to use the proximity (similar name) plugin that basically does this. You might also have better luck talking to some of the plugin developer guys to see if you can get one of them to make a better plugin for you.

@unknownuser said:

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.

This would be nice.

@unknownuser said:

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.)

Sketchup zooms to the mouse cursor. If you're point at empty space it zooms really fast. If you (preferred method) point at an object and zoom, the zooming slows down dynamically as you get closer.
Zooming shouldn't change the FOV, although there is a command where you change the FOV by zooming -- do you have that command activated, maybe? Normally, I choose a low FOV for exteriors and raise it when doing interiors. Zooming is actually very convenient once you get accustomed to how SU works.

@unknownuser said:

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.

I don't know the technical details, but multi-core seems to be always requested and the SU developers tell us it would be a LOT of work for very little performance improvement. They say there are more efficient ways to increase performance and they are focusing on those. Not sure either way, but SU has been getting noticeably faster with each release... so I tend to believe them.

@unknownuser said:

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.

SU is now large address aware, which, as I understand, effectively allows use of more than 4gb memory, even if it's not officially 64-bit.

...

Lastly, since it sounds like you are still learning SU, can I recommend this tutorial?
It's technically a tutorial for exporting SU to the Crysis editor (which is VERY interesting, by the way) but it does a great job of establishing best practices for SU use, including texturing and grouping.
Good luck!

thomthom

@dsarchs said:

SU is now large address aware, which, as I understand, effectively allows use of more than 4gb memory, even if it's not officially 64-bit.

No, it means SU can address up to 4GB under a 64bit OS. Under a 32bit system its still 2GB, unless you have the 3G switch - where you can address 3GB.

Anton_S

Calculate center of area/volume

Dave R

@anton_s said:

Calculate center of area/volume

There are tools for that already. Try here, here, here, here...

Anton_S

@dave r said:

@anton_s said:

Calculate center of area/volume

There are tools for that already. Try here, here, here, here...

The only 'here' I was talking about was the first and the last one...

dsarchs

@ thomthom

Thanks for the correction.

oganocali

My list is soo short.

PERFORMANCE!

There... I had to shout it aloud. Specifically I wish to be able to explode the silly tiny (ish) attached one component with 24K faces faster than fixing myself a cup of coffee. My guess is if this is fixed scaling rotating, and editing will also speed up.

performance_problem.skp

TIG

@oganocali said:

My list is soo short.

PERFORMANCE!

There... I had to shout it aloud. Specifically I wish to be able to explode the silly tiny (ish) attached one component with 24K faces faster than fixing myself a cup of coffee. My guess is if this is fixed scaling rotating, and editing will also speed up.
But 100s for something this complex seems acceptable to me - my PC is pants too !

oganocali

My computer is not that bad (i7 2600 with 8 gig ram). In my case it takes over 30 seconds to explode.
24K faces should be nothing with these computers. This case is complex only by SketchUp standards.
Apparently SketchUp takes several million instructions per face for the explode operation (for this case).
I did a quick experimentation varying the size

face count |  explode time (secs)
     3K        ------|      < 0.5 
     6K        ------|         2        
     12K       -----|         8
     24K       -----|        30
     48K       -----|          ?

Admittedly the times are only approximate but seems to me the explode operation has n^2 complexity. Double the size -> quadruple the time (which should be fixable).

thomthom

SketchUp also takes longer to add geometry the more geometry already exist in the context its added it.

I'm guessing that it's due to SketchUp's nature of automatically merge and intersect geometry. This differs from most other 3D modellers where you explicitly needs to tell it to split and merge.

oganocali

@thomthom, I would expect the incremental merge/split/intersect cost to increase with increasing size but my suspicion is that incremental cost is linear for SU (whereas it should be sub-linear). Explicit split/merge would be a nice workaround indeed.
Ogan

thomthom

Well I really hope there is room for improvements, because as you say, Explode becomes horribly slow very quickly.