Last GSU Survey - results
-
@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.
-
@anssi said:
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.
I don't bother to keep up with details of this stuff anymore but my understanding is that the 64bit mode allows use of a the 'real' cpu instead of limiting you to the 'fake x86'. Current intel CPUs are massive RISC machines with a layer of fake x86 wrapped around them. They have dozens (or even hundreds!) of registers instead of the insane old x86 arrangement. Think of it as being similar to running the old 68k MAc emulator for the PPC Macs on top of the PPC emulator for intel Macs. Some parts of some code might run dozens of times faster in 64bit OS mode.
-
@solo said:
They never had it as an option on the survey, only options were things that they might be able to fix, High poly support is a taboo topic to the GSU team as they have never mentioned it, aknowledged it or even responded to all the complaints and cries about it.
SU's shelf life is nearing the end without it, start learning another app now before you find yourself redundant.
Yep, and 'high poly' is a moving target that is now in the Giga-poly range in terms of how many polys some apps can handle at once. And that's Giga-POLY, folks, not Giga-entity.
SU is getting to the point that it can choke on 'LOW-poly', nevermind 'HIGH-poly', compared to what other apps and game-engines are now handling!
How's that 'free' working out for you now?
Advertisement