Looking ahead to SU 8.

plot-paris

two really useful things (I will write them again, even though I think both were mentioned before - but they would be so easy to implement and so useful):

the ability to change axes for groups as well. at the moment you can define component axes. that affects the bounding box as well.
for rectangular object even an option such as 'align axes to geometry' could be useful.

the second thing is an option to switch between 'world axes' and 'object axes' orientation.
imagine you draw a group or component, then rotate it at an odd angle. if you now enter this group and start drawing, and want to stay at a right angle to the geometry, you have to refer to inferencing, because the red/green/blue axes point another way. if you now switched to 'object based' axes orientation, it would be a lot easier to draw in this particular context. and creating groups/components would result in their bounding boxes being aligned to the actual geometry (as opposed to today, where they are aligned to the world axes...)

what do you think?

oh, and another thing just popped into my mind:
introduce the option to right click buttons to define specific tool parameters. that keeps the UI simple whilst giving us a whole new world of options.
in addition to that holding down your left mouse on a button could expand a 'sub-button-bar'. that would be very useful for a lot of rubies (half my toolbars are fredo's at the moment. imagine you could collapes all tools on surface to one button...)

thomthom

@plot-paris said:

the ability to change axes for groups as well. at the moment you can define component axes. that affects the bounding box as well.
for rectangular object even an option such as 'align axes to geometry' could be useful.

the second thing is an option to switch between 'world axes' and 'object axes' orientation.
imagine you draw a group or component, then rotate it at an odd angle. if you now enter this group and start drawing, and want to stay at a right angle to the geometry, you have to refer to inferencing, because the red/green/blue axes point another way. if you now switched to 'object based' axes orientation, it would be a lot easier to draw in this particular context. and creating groups/components would result in their bounding boxes being aligned to the actual geometry (as opposed to today, where they are aligned to the world axes...)

what do you think?

Gaieus

Yes, this axis thing is definitely a good one. Particularly that components (at least) work perfectly as embedded mini models and when you save them as..., youi can work on them in a separate file and the axis system of that file respects the original component axes.

So why not be able to do it "In model" as well?

(Although this should be something like "hide rest of model" and "hide similar" - i.e. toggle-able as sometimes you may need to work in other ways)

plot-paris

@gaieus said:

(Although this should be something like "hide rest of model" and "hide similar" - i.e. toggle-able as sometimes you may need to work in other ways)

I've already got my keyboard shortcut reserved for that
(F2 = show/hide hidden geometry
F3 = perspective/parallel projection
F4 = show/hide rest of model
F5 = world axes/component axes )

Gaieus

I use Ctrl+H to hide rest of model and Shift+Ctrl+H to hide similar components. Sgift+H could be the one to switch between axes.

plot-paris

damn, my hand is to small for Ctrl + Shift + H

davide.skp

a powerfullllllll camera match

Bob James

Maybe someone else has mentioned this, but how about being able to keep the View/Toolbars drop-down open to allow multiple checking/un-checking toolbar choices at the same time?

Aerilius

I've not read it yet, but I agree. Very reasonable idea!!!

thomthom

@bob james said:

Maybe someone else has mentioned this, but how about being able to keep the View/Toolbars drop-down open to allow multiple checking/un-checking toolbar choices at the same time?

Might be possible to do this by ruby... might

dominikh

About multicore support
I don't exactly see how support of multiple CPU cores would enhance SketchUp's speed.

Admittedly, I haven't been working with huge models yet, but nevertheless I only noticed two cases in which CPU power matters: loading/saving* and using Ruby scripts. And exactly here lies the problem: Ruby itself, especially the very old version (1.8.0) that is being used in SketchUp, does not support native threads, but only green threads (and those won't even work properly in an integrated environment like SketchUp).

Now it is not an easy task to just add support for native threads to Ruby, and it won't be of any use if the scripts don't make use of threads themselves (and none of them does as of now, because they don't work, as I stated earlier**).

As a result of this, SketchUp could at most really make use of two cores, using one for the UI and one for processing/ruby scripts (and as I've understood, Google is indeed working on that and made underlying preparations already with the release of 7.1)

*: with the current file size of bigger models, an unlimited amount of CPUs/cores won't be indefinitely increasing speed anyway, because the underlying filesystem and even more underlying performance of HDDs is the real bottleneck.

**: an integrated Ruby interpreter will only be able to execute commands if the main application, SketchUp in this case, calls out to it. This also means that Ruby threads (not to be confused with native threads) will pause until SketchUp calls the interpreter. This is done for events like moving the mouse and of course other UI interactions (and that monitoring stuff, forgot its name right now), but only for those. As long as the user isn't interacting with the applications, threads will pause (and thus would intensive calculations).

A way to demonstrate this is to execute the following code in the Ruby console:
Thread.new { 5.times {|i| puts "iteration #{i}"; sleep 0.1 } }

This, if it worked, showed "iteration 0" to 4 within 0.5 seconds. However, it won't print anything until you move your mouse in the model.

An updated version of Ruby
I would really appreciate if the used Ruby would be updated to one of the two recent versions, 1.8.7 or 1.9.1 -- I do favour 1.8.7 though, because 1.9.1 breaks compatibility in some regards (I do, however, not know if 1.8.7 is fully compatible to 1.8.0 :/)

Also, there should be no problem in shipping the stdlib with SketchUp, I think.

A plugin manager
Like some of the others in this forum, I would appreciate a well thought-out plugin manager, with per-plugin metadata like author, license, version and dependencies (and legacy support for current plugins, that miss those information for obvious reasons).

The plugin manager could also work like APT (a package manager on Linux), with support for so-called repositories, updates and dependency resolving, thus providing a one-click interface for installing and updating plugins.

thomthom

Agree - the UI should be separated from the processing. So many plugins that would benefit from that.
This week I came across some API for Windows7 which I#m wondering might be workable. http://forums.sketchucation.com/viewtopic.php?f=180&t=25790 But I#m not sure how to translate that into Ruby.

@dominikh said:

A way to demonstrate this is to execute the following code in the Ruby console:
Thread.new { 5.times {|i| puts "iteration #{i}"; sleep 0.1 } }

I'm not seeing what you are seeing. I see it printing "iteration 0" the first time I run it. Then when I run it the second time I get two lines, then three etc...


Thread.new { 5.times {|i| puts "iteration #{i}"; sleep 0.1 } }
iteration 0
#<Thread;0xf953ad8 sleep>
Thread.new { 5.times {|i| puts "iteration #{i}"; sleep 0.1 } }
iteration 0
iteration 1
#<Thread;0xf94f920 sleep>
Thread.new { 5.times {|i| puts "iteration #{i}"; sleep 0.1 } }
iteration 0
iteration 1
iteration 2
#<Thread;0xf94dd90 sleep>
Thread.new { 5.times {|i| puts "iteration #{i}"; sleep 0.1 } }
iteration 0
iteration 1
iteration 2
iteration 3
#<Thread;0xf94be70 sleep>
Thread.new { 5.times {|i| puts "iteration #{i}"; sleep 0.1 } }
iteration 0
iteration 1
iteration 2
iteration 3
iteration 4
#<Thread;0xf94aeb0 sleep>
Thread.new { 5.times {|i| puts "iteration #{i}"; sleep 0.1 } }
iteration 0
iteration 1
iteration 2
iteration 3
iteration 4
#<Thread;0xf94a2c8 sleep>
Thread.new { 5.times {|i| puts "iteration #{i}"; sleep 0.1 } }
iteration 0
iteration 1
iteration 2
iteration 3
iteration 4
#<Thread;0xf9491b8 sleep>

Many people have tried threading - but it appear to be a dead end.

@dominikh said:

An updated version of Ruby
I would really appreciate if the used Ruby would be updated to one of the two recent versions, 1.8.7 or 1.9.1 -- I do favour 1.8.7 though, because 1.9.1 breaks compatibility in some regards (I do, however, not know if 1.8.7 is fully compatible to 1.8.0 :/)

I'd prefer 1.9 - due to Unicode support, which is sorely needed. But as you said, compatibility issues. Update to a newer 1.8 branch would be appreciated.

@dominikh said:

A plugin manager
Like some of the others in this forum, I would appreciate a well thought-out plugin manager, with per-plugin metadata like author, license, version and dependencies (and legacy support for current plugins, that miss those information for obvious reasons).

The plugin manager could also work like APT (a package manager on Linux), with support for so-called repositories, updates and dependency resolving, thus providing a one-click interface for installing and updating plugins.

I've been thinking of this again lately. Been thinking of presentation a mock-up UI and API for review. First task is a system to let the user organise menus and toolbars. Then a update/install system would be a nice addition.

dominikh

@unknownuser said:

I'm not seeing what you are seeing. I see it printing "iteration 0" the first time I run it. Then when I run it the second time I get two lines, then three etc...

Well, you did, in your own way, prove that threads don't work properly (which is exactly what I wanted to demonstrate).

However, what one was supposed to do, and what one was supposed to see was:

execute the line of code, once
don't do anything => it won't display anything, even though it should every 0.1 seconds
move your mouse in the viewport (where the actual model is displayed) => you will see that now the thread will be executed.

you, kind of, did the same by executing new ruby commands, which also executed the threads you created.

thomthom

@dominikh said:

move your mouse in the viewport (where the actual model is displayed) => you will see that now the thread will be executed.

Did not see this. Nothing happens when I move the cursor over the viewport. It's why I tried to execute the command again.

dominikh

okay, maybe it's because of one of the plugins I am using. Anyway, the point is that the ruby interpreter is only being run for events, rendering ruby threads useless

thomthom

What SU version and OS you run? (Recommended you add that to your profile.)

genma saotome

Let me assign a color to my endpoints and edges, globally as a default and individually by object. It's just an attribute for display afterall. And if there isn't time to do both, for goodness sake, do endpoints. Can't see the darn things when ever the texture is also dark and patterned.

remus

If you go window->styles->edit you can turn 'end points' on and just below that you can set edges to be coloured by material (which you can apply using the paint bucket, as you would for faces.) The colour of the endpoints is then inherited form that of the surrounding edges.

genma saotome

Thanks for the suggestion Remus but it wasn't adequate for the situation I have.

Thinking a bit further, I'll restate my need: As endpoints are only a slight thickening of the edge line their visibility decreases substantially in proportion to the length of the line. Right now I'm looking for "inner" endpoints on a 300m arc... they're veryhard to see. I would like to see something in SU 8 that allows the user to make endpoints more visible in these situations, optimally by letting the user select a color that's different from the edge line so they stand out.

Bob James

What has all of this to do with "Looking Ahead to SU 8"