[POLL]: If SU 7 will not have multicore/high poly support
-
And some more arguments for having High poly support /multicore / 64 bit in response to Coens post:
RENDER ENGINES!Currently, most render engines are crippled at export phase because of SU limits (a maximum of 3Gb RAM supported, not large adress aware, no 64 bit, export within the same SU process (=not multicore support).
Some render egines cost 1000 dollar and would definitely benefit from a better SU core code.
SU is not a standalone piece of software anymore , it is a 'platform' for 3td party software as well.
And YES, Su needs to adress this!@Coen: enough reasons here to have a better SU.
I can't understand why you would not support this as a wish. -
I love sketchup!!
I also love looking back to the time on my Commodore 64, but guess what, later I bought a Commodore Amiga.
If software/hardware arn't updated/developed it's just a matter of time before it's history!
Google is a large company fighting to gain marked, and I'm sure they didn't buy Sketchup just to let it die.
-
I can't understand Coen's defensiveness. If you aren't moving forward, in effect you are moving backward.
I agree with kwistenbiebel, yes I use the tricks, but using components means it is easy to add a huge amounts of detail to a model. When you have models which have lots of components of say, furniture with lots of curved forms (even tubular chairs for example) SU can get very slow indeed. When you work up the detail level internally and externally, add trees, some cars etc, your model gets really slow.I'm afraid I just don't buy the argument that SketchUp was only intended for modelling simple sketchy scenes. The program liberated us all from complicated tedious modelling packages and multiple 2d views, and we all loved it. Then when enough people get competent enough to fully exploit the software and ask for more, the response is,"Well you are pushing it beyond what it was intended to do".
The things that are being requested are natural extensions to the program's capabilities. Seriously, obviously it's achievable. Max, Lightwave, Rhino, MoI and C4D can do it, why can't SU? I have mentioned elsewhere that Google employs some of the best and brightest people in the industry (and some others that are responsible for LayOut
) and this is what we reasonably ought to expect from one of the most powerful software companies in the world. There ought to be almost nothing they can't do.I think it is fair to say that SU raised the bar for everyone, and if it doesn't keep making good progress, it is going to lose users as the opposition (driven by commercial pressures) gets smarter and delivers what the market demands.
I see nothing wrong with the voting options, and for people to think of leaving if development doesn't offer enough progress.
I think it is sometimes easy to overlook the fact that we are here because we love SketchUp and want more from it. It will be a really sad day for me if I have to start using something else. I never had so much fun in my work before SketchUp came along, and it is a real joy to use - mostly. I'm not ready to jump ship yet, but the opposition is catching up, and I can see a scenario where I start to use another modeller.There is nothing wrong with prodding Google to focus their attention from time to time
-
Hear, hear.
-
SU may not have been intended as a low poly modeller. But the userbase would like it to be in increasing number. (that the impression I get from this forum anyway.) And it's on top of nearly any SU wishlist y ou find on the net. So it would make sense for the SU team to improve on this matter. They said it them sef in their blogs, people are using SU for things they never imagined. The users are evolving, why shouldn't SU?
Apart from being able to handle higher polycount, I think ruby script optimization would be a great benefit as well. REcently, Javascript has gotten great optimizations in browsers. Seeing something similar in Ruby would be a big plus. (If it is at all possible, I know that interpreted scripts aren't as fast as compiled programmes.)
-
SU high poly / 64 bit support has been on a lot of people's list of things they want for a while now. It'll be sad if it is not implemented.
Let's put it another way. If SU doesn't get high poly /64 bit support soon, dear Santa Clause will get his ass kicked six-love six-love six-love by quite a few people come Christmas. So, unless Google want to be responsible for a really bad Christmas and no Santa, they better deliver... Think of all the children people, do it for them!
-
maybe google is waiting for someone who writes a ruby to support 64bit... and multicore of course
-
@numerobis said:
maybe google is waiting for someone who writes a ruby to support 64bit... and multicore of course
Ruby is something 'on top' of the software as I understand.
Making a 64 bit version, multicore optimisation and adding Large Adres Awareness, are all things that need to be implemented in the core code itself , i.e C++ or whatever the code language used.As a note: A 3td party developer for Sketchup told me a while ago that implementing 'large adress awareness' is just a matter of adding a few code lines. This 'feature' is very useful to avoid crashes of big SU scenes at the export phase towards render engines.
-
With all the rubys we only need a small code without any functions but our rubys.
-
@unknownuser said:
A 3rd party developer for Sketchup told me a while ago that implementing 'large adress awareness' is just a matter of adding a few code lines
Really?If that is indeed the case then I insist it be implemented, hold on ... I DEMAND it! (please)
-
@kwistenbiebel said:
@numerobis said:
maybe google is waiting for someone who writes a ruby to support 64bit... and multicore of course
Ruby is something 'on top' of the software as I understand.
Making a 64 bit version, multicore optimisation and adding Large Adres Awareness, are all things that need to be implemented in the core code itself , i.e C++ or whatever the code language used. -
@solo said:
@unknownuser said:
A 3rd party developer for Sketchup told me a while ago that implementing 'large adress awareness' is just a matter of adding a few code lines
Really?If that is indeed the case then I insist it be implemented, hold on ... I DEMAND it! (please)
Some more info from MS: http://www.microsoft.com/whdc/system/platform/server/PAE/PAEmem.mspx
-
Hey, from that link I posted:
@unknownuser said:
To set this bit, you must use Microsoft Visual Studio Version 6.0 or later and the Editbin.exe utility, which has the ability to modify the image header (/LARGEADDRESSAWARE) flag. For more information on setting this flag, see the Microsoft Visual Studio documentation.
Some manufacturers preconfigure their applications to use application memory tuning, making it unnecessary for you to make this change. For more information, see your application documentation and contact your application vendor to determine whether they support Large Address Awareness or whether you can enable it in their application.
Looks like we can set this flag our self. I have Visual Studio Express installed on my home computer, so I maybe I have that utility. It could be that it only comes with the non-free version of VS. I'm unable to check this out until I get home. Anyone else here in the position to check this out?
-
Ok, further digging confirms what I thought. Here's a howto that applies to poser. http://www.keindesign.de/stefan/poser/3gb.html
-
64bit XP/Vista would not need the large address aware flag as it can handle much more memory. It's 32bit Windows that makes use of it.
I wasn't aware that Vista was different from XP. Can't say anything on that. I'd have to look up that.
-
Interesting Thomas,
One would think that if it works for Poser, a similar way could be found for sketchup.
But what about Vista (and its 64 bit versions)?.
Vista has the 3B switch 'on' by default, but in a global way, not per application...
I am not having the impression that SU is large adress aware in Vista neither (=I experience the same crashes as I used to have using XP 32 bit when exporting large SU files to a render engine).
Advertisement