John Bacus interview about Sketchup 7
-
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. -
I read JB's interview with Architosh quite carefully before responding. I have to say that I agree with his whole multithreading argument. With something like rendering for example, it lends itself very well to multithreading. You start a process and then when the CPU has a big chunk of work to do, it can be divided up into separate chunks for parallel processing. It is probably only Ruby and a few other operations that would benefit from multi-threading. For example file import/export, sandbox activities and that sort of thing where a specific task can be 'farmed out' to the various cores. This is his linear workflow argument and it seems to be convincing to me.
As has been discussed previously, one of the drawbacks with the later releases of SU is slow orbiting. I did think that some kind of keyboard override to disable inferencing while orbiting might improve things a lot here. This seemed to me to be completely logical and perhaps an easy temporary fix. However, the point about the viewer seeming no faster without (apparently) having inferencing was interesting and would tend to indicate that this might not be the case. Can anyone shed any more light on this? We know the SU team checks out the forum threads.
But - I have to come back to the point about orbiting (and high poly support because the 2 issues are linked), SU is not fast enough when manipulating large or complex models. I think the survey is misleading because the questions are too vague. If you want a survey to be of any value at all, you have to be very specific about the questions asked, otherwise you can't really draw any meaningful conclusions. In my opinion, the question about making SU more powerful should have explicitly mentioned adding new features, and the issue regarding improving speed ought to have been clarified in terms of improving shadows, and performance with more detailed models. I mean, in what other ways is the performance unsatisfactory?
I am an unashamed SU fan, I really love using the application, except when the limitations become an obstacle to the design process. It's useful and fun to be able to model a whole building, including some of the detailed construction elements, and to see how these things affect the whole building before you actually start construction.
I'm sure I can't be alone in going to site and finding that the clumsy and ugly way some of the services have been integrated lets a building down. SU has the facility to include as much detail as possible to effectively simulate construction before you get on site. The more detail you add, the more problems you can anticipate and solve. I think it's practical, efficient and (still) fun!
With the cool plugins that are available, you can try out different design options, including light fittings, furniture and render them to show clients and inform the design.I'm not sure the SU team really appreciate exactly how obsessive architects in particular can be in terms of design. With components (and more so with DCs) we can be so much more fanatical about this stuff. For some of us it's like 3d OCD! As a result it is absolutely imperative that we get nice, smooth navigation of detailed models. Other apps can do it, and I don't think it's an unfair request. It might be a massive job to improve the geometry manipulation, but I'm sure it's going to be necessary some time or other, so why not now? You really need to get the foundation of anything right, and a fast, smooth and reliable geometry engine which supports tens or even hundreds of thousands of polygons is essential.
No-one is expecting the core application to be a cheap or free alternative to 3ds max, Lightwave or Maya with NURBS and bones and fabric and in-built photorealistic rendering, but we do want to be able to add lots of detailed basic geometry and be able to smoothly and freely navigate some complex models with textures and shadows.
To be honest, I don't really think there is much point in adding many new features if we can't use the existing ones with a satisfactory degree of complexity. If SU does become 'more powerful', it's unlikely that this is going reduce model complexity is it?
So if I'm speaking from a position of unparalleled ignorance, sorry - but quite a few of us really do think that we need a more capable 3d core.
-
@bigstick said:
To be honest, I don't really think there is much point in adding many new features if we can't use the existing ones with a satisfactory degree of complexity. If SU does become 'more powerful', it's unlikely that this is going reduce model complexity is it?
Sorry to pick just one phrase out of your well formulated discours, Jim, (I really dig the whole post), but I can't help reacting on this line.
You hit the sweet spot with it.
Without optimisation of the Sketchup core code, new functionality will indeed make no sense.
The new in(ter)ference engine makes SU a tad slower than before. Also the DC (which is a nice feature by the way)pushes the limit.
I think it all proves that the SU engine is running at its limit.....
In the survey, if 'more power ' means having more functions than 'more speed ' needs to be solved first.As some of the other members here, I support the idea to further 'OpenUp' the Sketchup 'Platform' and make a strong playground for the plugin developers. But they will need a stronger base to work on to get serious things going.
It is good that SU still is a lightweight app (as Kmead pointed out) and it should stay that way. A strong but small Sketchup can be the foundation and open platform for lots and lots of plugins for different kinds of purposes.I see parallels with how Microsoft is now trying to strip the current Vista and make a smaller but more stable core and release it as 'Windows 7' (next year). Sketchup should be going that route as well imho.
Make it small but powerfull and make it as open as possible for 3td party devs.Asking for 64 bit and multicore (those words are starting to sound nasty) is not just about high poly modeling, it is also about stretching the live span of Sketchup and strengthening it for more years to come.
64 bit is not marginal anymore. If you are about to buy a PC soon, really consider a 64 bit OS, as 32 bit will be dead in a year (or two) for newly purchased computers.
64 bit has much more to offer now and it IS very stable, especially in Vista. -
@unknownuser said:
Make it small but powerfull and make it as open as possible for 3rd party devs.
My thoughts exactly.
Advertisement