Who said SketchUp doesn't need to be 64 bit?
-
Thanks for taking the time to explain the intricacies involved. I think your comprehensive assessment of the current situation puts matters into perspective.
I wonder if the situation might be leveraged for the generation of an Ultimate SketchUp Pro 64-bit version (with all the bells and whistles sought by power users) via a Kickstarter-like venture? Have a look at what the power of crowd-funding can produce here, Kickstarter's 10 Biggest Success Stories http://www.cnbc.com/id/48725154
Mike
-
@jeff hammond said:
i highly doubt anybody from trimble is going to talk about this anymore.. pretty much anything that can be said about it already has.. at this point, it's either going to be 64bit or not and i don't think the end users have any say in the matter.. up to now, the stance is pretty much "if you want sketchup to be 64bit then too bad"
I agree, it does not look like SketchUp is going the 64bit route anytime soon.
Architosh recently stated that: "As a realtime rendering system (OpenGL-driven) there is no performance benefit for making SketchUp a 64-bit application." and quoted Bacus saying: "While there are increasing numbers of CAD developers offering 64-bit versions of their applications, it really isn’t a given that 64-bit computing (access to more memory) improves their performance.”
Bacus also claims that: "SketchUp won’t run out of system memory until there are tens of millions of polygons in a model, well past the point where any modern graphics card is capable of rendering the scene.”
Link to article @ Architosh. The 32/64bit part is covered at the end on page 2.
-
@frederik said:
I suppose you haven't read the entire thread...
As far as I've seen so far, no-one is claiming that 64bit will make SU run any faster...
The primary reason users want to see a 64bit version is the use of i.e. 3rd party integrated render applications, where SU - being 32bit - is the culprit because of the RAM limitation...
But it's also a request to make SU compatible with future computer systems as well as a hope that it will be able to handle high poly models better than what it can today...I have the impression that Bacus is either not aware of this or does not understand the problems as most of his comments point out the performance part of the discussion.
-
Thanks for replying.
If nothing else, it's good to know your thoughts on the subject. But why are you so secretive about the future?
It's not like you have released a whole lot of cool new features that the competition would have stolen if they known about it.
I think we all know more about upcoming products from Apple than the tiniest bit about where SketchUp is heading.
As a professional user that is frustrating. "Is the next SU version going to fix [i]"this" problem or should we invest in some other software?" is a question we repeatedly ask our selves.[/i]I'd welcome a serious discussion about what is most problematic with SU for us power users and ways for you to fix those problems.
Now if 64bit version isn't the solution to working with heavy SU files what is?
I've never heard any explanation to your statement that 64 bit isn't the solution.
Could you please tell us what the bottleneck is?Why is it that if I have some heavy geometry in SU all of a sudden some soft edges become hard edges?
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.I could go on ...
I must say that some of John Bacus statements seems like he doesn't understand the importance of some of our wishes. Like his statement that quads isn't necessary.
I honestly don't understand why he is saying this and why he is using this arrogant way of expressing himself.
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.
Quads ARE important and could be incorporated into SU without the average user ever noticing.I feel that if there is to be some kind of discussion the initiative must come from you. Open up a bit!
A discussion, no wish list! We've done that already. -
Very well said Pixero. I think that pretty much sums up how many of us feel after the post-Trimble releases and Bacus' negativity towards power users.
-
@Andrew, very much appreciated you took the time to write here.
I guess, the 64bit discussion will be over for now. My concerns about Sketchup's future direction and the steps being considered to help us meet our clients growing demands though are not over.
For a lot of people here, working with Sketchup is a big part of business and thus affecting our time and income. If the same wishlists re-appear after every new release of Sketchup, at some point people can't afford anymore to stick to Sketchup and will switch to another program.
Communication is key, so please if you can, come back more often and share some insight about Sketchup's near future direction and, if possible, post again about our biggest concerns.
kind regards,
Max
-
@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.The boring reality of this answer is that there isn't a single bottleneck. It's not as simple as just tweaking a single point in the code and everything runs in instant time.
There are many areas where performance can be improved, no doubt about it. But the discussions are much more fruitful if they are about "what is snow" instead of users discussion various guesses to what technical solution should be applied. Don't be blinded by buzz words as 64bit and dual-core - that's not the only thing that makes an application fast and responsive - far from it.
If you think that these two things (which very often come up) will fix everything then you will be forever disappointed.
If you experience that SketchUp crashes when it's memory usage exceeds ~3-4GB then you do have a real need for 64bit. So far, this really only happens when a third party process like a render engine is running inside of the SketchUp process instead of spawning a separate one.
But if anyone reading this thread thinks 64bit will have any performance impact, forget about it. It simply isn't.Dual core? Most modern computers these days have four cores. Now, for the sake of conversation, lets says that any operation could be split up and run in parallel, the max gain would only be a 4x increase. Consider how slow Explode is on a large terrain model. A 4x increase would not be enough to make that operation fast.
The real gain is made by improving the algorithms and data structures. Good algorithms are the true heros of performance. But there is no one-fit-all. There is no magic bullet.
Performance improvement is a continuous work and I can assure you it is of a high concern within the SketchUp team. But let us keep discussions at a higher level than low level technical level.
-
@pixero said:
But why are you so secretive about the future?
It's not just friendly ears that listen...
-
@tt_su said:
It's not just friendly ears that listen...
Spock is a member?
You know Spock had 3 ears didn't you? His left ear, his right ear and his final frontier
-
@kaas said:
For a lot of people here, working with Sketchup is a big part of business and thus affecting our time and income. If the same wishlists re-appear after every new release of Sketchup, at some point people can't afford anymore to stick to Sketchup and will switch to another program.
Here is my personal take on this, we need to nurture a larger third party developer community around SketchUp using SketchUp as a platform to provide a rich range of tool suites. Given the incredible large and diverse user base the best way to get quality tools for the different user types is to have more professional developers catering to the market. Each free to run their own direction based on their specific target user base.
I wish we where there already, but we still got a good amount of work to do. -
@tt_su said:
@pixero said:
But why are you so secretive about the future?
It's not just friendly ears that listen...
Sorry but I don't buy it. Why can can so many other software companies have a more open relationship with their customers?
It's not like every other 3d software is trying to catch up with SU. Rather the opposite. -
Thomas,
Thanks for also taking the time to respond, but now I feel even more miffed than before.
So there are not a few things, there are many things wrong that is causing us not to be able to use SU like we use other software?
Can we concentrate on the issue of SU buckling and folding under minimal poly levels, is this caused by many little bottlenecks or just one?, can you tell us all the bottlenecks preventing me from having a medium sized model? (medium in in other softwares)
What ever happened to your quads crusade?, I too thought we'd be seeing them in SU by now.
-
Oh for crying out loud.... I thought for sure we were past the same old smokescreens.
Look, if SketchUp is meant to be platform for other people to build on then it is a very poor platform that does not allows 3rd party developers the best tools to do thier work. 64-bit is simply a tool SketchUp (as a platform) should be providing to every 3rd party developer.
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... where if SketchUp were to embrace more advanced technologies the user could see real improvement. However as long as SketchUp is designed for users running cheap integrated graphics chipsets, instead of requiring dedicated workstation graphics like any proper modelling app, this will remain the case. All you need to do is load a heavy scene and disable the fancy viewing options to see dramatic performance improvement... this is all the proof needed to see this in action.
The idea that "converting to 64-bit is too much work" is a valid excuse is beyond rediculous.... what have you actually done in the last 5 years that is so impressive that we should accept such a lame excuse? Stop wasting time designing websites and actually work on the software people are paying for!
-
@jason_maranto said:
what have you actually done in the last 5 years that is so impressive that we should accept such a lame excuse?
May I point out that Trimble acquired SketchUp in 2012. During the six years of Google the focus was mainly on Google Earth integration and now much otherwise.
So what about the two last years with Trimble?
Turning the ship around. Changes are happening and as we continue to staff up there will be more noticeable improvements.@solo said:
Thanks for also taking the time to respond, but now I feel even more miffed than before.
Cheer up buddy! I know it's no fun being on the outside trying to peek in, but during the six months I've been on the SketchUp team I've become very positive on the future.
Just because the technical bottleneck is different that the initial assumption doesn't mean it's a bad thing. I only mentioned it because I didn't want people being perpetually disappointed by expecting a technical buzz-word in the release log. Focusing on assumed technical details is clouding the more useful higher level discussion. What are your goals with the tools you use?
@solo said:
So there are not a few things, there are many things wrong that is causing us not to be able to use SU like we use other software?
This is the entry to something that can be interesting. How is it that you use other software and what do you do? Then compared to SketchUp and how you use that?
-
@tt_su said:
A 4x increase would not be enough to make that operation fast.
Quite the opposite, a 4x increase would be amazing!
@jason_maranto said:
Look, if SketchUp is meant to be platform for other people to build on then it is a very poor platform that does not allows 3rd party developers the best tools to do thier work. 64-bit is simply a tool SketchUp (as a platform) should be providing to every 3rd party developer.
I often disagree with Jason, but he's got a point here.
-
- I have not seen one specific example of model presented showing the problem. I do not mean just the skp file, but all the other settings along with data on the target system showing RAM usage, processes running etc, what graphics, graphics memory and etc. There are many permutation and combinations that can contribute and until the problem is understood I am sure the developers feel they are in a undefined box.
- For the windows users there are many resources available but you have to be willing to take advantage of them. Many of these are same Microsoft uses in their resolution of problems.
- Those who think Trimble should have a nice road map of long range plans are not living in the real world, that info is usually closely help and you will not see any specific detail unless you are a level 2 manager or higher. Those many times will be in 3 to five year long range plans. Reading the base camp notes they have and the scan explorer, ruby begugger etc. release should give one some sense of what those are. With the statement they are staffing up the question in my mind is for what?
- For those rejecting off hand the thoughts John B and Andrew give makes one wonder why you are not working at MS or some other development company. They may not give the answer you want to hear but have the info base you should at least listen too. IMHO they are missing the boat not making better use of the employee badged folks showing on the forum to help answering some issues ,but that goes back to long range plan and man power use. IMHO I would think say a web type conference with a select user set often vs the 2 year base camp show and tell could help to establish what their long range plans should be or even what near term fixes are required.
-
@jiminy-billy-bob said:
Quite the opposite, a 4x increase would be amazing!
hmm.. not really. you'd adjust quickly..
as in, i used to do renders which would take 8 hrs.. nowadays, i can do the same in 2hrs with better hardware..
2 hour render is not 'amazing'.. waiting 2hrs for a render to complete or waiting 2 minutes for a judge_able preview still kinda sucks when you're in the middle of a project.amazing is real time rendering.
if an explode takes 1 minute today.. and 15 seconds tomorrow.. that 15 second explode is still going to be annoying and i won't be sitting there going "wow! this is fast!"
-
Warning! Irony ahead.
Sorry I just had to get it out of me so I made this quick drawing:[irony]
[/irony] -
@mac1 said:
- I have not seen one specific example of model presented showing the problem. I do not mean just the skp file, but all the other settings along with data on the target system showing RAM usage, processes running etc, what graphics, graphics memory and etc.
..and on and on..
look at it from the opposite side.. let's imagine sketchup was 64bit.. do you think anybody - user or developer - would be saying "oh geez.. i wish it were 32bit"
i.e.- an attempt at trying to differentiate between "going 64bit is a heckuva lot of work" vs "going 64bit will not help anything"
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.
i get it that i might be wrong about that assumption but maybe i'm too hard headed to truly believe it.. i really think they would all push the button.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 because if there were an easy way to switch to 64bit, none of those explanations would happen.. sketchup would be 64bit.
-
@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. 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.
Sure, this is nothing where 64bit would help, and as i said before making SU 64bit would not help very much without increasing the overall performance - when working with objects/geometry AND the display performance, but i think the opengl performance is the smaller problem. 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...And btw. x64 doesn't have to be neccessary slower i think. I have seen tests with very different results for different apps - some slower and some faster (sure, some maybe RAM related, so maybe they were faster because of more RAM).
But almost every other 3D and 2D app i'm using has done the move without noticable performance decreases (maybe 2-5%) - so, why should it be so dramatically for SU?!? To get a reasonable performance gain in SU it has to be increased maybe 10-100 times for some operations - what would be a decrease of 5% if the overall process is much faster?!?
Advertisement