Who said SketchUp doesn't need to be 64 bit?
-
@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
-
@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
-
@andrews said:
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;
simple for the user.. not so simple for the developers..
re: the magic button i was talking about earlier.. you guys don't have the magic button.. but we do- it looks like this:
your magic button is hard to push and requires lots of effort.. ours is real easy to push so we just keep pushing it over and over.
-
@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
-
@andrews said:
You've probably heard us talk a lot about under-the-hood improvements in 2013 and 2014, again, without seeing any of them.
well, i have noticed one thing for sure.. and it's probably the most important of them all.. sketchup doesn't crash anymore.
(well, i've crashed 2014 a few times and sent in my splat reports.. i'm not sure if you can see exactly what i was doing prior to those crashes but they were ,to me, understandable as i was trying some stupidly demanding tasks with a few of the more powerful rubies.. regardless, it's yet to crash on me while i was actually working whereas in the past, i'd get crashes during designing or worse yet, on the job site when time = even more $$)so if that's anything to do with under-the-hood improvements then awesome work.. because crashing and/or losing work is pretty much the most frustrating thing a user can experience when using computers.
-
@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
-
@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
-
@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
-
@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
-
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
-
@pixero said:
Why is it that if I have some heavy geometry in SU all of a sudden some soft edges become hard edges?
Yea, that one - that's one of my pet peevs and I looked into it. It's a very bizarre bug. I would like to see that fixed myself.
@pixero said:
Why is loading and saving big scenes take forever?
In Photoshop you can press save and immediately continue to work. All saving is in the background.Our file handling routings could do with improvements - it's well known. As to why? The initial implementation hasn't scaled along with the complexity of the models 14 years later. It's certainly on our radar - one of the nth number of things to address.
@pixero said:
I could go on ...
These are good things to report and have discussions around.
-
@pixero said:
It's like he doesn't care for our needs. I feel I was a fool to believe that quads was one of the reasons he hired Thomthom.
For whatever reasons I ended up here, do remember that I've only been at SketchUp for a little over half a year...
-
Thanks for your posts. Very informative. See, doesn't it feel great to "open up" a bit?
I think these posts are some of the best from the SketchUp team ever.
I'm still worried and confused by some things John B says and the way he's saying it though.I believe getting the users on the train is important for our understanding.
That's why a more open dialog is so important.I wouldn't ask you to reveal every secret with us but a better understanding comes from knowing where we're heading.
Not saying anything because of all "unfriendly ears" just seems ridiculous when no ground breaking things is released.
There are many different ways other companies are communicating this with their users, with labs or technology previews.
If they can do it, surely you can too? -
@numerobis said:
@jason_maranto said:
The idea that 64-bit is relevant to why SketchUp high poly performance is so poor is just misdirection. The real culprit there is primarily the video card and openGL...
Processes like import, explode, copy, save/autosave(!), etc. are not opengl related. And this is what really annoys me - simple operations that can take forever.
Yes, explode is dead slow. It's the SketchUp stickyness in works. It's one of them things where when it was first made it was fast enough, but as models have grown due to other improvements this one hasn't been able to keep up. This is one of them algorithms-solutions. But it's deep into the core of SketchUp so any modification is risky and need extensive testing and research.
You mention import, of which file types? SKP or other formats?@numerobis said:
And things like beveling should work in realtime (maybe not for 1 million polys, but for normal models) - watching this process bar is really laughable.
Beveling? We're talking about a plugin here, right? Performance for the Ruby API is high up there on my personal list. I've been spending a great deal of time poking into the performance of Ruby extensions and it's clear we need to improve this area as well. We have some ideas that we are exploring. On top of improving the API we also need to improve how we provide guidelines back to the developers of our API so they can utilize best practices that we've discovered over the year.
@numerobis said:
But... if SU would be able to deal with bigger models, then 64bit would be needed very quickly. I'm currently working in Max on models with 20-30 million polys that need 10-15GB RAM. Applying a turbosmooth i can easily max out my 32 gigs...
Sure, but to get there we need to fix a bunch of other things before the memory cap is an issue. When faces with a long list of things to do one need to pick the most imminent ones.
-
@pixero said:
I wouldn't ask you to reveal every secret with us but a better understanding comes from knowing where we're heading.
Consider that third party developers are also part of this train - and their vision for what they want to make with SketchUp also greatly affect the possibilities of SketchUp. The direction of Trimble isn't the only concern in play here. With more professional developers using the platform the directions would be endless. A good ecosystem of third party developers is in total capable of responding to a much larger range of users than each individually.
-
Yeah, that's all kool and everything but, we can haz 64bit?
-
-
I am using al lot of different software packages, but SketchUp is the only one for which I know severals persons in the developer team by name. So, thank you for beeing here and listening. I think the (sometimes frustrating?) discussion is a great way to put together a well prioritized "what"-list... (sorry, no how from me)
-
@andrews said:
@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
well, to be honest andrew, what you're saying in this thread is pretty much opposite of the jab i was taking in that post..
generally speaking- when these conversations would come up in the past, i've always been left with the feeling that good communication never occurred.. there's way too much of an us_VS_them type of vibe which seems unnecessary and unproductive.
people would say "we want to see sketchup go 64bit" but the responses were of a tone of "you're wrong" or "your idea is bad because..."
(-or- team A was 'we want 64' -- team B was 'we want 32' ...the disagreements happened right from the very beginning)so the rest of the conversation is the user's trying to convince why their idea isn't bad.. then the developers or those defending the developers get more annoyed etc.. then someone says something overboard mean and the 'conversation' ends until the next go-a-round 4 months later.
but really, this is the first time someone from the team is so openly saying "hey, we want sketchup to be 64bit too.. sketchup will be better off down the line if we can get it to 64bit.. if it were super easy to do, we'd be thrilled to release a 64bit version tomorrow.. your want isn't stupid" etc.
and if it really is true that the devs (in magic button land) would really like to see sketchup go 64bit then it gives the us_VS_them somewhat of a common ground to stand on.. which in turn should lessen the battle mentality of people simply defending their ideas to more of a listening/understanding mentality..
i don't necessarily think this type of shift speeds up any development processes or leads to a user working in a more fluid manner (or whatever) but at least the communication can be better with less of a battle vibe.
-
Advertisement