Google is Listening!
-
64bit offers faster computing of scientific formulas, increased memory up to some 62 gigs depending on your setup... what's more it's what most all new systems will be from now on, it's simply staying with the times. and of course I would expect multi thread support as well...
-
@unknownuser said:
i dunno, export your stuff on a mac if it's that important to you.. you'll get twice the size.
Maybe if I was a one man show but I work for a company that has strict rules for software and hardware. Mac is not allowed.
@unknownuser said:
but i'm not really buying into it.. seriously, why on earth do i need something bigger than 10,000 px wide jpg?
there are much more important things to focus on.I can very rarely export images wider than 4000 pixels. On a lucky day I might be able to get it up to 4300px. That isn't enough for our needs.
-
@krisidious said:
64bit offers faster computing of scientific formulas,
like booleans for instance?
or algorithms for the upcoming generative modeling plugin? (or some of the existing plugins needing mad calculations?)if that's true, then yeah.. 64bit sounds worth fighting for.. but then again, i don't understand why j.b. would say that.. (well unless he was being genuine in his question)
-
A real honest to goodness Linux Sketchup. I mean, why insist that we run it in Wine when usability is severely hampered. Please?
-
Hi Jan,
To my understanding, the biggest obstacle of running SU under Linux is the lack of proper video drivers supporting full OpenGL for SU. That is; it would be not mainly a SU limitation but rather Linux' fault to support the video cards' full hardware potentials.
-
@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...)
Advertisement