Google is Listening!
-
@krisidious said:
64bit offers faster computing
Faster? 64bit can be slower. The data types are longer - takes more power to process. 64bit != Speed
-
@unknownuser said:
but still, what are you going to gain from more memory?
maybe export bigger 2d images or something?From pure SU use - mostly the export. But the main desire for 64bit SU would be because many people use render engines that run inside SU - and then you really do need. all the RAM you can get. But 64bit isn't a quick and easy thing to just slap on. And it might very well affect performance in a negative way. It's not a magic bullet - it has it cons.
There are however one thing that can help to some extent, which should not be a big deal to do - it's nearly free: LargeAddressAware application. If a 32bit application is LargeAddressAware it can address a full 4GB under 64bit OS. Double the amount available now.
http://msdn.microsoft.com/en-us/library/ee418798%28VS.85%29.aspx#The__LARGEADDRESSAWARE_flag@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. As explained earlier, enabling this flag for a build allows a 32-bit program to access more memory with special boot options on a 32-bit OS or on a 64-bit OS. 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.
Thirty-two-bit applications that are large-address-aware can determine at run time how much total virtual address space is available to them with the current OS configuration by calling GlobalMemoryStatusEx. The ullTotalVirtual result will range from 2147352576 bytes (2 GB) to 4294836224 bytes (4 GB). Values that are larger than 3221094400 (3 GB) can only be obtained on 64-bit editions of Windows. For example, if IncreaseUserVa has a value of 2560, the result is ullTotalVirtual with a value of 2684223488 bytes.
-
Added LargeAddressAware as an idea.
-
As I read between the lines here and there the main problem with SU is it's architecture showing it's age and limitations. Somewhere I read a SketchUP developer asking if we could wait year or two for rewriting SketchUp's code.
-
I do find this obsession with 64bit depressing.
64 bit general code can often run SLOWER than 32 bit because it has to pick up twice the amount of data so hurts your i-cache.
A lot of math in 32 bit applications is performed using 128 bit operands already (SSE / Altivec). No idea where people get the idea that 64 bit is 'faster' somehow - its a misunderstanding how stuff works I guess.
Like Jeff Hammond, I struggle to understand what workflow using SU requires 2 GB of memory. I'd say your workflow needs looking at.
And lastly, you're wrong to dismiss John Bacus's comment about 64 bit. He's simply nudging you to really engage about what you hope to achieve with 64 bit because from the comments above, most SU users don't understand what 64 bit actually means. They have wholly unrealistic expectations.
The big problem - I've seen this often in the past - is where people fall into the trap when asked for feature requests, by being proscriptive about their preferred solution. We should focus on things we'd like SketchUp to be able to do and not tell the Developers how they should be realised.
Having said all that, The Google SketchUp team are rubbish at providing any visibility of future roadmaps for SketchUp to help us understand where they think its going - and take us with them.
Adam
-
@adamb said:
Like Jeff Hammond, I struggle to understand what workflow using SU requires 2 GB of memory. I'd say your workflow needs looking at.
When you export really large 2d exports that memory usage easily run up to that point - nothing to do with the workflow. But that's about the only area where SU itself run into the memory issue. Mostly it's when using render engines that run inside SU's process.
-
@adamb said:
The big problem - I've seen this often in the past - is where people fall into the trap when asked for feature requests, by being proscriptive about their preferred solution. We should focus on things we'd like SketchUp to be able to do and not tell the Developers how they should be realised.
Yup - ditto. I read multi-core support as "increased performance". But people gets fixated on reading that it should have mulit-core support to be fast - so when performance increase is provided, such as in SU7.1 - it doesn't get full credit.
Best thing we (the users) can do is request the goal - then let the engineers work out the means. -
@thomthom said:
@adamb said:
Like Jeff Hammond, I struggle to understand what workflow using SU requires 2 GB of memory. I'd say your workflow needs looking at.
When you export really large 2d exports that memory usage easily run up to that point - nothing to do with the workflow. But that's about the only area where SU itself run into the memory issue. Mostly it's when using render engines that run inside SU's process.
I don't understand. 10000 pixel * 10000 pixel * RGBA is 400MBytes. You're doing images larger than this? Mad.
EDIT: OK perhaps not Mad. But surprising.
-
AdamB, I totally agree with you regarding the typical request for a compiled 64 bit version of SU. While I understand users preference for real time modeling, and rendering, until Intel finds a way to exceed the current limit on processor speed, it's not likely that those goals will be achieved. Even multi processor programing have limits bound by CPU speed.
All 64 bit programming provide for, is more memory addresses.
-
my requests.
move OBJ Import / Export to the Free Edition. since OBJ is the most common denominator for 3D interchange it makes more sense and will increase SU's usage all round. Collada is a bit of a joke.. while many programs write it.. you can count the amount that read it on both hands with at least 4 fingers left over.
Improved UV support.
better handling of high polygon models. there's a huge resource of human models in the poser world. we could be using them.. but just 1 human right now will bring SU to it's knees.
listen to the Ruby writers and give them what they want. they right now are SU's greatest asset.
-
Whatever the argument for it (multi-core or 64 bit) I'd like to see SU support and handle higher poly counts with better optimization. I can open something in Sculptris or Blender that consume a small percentage of memory, compared to SU which might consume 1-2 or even more GB of memory and be so slow as to become unusable.
Not all of us use SU for simple models like houses or buildings. It doesn't have to be Zbrush, but somewhere in-between would be nice to better model more organic shapes.
Ditto on the UVW support. Even without high-poly support, texturing and materials are one of my biggest points of frustration in SU.
That said, there's another wish-list floating around on the site, it's full of good ideas.
-
SketchUp is a 3D modeling program...
so why not add more modeling tools?
There are a lot of tools that can make it modeling more easy and fun...
For example:
http://forums.sketchucation.com/viewtopic.php?f=323&t=16909
or
http://forums.sketchucation.com/viewtopic.php?f=180&t=19321#p159451Animation is also something like I want to have inside SketchUp.
If this kind of things can´t be made in the native SketchUp tools because can break other things... why don´t you try to release tools as plugins?
Plugins are very important... so why not add some kind of plugin organizer?
I want to see evolution of tools too. In lot of SU tools there are small things that can make it Sketchup more powerfull. Why not add push/pull for edges?, push/pull for curved or smoothed surfaces, offset for curved or smoothed surfaces, use the scale tool for scaling edges....
My list is very long... but for SU9 I want to be surprised!
Daniel S
-
My opinions -
- Yes, the x64 is overrated. It has now become an 'oohhh ahhh' buzzword.
- The UI look hasn't changed - not even the startup icon. I know it does nothing to improve the speed. Marketing-wise, some people tend to purchase upgrades because of the snazzy new look.
- I think you should have paid some royalties to some of the more powerful ruby designers and incorporated some of their ideas into the SU. It is THEY who are keeping your program alive and exciting for me. Some of them are just genius and I cannot imagine NOT having their scripts included in my daily arsenal of tools.
- Last, but not least for me - you just can't take away features from the free version! It's just wrong. Perhaps by keeping them in and ENHANCING them in the paid version would entice users to upgrade to the paid version. I highly recommend the 'How to win friends and influence people' book.
As I said, I'm sticking with 7.1 free because (at a glance) it has more to offer me than 8.
Rick
-
If Google would listening we would not have this Version 8. It's a fake...not worth to respond
-
@gaieus said:
Hi Carolyn and welcome to SCF!
(Please, old members, easy with our new member, she has just joined the SU Team...)
-
yes I think it is always wise for a software company to stick with a design that will keep them being used in some kind of compatibility mode.
-
@unknownuser said:
@thomthom said:
Faster? 64bit can be slower. The data types are longer - takes more power to process. 64bit != Speed
True, but I always thought that when you have a 64 Bit chip the increase in speed is in fact there. I can imagine it's slower on 32 Bit hardware. I have a 64 Bit Intel in this machine I'm using now and it should run a 64 Bit SketchUp faster than a 32 Bit. Are you saying that would not be the case?
32-bit hardware is not capable of running 64bit. You must have 64bit hardware to run 64bit software. And yes - 64bit means more data which means more processing power required.
-
As for the comparisons of polycount handling in SU vs other applications - which other application provides a sketchy rendered view like SketchUp? All these applications SU are compared against does not provide a presentation quality viewport - they all require you to render. Max, Maya Blender etc - it's just shaded wireframes with lots of visual glitches that would not work as presentation output.
-
@adamb said:
I don't understand. 10000 pixel * 10000 pixel * RGBA is 400MBytes. You're doing images larger than this?
This is not possible on Windows as far as I know. My PC have 4GB ram and I can't export larger than some 4000px.
And THAT is not enough.Thomthom said it right. For me increased speed isn't what I expect from a 64bit version.
Its all a memory issue thing. Especially with third party renderers (like Vray).And Coen, thank you for stepping up and expressing what I and several other loyal SketchUp users feel about SU8.
Things like "Google is listening" and "Your wish is our demand" feels like a slap in the face.
I don't see any creativity and new thinking in the latest release.
It's more of a bug fix release that should have been free.
As I said in another post: What arguments should I tell my boss to get him to upgrade to v8?What I would wish for is some kind of discussion with the Google team about the future developments of SU.
Not just a wishlist. What do we (the users) need/want? What is possible? How can it be achieved?
Things like, Google team concentrating on the core and giving community developers even more access to enhance SketchUp in ways that cannot be done today. Or maybe going open source all together?
Or no further development for "professional users"...and then we know and can move on to other software. -
I find it interesting that SU8 was released during basecamp.
Would it not have made more sense to release it before so that people could have tried it and be able to discuss it with some experience at basecamp.
A more cynical person might suspect that it allowed basecamp to ignore the nuts and bolts of it and just get the Hype of a new release.
Advertisement