Google Sketchup Pro 7 is out
-
I also think it is not insignificant that all of the tutorials on SCF that deal with animation...be it via hidden layers, travelling sections or Face Me components (some of those tuts by me) are all now totally redundant...at least for Pro Users. You can now animate directly with DCs...either along a simple vector, or by following a (hidden) path.
-
I wouldnt say that alan, for some things doing it the old fashioned way would be faster than all this fancy new DC stuff.
-
Scott, you wont be able to do a direct comparison though, because SU has inferencing which you cant turn off.
For a proof of sorts have a look at the file below, 1.7 million polys and orbitable
Problem is all the edges are welded and hidden, so not really practical for day to day use.
-
@remus said:
I wouldnt say that alan, for some things doing it the old fashioned way would be faster than all this fancy new DC stuff.
Not if you can simply pull a DC off the shelf (or FF or the 3DW or here) which is what many people will do. There will soon be scores of ready-animated doors, windows and vehicles.
-
@whaat said:
@remus said:
Unless im mistaken, DCs arent ruby, theyre straight SU.
I think you're mistaken. Strange that they would use Ruby for this one. Oh well...
After a bit of initial disappointment, I am starting to get more excited about the new features of SU7. I think dynamic components will make things interesting. There's lots of potential there. I hope we'll get a detailed list of Ruby changes soon.Hearing you say that gets everyone much more excited I think!
-
@unknownuser said:
Just a bit of clarification.
@unknownuser said:
@unknownuser said:
- handle high poly count.
One of SketchUp's lead developers, John Bacus, has actually asked users at Basecamp exactly what this means. High poly support when orbiting, when modeling, with or without inference.
You see everybody whining about this feature but no one comes with any specifics and when they are asked for them no one replies. So by all means, SPECIFY what you mean with high poly support.... huh? Coen doesn't know what we mean if we 'whine' about high poly support?
@unknownuser said:
@unknownuser said:
Every other modeler worth its weight is handling millions and millions of poly's and maybe choking, not SU........it chokes on hundreds of thousands! Come on!
Yes Scott, but the fact of the matter is that those applications don't support inferencing and/or not in such a superb way.
If I turn off Edges and Profiles I can easily handle 500.000 Faces as well. But I was earlier talking about a model with just 50K Faces in a normal inference enabled scene. When you turn off Edges and Profile the inference engine is likely to be switched off as well (though I'm not sure about this) and whatever be the case it DOES provide me with 10x higher framerate.... well, whaddaya know ... he does know what it means. I'm sure John Bacus does as well.
Coen, I don't mind if you defend SU. Not at all even. But I would like you to do it without dodgy rhetorics. Pretty please?
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.
Coen a 10% speed increase when we really need 100's isn't even on the measurement scale! To work even moderately efficiently in SU one must rely heavily on management. You mentioned in one post about Alan Fraser's trees and as amazing a job he has done on them and trust I've done many of my own as you would know they are still low poly!
Mate I suggest you drag one Xfrog or Onyx tree into a scene (where most apps will handle dozens or 100's) and SU will pretty much give up on you! Why do you think it is that most trees SU users use are billboards????
I must say that everytime somebody suggests a shortfall in SU somebody will offer a workaround - "workaround" is really a way of saying it doesn't work so here's some tape to hold it together! In regards to the issue of inferencing being a massive drag - one post I read recently and I think it was Whaat who replied suggested inferencing was infact not likely the drag given that the calcs to achieve this would be handled by the processor almost instantly!
Sure it well could be that high poly users are asking too much but mate if they are paying customers they can still ask!
In regards to DC's - if anyone counts on rendered output from SU they will soon find DC's have very limited application without the ability to make textures non-scaleable. Many manufacturers will also find that the lack of critical map placement will limit the quality reproduction of their product and find significant limits to there use!
-
@remus said:
Rick, although i agree with most of what youve said, i think SU has moved on form its sketched based origins. It is so easy to create hugely detailed models, if only SU was faster!
Larry, i have to agree. I cant help but think a huge amount of hassle could have been prevented if there was a good dialogue between developers and users.
Mate I think this happens well in testing - this is the one area where I must say the Googies shine!!!!
I will go out on a limb to say they listen, understand and interact far beyond what is normal to beta forums AND they even hear the same rants as we are reading here and take that weight on their shoulders well!!
-
In regards to Layout
I would really urge others to have a clean look at layout! I for one wrote it off completely in V1 and now it will become a big part of my daily workflow! Sure it won't right now replace even the most simple CAD app but I have real confidence it will become so quickly!!
It is now a very simple and effective page layout tool and a VERY good 2d design tool. I've currently been using it (during testing) to assist in the design of 16 individual dwellings to develop the floor plan layouts after massing in SU and now cant understand how I lived without a simple fast tool like this before!
Honestly I reckon I could bet each a carton of beer that Layout will develop toward something exciting as even incremental steps in functionality are realised!
-
@unknownuser said:
@unknownuser said:
It was said by someone else (sorry don't have the time to go through all the posts) that they have yet to see a truly professional presentation done in Layout that would change their mind into using it.....me either.
Scott I reckon I might prove you wrong there mate! Mind you I still have to finish it and I'm not sure of your expectations of course!
That said I still do have a lot of gripes with limited functionality though it really is a far better release this time around! And next time I reckon it will jump!
-
@richard said:
In regards to Layout
I would really urge others to have a clean look at layout! I for one wrote it off completely in V1 and now it will become a big part of my daily workflow! Sure it won't right now replace even the most simple CAD app but I have real confidence it will become so quickly!!
It is now a very simple and effective page layout tool and a VERY good 2d design tool. I've currently been using it (during testing) to assist in the design of 16 individual dwellings to develop the floor plan layouts after massing in SU and now cant understand how I lived without a simple fast tool like this before!
Honestly I reckon I could bet each a carton of beer that Layout will develop toward something exciting as even incremental steps in functionality are realised!
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 .
-
@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.
Advertisement