[POLL]: If SU 7 will not have multicore/high poly support
-
Hm.I made this model using an old machine with a 2.7 GHz CPU,a 256 Mb Ati Radeon x550 video card and 512 Mb memory. More than 1.2 million edges and 300.000 faces
and I can navigate, orbit and what not in it with a laptop with 3.8 GHz CPU, a 256 Mb Nvidia 6800 video card and 2 Gb memory with no problem.Certainly I used a lot of "tricks" (like hidden layers and such) while modeling but by adding scenes in my workflow it wasn't a pain really.
-
A lot of tricks is not really 3D for everyone
-
Well, each program has its learning curve and once somebody gets to the point that he/she wants to assemble such big models with lots of edges/faces, should already be aware these basic "tricks".
To model my house by making a simple box then texturing it with photos and uploading it to GE does not really need high poly support.
Nevertheless I admit that it would be nice and easier if SU could support higher poly count so don't think everybody that I am against it!
-
Beware of it.
To make some sense of Google explanations I sometimes would like to see more correlation with the userbase
btw. 3D for everyone doesn't contain only simple textured squares for GE. my2cent -
I think there is - however the current Google software development policy (more exactly the non-disclosure of details) does not let them leak info about the directions of things.
Also they seem to have been busy lately
-
@Kwist: Read between the lines. If 2 the closest to dev camp guys ~1-3(?) month before v7 say "basically everything is ok- just turn off profiles,SU is meant to be lo-poly modeller"- this is a bad indication. Passover to cinema if hi-poly support is the key stone. What smily to drop here?
P.S. I'd be glad to be wrong though- SU speed outweigh (meanwhile) all it's issues -
@gaieus said:
To model my house by making a simple box then texturing it with photos and uploading it to GE does not really need high poly support.
...yes, this seems to be the point! ...unfortunately
i was afraid that this progress would happen as google bought it.
hopefully, there will be alternatives to sketchup in the near future - like bonzai...btw: 50000 skp faces - maybe 500000 polys is NOTHING when you get into archviz
kwistenbiebel has said it: load only ONE bigger tree (maybe 200 - 300k) into sketchup and it's nearly dead. only importing this tree will take minutes! and then compare this with importing the same tree in max...
...and i've turned off everything i can in the settings
-
@rv1974 said:
@Kwist: Read between the lines. If 2 the closest to dev camp guys ~1-3(?) month before v7 say "basically everything is ok- just turn off profiles,SU is meant to be lo-poly modeller"- this is a bad indication. Passover to cinema if hi-poly support is the key stone. What smily to drop here?
P.S. I'd be glad to be wrong though- SU speed outweigh (meanwhile) all it's issuesI know....There is no indication that SU will adapt to the current hardware standards.
That's why I voted option 3, while I would really like to vote 2.And in my personal view, yes, we need to speak up for what we wish for.
Who else will do it if we don't. -
i will still use it as modeller for my architectural vizualization. on the other hand im already looking on max and vray combo. because im doing mostly interior and exterior it seems to me that the alternative of exporting my shell sketchup model (without trees,plants,accessories for interior) but already with su materials. exporing 3ds wiht the option of not loosing the coordinates seems a very good workflow, then will do the max and vray render. at the moment its just a plan.
-
I don't think anyone here truly wants to leave SU as our core modeler. In reality, I think we all just want to see the fulfillment of true potential. It's time for a blossoming evolution of inevitable development.
The "people" have been working diligently to modify the go kart into a competitive race car. As we pull the race car up to the starting line, all the other "big name" cars look over and snicker. We'll show them! As the checkered flag drops, our beloved "hell on wheels" leaves all competitors in the dust. The fastest of the fast! Our machine is made for speed.....streamlined and efficient. We are lapping the competition. Going into the turn on lap 7 of 50...we start to loose speed. Slower and slower she gets, until she grinds to an abrupt halt. And there she sits. Out of gas. Out-matched, out-classed and humiliated. One day we'll beat these guys.......one day.
-
@earthmover said:
I don't think anyone here truly wants to leave SU as our core modeler. In reality, I think we all just want to see the fulfillment of true potential. It's time for a blossoming evolution of inevitable development.
The "people" have been working diligently to modify the go kart into a competitive race car. As we pull the race car up to the starting line, all the other "big name" cars look over and snicker. We'll show them! As the checkered flag drops, our beloved "hell on wheels" leaves all competitors in the dust. The fastest of the fast! Our machine is made for speed.....streamlined and efficient. We are lapping the competition. Going into the turn on lap 7 of 50...we start to loose speed. Slower and slower she gets, until she grinds to an abrupt halt. And there she sits. Out of gas. Out-matched, out-classed and humiliated. One day we'll beat these guys.......one day.
I couldnt have put it better myself.
-
@kwistenbiebel said:
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!Precisely, otherwise it'll soon be nothing more than a bottleneck in people's workflow.
-
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.
Advertisement