Trimble & Sketchup 64 bit
-
I have sat through a whole bunch of discussion on this. Especially at Basecamp 2010, where John Bacus spent a whole bunch of time going through this and then answering questions.
After this, I am not so convinced that 64 bit will speed things up.
John links a discussion on the Google groups in this posthttp://sketchucation.com/forums/viewtopic.php?p=297663#p297663
The other draw back that I have heard discussed, is that there is no mechanism to develop Ruby scripts in 64 bit for SketchUp, but perhaps one of the Ruby Gurus can jump in on this. -
Thanks for the comments guys... a little more background on my frustration, to add fuel to the fire:
I run Sketchup on my little personal netbook flawlessly. (Acer Aspire with a Core II Solo... don't remember the rest of the specs but I don't think I have more than 2GB RAM.) It's a decently zippy proc for the size, and is obviously just one core... so fits SU's parameters perfectly.
I recently had my work machine upgraded to support the 64 bit version of AutoCAD 2013. So now I'm running a Dell Precision T1600 with Intel Xeon E31245 @3.3GHz with 8GB RAM. VAST improvements in system performance with aCAD and all other programs.
Except Sketchup.
Which I can't get to run in a usable form at all. Not only is it slow and jaggy, but anything more than a minute of use makes it crash. I wish my IT guys had done a little more research and let me know that one of my 2 most used programs was not going to run on my new machine, alas they didn't, and I'm stuck trying to figure out the rest. Changing video card settings doesn't hack it. Running virtual PC in XP mode seems to ease some of the crashing issues (though not all) and it won't run for more than a few minutes without bogging down and becoming so unresponsive I can't use the program at all.
I'd imagine there are vast quantities of other users out there in the same situation. The majority of the other programs we use REQUIRE new systems with multiple proc's and huge quantities of RAM. Sketchup has done a great job of making our industry (and the design industry at large) highly dependent on their product, however our new computer systems are rendering their software obsolete.
I understand why Google wouldn't keep dumping resources into developing the software if they were looking to sell. SO. I'm hoping now that Trimble has purchased it, they will keep it moving forward.
Bottom line: SU may not NEED to use multiple proc's, etc. etc. in order to run better. However, our systems NEED to be robust for other software we NEED to run. SU is going to have to figure out a way to run flawlessly on these systems or we just won't NEED SU anymore.
-
@unknownuser said:
Sketchup needs a new engine with graphics cards support (multiple), multi cpu core support (at least 8 core) with at least 8 channel 64gb ram support, a hq rendering component and 3d scanning support,
This is an old topic, please inform yourself. In short, not all softwares can be made multi-core (no 3d modeller is multicore). RAM is not a limit of most actions in SketchUp, but speed. Some other applications are even purposely made 32bit to gain speed over 64bit, and it's best if we tell the SketchUp developers that we want speed, and let them figure out how to technically achieve this goal.
Ruby is an interpreted language, so the hardware architecture does not matter for scripts/plugins. Nevertheless the Ruby interpreter (that SketchUp ships) can be compiled for different architectures (Intel 32bit/64bit, ARM, PowerPC...).
@unknownuser said:
...has not been seemingly addressed in the interum 3 years
I remember the last 6 years SketchUp belonged to Google. I also remember that the new owner "Trimble" wants to turn it into its core program (SketchUp as a platform) and is hiring developers as never before.
-
@aerilius said:
In short, not all softwares can be made multi-core (no 3d modeller is multicore).
i think they will have to be made supporting multicore in the future since this will be the way processor power will evolve... i seems that there will be no real speed gains in the near future for single thread performance
-
"This is an old topic, please inform yourself." Aerilius
This seems a little disingenuous, perhaps spawned from a noble attempt to in some way defend the developers, though to cast dispersions on another as a defence would seem to water down that nobility considerably.
Sketchup does not run in isolation, as the virtual world moves forward one has the right to hope that each part of their solution will move forward with it and just as importantly - to voice their concern when it doesn't. I did do my homework, not only here but in the other place, the mainstream Google forum - though even if I hadn't that should not render any Sketchup user mute.
From my reading at least, the same concerns are shared by many, moreover there are also those with contemporary hardware purchased as a result of the demands of their other software finding difficulty running Sketchup fluidly. That's a concern for any office that includes Sketchup as part of their solution.
Sketchup as an anachronism will benefit no one, moreover it will remove the most intuitive design tool available from the design scene without the prospect of a mature alternative for some time. Not good.
Further, the design phase usually involves a concept and sometimes some mild construction drawing giving direction as to the likely direction for tricky documentation - layout is a good mechanism for the latter. The glaring omission from Sketchup's package is a means of fluidly rendering the concept at world standard to communicate the concept professionally - that will likely call for a 64bit render engine with the full power of current technology.
In summary then, although most Sketchup users would find an inbuilt plugin organizer a quantum leap forward, it is likely to be of little long term consequence if Sketchup doesn't keep abreast with changing technology.
-
What do you expect from 64bit SketchUp? All it would do is allow more memory to be used.
And so far - even with the largest model I have never ever experienced SketchUp to run out of memory. (The only exception has been when using V-Ray for SketchUp - but that's an issue that belongs to V-Ray for SketchUp because they do the rendering within the SketchUp process instead of hosting their own.)A lot of people think that 64bit will make applications go faster - which just isn't the case. It can in fact become slower - because the data is now double the size. It's far from a magic bullet.
Instead of fixating on a technical implementation, it's better to ask for the ultimate goal: better performance. There are many many ways to achieve better performance and the developers who has the knowledge of the SketchUp core knows best how to do that.
-
@numerobis said:
@aerilius said:
In short, not all softwares can be made multi-core (no 3d modeller is multicore).
i think they will have to be made supporting multicore in the future since this will be the way processor power will evolve... i seems that there will be no real speed gains in the near future for single thread performance
The modelling software out there that promotes themselves to have multi-core support generally all have mulitcore support in the render engine. The modelling engine will generally be single-core - like SketchUp.
-
-
@numerobis said:
@thomthom said:
The modelling engine will generally be single-core - like SketchUp.
for now... yes
I wouldn't hold my breath for this to change. Some, lots actually, processes simply cannot be split up and done in parallel and have to be done linearly. It's a logical problem that cannot be solved by throwing more processors at it. Like 64bit, mulit-core isn't a magic bullet and there are other ways to gain performance.
-
@thomthom said:
Instead of fixating on a technical implementation, it's better to ask for the ultimate goal: better performance. There are many many ways to achieve better performance and the developers who has the knowledge of the SketchUp core knows best how to do that.
OK, these are the "core" things I would like:
I want render engines to be able to work inside SketchUp in 64bit mode.
I want to be able to open and work with polygon heavy scenes that make SU stall for up to 30 minutes just by opening them or bugsplat or mysteriously make soft/smooth edges hard.
I don't want SU to crash when exploding polygon heavy groups. -
@pixero said:
I want render engines to be able to work inside SketchUp in 64bit mode.
Why not ask the render engines to sort this out them selves? By spawning their own process - instead of twiddling their thumbs and waiting for SketchUp to do the work for them?
@pixero said:
I want to be able to open and work with polygon heavy scenes that make SU stall for up to 30 minutes just by opening them or bugsplat or mysteriously make soft/smooth edges hard.
I don't want SU to crash when exploding polygon heavy groups.This is the kind of requests that makes more sense. The development team can address this more directly when we tell them exactly where the pain lies.
Explode is one of them things that's incredible slow - I also which this could be improved. -
@thomthom said:
Why not ask the render engines to sort this out them selves? By spawning their own process - instead of twiddling their thumbs and waiting for SketchUp to do the work for them?
I was under the impression that the host application (SU) had to be 64 bit to be able to run a 64 bit renderer inside?
Does this mean Vray or Thea could run in 64bit mode inside a 32bit SU?
In that case horray! -
@pixero said:
@thomthom said:
Why not ask the render engines to sort this out them selves? By spawning their own process - instead of twiddling their thumbs and waiting for SketchUp to do the work for them?
I was under the impression that the host application (SU) had to be 64 bit to be able to run a 64 bit renderer inside?
Does this mean Vray or Thea could run in 64bit mode inside a 32bit SU?
In that case horray!No - not inside - but they can spawn their own 64bit process which they send the data to - while their UI reside within SketchUp. Thea already does that in a way - it sends the model data to their own studio solution which is 64bit.
-
In that case I still want to be able to run a 64bit renderer inside SU.
-
@pixero said:
@thomthom said:
Instead of fixating on a technical implementation, it's better to ask for the ultimate goal: better performance. There are many many ways to achieve better performance and the developers who has the knowledge of the SketchUp core knows best how to do that.
OK, these are the "core" things I would like:
I want render engines to be able to work inside SketchUp in 64bit mode.
I want to be able to open and work with polygon heavy scenes that make SU stall for up to 30 minutes just by opening them or bugsplat or mysteriously make soft/smooth edges hard.
I don't want SU to crash when exploding polygon heavy groups.
-
@pixero said:
In that case I still want to be able to run a 64bit renderer inside SU.
I assume you want to use the UI for a render within SketchUp - and that is possible. It's just that "under the hood" the render engine sends the data form the model to an external 64bit process - which is perfectly possible now. It's a matter of how they design the application. But this just illustrates how requesting technical features which one assumes will solve the actual problem just becomes confusing.
-
@thomthom said:
I assume you want to use the UI for a render within SketchUp - and that is possible. It's just that "under the hood" the render engine sends the data form the model to an external 64bit process - which is perfectly possible now.
Well, take VRay for an example. When I still was using it (v1.49.01) I often had problems rendering "heavy" scenes in high resolution (5000 to 6000 pixels wide) which often ended in a crash or just simply refused to save the image when rendering finished.
Had to use workarounds with Vray image files which made the preview of the render in progress not work.
My belief is that that was caused by it beeing 32bit? -
@pixero said:
My belief is that that was caused by it beeing 32bit?
Yes, but that's a design issue of V-Ray for SketchUp because they designed their application to fully run inside SketchUp. That is the responsibility of V-Ray for SketchUp - not for SketchUp itself. Nothing prevents VfSU developers from spawning their own 64bit process and use that.
Their application needs 64bit - in which they are the one responsible to design their application to be able to do so. You cannot expect SketchUp to do the work for every extension developer. -
I do not believe Vray has a studio build/ stand alone version which may be the reason it's limited to 32 bit, on the other hand Thea does have a studio version 64 bit that can be used in the way Thomthom was mentioning.
-
@solo said:
I do not believe Vray has a studio build
http://www.evermotion.org/modelshop/show_product/v-ray-standalone/2703/0/0/
@solo said:
stand alone version which may be the reason it's limited to 32 bit
V-Ray exist in 64bit version. V-Ray for SketchUp does not because their current design is to run fully inside the SketchUp process.
Advertisement