Looking ahead to SU 8.

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"

honoluludesktop

Good minimum list Solo. Would only add fixing the animation codec bug. Drawback is that then this is a Pro only feature (as advertised).

Btw, my workaround for flickering shadows is to export to MovieMaker, and edit out the bad frames. Compresses the file in the process.

paulside

So, is there ever going to be a Sketchup 8, Google - is it really asking to much of you to keep loyal users informed of future plans ?.

Chris Fullmer

Well, we are pretty sure there will be one.

And no, Google (and @Last before them) is not really fond of saying what they have planned.

paulside

Well I Know they wouldn't want to disclose details of any new features, thats fair enough, but surely wouldn't it make good business sense to at least give some indication to current and potential users as to when a future release could be expected?

MichaelG

I'd like to see some attention paid to the presentation of SketchUp models in 3D space. While I admire the skills needed to present photo-realistic renderings, the viewing and manipulation of the full model in 3D is really what most interests me. While the program can be freely downloaded for this purpose, I think the products of it could be presented on the web much more effectively with the proper interface. I'm thinking of something along the lines of the little 3D widget used to show models in the Warehouse. Since Google Earth already makes use of a similar interface, it doesn't seem like it would be all that difficult for Google to develop a 3D viewer with considerably more capabilities than the small one now in use.