SketchUp 2016 Wishlist

Aerilius

It "can" be achieved, but not reasonably good and usable. In fact I have this laying around for a couple of years. I'm not sure how useful it is (since resolution is very limited in SketchUp to 1024–2048px, and SketchUp does not have adaptive texture resolution techniques like Ptex). There are a couple of problems that would lead to undesired behaviors:

Interactivity: SketchUp's API does not allow direct pixel manipulation, and saving images to disk and reloading takes a too big fraction of a second, and makes it feel very sluggish.
Mousemove events: SketchUp signals only mouse positions in time steps. When the mouse hovers a face and then leaves it (to hover another face or empty space), it is hard to reconstruct the path that the mouse took in between, it requires a lot of intersections which had sometimes numerical errors.
User workflow: The faces must be seamlessly textured before. This is trivial for planar projections, but in many cases users would need more advanced mapping techniques to avoid image stretching.

jfrancu

Layout:
~~I would like to have non-rectangular viewport in LayOut.~~
It would be nice to be able to write plugins for LayOut in ruby.
Sketchup:
Better importing of dwg/dxf files - to have an options to load only some layers (based on its size). Loading text?
Better UI in ruby console like proper window with tabs and colored syntax and auto-completion.
Better functionality on Outliner.
Pricing:
I would like to have smaller price for a year subscription or to have a new stable version every 2-3 years.

kaas

I would love to some see extra customization options for the toolbar icons; custom toolbars with flyouts like on the 'getting started' toolbar. Not only for the native commands but especially for all the plugins. That way, you could group plugins into custom categories and really clean up your interface and get some screen space back.

edit: More customization options for the dimensions in Sketchup (and Ruby) would be very welcome as well. Custom size for the endpoints, custom trailer and leader sizes, maybe even custom endpoints.

jgb

@desertraven said:

Okay here it is,

!!!!! Give us an override for that obnoxious constraint engine and give us object-snap options already!!!!!!! Try tracing something that's not supposed to be square????? :berserk: :berserk:

Yeah!!!!

Drawing a line from endpoint A to endpoint B should NOT be a crapshoot because B is not exactly on an axis projection. I know that if A to B is "constrained"; ESC then going from B to A works. But that is double work and often the "constrained" message is not forthcoming. So that blows a solid up, and Curviloft goes nuts, followed by a 1/2 hr to sleuth out the error.

TommyK

@jgb said:

@desertraven said:

Okay here it is,

!!!!! Give us an override for that obnoxious constraint engine and give us object-snap options already!!!!!!! Try tracing something that's not supposed to be square????? :berserk: :berserk:

Yeah!!!!

Drawing a line from endpoint A to endpoint B should NOT be a crapshoot because B is not exactly on an axis projection. I know that if A to B is "constrained"; ESC then going from B to A works. But that is double work and often the "constrained" message is not forthcoming. So that blows a solid up, and Curviloft goes nuts, followed by a 1/2 hr to sleuth out the error.

I think all we need to resolve this is a modifier key, which if you hold down turns off axis/perpendicular constraints, on move, line and circle tools. I think "Ctrl" is the only obvious key that isn't taken by all those tools. If I understood you correctly....

JQL

@jgb said:

@desertraven said:

Okay here it is,

!!!!! Give us an override for that obnoxious constraint engine and give us object-snap options already!!!!!!! Try tracing something that's not supposed to be square????? :berserk: :berserk:

Yeah!!!!

Drawing a line from endpoint A to endpoint B should NOT be a crapshoot because B is not exactly on an axis projection. I know that if A to B is "constrained"; ESC then going from B to A works. But that is double work and often the "constrained" message is not forthcoming. So that blows a solid up, and Curviloft goes nuts, followed by a 1/2 hr to sleuth out the error.

I imagine I didn't understand this correctly but do you know about the "Shift key" for constraining what you're drawing to an existing element?

You can use it with a line or a guide line, to create any direction constrains: on line, on an extension to the line, draw parallel and perpendicular lines. From A to B related to that line.

Tape measure could help you a lot.

You can also use it with an existing plane and draw whatever you want constrained to that plan. From A to B in that plane.

jgb

@unknownuser said:

I think all we need to resolve this is a modifier key, which if you hold down turns off axis/perpendicular constraints, on move, line and circle tools. I think "Ctrl" is the only obvious key that isn't taken by all those tools. If I understood you correctly....

Seeing as "CTRL" has no effect when drawing a line, I would agree to using it as a modifier key to override the "Constrained" feature.

The "ALT" key could also be used, but in limited testing, I noticed a strange effect of placing a line temporarily in position, sort of.... no time to follow up on this.

And to JQL.....

The "SHIFT" key modifies a line draw to maintain a set vector/direction. It does nothing to prevent "constrained".

JQL

Sorry jgb, I do understand what you're talking about now and I do agree with you. It's those auto dotted system of inferencing that keep showing up undesired...

jolran

@jiminy-billy-bob said:

/summon Jolran

The project of "Node-modeler" is far from dead. Although I have taken the direction of a NURBS based approach for curves and surfaces. Which have delayed any potential release considerably.

Polygon/vertice based parametric calculations proved rather slow and unpractical in many cases. Even in C++

jolran

@jiminy-billy-bob said:

Whow, where did you dig out that quote?
Great to hear your project is still alive!

A friend directed me to your post in this topic

And yeah, havent given up yet. I hear you are on the way to success soon

HornOxx

Perhaps my wish has already been mentioned here (?)

I want an improved 2D Export - regardless of the width/height-size of my currently used SkUp viewport.
(As if I would use any render plugin)
I want that other Skup users with their own viewport sice can export exactly the same file as I do. Interacting with other users would be so much easier ...

Even if there is a plugin for that, SkUp should be able to do this "out of the box"

JQL

@hornoxx said:

Perhaps my wish has already been mentioned here (?)

I want an improved 2D Export - regardless of the width/height-size of my currently used SkUp viewport.
(As if I would use any render plugin)
I want that other Skup users with their own viewport sice can export exactly the same file as I do. Interacting with other users would be so much easier ...

Even if there is a plugin for that, SkUp should be able to do this "out of the box"

It's incredible how everyday we remember something that never was right, but that has been like that for ages, so it keeps hanging there and it seems it will hang there forever. Simple things like this or complex stuff that from time to time reemerges to haunt someone.

This sort of things generate a lot of frustration and Sketchup has too many.

My wish for 2016 would be that Trimble would hire someone just to try every button and function Sketchup has and find things like:

Wrong or unexpected behaviours;
Inconsistent UI;
Recurrent feature requests;
Standardization of usual processes;
Etc...

pbacot

I too want more control of the 2d export, but how would SU know the image you want if the viewport is set differently. Or how would you know what you will get. There would need to be some sort of set "view frame" associated with scenes (which would interfere with workflow) or some new viewport setting saved for it to be identical between users, sesssions, screens etc.

JQL

@pbacot said:

I too want more control of the 2d export, but how would SU know the image you want if the viewport is set differently. Or how would you know what you will get. There would need to be some sort of set "view frame" associated with scenes (which would interfere with workflow) or some new viewport setting saved for it to be identical between users, sesssions, screens etc.

Imagine a square that is touching the shortest dimension of your workspace. That square would be the reference and the part of the model it's framing should always be the same no matter the size or porportion of the working space and it should always touch the smallest lenght of the working space.

When exporting a rectangular image from a scene, that square should always be shown in the center.

If the image is exported in landscape mode, the square hits top and bottom, if the image is exported in portrait mode, the square touches the sides of the image.

This way the center of the scene is always guaranteed to be the same and the same thing happens with 2D outputs of the scene.

driven

@jql said:

Imagine a square that is touching the shortest dimension of your workspace. That square would be the reference and the part of the model it's framing should always be the same no matter the size or porportion of the working space and it should always touch the smallest lenght of the working space.

When exporting a rectangular image from a scene, that square should always be shown in the center.

If the image is exported in landscape mode, the square hits top and bottom, if the image is exported in portrait mode, the square touches the sides of the image.

This way the center of the scene is always guaranteed to be the same and the same thing happens with 2D outputs of the scene.

this may be a possibility if you 'always' wanted a 'Zoom Extents' type of framing, but would fail if you want to frame in on a detail...

changing the SU viewport is similar to using a crop tool in image apps, and allows you to set the frame and position the content independently...

I can't see how any automatic solution could return the results in my minds eye...

but that may just be me...

john

HornOxx

Hello JQL and John
the developer of a SU-Render plugins turned my attention to the following.
He said, that for SkUp - based on a scene - always the height proportion of scene content and viewport height remains constant. This means that only the image width is the variable.
Within my Render plugins this is a true statement - no matter what resolution I choose, the height proportion remains the same. Fortunately! - Because otherwise we could not produce render series on different computers, which perfectly fit together.

Now I have repeated this procedure as a 2D export in Skup by using the animation export, because I was able to choose any free resolution settings there. Also Skup exports these 2D images always with the same height proportion As you can see in the little sketch below.
Although my colleague repeated this procedure on his own computer with other Skup viewport settings, and his export result is the same as mine.

This result is promising, because it would mean that only a freely selectable height-width resolution should be adjustable within SkUp´s 2D export settings as it is possible in the animation export if you choose JPG for example instead of avi...

jgb

@jql said:

My wish for 2016 would be that Trimble would hire someone just to try every button and function Sketchup has and find things like:

Wrong or unexpected behaviours;

Inconsistent UI;

Recurrent feature requests;

Standardization of usual processes;

Etc...

No need for Trimble to test every button and function. They will not learn much from doing that. SU needs to be worked to discover "bugs" and inconsistencies.

All Trimble and the SU development team needs to do is READ the past posts here and in other SU forums to learn what goes wrong and needs fixing.

I have bitched (and others too) about these problems for years, and they are still with us.

Near field clipping
Hyper zoom (click on empty space when panning...)
Z fighting
"constrained by..."
There is a lot more, but only silence from the SU team.

I'm not talking about enhancements and new stuff.
This is OLD stuff that still doesn't work right.

But SU dev has always been far more interested in new bells and whistles for next years SU than in fixing past problems.

jiminy-billy-bob

Whow, where did you dig out that quote?
Great to hear your project is still alive!

craigcampbell66

Deals with higher poly/larger models better.
Quicker saving/autosave.
Layout - Active or Current layer 'automatically' switches to Dimensions when activating the dimension tool or Annotation when either notes or text tool is selected. Maybe the ability to customise this feature.

derei

SU 2016 BASIC WISHLIST

I want for no magic and fairy tales... all I wish is common sense:

%(#BF0000)[1. Fix Scenes Bug that can lead to accidental Scene Renaming !
2. Fix Importers/Exporters to work at decent speed (take any other 3d software from the market as example)
3. Fix the iterating commands in SU, because they take forever to run on complex models. Either if those commands are coded in SU or ran from scripts and plugins. This includes the Outliner crap, that makes everything blow to hell when Outliner is opened.
4. Make a BETTER Layer manager (get inspired from Layers Panel plugin).

5. (optional) - try to make plugin parsing a bit faster... would help a lot when SU is loading. One suggestion would be to have all the plugins parsed and converted in binary and saved as a "copy", ready to load in memory. And to have a (manual) function to rescan the Plugins folder in case that plugins were added/removed/updated. This way, won't be needed to parse and interpret all the plugins every time SU is loading...

MAKE LAYOUT DECENT ! - this can become a huge list of things that can be improved. The general idea is that Layout at this moment runs like a Beta version in all aspects. Text editing is a mess, dimensions placed in SU are not consistent (displayed too big in Layout), general performance is less than decent.. and so on.]

Thank you very much. This would make SU2016 what it should be, BEFORE adding extra functionality and fancy things that we all dream to. At least make it work, before making it fancy (and before adding price increase).