SketchUP 8
-
Hey John,
Just want to say thanks for replying to some of these questions. I personally find the fact that you have bothered to take the time to reply to us much more satisfying than any new sketchup features. The fact that the sketchup team is willing to openly converse with its users is a big thing I guess, and not something I was really expecting given its track record of versions in the past few years (which is why many complain). Now I can be put to rest and just accept that sketchup will probably never do some of the things I would like it to do, and I mean that in the best way possible. I can plan ahead and make sure that I have other tools on hand to fill the gaps around sketchup. There are of course many simple core problems in sketchup, that, I'm sure will get solved given enough time, but I'm no longer left in the dark half hoping that they will get fixed soon.Thanks
-
@cadmunkey said:
I guess what you are really saying is "tough luck, thats a render program problem, NOT a limitation of SU".
Kindof is... SU was designed as a sketching application. By the sound of it, more render apps are moving to studio solutions - to escape the 32bit limitation of SU.
The thing is, people as for more performance at the same time they demand 64bit. As it's been mentioned before, 64bit mean more data to process and can just as easily hurt performance.
However, I use render engines as well, I'd love to be able to use more memory, but I realise that 64bit is no magic bullet for SU it comes with its cons as well.
But I'm curious if SketchUp can be made LargeAddressAware, which would mean under 64bit OS it could address 4GB ram instead of 2. And it's just a compiler flag - pretty much free - without the overhead of 64bit processing.
http://msdn.microsoft.com/en-us/library/ee418798%28VS.85%29.aspx#The__LARGEADDRESSAWARE_flagWouldn't give you as much memory available as 64bit - but 4GB is a whole lot better than 2GB.
-
"No one will need more than 637 kb of memory for a personal computer." -Bill Gates, 1981
"64-bit processing will have no benefit" -John Bacus. 2010(sic!)
-
@jbacus said:
@unknownuser said:
@unknownuser said:
What benefit do you hope to gain from a 64-bit version of SketchUp? This is really the question that needs to be discussed.
Speed (particularly with plugin routines) and the ability to carry higher poly counts without considerable slowing. SU can't handle more than 1 high poly tree or car for architectural renderings.
64-bit processing will have no benefit to managing higher poly counts without considerably slowing. Performance in this area depends either on the capability of your GPU, or the clock speed of your CPU. Memory is not the bottleneck for these kinds of operations.
john
.From my experience, if you compare some well build 32-bit and 64-bit apps, that do load plenty of polygons to memory, there usually is no considerable slowdown, if poly count is the same. Increase poly count and then in some point 32-bit program will fail as it does runs out of memory and 64-bit will go on. Is it better to have a failed app or one that works in any scenario (even tiny bit slower)?
-
@thomthom said:
But I'm curious if SketchUp can be made LargeAddressAware, which would mean under 64bit OS it could address 4GB ram instead of 2. And it's just a compiler flag - pretty much free - without the overhead of 64bit processing.
http://msdn.microsoft.com/en-us/library/ee418798%28VS.85%29.aspx#The__LARGEADDRESSAWARE_flagWouldn't give you as much memory available as 64bit - but 4GB is a whole lot better than 2GB.
A good point, better than nothing.
-
@jbacus said:
I think if you were a part of our beta program, you'd find that we are similarly responsive there.
Hey, I have volunteered to be on your beta team several times via various groups (this one and the Google SketchUp one). My email address has not changed since then. And I do understand the NDA process completely and know the level of communication changes from the beta room to the open forums. I also know, that you cannot please everyone at the same time.
Rick
-
@d12dozr said:
John,
I should have been more clear, I meant rendering with a plugin inside Sketchup. I use Twilight, I understand Vray and other render programs have similar trouble. Depending on model size, trouble can start at 2000 px.Thanks for replying.
Photorealistic rendering operations surely benefit from 64-bit processing. Rendering plugins do not have to execute rendering operations inside SketchUp's 32-bit environment, and can be built to run in their own 64-bit environment outside of the main SketchUp process. I think many of the more popular ones are already doing this.
john
. -
@unknownuser said:
Personally I think a better fix, at least in the case of exporting images, would be to have the ability to determine the thickness of SU's linework. I find personally that because a line is always 1 pixel thick I end up having to export very large images even if (especially if) I don't need that much resolution. I'll end up exporting a very large image and then reducing the image size in photoshop. Other than this reason, I'm not sure why someone might need a SU image to export at more than 4,000 pixels (between poly counts being limited and texture resolution limits I can't imagine what benefit you'd get).
You should try rendering images in LayOut instead of SketchUp. Layout gives you the ability to change the line weight of the drawing prior to export so that you don't have the problem you're describing.
john
. -
@d12dozr said:
John,
I should have been more clear, I meant rendering with a plugin inside Sketchup. I use Twilight, I understand Vray and other render programs have similar trouble. Depending on model size, trouble can start at 2000 px.Thanks for replying.
It is certainly the case that photorealistic rendering benefits from a 64-bit environment and access to loads and loads of memory. Rendering plugins for SketchUp can be built either to run their rendering processes inside SketchUp's 32-bit environment or outside it in their own separate 64-bit environment. You might check you favorites to see how they work.
john
. -
John has entered an infinite loop? /me files a bug report on d12dozr's post. 
-
good morning John... bright and early and already answering the onslaught. I must say I commend your attention to the users questions and statements.
-
@thiago luz said:
John, a SIMPLE work I decided to use a bank that was a model of BB Italia ... the sketchup only took 18 HOURS to explode the bank ...
If it took 18 hours to explode your model, then it doesn't seem to me that it was very simple! 'Explode' operations are a good example of the sort of computation that benefits from a single fast processor core (not from multicore or from 64-bit).
john
. -
john,
thanks for taking the time to answer these. I am very appreciative of your support.
-
@cadmunkey said:
@jbacus said:
@cadmunkey said:
Jeez.. no 64 bit version in 2010? C'mon Google you've dropped the ball! You beta testers couldnt persuade them?
What benefit do you hope to gain from a 64-bit version of SketchUp? This is really this question that needs to be discussed.
john
.John I hope you are joking. Obviously more memory space and the ability to render out complex models.
I think I've already answered the question about rendering large models. Rendering engines, which do benefit from 64-bit processing, can be run today in their own 64-bit environment.
Performance is clearly important to all our users, but "64-bit" isn't really the technology that I'd bring to bear to improve SketchUp's performance next.
john
. -
@jbacus said:
If it took 18 hours to explode your model, then it doesn't seem to me that it was very simple! 'Explode' operations are a good example of the sort of computation that benefits from a single fast processor core (not from multicore or from 64-bit).
Explode is notorious slow though. So is adding entities when there is existing entities. If you do an iteration it'll take longer as it progresses. I'm guessing it's related to how SU merge entities together - which is why Explode slows down? (Say you have a 50K faces in a terrain.)
-
@jbacus said:
Performance is clearly important to all our users, but "64-bit" isn't really the technology that I'd bring to bear to improve SketchUp's performance next.
But could LargeAddressAware be an option? I'm using VfSU and it's not a studio render but it won't be for a long time.
Now, I'm not expecting that SU should address design issues by third parties, but since from teh description of it, LargeAddresAware is a compilation flag - it's pretty much free, then would this not be a nice boost?
Sorry for nag on this very topic, but I'm really curious if it'd be possible for SU. I've heard of people that's hacked the SU executable to enable this flag and was able to run it without any reported issues.
-
@thomthom said:
Kindof is... SU was designed as a sketching application. By the sound of it, more render apps are moving to studio solutions - to escape the 32bit limitation of SU.
Using Ruby, it is possible to access an engine running outside SketchUp's process while still maintaining UI inside the SketchUp application. It is not necessary to switch to a full 'studio' solution. There are several examples of rendering engines that do this successfully on the market today.
I'm not familiar with the "LargeAddressAware" flag in Visual Studio, but wouldn't expect it to be a panacea. Since this is a holiday weekend in the US, I'm not going to bother Tyler with this until Tuesday.
john
. -
@jbacus said:
I think I've already answered the question about rendering large models. Rendering engines, which do benefit from 64-bit processing, can be run today in their own 64-bit environment.
Performance is clearly important to all our users, but "64-bit" isn't really the technology that I'd bring to bear to improve SketchUp's performance next.
john
.If it is like you say so be it, but we still havent got the improvements to make SU work as we need, 64bit or not.
I think a lot of our "rage" is very much caused by Googles lack of communication with the community about these issues back when v7 was released and we voiced our concern that these issues weren't adressed in that release. We also filled that wishlist with our needs so I think you had all the time to come back to us for more information what we meant and didnt have to wait until now for that.
I think I can speak for a lot of people here, that we really though this time we would see some progress with these things. -
@jbacus said:
I'm not familiar with the "LargeAddressAware" flag in Visual Studio, but wouldn't expect it to be a panacea. Since this is a holiday weekend in the US, I'm not going to bother Tyler with this until Tuesday.
Oh no - no need rush with this right this second. It would just be nice if it could be looked into. It would have the benefit of not having to refit to 64bit system, or the performance hit of 64bit. As the MSDN article says:
@unknownuser said:
It is a good practice to specify large-address-aware when building 32-bit applications, by using the linker flag /LARGEADDRESSAWARE, even if the application is not intended for a 64-bit platform, because of the advantages that are gained at no cost.
Though, the caveat is:
@unknownuser said:
However, developers must be careful that pointer assumptions are not made, such as assuming that the high-bit is never set in a 32-bit pointer. In general, enabling the /LARGEADDRESSAWARE flag is a good practice.
So, from what I gather here is, that as long as SU doesn't make assumptions about the high-bit in it's pointers then this would mean 2 GB extra at virtually no labour at all. It'd be a nice bone to throw out there for all the cries for more memory.
-
@rv1974 said:
"No one will need more than 637 kb of memory for a personal computer." -Bill Gates, 1981
"64-bit processing will have no benefit" -John Bacus. 2010(sic!)
Be polite. I'm making a more complex point than you're giving me credit for making.
john
.
Advertisement