Google is Listening!
-
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.) -
@unknownuser said:
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.
If I may ask, what was the fredoscale example?
-
Due to an unknown design limitation on the API regarding the
UI::Commandobjects, context menus began to grey out when one used the plugin. -
-
Thanks.
-
Thanks for your input Gaieus. My observation with Sketchup in Ubuntu Koala with Wine 1.2 is very good speed using Nvidia drivers, so it must be using openGL natively. But you have a point because trying to make a raster export is disastrous. But working within Linux without doing that is snappy,apart from a garbled start screen. What I was thinking of was a Sketchup Linux written for Debian or Red Hat which has a large user base. Recently, Bricscad released a full Linux version of their CAD application and it is pretty impressive. Snappier than in Wine.
-
@unknownuser said:
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.)Jeff,
I would not go that far to put the ruby plugin dev under their wings. I think the way it works now is ok.
There are a lot of good plugin ideas being put in a trash can caused by the lack of some basic classes.
The handling of problems with (and responsibility for) the plugin must be handled by the plugin author, not by Google SU.
Advertisement