Hi everybody,

I'm doing a little informal survey of SketchUp users, and I wonder if you'd be willing to help out. I'd like to see how you've customized SketchUp's UI to suit the particulars of your workflow. In other words, what toolbars you've shown/hidden, what scripts you've added and where you keep your inspectors on the screen. Can you help?

If so, please post a screenshot of your workspace in this thread. Show me your SketchUp!

thanks-
john
.

@unknownuser said:

I can select the archiver selection and go back to work as fast as the mouse can move to another tool. It is quick.

Well, I've looked at the code, and it looks like it is doing a "model.save" to do the actual archiving operation. Which is the same code path that SketchUp executes from the File menu. Not sure why that would be faster.

TIG: Can you explain what your script is doing differently?

john
.

@unknownuser said:

Try this plugin by TIG. I set my autosave to 30 minutes and use the archiver.rb plugin. So a search and check it out, it is fast.

Ken

This looks like a tool that is similar to SketchUp's existing "Save A Copy As...", though it automatically names the file for yu so you don't have to navigate a dialog. Are you saying that this script saves large SketchUp models faster than a simple "Save" operation?

john
.

@jgb said:

I too found autosave annoyingly slow. And I also found in V8, it is faster than it used to be, but manual save seems faster than autosave.

It would be great if you guys could help to quantify this– in our lab (and in the code) 'save' and 'autosave' are expected to take the same time. With a couple caveats:

1. If you have "Automatically check models for problems" and "Automatically fix problems when they are found" enabled in "Preferences > General > Check Models for Problems" you may experience differences depending on the validity state of the model.

2. Autosave always happens when you aren't expecting it. Doesn't matter how you've set the timer, it just won't sync with your mental state while modeling.

If you feel like Autosave takes longer than Save, try timing it to see if you're right. It would be useful data for us to have.

john
.

@3rdeye said:

I don´t know if anyone already posted one of the following, anyway (i´m almost sure someone has):

• 64 bit
• Multiprocessor support
• UV mapping tools

You're right- these requests are frequently made, though they are usually masking other more general requests. I've discussed them in detail several times in our Help Forums. Here are a few links you might wish to review:

64-bit: "Google SketchUp Questions and Ideas: 64-bit version of SketchUp" and Make a 64 bit version for XP and 7

Multiprocessor support: Google SketchUp Questions and Ideas: Multithreaded version of SketchUp

UV mapping tools: Google SketchUp Questions and Ideas: Improve Texturing Tools

john
.

@rock1 said:

@thomthom said:

It is a thing asked about from time to time which would have been made already if it was possible.

then why don't people at SU development do something about it?

We don't do anything about this because it isn't something that can be done. SketchUp's inference system is designed to be on all the time– never turned off. SketchUp without geometric inference wouldn't really be usable.

john
.

@jgb said:

Thanks for explaining away just about everything.

Not sure what you're hoping to achieve here, but I am trying to answer your questions. I think I'm going to stop for a bit and show your post to some other folks to see if they can help me understand what you're trying to do. It isn't at all clear to me what work you're doing with SketchUp.

john
.

@jgb said:

First, I'm not sure what you mean by "archviz folks".

By "archviz" I mean the community of professional SketchUp users who use it as the modeling front end to an advanced (photorealistic) rendering process for the pre-visualization of architectural design projects, either still images or animations. As for example represented in the CGarchitect forums.

From your list of issues, I'm going to guess (please confirm or correct so I can answer your questions more accurately) that you are doing more "MCAD" kinds of projects with SketchUp. In other words, the sorts of projects which might also be done in Solidworks? Things which might eventually be fabricated in a machine shop?

If this is the case, then I can imagine the sorts of problems you are seeing in SketchUp. And to be fair, we didn't design SketchUp for this sort of work. As you may know, SketchUphas a hard lower precision threshold at .001". For folks working on projects from 'furniture' to 'office campus' scales, this precision is perfectly sufficient. For folks working on projects smaller than 'furniture', problems like those you describe can occur. I think this probably accounts for all of your issues with 'face forming' and I'm afraid the only recourse is to scale your project up artificially while you are working. There is no fix for the .001" lower precision threshold coming in a future version of SketchUp.

The issue you refer to as 'Hyper Pan' or 'Hyper Zoom' likely comes from the same root cause as the above issue. You're working close to the lower precision threshold in SketchUp, and tools which have been tuned for use at larger scales are beginning to behave in an less predictable way. You may find that the "Camera>Previous" command will allow you to recover easily from errant Zoom or Pan operations.

The adoption of "Pencil Tool" as the startup tool comes from a historical decision that drawing should be the default behavior in SketchUp. Over time, alternate opinions have asserted themselves. In fact, for several releases, we flip-flopped on this decision. Which folks also found upsetting. In our current build (SU8M1), "Select" is the default tool on our Mac OS X build. Perhaps one day we will also make it so on Windows.

Toolbar positions are very difficult for SketchUp to maintain when you are using lots of Ruby scripts that add their own toolbars. The addition of a new Ruby toolbar is currently the most chaos-inducing thing you can do. We're still working on this problem, but you should know that it is like 'cat herding' for us.

As for your preferred units, I think this is a simple tech support issue. "Decimal > Inches" are supported in SU8 today. In fact, under the hood, SketchUp uses decimal inches natively for all calculations. If you would like this to be the default for all your new models, learn about Templates.

Now for your mouse with all the buttons- this is a tech-support issue as well. SketchUp can never hope to support every mouse in the world natively. There are literally thousands of them. Most mouse drivers for more complex mice include some kind of application-level settings for their buttons. This is your best bet for configuring your mouse to use more buttons in SketchUp.

There will always be some keys on your keyboard that are either reserved by SketchUp for some purpose, or by the operating system. Are you really running out of keys to use for all the thinks you want shortcuts to access?

And finally, Materials. Certainly it is possible to modify sets of materials in SketchUp, though perhaps not in the ways you wish to do so. Probably you'll find some crossover with the archviz folks here (or maybe not?). I find that purging unused materials often solves the majority of my problems with ballooning material lists. A way to consolidate all of the similar colors in a model would be useful and I'm glad you've found a plugin to help you resolve that.

john
.

@pixero said:

I'm sure I can think of more when I'm not this tired.

Looks like you'd mainly like to see the rendering pipeline opened via the API so that advanced rendering features can be implemented by the Ruby community. Is that correct? It is true that we don't provide access to that at this time.

john
.

@jgb said:

FIX WHAT IS BROKE first.

Please define what broke things you'd like fixed. Do you disagree with the wants and needs of the archviz folks who would like us to prioritize the list of things I itemized above?

john
.

i.Materialise are really leading the pack right now- they are able to do amazing things with 3D printing. I uploaded a complex jointed model last night (made using our new "Solid" features in SU8), chose a material (stainless steel?!) and got a bid right away (~$35?!).

Only problem is the $20 shipping price to get the print shipped from Belgium to Boulder. I think I'll wait until I have a few more things to print at the same time.

john
.

@unknownuser said:

Can you provide some links for the discussion on the Help Forum?

You can search to find a variety of related threads, but here are some URL's to get you started: Improved Texturing Tools, Ruby Plugin Management , Plugin Manager for Ruby Scripts, Improve Performance (plus numerous topics on "multicore" and "64-bit"

There isn't really a single forum post to point out for import/export improvement, as workflows differ depending on the apps you're trying to make work together. Often, import/export problems are really tech support issues, not missing features in the product.

john
.

@pixero said:

There still are big areas we can't access with ruby.

What would you like to be able to do with Ruby that you cannot do today?

John
.

Ok- so I'd say you guys have communicated your needs to the SketchUp team. I was able to recreate your list without checking my notes, which you should regard as a good sign. Unfortunately, knowing what you want is different from actually getting it done. All these requests have been discussed extensively either here or on the official SketchUp Help Forums.

Let me summarize what I've said elsewhere- you can follow up for additional detail in any of the related threads on the SketchUp Help Forum:

• improved texturing tools: SketchUp was designed with a 'simple' texture implementation. Other apps that you guys like may have up to 30% of their UI dedicated to the management of material properties or UV manipulation. Adding equivalent features to SketchUp would add considerable complexity to our app (I recoil from this) and require significant engineering effort (Tyler recoils from this) at the expense of everything else we're doing. This is a feature of clear significance to the 'hard-surface modeling' community, though of less clear benefit to everyone else.

• improved Ruby Plugin management: I recognize that a significant number of our Pro users are using one or more Ruby scripts every day, and that improvement here would benefit most users. Also that it would benefit our API developer community. Significant legal hurdles remain in place (think: Android Store) in addition to the engineering effort.

• improved performance: SketchUp's performance increases with every release we make. Sometimes you guys notice that

• improved import/export: I'm going to keep pushing COLLADA here. Industry players are lining up behind this now, in no small way because of Google's advocacy. Solving problems with proprietary import/export formats is like playing whack-a-mole for both you and our engineering team. Is there an important workflow (move model from [source application] to [destination application]) that we can't support for you today?

john
.

@tfdesign said:

BTW John B, adding a STL export option to SketchUp would be very useful for many (especially as an alternative to much more expensive apps such as Solidworks et al).

There are a few ways to export SKP > STL today (my favorite is CADspan), but I'm seeing different formats being used more commonly now. In the 3D Printing world, COLLADA is getting pretty wide support (both Ponoko and Shapeways support it natively). Our friends at i.Materialise actually accept SKP uploads now

john
.

@unknownuser said:

However, have you considered that perhaps SU Free should be for "everyone" while SU Pro shouldn't (not everyone is a professional afterall). Can you comment at all on how interconnected you see the free and pro version being?

The Free and Pro versions of SketchUp share a common code base. I tend to think of them as being two faces of the same product, developed by the same team with the same basic goals in mind.

Just for the record, I think those "PRO" features that you'd like implemented for the "hard surface modeler" market are:

**Improved texturing tools:**UV unwrap and additional mapping types (ex: spherical)
**Improved Ruby plugin management:**better toolbars, easier discovery/installation/updates, community script repository integration)
Improved performance: for realtime display and editing of arbitrarily complex models
**Improved 3D model Import/Export:**Different/more/better import-export paths for (your favorite other 3D app)

Does that sound about right? I just came up with that off the top of my head, so perhaps I've missed something critical- please correct me if that is the case.

john
.

@pixero said:

@jbacus said:

I can say with confidence, however, that our singular agenda is also not archviz/rendering nor advanced animation.

Sorry, but as I am not nativly english speaking I have a hard time understanding what you actually mean by that sentence.
Would you care to rephrase it more clearly?

The SketchUp team does not focus product development narrowly on any vertical market. Not geo-modeling, not archviz, not animation. The SketchUp team focuses product development more broadly on "3D for everyone."

john
.

Just read the last few posts again to see if I left anything out, and maybe I did. I think you're still concerned that our singular agenda for the future of SketchUp is 'geo-modeling' for Google Earth. Of course it isn't that simple, nor that restrictive. I can say with confidence, however, that our singular agenda is also not archviz/rendering nor advanced animation.

SketchUp aims to be "3D for everyone." If we have a singular vision for the future, it is that one. That is the project we've been working on since the beginning, and that is the project we'll keep working on into the future.

john
.

I recognize how comforting it would be to know that we're actively working on the particular feature/bug that you think we should be working on. Unfortunately, there are a number of valid business reasons that prevent me from opening our roadmap. We aren't an open source project and we have real competitors in the market. Also, we're a publicly traded company– which adds a whole new layer of complexity around "forward looking statements."

But I think the most important reason is that by disclosing our roadmap we limit our options as a development team. The team needs a private space in which to work. As designers yourselves, I'm sure you know what it feels like to have a client constantly watching over your shoulder and second-guessing your every move.

If you feel your needs aren't being met, state them again or (better) in a different way. If you've got a new idea you think has merit, bring it up for discussion. If you need help with something, ask for it. That's what moves your relationship with the SketchUp dev team forward. And acknowledge that we've got plenty of our own ideas about where SketchUp should go in the future that just might delight you. Or not, as may be. But accusations of inattention or incompetence just lead us to check out of the conversation.

john
.

If you're just starting out, you should give Ponoko a try. I just uploaded a project there last night, and was really impressed with the process they've put in place. They require either an .eps file (for their laser cutters) or .dae file (for 3d printing) that can be generated right out of SketchUp. Ponoko will give you quick success if you just want to get some parts made. Not too expensive, either.

John
.