Last GSU Survey - results
-
@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