SketchUp 2016 Wishlist
-
@desertraven said:
I kind of asked for this before and we all agreed that without 64 bit and loads of memory it would not go anywhere.
Well now we got 64 bit and plenty of computing power. So let's see what you think.
This does not have to be fancy with true colors or high resolution, just basically a pen or marker that you can use to sketch a bitmap directly on a surface.
The tool could have say 4 different resolutions or anything between 320 by 320 pixels up to 3200 by 3200 pixels. 4 different line widths from thin to thick and of course an eraser.
Many times I was thinking to have some pen to draw on a say empty landscape surface or wall, to sketch in some rough ideas on the fly in a presentation or work meeting.
The point is that we could draw in rough geometry on a surface as a bitmap and later 3d edit with lines, arches and circles as geometry.
It would only work on a special sketch material that would appear in the materials window. Each surface that gets sketched on will create its own new material. Background colors could be chosen before the first line gets drawn.
I rather like this idea. I think it would work well with the sketchy way in which people use sketchup. I wonder if it can be achieved with a plugin....?
-
@aerilius said:
It "can" be achieved, .....
[*]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.[/list]
What if this would only allow one face/coplanar shape at a time? One texture image per face at a time is produced? The pen sticks to this face during the command / operation and only draws in the limits of the extents. Maybe by pressing the alt key it also aligns, zooms to extents and centers the camera to the face in question?
2048 resolution would be sufficient. The image size will automatically fit to the size of the face's extents/ bounding box. The origin is set in the lower left corner of the extent/bounding box.
E.g. My wall is a n-gon shape/ face, as I attempt to draw on it SU creates a texture image this image is treated like any other image you can load into SU.I don't know what it would take to get rid of the limitations of the "API", but maybe there is a way?
Maybe not as a plug in but as a native SU tool?
-
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.
-
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. -
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.
-
@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.
-
@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....
-
@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.
-
@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".
-
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...
-
@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++
-
@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
-
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"
-
@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...
-
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.
-
@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.
-
@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
-
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...
-
@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.
-
Whow, where did you dig out that quote?
Great to hear your project is still alive!
Advertisement