John Bacus interview about Sketchup 7
-
@remus said:
...if i remember correctly crysis averages about 1 million triangles, which isnt far off what SU can handle.
Thanks Remus, now I've seen it all
.Well, you're right. But you might want to mention that, with a pretty standard PC, Crysis will throw those 1 million triangles at you at 40 fps with a lot of eye candy and SU will haaandle it, looking very crispy with shadows turned of... [I'm not even talking about textures here]OT, I think the whole interview sounds like an excuse, which shouldn't be the case when you're releasing 'new' software. I mean, the whole keeping it easy and clean for a wide variety of people to be able to work with SU, I'm buying. But no need for multicore support?... Seriously?
Am I [are we] too demanding, asking for multicore support, shadow bug fix [yes, legal issues, bla bla] or something as simple as locking toolbars?
[/rant]
-
@remus said:
When modelling SU doesnt consume anywhere near enough memory to warrant 64 bit support.
You're wrong Remus.
Some of the ruby plugins crash on RAM overflow on larger models.
Subsmooth for instance, or ComponentSpray.
A 64 bit version and multicore support would help (or another way to overcome the High poly bug)
I am not even mentioning export towards high end render apps.I hate reading an interview like that, as it proves once again how ignorant Google is on its own software.
Google is for the web, not for 3D. Proven once again.
-
matteo
I couldn't agree more in keeping things easy and acessible in skethcup but keep in mind 2 things: the pro users aren't the same as the free users (not everyone models blocks for GE..), and before Google, Sketchup was made inicially for architects and anyone who wanted an easy 3d modeler to use combined with other softwares, right now the core aren't the architets or modelers or anyone who used sketchup when it was @Last, now the most important thing is google earth integration and everything related (just see the new browser in sk7, it's not as eficient as in the previous 6 but now has google all over it). Righ now, the pro version is dying.
remus
Like kwistenbiebel said, you're wrong. One of the main diferences between 32 bits and 64 bits operating systems is that 64 bits allows more than 3.8Gb of ram (even if you have 6 Gb ram the system will just see and use 3.8Gb if i'm not mistaken). In a basic and simple way, more memory means more things at the screen at the same time. Now imagine what skethcup could do if it were optimized to run in 64 bits...
Real time rendering in sketchup was great 6 years ago...Now before we can use the 2d output (i wouldn't really call it a rendering...)in skethcup we have to model what we want to show, but if i can't model it what will i have to show? i'm not saying that real time render and walktroughs in sketchup models should be over but this should be the part were the diference between sketchup free and pro should be seen. From the moment that the real time stops helping and starts delaying work i would turn it off and would just be turn on when all modeling and optimization was done (for real time walktroughs, 2d exports, rendering, etc). And please don't compare the images produced in real time with skethcup with the ones in crysis...that engine it's a real peace of art and is used, more than a year after, still as a 3d bechmark.
-
Kwist and DacaD, with regards to 64 bit: I have never run in to a memory overflow when modelling and before now i've never heard anyone else mention it. I don't think it is a very widespread problem, really.
Crysis probably wasn't the best comparison
The joys of late night posting live on.Oh, could someone please quote the bit where jb says multicore isn't necessary? I've read the interview 3 times now and cant see it. I must be particularly blinkered today.
-
Let's have an example of a simple cube. It has 6 sides, 12 edges, 8 endpoints.
It means 6 On face inferences, 12 On edge inferences, 12 Parallel to edge inferences, 12 Perpendicular to edge inferences, 12 Midpoint inferences and 8 Endpoint inferences. This altogether 62 different inference possibilities plus 3 for the axes. If you press Shift to lock an inference and still using other inference points, it can be doubled.
Now "real time rendering" does not mean any kind of export or whatever but that the computer needs to keep all these things in mind while modeling/orbiting and such (beside displaying the model itself) and with millions of faces, edges, vertices and midpoints it may be very hard. What JB is saying there about multicore support is that this modeling part cannot be split into threads. Once they found a way that say different inferences go on different cores, it could be solved.
So practically now the case is that what makes SU a great, easy to use and intuitive modeling tool prevents it from being high poly supportive. I personally wouldn't for instance like to sacrifice inference to high poly support. Would it be easier to model anything using gizmos and constantly typing in co-ordinates?
What I could imagine however are a couple of things like
- turning off inference while orbiting or running an animation
- turning off inference for a kind category like what we have now with locked objects (all kwist's high poly trees could go here) maybe leaving a single inference point active at the origin of the component so that it's easily positionable
- turning off different inferences selectively
etc...
-
As far as I know (I am no more a programmer than any of the other posters)
- 64-bit addressing makes applications run a tad slower than 32-bit, because of the added overhead.
- there are no multithreaded modelling applications on the market. Even the big and expensive apps like AutoCad and 3DSMax use multitasking only for rendering and other subordinate tasks.
Bigger always sounds better, but my first hope for SU would be a better optimization of the inferencing system. I see it as the core of the superior usability of SU. Discarding inferencing would perhaps give us instant high-poly satisfaction, but the application would no longer be SU. The market is already full of applications that can handle a lot more geometry than SU, but lack the essentials.
Anssi
-
I agree, Anssi, yet making SU a 64 bit application would surely improve rendering with rendering apps that run inside SU. Does is still say on the SU site that "no application is an island"?
-
@unknownuser said:
...I am no longer struck with fear when the boss runs in with some complex gem he wants built before the day is over...
Or when he comes in and asks you what you've been doing all day...
-
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.
Advertisement