Google Sketchup Pro 7 is out
-
@stu said:
Woooo! If I can read between the lines....it looks like Richard is giving up MS Word as his prefered CAD app and moving on to Layout!!!
Mate, if anybody can make layout sing, it will be you .
LOL - Yes mate MS Word is out the window now! Though I'm probably haunting the Googies now! Posted about 40 feature requests and you know where I would have got the ideas!
Yeah I actually developed a way to get LO to give SU style output with a sketchy style! Funny thing is it actually really speeds up the designing / drawing process in layout! I'll post some output and a tut soon as I get a chance!
-
Yeah, I remember those FR's - no-one could follow their own ones because you overwhelmed the place so much!
Actually they are good ones
-
@richard said:
Yeah have to agree with you here Stinkie - I've just read post after post of Coen sticking up for so many downfalls to the point I've actually got a bit cranky!
Some people (me included) aren't at all happy with the shear lack of poly support in SU.
Will you marry me, Richard?
-
@numerobis said:
and 64bit support becomes quite useful if you try to export a model like this for rendering (or as dwg/3ds) and skp likes to crash at ~1.6gb ram usage...
so, is there a 64 bit manager for SU? or is there no love? any idea if it is coming?
forget 64 bit, how about utilizing all 8 of my processors. too often SU hangs cause it is only using a single processor. multiprocessor is not the future, its the present. this baby needs to rock all 8 of these bad boys!!
anyone know anything about improving the management of each?
-
There is no love, Bmccall.
Unfortunately, Google chooses to ignore it. -
@kwistenbiebel said:
There is no love, Bmccall.
Unfortunately, Google chooses to ignore it.grrrr!!!!!
-
How on earth did I miss this thread for so long? Lots of my favourite topics - high poly support, shadow bug, DCs, multi-core, future direction of SketchUp etc.. Sure it is littered with Coen's habitual weak attempts at justifying the limitations and missed opportunities but hey, there is always a downside.
My 0.2c worth -
-
Multi-core support has been dealt with before. It won't help SketchUp because it relies on the program being able to divide a task into a series of distinct parts. There are actually few things that the application does which rely on heavy processing of a single task. For Ruby and things like sandbox activities - sure. For general modelling - no, not really. It will not help with smooth orbiting and navigation of large/complex models. John Bacus's interview, referred to elsewhere on the forum - too lazy to find the link) was quite succinct in this regard. It isn't possible to predict every possible course of action and calculate and cache it. Yes it is the future, but it the application doesn't lend itself to the technology, there is no point.
-
Shadow bug - we know about the legal stuff, but the fact is that Google has some spectacularly clever people, (and they have been let loose on Layout now apparently
) and other applications, produced by companies with a lot less money, seem to manage without the problem. So, go figure. -
High poly support - it really intrigues me how some people just don't get this. So, for Coen and others, I'll try to express it simply:-
We-want-to-be-able-to-manipulate-complex-shaded-models-with-edges-and-textures-and-working-shadows-smoothly-and-quickly-without-a supercomputer. -
DCs - these are really fabulously cool things. Sure at the moment there aren't enough around but more are being produced all the time for download. I suspect in time they will be one of the things that you really rely on all the time.
-
Stability and new features - some good stuff, but not enough. The newest version is too slow, too unstable and doesn't contain enough new stuff to get us really excited. The new inferencing is just too slow when orbiting. Suppose I want to draw a line from one part of a complex model to another, rotating the scene when zoomed out takes an age, because SU keeps trying to snap to every point under the cursor, when all I want to do is orbit. Why can't we turn this off temporarily? It isn't always convenient to switch to the selection tool when orbiting. I'm going to try LayOut again and I'll try not to swear a lot this time, but really this and DCs seem almost to be distinctly separate applications. Okay DCs are integrated, but are almost like a (great) plugin.
Unlike lots of people, I do think that Google care, and I do think that the problems will be fixed. I also think it is important to try to stay positive about the application. there are some great, talented people there, and they post help here from time to time. SketchUp hasn't suddenly become a bad product overnight, but there is a widening gap between expectations and reality. We need to keep things in perspective IMO.
I think one of our niggles is the whole concept of 'Google-time'. Progress is too slow for such a huge and wealthy company with so many really clever people. I think we have to accept this as part of the company that gives us the application we love for free.
If you want to see contempt for customers and 'no love' in action, you should try AutoDesk or to a lesser extent, Nemetschek.
-
-
@bigstick said:
- Multi-core support has been dealt with before. It won't help SketchUp because it relies on the program being able to divide a task into a series of distinct parts. There are actually few things that the application does which rely on heavy processing of a single task. For Ruby and things like sandbox activities - sure. For general modelling - no, not really. It will not help with smooth orbiting and navigation of large/complex models. John Bacus's interview, referred to elsewhere on the forum - too lazy to find the link) was quite succinct in this regard. It isn't possible to predict every possible course of action and calculate and cache it. Yes it is the future, but it the application doesn't lend itself to the technology, there is no point.
Can anyone who believes this explain it to me in layman's terms? I've fairly computer savy and have read the interview mentioned but it just doesn't make sense to me. When you orbit around a model with a lot of polygons, for example, you're likely to encounter some bogginess. So if SU isn't using even 100% of 1 processor then what's slowing it down? And if SU IS using every bit of 1 processor then why wouldn't it benefit from having even more processor speed to grab onto?
-Brodie
-
If you want to make use of multiple cores you need to be able to split your program up in to multiple 'threads', with each thread running on a different core.
Each thread needs to be able to run independently of every other thread but still contribute to the final task that needs to be achieved.
Because of the real time nature of rendering in SU (i.e. making the model appear on the screen) it isnt possible to split the process up in to threads, and so the rendering engine cant utilise multiple cores.
Thats my understanding of it, anyway.
-
Yup, that's true. It's not that easy to "just add more cores". It's a very distinct posibility to end up with a deadlock.
But! They could make the UI more independant so it doesn't stop updating when rubies are doing heavy tasks.
-
Yeah, that would be very cool, nothing more frustrating than the white screen of doom popping up for half an hour.
-
I think turning off the inference engine temporarily (or seletively) could be the way to go. Imagine that you can Orbit or change Scenes with inferencing off (in these two particular cases it is very unlikely that you'd like to snap to anything on the fly anyway).
Also,similar to locked entities, there could be a "mode" where you turn off inferencing of some entities (particularly high poly entourage for instance).
Selectively turning off inferencing is a continuous wish by many anyway. Imagine when you are trying to trace around an irregular, 2D shpe (like a person's body). All you need there is "On face" inferencing (and maybe locking).
-
Correct me if I am wrong but surely exporting animation and images could use more than one core?
-
Probably, although id guess it isnt quite as simple as 'adding another core.'
-
Whether it is by implementing multicore support, 64 bit, Gpu accelleration or any other technique....Fact is that Sketchup needs a speed boost by a serious clean up of its code.
We are only speculating on possible solutions.
It is up to Google to find a suitable way.
But from seeing what they have done from the moment they bought Sketchup up until now, I have serious doubts they are even capable of doing it.The Sketchup core (engine?) itself seems untouched all that time.
With recession kicking in, I doubt that the development of Sketchup will be getting much attention the next months or even years. -
Only time will tell.
-
@remus said:
Only time will tell.
In a fast moving CG market, there is no waiting around.
Go talk to people working in any medium/large sized architecture firm, and they are struggling with the same hassles when trying to implement Su in a serious workflow.
The lack of communication on Googles behalf and ignoring specific needs might result in the Pro version becoming obsolete. -
come on Google! you can do it!
even the Microsoft guys finally made Vista fast, responsive and reliable (with Windows 7) -
@unknownuser said:
@unknownuser said:
Now people will turm more and more away to other programs, even to bonzai,
Vaporware.
Gentlemen,
We are pleased to announce that bonzai3d Beta has now been released. You can take it for a test drive by clicking on Get Beta from the upper right corner of the bonzai3d web site:
Enjoy!
bonzai3d support
-
@bonzai3d support said:
@unknownuser said:
@unknownuser said:
Now people will turm more and more away to other programs, even to bonzai,
Vaporware.
Gentlemen,
We are pleased to announce that bonzai3d Beta has now been released. You can take it for a test drive by clicking on Get Beta from the upper right corner of the bonzai3d web site:
Enjoy!
bonzai3d support
Neat'o! Downloading...
Advertisement