@jeff hammond said:

aww.. i started reading that as the rest of the sketchUp core team got too high to....

was hoping for something a bit more gossipy
: )

Getting high would make work a lot more interesting, but were that part of our regular development practice, I'm not sure we'd have ever gotten around to fixing the shadow bug, let alone going to 64-bit.

Come to think of it, maybe when our users get too up in arms about the SketchUp x+1 feature list, we should just raffle off a few trips to one of the places where they can legally go chill out.

Andrew

@jonfar said:

when i saw "Sketchup 64bits" i thought i was gonna be able to work with high poly trees and objects like i do with C4D

We worked for YEARS to dispel the notion that 64-bit SketchUp == faster or more cores. If you go back and read everything our team said about 64-bit migration years ago, the theme was essentially, "by and large, people don't need 64-bit; it's not going to get you anything--unless you do activities that cause you to exhaust your memory, like rendering." We beat that drum over and over and over, but people didn't listen. Now we provided 64-bit and it works exactly like we said it would and people are surprised.

Take that thought a little further and consider the atmosphere of us discussing this in the planning meetings over the last few years. Someone says, "Hey, guys, I've got an idea! Let's devote the entire engineering team for months on end to implementing a 64-bit SketchUp. What it gets us is something that 98% of our customers don't need, and it'll completely tie up our team to the point where we'll be able to implement precious little else during the major development cycle, but we should totally do it. Because...64-bit!!!"

We only managed to convince ourselves to do this once we got to the point where a) more of our users started to be affected, b) we could be sure we wouldn't need to support 32-bit on Mac anymore, c) we had enough momentum on this to get it done a little faster than we thought, and d) the rest of the SketchUp core got to high enough performance that we could actually leverage additional memory in a usable way (in the past, SketchUp would often fall to its knees for other reasons before exhausting memory).

Nevertheless, here we are. 64-bit SketchUp. Everything you wanted, but not what most people needed.

Andrew

@al hart said:

Thanks Andrew - I had seen the warning - but still I assumed I was in the right place, since I had gotten there by clicking on the link in the SketchUp 2015 What's new article.

Al,

We're pretty excited about how the new knowledge/help center allows us to post different articles for each SketchUp version all under one heading, but the events of this week have also made us aware of how it still needs to be improved. At present, we use a cookie to decide which version of content to show you by default. I don't remember how that cookie gets set, but it's essentially created the first time you come to our help site and indicate which version of SketchUp you're using. The problem becomes trying to understand under what circumstances to change the cookie to reflect a new version. We hope to come up with something better one of these days.

Andrew

@al hart said:

The SketchUp description of 64 bit says: "The exception to this 32-bit status is that SketchUp for Windows has been built with an exception to allow 64-bit memory usage which allows SketchUp to use more than 4 Gb of RAM."

Just a moment...

(help.sketchup.com)

DO you think the second use of the word exception is a mistake, or do you think SketchUp found a way to create a "pseudo" 64-bit - which uses more memory, but isn't really recompiled for 64 bits?

You're looking at the wrong version of the article--for 2014 instead of 2015. Go back to that article and read the bright red warning at the top that tells you to use the dropdown menu to change to the 2015 article. Then you'll see what you'd expect.

SketchUp 2015 x64 is absolutely, 100%, without a doubt, compiled for native 64-bit execution. The exception message was in regard to 2013 and 2014.

Andrew

@airwindsolar said:

But you'll never need more than 640k, applications will never be too big for a handful of 720k floppies, or manage to fill up a 40MB hard drive, or...

Obviously these sorts of statements seem ridiculous in retrospect, but the thing is that one never really knows which assumptions will hold true and which ones won't back when the original decisions are made.

The people who wrote computer BIOSes 30 years ago assumed somebody would come along and eliminate their use of two-digit years before 1999, but then nobody showed up to do it.

A lot of people saw the explosion of CPU clock speed from 1990 to 2000 and thought it would continue forever, but then one day we suddenly hit a barrier.

I once got to speak in-person with Vint Cerf when he came to Boulder for a lecture. He told me a funny story about the use of IPv4 addressing on the internet, essentially saying that at the time the original specs were drawn up, although there were a few folks on the engineering team who wanted 64 or 128 bits of address space, when push came to shove, since not a single device had been built yet and the whole thing was experimental anyway, he decided there had been enough arguing and just put his foot down, saying 32 bits were plenty--especially since he didn't think anybody would take his research seriously if the proposals asked for anything greater. Of course, just like with Y2K, nobody came along to fix the shortcoming it until the last minute.

Like I've alluded to throughout this discussion, the squeaky wheel gets the grease.

Andrew

@pixero said:

it seems they haven't even started converting to 64 bit to future proof SU. ... I would have thought that this process would be ongoing at some low level at least.

We're doing tons of work to try to shore-up and future-proof SketchUp. I just can't confirm or deny any specifics. See my previous point re: lawyers and Wall St.

@pixero said:

The first thing that I thought about when I heard Trimble had bought it was that they really have to ...

Good, more of that kind of thinking. Certain members of our team have been made into whipping boys because of the decisions people think they've made. Not all of the decisions come from the bottom like we sometimes wish. And luckily, not all of them come down to us from the top, either.

@pixero said:

I know J. Bacus have said that: "Access to memory is not the bottleneck in SketchUp where 'more geometry' is concerned."
If it isn't then please tell us what the bottleneck is and fix it.

OK, I'll tell you what it is. Ready?

Surprise, it's not just one thing. Certainly, not even a whole set of things we could very easily explain to our user community.

The biggest problem SketchUp faces is that it's an incredibly complex, legacy codebase. Having spent the last 13 years of my career working on legacy code, I can tell you that it's a whole lot harder and less glamorous than the preceding several years I spent working on brand-new code before that. Legacy code suffers from all sorts of problems you might expect with anything that ages. Sometimes you're dealing with cleaning up short-sighted decisions that should have never been made. Other times you're putting out fires caused by essentially random and unpredictable problems that no one can foresee at the time the offending elements are created.

As far as performance is concerned, just as with the 64-bit transition itself, you'll just have to trust me when I say, if there were a magic button, we'd have pushed it already.

Those who have used SketchUp a long time will remember the big performance boost we gave SketchUp with version 7.1. Well I'll tell you it wasn't for nothing. The gains we got there came from exchanging the entirety of our rendering engine for what we still use today--Intrinsic Alchemy. It was a massive, time-consuming insanely complicated integration to make that happen.

Some number of the big performance improvements will require really big investments like Alchemy did. As I think Thomthom mentioned, some other number of improvements, such as the increased zoom capacity of LayOut, faster vector rendering in LayOut, and 10x faster shadow rendering in SketchUp, will be realized by improved algorithms--getting something done in a new way that is fundamentally superior to the old method, which either wasn't available, or wasn't thought of, at the time the original element was written.

We continue to invest in both of those things. Unfortunately, they take time just like everything else, plus we just don't always get to predict the amount of improvement we'll be able to achieve before we begin.

@pixero said:

By the way, how many developers are they? Does anyone know?

I'm not sure if we're formally allowed to talk about this or not. At Google we were prohibited from revealing these details. I'll ask and see what our management says.

In the meantime, please consider something perhaps nobody on our team has stated clearly before: that there's a lot more going on in the "SketchUp Team" than just the SketchUp client app. I'm not listing everything or going into detail, but I think our resources are spread out across a lot more areas than people might have previously expected. Here are some examples:

• SketchUp desktop app
• LayOut desktop app
• Core platform
• Import/Export/Interoperability
• 3rd Party Dev: API/SDK/Ruby/EW Reviews
• Infrastructure/Tools/Build/Release/Installers
• Internationalization/Localization
• 3D Warehouse
• Extension Warehouse
• Mobile Viewer
• Intra-company Collaborations
• Trimble's DBO Platform
• Skunkworks/Secret Badassery/Mind Control
• QA for all of the above

@pixero said:

Is there anyway to run some diagnostics in the background that if SU runs out of memory makes a dump of all running processes and memory used at that point?
When these crashes appeared I didn't get a bugsplat I simply got that popup and another with "The application has unexpectedly closed". And it was gone.

This has a bit to do with the way BugSplat is integrated with SketchUp and also how the memory became exhausted. Lots of unpredictable behavior results when memory is severely fragmented or exhausted, whether just within a single process, or on a larger scale. I've opened a bug about your observation.

Andrew

Hey everybody,

This is my last response to this thread. The discussion of 64-bit has once again completely exhausted me. Don't expect any more updates on this topic from me.

After reading back through the whole thread though--and actually, not as much this thread as several others--there's something I think is very important to get off my chest.

While not directing this at any one poster, I want to make it clear how fed up I am with the finger-pointing and brow-beating that's been allowed to happen way too much on some of these threads. Sure, I'm a fan of free speech. I'm also a big fan of grace and civility in a professional setting.

In particular, I'm just tired of how often people post negative, derogatory, or otherwise inappropriate messages about the people involved in the engineering or decision-making processes of the SketchUp team. I don't think users have taken to doing this to each other, but trust me I'd be just as disgusted about that if it were the case.

Just like all of you, those of us on the SketchUp team who participate in these forums do so on our own time and don't find it motivating, fulfilling or helpful to put up with child-like outbursts or general incivility, particularly in what I'd consider to be a community that was created for the express purpose of professional exchange, and especially not in a context where people behave that way while simultaneously trying to get me or my team to listen to or help them in some way.

If you've ever wondered why so many of us continue to work on the SketchUp team through transitions from @Last to Google and now to Trimble, the reason is because of the people. I'd trust my teammates with my life, let alone with guiding and nurturing a software product. Can you say the same abut your coworkers?

Regardless of whether you believe me--and if you don't have coworkers like this, then you probably don't believe me--please hear this.

Levying personal criticisms--those that are aimed at people instead of the product--is a sure-fire way to make me and the rest of my team ignore anything else you have to say.

Those of us on the SketchUp team want to make the best product we can. We also want our users to have the best experiences they can, and to have a fair bit to do with guiding the future direction of the product, within the realistic constraints of us needing to balance the desires of a great many different stakeholders in this endeavor.

Concerns, suggestions, bugs, problems, and questions about SketchUp? Keep them coming all day long. That's how we get better.

Implications, complaints, criticisms and commentary about the character of the individual people on the other end of your keyboard? Keep them to yourself.

If you wonder why so few of us still actively post on SketchUcation, look no further than this. Too many of my friends got tired of having to sort through character assassinations and tirades questioning the motivations of their coworkers, which they took as a sign that their participation was no longer desired. If it keeps up, I'll assume the same.

Let's all be better to each other. Thanks for your consideration.

Andrew

@jeff hammond said:

i'm pretty sure if there were a magic button which the suTeam could press and sketchup were suddenly 64bit, they'd all push it.. without hesitation.

Winner, winner, chicken dinner. You're 100% right; we'd have hit it a while ago, no hesitation. Look, there's no ideological argument here that's causing us to say, "no, never!" There are just real technical hurdles and other priorities competing with each other all the time. We have to do our best to work it all out.

@jeff hammond said:

so if that is in fact true, everything which comes afterwards "benefits are minimal" and/or "performance may actually suffer" etc.. it just comes off as excusey sounding ...

Exactly. There's an inverse relationship between the length of time someone wants something and their ability to be satisfied by the reasons why they can't have it. After a while, anger and pessimism win over, no matter how accurate, true, or reasonable the explanations may be.

Andrew

@solo said:

I do not know the technicality of what is needed or what is going to work better however I do know what I'd like to be able to achieve with Sketchup.

Maybe we can start a new thread and have a real discussion of what can be done to help us with higher poly models, not how to model leaner but rather how SU can be "fixed" to handle more complex scenes.

Many folks believe going 64 bit or multi thread would help, maybe even having a way to turn off the inference engine, I do not know so maybe we can all discuss and perhaps even find a direction y'all may be willing to investigate.

Solo,

This is exactly the kind of thing we've done with our surveys in the past, with only varying levels of success.

What we need to know before we begin investigating performance problems is that people are doing everything they can to follow our previous guidelines about making SketchUp work as well as possible with high-poly models, etc.. Only then can we fairly evaluate the feedback about what kinds of operations are getting people stuck. We need to see consistently and repeatably that under the controlled circumstances we've suggested, the bottlenecks exist <wherever-they-are>. We need to get a really good idea for not just the fact that some operation is a problem, but more importantly, to know the frequencies with which those problems occur. That's what allows us to put together a comprehensive plan to deal with those things that will make the most difference--those items on the critical path, in order of severity, as dictated by overall impact.

In fact, that's exactly what we do with BugSplat. All of the crashes are prioritized by number and frequency of occurrence. When we address them, we do so in that order. That's why you've heard so many people talk about SketchUp crashing less often than ever before.

The problem we've had to this point is that generally, we get a lot of people who cruise the forums and the internet and pick up on buzzwords like "multi-core" and "64-bit" and then instead of following our suggestions for how to use the software and working to give us good feedback on where their limitations are like I've described above, they just come back at us and throw the buzzwords around without doing anything helpful.

For instance, just at this last basecamp, when I asked someone for what I just wrote above, he responded by trying to dictate his own process. He said, "No, it's not my job to do that; I'm paying for Pro and it doesn't work like I want, so that's your job to fix." He said, "Implement 64-bit and multi-core and xyz and then once you're done, you'll see all my problems are solved."

I see that all the time and it does us absolutely no good.

What we need is more people being really cooperative and forthcoming about helping us figure out exactly "what", and fewer people concerned about the "how." Our job is to figure out the "how" after we have a clear idea of "what," not the other way around.

Always asking for "how" is just a recipe for disaster: Either we give you nothing but the "how" because that's what you insisted we do, though it doesn't actually do anything to satisfy, or we do our damnedest to figure out the "what" on our own and implement an appropriate "how", only to find that the "what" we did isn't the as important as the "what" we didn't.

And believe me when I say that at least half of the time people think they're giving us a "what", they're actually giving a "how"; not necessarily to be obstinate, but because they don't actually realize their proposed improvement actually dictates a particular implementation.

I think the issue for the immediate moment though is that we've done a reasonable job of collecting quite a bit of "what" and are in various stages of working through that stuff. The progress just never seems fast enough to satisfy. Plus all the while, we continue to have to try to quell the storms of people demanding their own "how".

One of the ideas we've kicked around in the past is trying to create a sort of monitoring utility inside of SketchUp that we could use under some circumstances to try to collect really good data of the sort we need to figure out exactly where the problems are coming from. The problem is that it's a bit too much like Schrodinger's box, where the impact of running tools to observe the problems actually masks what's really happening by changing the timing and overall speed. Whatever the case may be, please trust me when I say we're always interested in trying to improve performance, although we simply can't sacrifice everything else to get it.

Andrew

@driven said:

Maybe you can purge the 'carbon' that's still floating around...
24/04/2014 21:59:24.756 SketchUp[22606: *** WARNING: -[NSImage compositeToPoint:operation:] is deprecated in MacOSX 10.8 and later. Please use -[NSImage drawAtPoint:fromRect:operation:fraction:] instead.]

John, I can't think of a single one of our Mac developers here who would disagree with that sentiment. Carbon has well overstayed its welcome. It's all just a matter of time and priorities.

Andrew

@jdagen said:

@andrews said:

I very much doubt that anywhere near even 5% of world-wide Pro users would see tangible gains from adding 64-bit support

while the active users from here may be 'a drop in the bucket' consider that many in the rest of the ocean are people who have the free version installed and are modeling things for fun from their basements.

Agreed, many free users are such. That's why I wrote "world-wide Pro users". I'm talking about Pro users only--those who pay for the product. And yes, I'm sticking to my assertion that at this specific moment in time, there are lots of other issues that are important to a greater number of those users than the 64-bit thing. 64-bit is a false prophet.

@jdagen said:

The type of users represented here are your biggest evangelists, scripters, salesman, and customers - though small by percentage. By ignoring them for the vast ocean, you may slowly loose some of your greatest assets.

As detailed in some of my other recent follow-ups, we're definitely not ignoring the users here or anywhere else. Everything we hear as feedback is valuable. We just can't do absolutely everything people ask of us. That means we have to make decisions that don't please everyone.

@jdagen said:

Furthermore, if you really are aspiring to compete with the 'big boys' as it relates to BIM and IFC, you simply cannot ignore the 64X issue.

As with any other issue, "not available" does not equal "ignored".

@jdagen said:

Not going to 64X may also be tipping the hand as to who the intended user base is, and it seems that may not be many of us here.

That has nothing to do with it. In fact, Google favored expansion of the free user base; Trimble is quite the opposite. They spent a lot of money on us and you can be sure they expect to see a return on their investment.

@jdagen said:

Second, I seriously doubt only 5% of users would realize the performance improvement. Anyone working on a large architectural model is familiar with the perfromance issues especially with terrain. If this isn't an issue, why does almost every Basecamp have sessions on working with large complex models?

Take a look at pretty much every other 64-bit thread on this site and you'll see we've talked through this one until we ran out of air. 64-bit memory addressing has absolutely nothing, nada, zip, to do with models bogging down with complex geometry.

The basic fact is that as soon as we raise the performance ceiling, use of the product will grow to match it. That's how it's always worked. Guidelines for high-complexity modeling exist to try to extend that ceiling as far as possible, for as long as possible. There will always be limits.

A 32-bit memory space is more than adequate to address many times more geometry than SketchUp could ever reasonably handle today. The memory limitations come into play when dealing with insanely large textures, data imports/exports of massive files, trying to implement seriously complicated computation extensions within the SketchUp process instead of spinning off a separate process, and other stuff like that.

Andrew

@solo said:

@unknownuser said:

Andrew stepped in and informed that it was also a matter of resources available...
Another point in the post he made was that only a few out of the multi million user base, don't ask for this...

If Apple worked like this there would not have been iPod, iPad, iPhones either as the majority never asked for it.

Solo,

Good point, well made. In addition to listening and trying to incorporate the desires of our active users, we've also got to pay attention to doing things we think will help win us new business. Some of that new business will come from adding user-requested features. Other business will come from introducing a new element with just the right timing to make it revolutionary--bringing something to the table that nobody realized they wanted before it showed up.

As some folks have stated before in other threads, it's important for people to keep in mind that Trimble didn't buy SketchUp on a whim, and they didn't do so in order to let it stagnate. They've got plans for the future that they're willing to gamble on. Some of these plans won't work out. Hopefully, others of them end up as well as the iPod. Only time will tell.

So I hope you hear me saying that we are aware of the importance of innovation. Most of what I hear people asking for on these forums is evolution. But to your point about Apple, usually, a company's long-term success is dictated far less by evolution than it is by innovation. When Apple teetered on the edge of bankruptcy, it wasn't saved by introducing a new Mac computer, but by iTunes.

Please though, nobody write another message asking, "and these new whiz-bang features of the future are what exactly?"

It's part of our nature as a large, diversified, publicly traded company, not to discuss our future plans. Simple as that. It doesn't have anything to do with how much I or anybody else on the team wants to be secretive. It's just the way things are when running the world is left up to the lawyers.

I also don't remember Apple pre-announcing the iPod or iTunes before they hit the market and I know we didn't do that at Google, either. Besides, in a lot of cases it wouldn't do any good even if we did show you everything on our roadmap. We'd tell you we're working on some new thing we think is going to be revolutionary, but since no one thinks they need it yet, we'd get nothing back but flack. To top it all off, then someone would just beat us to the punch and make it moot anyway!

Andrew

@jeff hammond said:

for me personally, having a 64bit foundation is more symbolic than any immediately noticeable performance gains that one may or may not see.

it's modernizing the base application and signifying sketchup is ready to grow into the next decade or two.

Jeff,

I'm glad to hear someone share those sentiments, because this is exactly the kind of thing we constantly consider. Trust me when I say we've grabbed the modernization bull by the horns.

When we break down the time to spend doing engineering work on SketchUp, we consciously divide the tasks into three buckets: bugs, features and infrastructure. We then choose some percentage of each of those things to be addressed during a given release cycle.

It's pretty obvious what bugs and features are, so I'll skip the explanation there.

The third piece, infrastructure, is what you're talking about WRT modernization, and that's where I spend the vast majority of my time. In our use of the term, infrastructure refers to the (generally invisible) things that happen both under the hood of a software product, and behind the scenes of its development, to keep everything working smoothly. For instance, some of my infrastructure projects for this release are upgrading our source code control system, upgrading our continuous build/integration system, and completely replacing all of the official Windows build servers we use to create SketchUp. Some other examples of infrastructure projects are upgrading the versions of Xcode and Visual Studio we use to compile the product; upgrading, replacing, or eliminating various third-party libraries we rely on; improving our test automation systems; working out difficulties with the processes and systems we use for language translation; or redesigning certain areas of the code that are so complicated or convoluted that every time we go in to work on them, we introduce an inadvertent bug. None of these things will be directly seen by any of our end users, but as you've alluded to, if we don't pay attention to them and allow the build-up of too much technical debt, it could be a death knell.

In any given release cycle, sometimes we choose way more bug fixing. Other times, we choose more infrastructure. It's difficult to get the right balance because every user of our product would judge the necessity of each of these things differently. We do the best we can to select a set of tasks that will give us the best balance. It's usually very difficult to decide where things will fall.

You've probably heard us talk a lot about under-the-hood improvements in 2013 and 2014, again, without seeing any of them. Suffice it to say that we've been working hard to recover from a few years of amassing too much of that bad technical debt...

Andrew

@frederik said:

I've been thinking... ... If the primary obstacle for not making SketchUp 64bit compliant is a matter of limited resources, why don't the management find a solution to eliminate this challenge...??

As we've announced at Basecamp and elsewhere, Trimble keeps an incredibly close eye on the bottom line of the SketchUp team. They're inclined to give us more resources when we prove that we're able to manage ourselves and perform well along the way. I'm happy to say they've been thrilled with our performance so far and continue to allow us to add new personnel to our ranks in ways that were never achievable previously. We've been very smart about our growth though, and we've expanded nicely across the board, from marketing and sales to product management, to development and QA. We can't simply add a whole slew of engineers to our team without pushing all of our numbers out of whack, but besides, we're actually growing as fast as we can given the amount of top-notch talent we've been able to find. We have pretty high standards.

@frederik said:

I mean... What about outsourcing some parts to specialists...??
Perhaps it's not very popular, but there are plenty of very talented developers in i.e. India - and I would assume also in China...

See the point about very high standards. Also, we have done that to some degree, involving other teams here at Trimble when it makes sense, and by leaning on some outside contractors for certain self-contained features. For instance, we've had help from the outside with some of our built-in importers and exporters from time to time.

@frederik said:

In my previous career I was working close with some developers in India and - to my surprise - it actually went very well...

We've had both good experiences and bad. Trust me, we're leveraging this avenue to the limit of our comfort.

@frederik said:

Arguments that you don't have sufficient resources doesn't last...

Yes and no. It's not to say there's nothing we can do as a team to try to grow ourselves; as I said before, we're doing it as well and as quickly as we're able to.

Trimble has been very supportive of us growing, as long as it's responsible and well managed. But you also must consider that while our SketchUp team has direct control of some amount of its resources, some other percentage of our growth is attributable to hiring people to work on the strategic and long-term goals, as determined by the company.

So while yes, we're growing steadily, and yes, we have enough people to apply some to issues that never could have gotten attention before, there's always going to be a limit to how much we can do--a limit that makes us prioritize our efforts, sometimes in ways that are hard for us, or our customers, to swallow.

Andrew

Hi, Jason,

@jason_maranto said:

Same song and dance -- and you know I bought it, but that was when I though you guys were actually going to do "something" (anything) with the resources saved.

If your mind is made up, then so be it--there's no need to be swayed by a real person giving an honest and forthright explanation of the situation. You're welcome to find your own reality if you'd like.

Five years ago, we were owned by Google, and as is the case for all assets of a corporation--product, personnel or otherwise)--they had the final say in charting the direction of all of those things until the acquisition by Trimble in June 2012. An awful lot of your anger could be saved by reading between the lines of so many messages posted to this forum about those times and by simply considering the fact that SketchUp was eventually sold to someone else. If you want to blame someone for whatever happened for the few years before the Trimble acquisition, take your complaints elsewhere.

Once you get past that and focus on only the last 22 months of our time at Trimble, you'll have the opportunity to get a more realistic perspective of things. I think it would behoove you to consider the reasons why Trimble made the SketchUp acquisition, how they would hope to make back such a major investment of capital, and what sorts of plans they would have for it in the future under their control, before making any claims about what we've been able to accomplish in these circumstances, let alone what role 64-bit compatibility should play in our long-term plans or how concerned we should be about whatever company X has done. I'm not saying you'll agree with it all, and that's OK; not everybody will. But I think if you were to assume good will on Trimble's part rather than ill, the rest of us here on this forum who are trying to build a helpful and uplifting community of users of this product would meet with enthusiasm the positive change in attitude and outlook that might result.

@jason_maranto said:

However, in light of the fact that you have done essentially nothing for the last 5 years, I would say that all you have shown is that you in fact fully intend to keep doing nothing for as long as you can get away with it.

You'll have to excuse my saying so, but to judge that the SketchUp team members or Trimble on the whole are intent upon doing absolutely nothing with SketchUp--despite the welcome reception of the work we've done at Trimble by many other of our users; without consideration of any long-term or strategic goals of the company we work for; without accepting the need for us to spend 18 months of our time on the difficult and resource-intensive contractual obligations we incurred upon splitting with Google; and without taking the time to get to know any of us personally--seems tragically misguided.

@jason_maranto said:

Try selling your misdirection to somebody who is foolish enough to actually buy it.

Again, the only thing you're ever going to get from me is the truth, as absolutely clearly, and fully, as I'm permitted to give it. I'm not some machine in a PR factory. I'm just a guy who loves the team I work with and is passionate about creating something awesome for our users.

Like I said before, I'm powerless to stop you from embracing an alternate reality if that's what you desire, but it doesn't seem terribly fruitful from where I sit.

Andrew

@krisidious said:

@hieru said:

What would SU be without all the great plugin developers here at SCF?

I doubt I'd be using SU if not for the developers here at SCF.

We made the decision a very long time ago to actively promote the extensibility of SketchUp through use of the Ruby API. We continue to believe that the developer community is a crucial part of the SketchUp ecosystem and we are pleased that we are able to continue our part of the vision to provide a powerful and flexible, but easy-to-learn and easy-to-use, 3D modeling application that fulfills critical needs for everyone from students and hobbyists to professionals and enterprises.

Andrew

Hi, Frederick and everyone else,

I'm responding to Frederick's message directly, but I'd like to be clear about the fact that in no way should anyone perceive the following message as pointing fingers at him. I'm using his quotations as a convenience to answer the questions he asks which I think are on most people's minds. But please keep in mind that everything I say here is directed toward the community in general and please no one take offense if something rubs you the wrong way.

@frederik said:

I'd challenge you and claim it's because they know zip about 16bit, 32bit and 64bit software...
You're talking about the average Joe who's using SketchUp similar to how they're using MS Word or Excel...

I agree 100%. "Simple" Pro users of that type would consider SketchUp to be every bit as integral to their work as Word or Excel, and yet they may not come anywhere near using the vast array of capabilities of any of those programs the way power users would. But as such, those folks aren't pressed by problems with 64-bit, at least not in the way power users may be. And yet, those folks buy SketchUp in huge numbers, and have just as many other complaints, problems, and feature requests for it as the outspoken power users on this forum. We take very seriously our duty to pay attention to these users' needs just like we do our power users.

@frederik said:

I know huge architectural companies who are using SU professionally on a daily basis, but where no-one are part of either the official SU community nor do they know about the existence of this board...

Exactly my point. Those people have myriad other ways of getting in touch with us beyond the forums--particularly the enterprise customers, who work with dedicated support and sales personnel. So just because they're not part of this community doesn't mean we don't have ways of gauging their interest and finding out what they need.

As an example, would you believe that the most important thing enterprise organizations want is for us to completely rewrite the licensing engine and provide better in-product identity management? We've spent a ton of time examining how we might improve licensing, and I'll bet almost no one in this forum would care. While it isn't something the average Pro customer with a small firm would care about, by sheer numbers of affected Pro users, it dwarfs the 64-bit proponents by many orders of magnitude.

And as for those categories of users who aren't getting in touch with us in any way? Well, an awful lot of complicated mathematics and heuristics go into classifying our user sets and extrapolating what features are (or will be) needed by those groups, even if they can't speak up directly. Yes, this is something we very much pay attention to!

@frederik said:

I'd say that less than 2% of the multiple millions of active SU users in the world cares about joining such communities...[i](As an example, I'm quite certain that there's a huge customer base in the Far East, who would never join this board...)

This is absolutely true. Mainland Chinese is the second-most-popular language of SketchUp besides English. And as such, we've dedicated tremendous resources to the Chinese market. The Sophie character who loads with SketchUp 2014 is a member of the SketchUp team, a native Chinese woman who leads our business development, support and outreach endeavors in China. By virtue of both the program running in another language and the people there using it for different things and under different regulations than elsewhere, Sophie has her finger on the pulse of an incredible number of issues that aren't even on the radar for our English users.

@frederik said:

The SCF community has grown to more than 250.000 users... As a software developing company, you should embrace every input you can get from here... Positive as well as negative...

Believe it or not, trust me or not, WE DO LISTEN! We love SketchUp and want to put out the very best product we can. We are also very keenly aware that without the income we earn from selling Pro, there wouldn't be a product at all, so of course we're interested in hearing every suggestion we might use to make the product better--to get new customers and keep existing customers as happy as possible.

If we didn't care to hear about the problems and criticisms, none of us would be here. Most of us don't have the time to ever post in response, but user suggestions and conversations such as those in this thread are read, passed along, and distilled by our team all the time! We don't ignore any of this stuff. All of it goes into the bug tracking and feature request systems. Maybe we've not reiterated this fact enough, but maybe we just took for granted that you all would know that since the people on our team are all the type who really do listen carefully when we say we will.

I'm not sure this community on the whole understands well enough that just because we don't implement every single suggestion we read here doesn't mean that we're not listening. Some of those suggestions are things that are in the works, or which are on our radars to do "someday". Others are those which we have considered, but ultimately dismissed. While we may not explain every decision and folks might not agree with our reasoning even if we did, our eventual dismissal of certain ideas doesn't mean we're completely oblivious or unconcerned about what our users have to say.

To reiterate what I said at top, I'm not directing everything right at Frederick, but at the whole community--especially in this case. Something I think a lot of people need to be reminded is, "you are not our only customer." While we work diligently to make everyone as happy as possible, the simple fact is that we have too much going on to pursue every single thing requested of us, and many times, keeping one set of users happy means consciously making choices that dissatisfy another group. We do the best we can.

Also, I know it's easy to forget or not to notice, but if you take a look back over the years and years of SketchUp development, there are plenty of examples of huge things we have done in response to user feedback.

@frederik said:

Solo have a great point with his statement:

@unknownuser said:

...especially folks that use 3rd party integrated software...

Jeff also has a great and very legitimate point:

@unknownuser said:

won't it have to go 64bit eventually?

We're very much aware of those folks who are using third-party software or running into problems with the 32-bit setup for whatever reason. We're also in agreement that SketchUp will have to go 64-bit someday. We've never said otherwise. It's just that, for myriad reasons, we haven't done it yet.

@frederik said:

I'm not saying that if you take the 64bit route, all issues will get cured, but I really don't understand why you cling to 32bit, when everyone else go the 64bit route...

By now, I've answered this in other messages that have come since. I'm just reiterating that I have indeed directly answered this question. Even so, I'll say it again, this time in a more succinct presentation.

Yes, we know SketchUp must go 64-bit someday, and in fact, all of us on the SketchUp team very much WANT it to. However, nothing is ever as simple as just wanting; if it were easy or free, we would have done it already. The technical endeavor of migration to 64-bit will be very difficult, expensive and time-consuming, requiring tremendous investment of skill and care to ensure the quality and performance of SketchUp do not suffer. Although there are some serious limitations of the current 32-bit system for some users, we believe the community greatly mischaracterizes the issue and sees a 64-bit binary as a silver bullet that it simply is not. The reason a 64-bit version has not yet been released is a business decision that stems from careful consideration of the the costs of the endeavor and the true benefits to be had, in light of our other priorities. Those other priorities come from several sources, including not just customer suggestions and wish lists, but those tasks which are found to be of critical importance to growing our customer base and the promotion of Trimble's strategic vision for our product and the company.

Andrew

Sorry for jumping into this thread unexpectedly.

Overview
We had a discussion going in this thread about where to find the 2014 materials folder on the Mac. Jeff Hammond then brought up some bugs about materials handling there. Someone else mentioned wanting a utility to migrate materials from one version of SketchUp to another. I was going to respond in-line, but felt like it hijacked the thread too much, so I switched over to this thread for my response.

Ideology
Technically speaking, it's best to avoid mixing user-created data with vendor-provided data. So, once you install the SketchUp application onto your computer, if it ships with any default content provided by us, it should live inside the app bundle, here:
[pre:1zpu56sv]/Applications/SketchUp 2014/SketchUp.app/Contents/Resources/Content/Materials/[/pre:1zpu56sv]while all materials created or changed by the you should really live in the user's folder, here:
[pre:1zpu56sv]~/Library/Application Support/SketchUp 2014/SketchUp/Materials/[/pre:1zpu56sv]

Bugs
Here are the two bugs we discussed in the other thread that impact what I'm about to say:

1. If you create a new material inside one of the default collections shipped with SketchUp, that material is improperly created inside of the materials folder that lives in the app bundle instead of putting it somewhere in your user folder. This is a bug because either SketchUp should disallow you creating any new stuff within the default collections, or it should invisibly create a like-named folder in your user location and store the file there such that when the materials browser is loaded, the contents of both folders are merged for display to you.
2. If you go to the trouble to use Finder or Terminal to create a directory tree inside of your own user materials folder and fill it with SKMs, that folder will only show up in the materials browser if its name does not conflict with the names of the default collections. For instance, "Wood" and "Metal" are examples of default folder names that must be avoided. Instead, use a name like "My Wood" or "_Wood" for all of the custom folders you make, thereby avoiding any conflicts.

Good News
As an aside, I'd like to start by giving you some good news. Upon digging into the bug tracking system, I see that we have several bugs grouped together into a major topic called "rationalize shipped content vs. user content". This includes a bunch of materials bugs, including those mentioned above. I think this might get traction soon, so though I can make no guarantees, hopefully we'll find some improvements to materials handling in an upcoming release.

Who's Affected
Now, with the background out of the way, here's what I'm trying to address:

• Some of you are on SketchUp 8 or 2013 and have already created a bunch of materials through SketchUp, which got created incorrectly in the App bundle. Now I'm telling you not to ever modify the app bundle and you're wondering how on earth you should migrate the SKMs to SketchUp 2014 if that's the case.
• Others of you have already migrated materials to SketchUp 2014 by putting stuff in the app bundle and now you want to know how to "repair" it.
• Still others may have tried to migrate materials into SketchUp 2014 by copying from the SketchUp 8 or 2013 bundles into the 2014 user directory, but not all of the materials are showing up and you don't know what to do about it.

Workaround to Migrate Materials
I've come up with a workaround that might work for some of you and I wanted to post it. Maybe someone will want to write a plugin to help with migration, now that this info is being explained fully.

Here's the basic idea of how to migrate:

• Close SktechUp if it's running.
• If it doesn't already exist, create a Materials folder in the user's directory, at ~/Library/Application Support/SketchUp 2014/SketchUp/Materials/.
• For every version of SketchUp that has materials you want to migrate from the .app bundle into your user directory, just copy all of the collection subdirectories from the Materials folder of each app into the user's material folder.
• To prevent any conflicts between the names of the collections in the user directory and the app bundle, systematically rename every subdirectory within the user's materials folder, either adding "My" or "_" before the name. This will guarantee no conflicts.
• Launch SketchUp and open the materials browser. Verify that you now have the same list of default collections (like Wood, Metal, etc.), as well as all of your custom-named directories.
• From now on, when you create a new material, be careful to create it within one of the collections with the "_" or "My" designation so that you don't pollute the app bundle again.
• This step is unnecessary, but if you really want to clean things up to be nice and tidy, you can now go delete the Materials folder from the SketchUp bundle and then copy a new one into its place from the SketchUp installer bundle. This will ensure the directory contents are exactly as they were when we shipped them.
• Another unnecessary, but possible step, is to run a diff between the content we ship and that which is in the "_" or "My" user directories and remove the duplicate copies from the user folder so that there are no duplicates.

Quick and Dirty Migration Example
As a brief example of how one might go about migrating content from the 2013 app bundle into the 2014 user directory, I created the following one-line script that can be run from Terminal.app. Please note I only just threw this together and so you may find it doesn't work quite right. You've been warned that it could cause some problems. It is intended to find all materials collections within the 2013 app bundle and copy them to the 2014 user directory, renaming them with an underscore in front of the name to prevent collisions.

[pre:1zpu56sv]find /Applications/SketchUp\ 2013/SketchUp.app/Contents/Resources/Content/Materials -type d -d 1 | while read i; do ddir="$HOME/Library/Application Support/SketchUp 2014/SketchUp/Materials/_$(basename "$i")" && mkdir -p "$ddir" && cp -Rf "$i/" "$ddir"; done[/pre:1zpu56sv]

Closing
Yes, we need to fix the materials bugs. Yes we hope to someday create a migration utility to handle this more easily or automatically. I'm sorry it's not ready yet. I'm sorry it's a pain in the neck. I hope this knowledge helps people somehow.

Andrew

@jeff hammond said:

^ great. thank you

Jeff,

I was gonna respond with some more info about material migration, but I feel like to do so would be hijacking the thread. Therefore I'm posting my next reply here instead.

Andrew

@jeff hammond said:

i still think it's sweetest when everything about an application can be handled from within the program itself.. ... imo, the more you can do to keep the support file structure out of sight, the better

We agree. That's why pretty much all of my posts WRT people asking how to find the plugin folder say, "stop worrying about where it lives; we're handling it for you in the new EW!" I know it's not perfect yet, but that's the approach we're trying to take.

@jeff hammond said:

i still keep wanting to just drag/drop an rbz onto a sketchup window for install

I agree. There is an open feature request for this already and I've just +1'd it.

@jeff hammond said:

i think the material browser could benefit from a better front end

We agree. I just talked to Barry and Brad earlier today when we looked over the other thread where you mentioned materials problems. The general consensus was that it's a total mess, especially given how behaviors differ from Mac to Win. It's a nagging issue for sure and I've just opened some new bugs about this point.

Andrew