SketchUP 8
-
@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
. -
@pixero said:
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 we got all the information we needed. I've been pretty transparent about the Product Ideas series, and have answered many of the posts there over the last few months– either right in the series (see "Answered Questions") or in the official SketchUp Help Forums. And as I've said elsewhere in this thread, I think we knocked off a respectable number of the top requests in SU8.
If the pressing issues that you feel we should have addressed in SU8 didn't rise to the top of the voting in our series last fall, it could be that they are simply not as important to everyone as you think they should be. We had over 12,000 votes by the end of the series, so I think we got a pretty good sample. You can review the final series to see where your ideas fell if you like: 2009 SketchUp Product Ideas
Don't let your feelings about how this went last time prevent you from participating this time. We've already got over 2000 votes on 120 topics, and we're less than a week into the voting. Head over to the 2010 SketchUp Questions and Ideas Series and make your voice heard.
john
. -
my extracted plugins are all working but i can not see them on the plugins folder..
anyone knows how to be able to see them? i want to delete some installed plugins.
-
@onesimo said:
my extracted plugins are all working but i can not see them on the plugins folder..
anyone knows how to be able to see them? i want to delete some installed plugins.
It'd be better if you asked this question in a separate thread.
Advertisement