Google is Listening!
-
@unknownuser said:
i don't really know what causes the slowdown in higher poly models so bear with me in the suggestion.
i'm assuming much of the performance loss is due to giving the model a certain look at any given time (shading all faces etc.).. if that's in fact the case, i'm wondering how people would feel about a mode where the look is plain jane.. for instance, if i have a group or component (say 3d trees) that i feel is bogging down performance, i could click something such as 'optimize performance' for that group and it would dumb itself down look wise.. ie, i wouldn't have to hide it in order to speed things up.. i could see it plain as day albeit the color/shading doesn't change as i orbit the model... any style options (profiles etc which may cause slowdowns) are disengaged from that component..
or maybe, if the above is even sensible to begin with, there could also be a mode in which the entire model is dumbed down and only when you open a group or component does the look become the sketchup look.is this making any sense or am i heading down the wrong path? how would some of you high poly modelers feel about this type of option?
Your 'optimize performance' idea would be a possible improvement but it would then emphasize another bottleneck that hasn't been mentioned yet. The Maxwell render plugin (and probably others) has the ability to use 'proxies' where you have some simple geometry component, say a box named PalmTree_Proxy. THen, you have your high poly object named PalmTree in the same model on a hidden layer. That way it doesn't slow down the viewport because it's hidden, and at render time Maxwell will substitute the high poly object for the proxy.
It works just fine but for some reason SU file sizes get verylarge with even 1 or 2 high poly objects (as compared to 3ds Max for example which can hold quite a lot of polys without getting too large). Combine that relatively minor inconvenience (file size) with the much large inconvenience which is save times, and it really bogs you down. To me, SU's save times once you start getting into higher poly's becomes almost as burdensome as viewport issues because it's something you have no control over. And again, I will compare it to 3ds Max which saves even huge models very quickly.
While I wouldn't compare SU's modeling capability to 3ds Max's, I think this comparison is only fair because if you're claiming that SU is purposely a much less complex program than 3ds Max and so it's modeling tools shouldn't be as complex as Max's, then shouldn't that lack of complexity also translate into smaller file sizes and faster save times?
-Brodie
-
gotta admit, file size has never crossed my mind as any sort of concern.. storage is way too cheap (relatively) to even worry about it.. i mean, one or two raw frames from a 20+megabeam digi cam = the same file size as a big model and some of those people are shooting hundreds if not thousands of pictures a day.
save times too.. that's like 5 seconds at the most for me (but if you're saying it takes more than say 30 seconds to save files then yeah, i'd be concerned too but i've never had a file do that.)..
point being, if i could have a 2million poly model [exaggeration] perform the same way as a 20,000 then i'd surely accept a longer save time as a consequence.. pretty much a no brainer tradeoff
-
@Jeff:
I wonder what it is that the Crytek game engine does. A while back there was a link to a Crytek demo that showed real time smooth refresh and in-scene remodeling. Yes, I am aware that it is a game engine and you probably need a gamer type video card, but I'm just saying.. -
I'm seeing alot of great ideas in the voting area -- and also some submissions that are already covered somewhere in Sketchup.
I love Sketchup and I love the ruby plugins that are available that make Sketchup much more powerful... I'm pretty sure I don't want the Sketchup team wasting dev time on reproducing the work already done by the ruby developers. I'd rather see them focus on giving the ruby developers the most robust and stable environment they can have to design in. Really the people who should get the strongest vote as to what gets included in future releases is them...
As far as the UV editing issue goes, I guess my reasoning for wanting this as a stand alone component for Pro (like style builder) is it is just so annoying to get things into and out of Sketchup that if I can keep the project within the borders of "Sketchup land" then I feel it would be much more productive and faster to work with textures.
It doesn't have to be really all that complicated -- but based on my personal experience poor control over UV's is the thing that really undermines the NPR render engine in Sketchup the most... that NPR engine is the reason why I use Sketchup for illustration. However I (like many others) use Maxwell Render to also produce realistic renders and the UV issue becomes even more of a problem in that arena. This of course really become a issue on curving/organic surfaces that are becoming more and more prominent on everything from buildings to cars to toasters.
I've got some ideas for names too -- I like MapUp, WrapUp, or TextureUp.
Best,
Jason. -
emage, if you have already used Maya, it seems to me, that you would be better off investing in a copy of 3DS Max. I did one module in ArchViz when I studied for my degree, and we used mainly 3D Studio Max. I did prefer SketchUp for its easy of use, but found that I couldn't use SketchUp with Flash (I ended up using Unity instead of Flash, but I had to use the 3DS Max/Flash combination set up to pass the module). You could also look at SpaceClaim, the version without all the engineering tools. The developers call it "SketchUp on Steroids"!
Failing that, try Bonzai 3D.
-
The thing is... I don't feel Bonzai handles more polygons than SU. Nor is it either 64bit. (and doesn't have as many render engines available.)
The key difference is that it's a nurbs and solid modeller. -
This is what I am up against often, using SU without needing photo realistic modeling.
I've got of model of a treatment plant. The footprint is large. Equipment (piping, channels, galleries, and bays) can span 2 or 3 floors. Components are used to keep file size down and reduce repetitious modeling. The compressed SU file size can easily be 25 meg. The associated Layout file (depending upon the settings) could double or triple that size.
Goal of the model has two basic needs. 1- produce technical illustrations (usually thruough Layout for highres transparent PNGs) and 2- Walk throughs.
#2 was a big a reasons for getting SU way back in version 2. However, with the complexity I mentioned above this is not fluid. Waiting to render even with the improvements since version 7 is a bummer. Perhaps there could me a mode where SU reads only the next or previous Scene or two and ignores "remembering" any other geometry of the model of scenes which are not in the immediate queue?
#1 usually Layout works good enough but depending upon the settings used with a big model or one that has a lot of textures it can seem to be slow and exporting a transparent PNG can fail and if it does you don't know it will until the end of the exporting process when you get an error message. Perhaps utilizing multicore processing would be possible for Layout rendering? This could make buying the Pro version more desireable and bolster the difference between the Free and Pro versions.
-
@jclements said:
Perhaps utilizing multicore processing would be possible for Layout rendering?
You guys want to know a funny thing? LayOut 2.0 on Windows
renders in another thread while you continue to work on the
document. What's so funny you ask? Well in LayOut 2.1 we
had to pull out the background rendering and guess
how many people noticed? ZERO! -
Perhaps if you hadn't have updated/improved the SU rendering engine we would have
. Kind of kidding you here. -
@jhauswirth said:
@jclements said:
Perhaps utilizing multicore processing would be possible for Layout rendering?
You guys want to know a funny thing? LayOut 2.0 on Windows
renders in another thread while you continue to work on the
document. What's so funny you ask? Well in LayOut 2.1 we
had to pull out the background rendering and guess
how many people noticed? ZERO!Touché!
-
@jhauswirth said:
@jclements said:
Perhaps utilizing multicore processing would be possible for Layout rendering?
You guys want to know a funny thing? LayOut 2.0 on Windows
renders in another thread while you continue to work on the
document. What's so funny you ask? Well in LayOut 2.1 we
had to pull out the background rendering and guess
how many people noticed? ZERO!Well I certainly didn't...since I don't use Layout.
-
@hieru said:
@thomthom said:
.....a Plugin Manager would let you browse and download plugins directly from SU. And of course update when updates are available. The Plugin Manager should be available as an one-click-installer.
Basically something like Dreamweaver's Extension Manager?
Now there's a good idea!
-
I would think google should keep the SU in 32bit for the less intense users and release the 64bit for more intense users. Let us (the users)test it out and you will get your response of what we think that if the 64bit version actually benefit more to the intense users. Now a day, I believe computers set their 64bit application as their standard. I have seen laptops as low as $400 with 64bit window base application. I believe 64bit is the future if not the current then why SU stays as 32bit.
-
Peep
I want a way to selectively disable inferencing -- a checkbox list for which inferences should be on or off.
Not having that option is a major bummer for me.
-
I think that introducing coloured guide lines will ease a lot of work during construction.
Just a thought
Toxik
-
Hi,
In my opinion it will be essential to bring in SU (free and pro - especially free) linetype, lineweight, hatching, even it's a 3D modelling tool. (in fact, we all need a 2D plan before 3D modelling)
-
@julyyen said:
Hi,
In my opinion it will be essential to bring in SU (free and pro - especially free) linetype, lineweight, hatching, even it's a 3D modelling tool. (in fact, we all need a 2D plan before 3D modelling)
2D tools by TIG here: http://forums.sketchucation.com/viewtopic.php?t=22091
-
-
There are a lot of questions/suggestions available in this topic:
http://forums.sketchucation.com/viewtopic.php?f=180&t=13666All of them for the use of developers.
But if those people get the right tools, they can make better plugins and extend Sketchup possibilities.
It's like Pixero wrote:'extend the API'!
I know it is impossible to adress everyones wishes. But if you make the API better, then more people can try to answer those wishes...
-
@pout said:
There are a lot of questions/suggestions available in this topic:
http://forums.sketchucation.com/viewtopic.php?f=180&t=13666All of them for the use of developers.
But if those people get the right tools, they can make better plugins and extend Sketchup possibilities.
It's like Pixero wrote:'extend the API'!
I know it is impossible to adress everyones wishes. But if you make the API better, then more people can try to answer those wishes...
i'm sort of under the impression (judging by a couple of random posts by SUteam members) that they don't want to go full on in supporting plugins..
i'm pretty sure if they set up a depot app store type of thing then they'd have a gigantic slew of new problems to deal with.. fredoscale was a decent example of what may happen so imagine if that was happening to millions instead of thousands.
it'd be sort of sweet if google had an approval process of some sorts prior to rubies going live but again, that's a big undertaking in itself + we'd miss (some of) the benefit of talking directly with the developers and offering ideas/additions etc. (that could still occur but the process would be weeks/months instead of hours/days.)
Advertisement