John Bacus interview about Sketchup 7
-
Gaieus
If things worked as you said, we wouldn't been able to model more than 100 polygons or so... You know how i know that? Try to open a very high and heavy poly model, now try to rotate and zoom around it for a bit. It worked right? slower or faster but it work. Now do "selet all" and try again to rotate and zoom around the model. What hapened? it gets really really slower. Sketchup just processes has you said when there selected, if it were constantly processing the cpu usage would always be 100% (or 50-25% depending on the number of cores).
Anssi
The problem with 64 bits it's beeing a relative new thing and most of the stuff aren't beeing fully optimized for it but that affects every software house. I also seriosly doubt that sketchup, if optimized for 64 bits, would run slower on a 64 bits workstation with 8 to 16 Gb of ram with a quad core and nvidia quadro card than in the same machine but 32bits just using th 3.8 Gb of ram.
Anyway i think (in my ingnorant opinion because i'm no coder) the main problem right now in sketchup it's using a very old engine that has been tuned up a little bit every new release but it's core it's still the same so it's not up to date with current hardware. It probably needs a big code rewrite but if so it's something that should be done long time ago (even GE has a better sun sytem than sketshup...). Then we have the problem not taking advantage of new grafics cards. The lack of new tools is also a problem and when, if any, new tool come out it's like a ruby plugin (think sandbox and dynamic components...) and don't tell me we don't need more tools for sketchup because who here doesn't have plug ins?or can you imagine working in sketchup without any plugin? at least give us the ability to draw curves. And how is aceptable that a new software release has very old bugs?!?
We can't really model more or diferent with 7 than we could in 6, and there's a 2 year diference between them so everything has change a lot: the users are better modelers, have better machines and optimized workflows and none of this was taken in consideration (there's no new or optimized tools, no suport for current hardware or OS an no export features that at least work as they should).
I don't wanna sound like the bad guy telling that now it's the worst thing in the world, i want sketchup exactly as it always have been but we really need better optimization and horse power. And this interview shows that they're happy with sketchup as it (it could be better but it's a great release for them) showing, for me, that easy modeling is the same as simple models for them at least...
-
Imagine this:
You have to do a 3d work that it's simple if you have a good base model to start. You go online, and see a perfect 3d model for sale fully textured that is exactly what you need it, you buy it and import it in 3ds format just to see that all the textures are messed up and theres model parts missing or out of place. You lose a lot of time just putting exactly everything as it should and then model what you wanted in the first place using every trick you know for model workflow optimization in sketchup but losing time in the process because he are really incledibly slow. You also use some plug ins that take a while to load and you wait because he just using 50% of your CPU. When you finish sketchup says the the model should be fixed, you tell him to fix it and he completly screws the modeling...you undo this and try to do a quick 2d export with shadows from a specific point to show the client but the shadows are messed up...you just export it to render elsewhere the preview. You needed the triple time and work you were expecting to do this work...
How would you be and what would you think? is this aceptable?
-
I think that JB has a point.
To my opinion there is no need for multi processor support, SU is fast enough and if you want to render your model just use a render tool with multi CPU support.
Wasn't SU put on the market to let us create low poly 3D models for GE? Like in real-time simulation you have to create your models as small as possible and use texturing for details. Sadly SU and GE don't use LOD's to make models even smaller in a large environment.
But what I think is strange that a tool like “dynamic components” does not fit in this philosophy.SU is an easy to learn and use 3D modeling tool, it is very cheap compared to other 3d modeling tools and powerful enough for detailed modeling two. Ruby scripts makes it even more powerful and it doesn't need all the fancy extras you never going use. These extras are what makes 3ds Max and Maya expensive and to complex to use.
I use SU on a 5 year old single core 3 Ghz processor with only 1GB memory and a simple AGP game card and it runs very smooth, also with larger models. I don't see the need to change SU for use with multi cores it doesn't help you with speed during modeling. The GPU's today on the market are fast enough and can handle large models even with texturing.
A better solution for SU, if it isn't fast enough, would be a new function like external reference. This should be very easy to implement in the software. But the best thing to do is keep your models as simple as possible.
Henri
-
@unknownuser said:
Wasn't SU put on the market to let us create low poly 3D models for GE?
No. It's meant to be an archviz tool.
SU will indeed handle the average GE model with ease. A detailed model of a building, however, is something else. Kwistenbiebel and Bigstick, amongst others, have commented on this extensively.
-
Just a thought has anybody tried the viewer, it does appear to take as long to rotate etc, surely this has the inferencing and rubies etc turned off
If inferencing etc is slowing down the program wouldn't the viewer be faster if they are indeed off. 
-
@unknownuser said:
I think that JB has a point.
To my opinion there is no need for multi processor support, SU is fast enough and if you want to render your model just use a render tool with multi CPU support.Again, simply not true...
Render apps are crippled because of lousy SU core code.
Most of the render apps have 64 bit versions and are adapted to multicore, but your file still needs to be exported/launched from WITHIN Sketchup.
And THAT is the problem.
SU still has the old fashioned 32 bit mono-cored code, which results in numerous crashes when exporting larger models to the render app. (RAM overflows,software stall,...)
Just talk to any of the high end render app developers to know how frustrated they are by this....And Google chooses to ignore this.
-
That interview was a sad read.
Just ignoring the users frustration and problems with a kind of "there is no problem" attitude.
I think our best bet for our hopes to come true would be if some SketchUp loving scripters/programmers got together to create a OpenUp version.
That would be something to hope for in the next year. -
What is this 'there is no problem attitude' you keep talking about. I cant find anything in the interview to that effect.
-
well besides discussing diferent points of view. this post is beeing good to understand something: i'm a old sketchup user and sketchup goal has change. We can see this by what users like matteo and Creator 3D said about sketchup beeing something for GE and 3DW. And the sketchup guys confirm this when there's nothing in the sketchup site now that says sketchup is for archviz and concept modeling like before (when in versions 3.1, 4, 5...), but there's a lot of saying regarding GE and 3DW...
remus read between lines: when John Bacus say, when asked about multicore, that they look for performance tweaks all across the sketchup pipeline, he meant there's not much to optimize because the core it's at is best, so they did nothing. Other thing that you have to keep in mind is even if there's impossible to use multicore with the modeling rendering or whatever they wanna call it, why didn't use molticre for animation exports? running plgins functions? they simply didn't touch it...
I have no problem with this new objective in sketchup but it would be good to know earlier...right now, unless there a very speific need that can't be solve by the use or creation of plugins or have any use for layout 2 (or if it doesn't have any better software...), there's not much reason to use the paid version of sketchup.
-
@unknownuser said:
remus read between lines: when John Bacus say, when asked about multicore, that they look for performance tweaks all across the sketchup pipeline, he meant there's not much to optimize because the core it's at is best, so they did nothing. Other thing that you have to keep in mind is even if there's impossible to use multicore with the modeling rendering or whatever they wanna call it, why didn't use molticre for animation exports? running plgins functions? they simply didn't touch it...
No, what he said was that they look for extra performance wherever they can get it and make improvements where they can. There was nothing there to suggest that '...the core is at it's best, so they did nothing.'
As for using more cores for running plugins/exports, im sure theyve looked in to it and havent done it for a reason.
-
As a product designer I likely use SU a bit differently and as a result my expectations are a bit different. I started using SU in v3 as a conceptual tool to create product concepts and applications to illustrate solutions. I still use SU that way as do many others at the company I work for.
SU really performs well at the conceptual level and becomes less and less appropriate as one tries to push it beyond that. I recently used it to successfully model a complete product and although I was able to model the 120 parts to make the various solutions. It was a ton of work and any minor change required that I adjust models throughout the various assemblies. As a result of that experience our work process now moves to a high end parametric modeler once the concept is complete. The point being that there are different tools that are appropriate for different parts of the development process. SU's area is at the beginning, not the whole process.
SU is not: Autocad, 3D Studio Max, Alias Studio or any of the other high end 3D modelers, drafting/drawing/CD generating programs or a high end renderer. It may not even be an appropriate front end for any of those. Expecting it to be all of those is a bit unrealistic given the price point and feature set. Google bought a program and is continuing its development in the same direction as the original creators, which I frankly applaud them for. They have kept it fast, light and true to its origins and intent.
Is it good for modeling Google Earth, apparently yes and is part of why Google bought the software. They do have other interests as well which the additions to SU are hinting towards.
As for 64 bit support, its likely a nice to have but hardly needed by the vast majority of uses, few of whom are actually pushing up against the memory limitations of 32 bit OS's.
Multi processor support would be great for the same things other software uses it for: rendering. A rendering can be cut up into discrete activities that are linear and fully predicable, turning those activities into something several different processors can chunk away at is a fairly easy thing to do. For most of the activities of modeling, a single processor is waiting patiently for the user to press the mouse button and aside from turning on shadows there aren't many of those clicks that are particularly taxing for that one processor or have much delay for the user.
Where this changes is when the model becomes complex, be it the model, the textures or what have you and the user wishes to change the view. The problem SU faces here is that dynamic environment, which is not linear in what the user will do next and as a result it cannot be parsed into a series of discrete activities that can be run in parallel. An analogy is a pregnant woman, a baby is built cell by cell one upon the next until the baby is complete. Nine women cannot make one baby in one month versus the 9 months it really takes. A SU model is very much like this, a huge number of discrete clicks, rotations etc. built one upon the next until the user is satisfied.
Some rubies end up taking time to run because they are performing a large number of tool calls and manipulations. Could rubies be multi processed? Maybe if Ruby allows for it and the programmer writes to take advantage of it. I doubt many will.
I think some of you really need to evaluate what you hope to accomplish and then understand whether you are using the right tool for the job.
-
@kmead said:
.....The point being that there are different tools that are appropriate for different parts of the development process. SU's area is at the beginning, not the whole process.....
BLASPHEMER!!!! BLASPHEMER!!! .....there will be no talk of using the right tool for the job here thank you very much!!! There is no other god, you WILL use SU from start to finish, you WILL complain to anyone and everyone that it does not have multi core support, you WILL b*tch and moan that SU can't be pushed far far beyond it's intent and design to do what you need, you WILL start a on-line petition forcing Google to go a 64 bit version even though only about 5% of the population actually has a 64 bit processor......
Hey you other guys... go pluck the chickens while I heat up this tar..... and don't let kmead get away.
-
Allrighty, Hazza.
"What!? Make it ... better? Whaddaya mean? I can make my three-piece, 15 kb models just fine with SU! And if I'm fine with SU's current abilities, you should be too! No, I don't give a hoot whether or not there's experienced, professional users who disagree with me! My workflow and needs über Alles! Put a sock in it, will ya? Don't make me ridicule you for having a different opinion than I do now! Suggesting improvements ... to the software you paid for ... and you're surprised you're met with sarcasm!?"
Let's have a constructive discussion, shall we?
-
I too want SU moved forward and most days that I visit this forum I see people doing so with the work they do using SU or the excellent plugins that are authored and available here. Periodically Google (and previously AtLast) makes substantive baseline adds that markedly change SU's baseline abilities. We all want improvements to SU, I just think people need to be realistic about what those improvements should be or even can be.
In all cases, the work, the plugins (rubies) and the things Google does, may or may not be of much value to me. Oft times they are.
In terms of the baseline features, I look forward to Google making deep structural changes but at the same time hope that they keep the program open as it is now and just as easy to use but with even more depth than it has now.
One does need to be careful about what one wishes for, in the past the major changes made by the developers were not always appreciated. Google having closed the old forum allows us to forget the calls from the past of malfeasance and incompetence. From minor issues like tool icons, the addition of the sandbox and even the ruby language enablement.
Yes we all yearn for more, I am looking for more functionality in SU, not necessarily just better hardware utilization which will come as OS's get more adept. Hopefully things like OpenCL will enable developers to make software that can access more hardware features, as multi-core hardware advances got well out in front of what software was able to make use of. The combination of multiple CPUs and GPUs working together is tantalizing but so far no one has fulfilled the promise.
-
@kmead said:
In terms of the baseline features, I look forward to Google making deep structural changes but at the same time hope that they keep the program open as it is now and just as easy to use but with even more depth than it has now.
Sounds good to me. Personally, I'm not whishing for SU to turn into Max, C4D or modo. I quite like it the way it is. Apart, that is, from it's poly limit. That's the one thing about it that annoys me. Mind you, I do optimise my models as much as I possibly can, and I don't mind doing that. Still, optimising will get you only so far.
Oh, yes, then there's 64 bit. I'm sure the devs over at, say, Asgvis HQ would be quite happy if SU turned 64 bit. Having a Vray license, I'd be too.
-
If you look at the current results of this survey, it says that performance is only the fourth most important issue. According to this, a new survey has been released where the "feature requests" possible to select are mostly things that could be done via plugins.
-
Slap a skirt on me and call me Shirley, but I think your interpretation of the results is off. Better yet: the results show that the likes of Bigstick, Kwistenbiebel and myself are not quite as marginal, with regards to our wishes for SU, as some make us out to be.
-
I never meant "marginal" but not a first priority (the "powerful" thing there refers to modeling tools while the "run faster" is about performance).
Look guys, I am not against high poly support at all - what's more, I have also voted for that when I filled in the survey. It's just other people who would like other things prior to this.
-
Not knowing the description given when asking the question: I'd say "powerful" refers to the amount of stuff (complexity) the program can push around without straining...ie. "high poly"?
-
Well, if you have a look at the original survey, it says it a bit more detailed: "More powerful (e.g., add new features and support different kinds of modeling)"
So this is the result the new survey is based on. "What tools"
Advertisement