John Bacus interview about Sketchup 7
-
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"
-
Gotcha...still?
-
Yeah, the "wording...", I know. And the "Run faster" option is not very clear either...
-
@gaieus said:
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.
lol. I wasn't referring to you.
-
I'm all for better high poly support as well (
), although i think there are other important things to look at as well.
Advertisement