Last GSU Survey - results
-
Well, in my interpretation, if SU supported "new technology" (like 64 bit, multi-threading) and would perform much better at orbiting/panning (framerate things), THAT would be high poly support. Theoretically there's not limit even now - you can just not do anything after a while.
-
Not necessarily, firstly is SU multi core even possible? how will that be achieved?
64 bit I'm not sure about but from what I've heard it won't make much of an improvement in performance, however utelising more of the GPU may be interesting but again I cannot imagine how that will be achieved more efficiently than it already is.
But here I'm just speculating and would welcome a member of the Google team to put me on the right track...anyone?? -
Now look, I think it's already something that they are communicating about this (and any other issues) in public, with the users/customers. I really doubt that you can get any technical details out of them - especially before any official sign of a new version.
You have signed a couple of NDA's with them and exactly know how these things go.
-
@solo said:
Not necessarily, firstly is SU multi core even possible? how will that be achieved?
It's probably possible but potentially very difficult. I could imagine separating out user input events, inferencing, rendering, to separate threads but making it possible and useful to have multiple threads working on each is harder. A quarter of a century ago (eek!) I was working on solid modelling software; it was possible to make a parallel version to ray trace the voxel models (and we did - a 128 processor system) but it turned out that you could write a better algorithm that would run faster on a single cpu given the hardware of the day. Perhaps it's better now. Perhaps it isn't.
@solo said:
64 bit I'm not sure about but from what I've heard it won't make much of an improvement in performance
My understanding is that 64bit here really refers to using the 'proper' 64 bit instruction set in modern intel architectures. Don't forget that the Core 2 Duos etc that we are mostly using these days actually have a reasonable cpu and instruction set hidden away under all that nasty x86 (blech) wrapping. I think they run x86 code (puke) as a sort of spare time hobby, something to do while they do their real work. Which as we all know, is plotting the overthrow of the human race. With the proper instruction set in use you suddenly have a sensible number of registers, for example.
-
@solo said:
64 bit I'm not sure about but from what I've heard it won't make much of an improvement in performance,
Maybe not for SU itself. But for Plugins that runs inside it. For instance, V-Ray would benefor from 64bit SketchUp.
-
OT: How come when I click on "Your Posts", sticky threads I've replied to is always marked as unread. Even though I'm the last to reply?
-
I am not a coder so I don't know how to fix the issue, but the bottom line is : Sketchup is slow as a snail.
And I am glad I never had to sign an NDA... What's the point signing a contract to keep secrecy about minor features and having to shut up about the things that really matter?....
They are doing an effort though to ask about the issue in the current survey .
I do wonder why they don't ask all the questions in one single survey and get it over with. At the pace they are doing these seperate surveys, they clearly aren't thinking about starting work on v8 any time soon...Moving on to other apps for some tasks is not a bad idea.
-
i have been wondering if @last first and then google ever expected that SUp would be used the way some of us do, that is, for complex and detailed design work, which amounts, of course, to huge files with very high poly counts. as its creators probably never expected it to be used beyond the sketchy design phase or for more than empty buildings with little detail SUp's performance with high poly models was never an issue. until now.
it really bothers me that no matter how well organized my models are (and they really are) there is always a point beyond which navigating between different scenes becomes painful and time consuming.
@solo said:
SU's shelf life is nearing the end without it, start learning another app now before you find yourself redundant.
this is the problem, pete: which app? of course there are other apps that would tackle high poly models without any problems but they are not geared to design work. i do not know of any other app that would allow me to work in architecture in a way similar to SUp. i would thank anyone who would suggest some app comparable to SUp so that i could follow your advice.
-
I think it's wrong to look at it as an "either-or" situation. Why completely replace SU? Use it for what it's worth. And use other tools to complement it. I have plans to look at Vue for vegetation modelling and rendering where SU tends to crawl to a halt. I'll still model the initial model in SU, but then take it into Vue for detailing.
I also have plans for a larger city model. Where each house can be modelled in SU. But I'm considering using another application to store the whole city model as it grows. Not sure which yet.
-
@edson said:
it really bothers me that no matter how well organized my models are (and they really are) there is always a point beyond which navigating between different scenes becomes painful and time consuming.
I think you will find that in most apps, it's just SU reaches the 'frustrating level' faster than a lot of other modellers.
-
@thomthom said:
I think it's wrong to look at it as an "either-or" situation. Why completely replace SU? Use it for what it's worth. And use other tools to complement it. I have plans to look at Vue for vegetation modelling and rendering where SU tends to crawl to a halt. I'll still model the initial model in SU, but then take it into Vue for detailing.
I also have plans for a larger city model. Where each house can be modelled in SU. But I'm considering using another application to store the whole city model as it grows. Not sure which yet.
thomas, you are right. it is a wise way of looking at it. let us know when you find that other application.
-
I have been working that way recently, using Max to accumulate my scene from SU models.
The problem there is the triangulation and grouping within SU which seems so foriegn in other apps.
I can build identical models in say MOI, Rhino or Hexagon and export to Max and the size is roughly the same, however making the same shape in SU (which is quicker and easier) exports roughly 3 times larger than the other modelers. -
@solo said:
I have been working that way recently, using Max to accumulate my scene from SU models.
The problem there is the triangulation and grouping within SU which seems so foriegn in other apps.
I can build identical models in say MOI, Rhino or Hexagon and export to Max and the size is roughly the same, however making the same shape in SU (which is quicker and easier) exports roughly 3 times larger than the other modelers.Yea, I'm not impressed with SU's importer and exporters. Importers are the worst. Only .3ds (old with many limitations + buggy importer) or DWG (no materials).
-
I recently did a test, I created a shape in SU using SDS it was 203kb as a .skp, I then exported it using native SU pro .3ds exporter and the size inflated to 341kb, I then opened the .skp in Deep exploration and converted it to .3ds and the size was 246kb. I compared them in Max and could not see any difference, they were identical.
-
Hi folks.
I did the survey and I added these comentaries at the end:
Please, keep the SU interface simple and efficient, as it is today.
Having construction lines or guide is excellent, how about construction circles ? Maybe it would put too much strain on the inference engine ? Maybe it could be turned on/off so it would be possible to remove the strain when this feature is not required.
How about specifying angles in Degrees, minutes and seconds in addition to decimal degrees and also pushing the precision to four digits so values like 134°12'45" or 134.2125° would be possible.
How about adding angular dimensionning for arcs.
Just ideas.
-
I wonder what extra 'stuff' the exporter is adding (or not getting rid of) that makes the file so much bigger
On a more general note, the exporters could definitely do with an overhaul. If SU is designed to produce quick small models quickly and efficiently it makes sense to then be able to take those models in to a more powerful app for the finishing details.
-
I'm not that concerned about the file sizes. Storage is cheap. But when the data isn't transferred properly, then it's a problem.
-
About 64-bit: I was recently at a short AutoCad Architecture New Features course, and I was surprised at how much faster it ran in their dualcore machines with a 64-bit OS compared to our 32-bit single processor old workhorses with a significantly faster clockrate. So I am starting to wonder if there must be something else about 64-bitness than the ability to use more memory - the actual memory usage of even the Autodesk bloatware is much below the 32-bit XP limits, in my use most often not more than a couple of hundred megabytes.
I added to the survey my usual "rant" about the inferencing engine being the cause of much of the trouble and the request for users to be able to limit the types of inferencing in use.
Anssi
-
Chatting with a range of architects at the AIA, I got some interesting feedback regarding high-poly support.
It would certainly be more than welcome, but many people actually don’t seem that bothered about it. There seems to be a growing tendency out there to use SU as it was intended…as a napkin sketcher, sorting out broad design issues on a general scale before taking the whole thing into Revit for more detailing, either by importing or simply starting over.
We even came across one guy that actually uses SU the other way round; he imports Revit/ACAD content into SU in order to make absolutely sure that it all works in 3D…SU’s accuracy regarding matters coplanar being as picky as it is.I guess this is little consolation if you are in the business of using SU for full-blown visuals and benefit from SU’s existing ease and speed while wanting the possibility of pushing it to tackle larger and more complex models.
-
@jean lemire said:
How about adding angular dimensionning for arcs.
Advertisement