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