SU is great, but cannot handle complex models with trees etc
-
It's odd that you couldn't use the style -- it should be as simple as dropping it into one of your styles folders...
I'm not sure what the holdup is on importing -- I know some of the issues that effect Sketchup while you are working, but import/export innards are greek to me... probably TIG and some of the other plugin gurus could fill those gaps for you.
Who knows on the cores thing -- it makes sense to me, but the base core of SketchUp must be completely incompatible with modern hardware architecture somehow... I know pure Ruby creates limits on multi-core for the free version... but if you are using SketchUp Pro that should not be an issue at import/export.
At one point in time they tried to do multi-core in Layout and it got messed up -- so they dropped it in the next update and I'm not sure if it ever got put back in.
Best,
Jason. -
In addition to the mentioned ways of handling complex scenes:
use a low poly component as placeholder, eg. a cylinder for a tree, one for each component you will use later. You can scale and rotate and this information will be kept.
Use random selection of a set of components to generate eg. a forest.After you set up a certain scene you can go to component library, select the placeholder, select component instances and then select "replace selected". (right click on high poly component)
That way you can make a big scene and handle it in viewport and replace it with high poly objects later. Keep im mind to set the pivot correctly within the components as these will be inserted there.
Definitely for handling bigger scenes in SU a good computer is a must.
Importing big files can be tricky, import files in parts, if possible.
The same for big automatised functions, using plugins.
Sometimes it's just better to use it on parts, not all at once.And never forget to save before you do a critical action
-
@jason_maranto said:
At one point in time they tried to do multi-core in Layout and it got messed up -- so they dropped it in the next update and I'm not sure if it ever got put back in.
multi threading for modeling operations (i.e. geometric calculations) is a pretty non-trivial thing, this shouldn't be underestimated... I'm not aware of any recent modeler being capable to do this, besides simple raster operations during rendering/raytracing of course.
Even file I/O operations putting to another thread seems to be difficult, at least according to the reply of John Bacus in the Google Help Group concerning my corresponding proposal. A further posting concerning multi-threading can be found here.
The sophisticated inference engine and geometry merging etc. that we all do like su much do obviously have a negative effect on application responsiveness which increases (maybe exponentially) with high poly count models of course.
Norbert
-
Thanks for the links sketch.de, they make interesting reading. I think the high poly, import and exploding problems have all been accelerated as sketch up has evolved. The render engines have opened up sketch up and have produced some spectacular results, people enjoy using sketch up and want to add all that detail that makes a good image. Also i think because of the huge user base a lot of people have grown inside sketch up, because it's so fast to model surely it was inevitable they need higher poly support. Perhaps 64 bit or multiple processor support is not easy or ideal, but at some point the application needs to respond to modern hardware. Other apps manage fine, so i believe it must be possible. perhaps inference and the other cpu hungry processes can be toggled off. I am becoming increasingly frustrated in the amount of crashes and lost modeling time, the worst thing is even with a lot of research sketch up is pretty much irreplaceable.
It seems that google are being tight lipped understandably but that could be a good thing, at least it seems like a sign that something is coming. Because of the huge range of users and the large free user base i think the answer lies in making the pro & free version more different. I expect most pro users would pay more for extra features i know i would. I have been with sketch up since v4.0.chedda
-
Google for sure have a different ethos to @last, the free version will fill all their GE needs, they can then open another avenue to add to their empire. I suppose to the google overlords sketch up is almost irrelevant it's a shame really because i'd like to see the roots driven love in the app.
-
@chedda said:
It seems that google are being tight lipped understandably but that could be a good thing, at least it seems like a sign that something is coming. Because of the huge range of users and the large free user base i think the answer lies in making the pro & free version more different. I expect most pro users would pay more for extra features i know i would. I have been with sketch up since v4.0.
I also agree and think it would be a good incentive to get free users to make the leap to Pro -- It may be my native paranoid thought processes at work, but part of me believes the reason SketchUp is not developed in that direction is because it has no application for Google Earth, and therefor to Google. They want low poly, and SketchUp (as it is now) already suits their purposes -- adding real high-poly support seems counterproductive to their goals.
Don't get me wrong, I like talking to the SketchUp devs -- and I'm not pinning this on them, I think it comes from above them... maybe from much higher.
I mean lets break it down, free version users are not the real customers of SketchUp (from Google POV) -- the real customers would the pro users of Google Earth, and the advertisers on Google Earth -- SketchUp free version users are meant to be a free labor workforce to populate Google Earth, making it a more compelling environment -- which would in turn draw more users, which would in turn generate more ad revenue for Google.
Best,
Jason. -
I've proposed a "work for SketchUp Pro" scheme that I thought would benefit everybody -- but it didn't seem to resonate with them (SketchUp) for some reason.
My idea was to give 3D warehouse users credits toward a SketchUp Pro license for each model they have accepted into Google Earth (maybe 1-5$ per model).
I thought this would rapidly increase the amount of models on Google Earth (making Google happy) and also allow people who could not afford a license to get a legitimate copy of SketchUp Pro.
I'm not sure why they didn't go for this idea...
Best,
Jason. -
some users might still know the times of @Last and the type of models SU was meant to be used for... today users are trying to replace expensive AEC/BIM apps like Allplan or ArchiCAD or Revit etc. and claiming that their 150mb model does lag during push'pulling and screen transformations etc. sometimes using a weak system additionally.
I very doubt that demanding development tasks as e.g. multi-threading for modeling operations which are still not solved by the 'big boys' can be done by the probably small SU dev team and from the revenues of the SUP version.
in short, evolution yes, revolution nope
jm2cts,
Norbert -
I don't think this thread has anything to do with Modeling operations at all -- this is about importing large assets from other packages... I think most users know that you can manipulate SketchUp to work well (or passably) with very large files once you actually successfully get them into SketchUp in the first place.
I have 6 3D packages and none of them have the problems of SketchUp (on open/import/save) and all of them can handle far more polys in camera movements and editing with no issues -- and several of them are cheaper than SketchUp Pro... and many of them are older too.
It doesn't add up... and SketchUp does not play well with others.
On top of all that there is the UV layout mess that is SketchUp -- it's almost comical to see the UV's SketchUp makes sometimes.
Best,
Jason. -
@jason_maranto said:
I don't think this thread has anything to do with Modeling operations at all -- this is about importing large assets from other packages...
I don't think this thread has anything to do with Data Exchange operations at all -- this is about using high poly count models in SU.
@jason_maranto said:
I think most users know that you can manipulate SketchUp to work well (or passably) with very large files once you actually successfully get them into SketchUp in the first place.
not the initial poster, data exchange was mentioned by you first.
@jason_maranto said:
I have 6 3D packages and none of them have the problems of SketchUp (on open/import/save) and all of them can handle far more polys in camera movements and editing with no issues -- and several of them are cheaper than SketchUp Pro... and many of them are older too.
and none of them is comparable with SU in the sense of user interface interactivity.
I do not deny that improvements concerning speed are possible and required and btw done already for all of the latest releases. I doubt that with the current implementation and internal data structures the speed improvements in quantum leap size many users are expecting for future releases are in general possible.
anywayz, future will show and we and our customers would be more than happy to have a lightnin' fast SU in the hopefully very near future.
cross fingers,
Norbert -
Where do you think the high-poly trees are coming from? Certainly not SketchUp...
Yeah we can do 2d face-me trees till the cows come home, but that isn't exactly "complex".
I know alot of what I said sounds very negative and it's not the only things I see -- I'm generally pleased to be a SketchUp user for alot of tasks.
I think all parts of SketchUp Pro (DCs, Layout, and Style Builder) have a ton of potential and I've actively suggested improvement on all of them and lobbied for things that I think could take the programs to the next level.
I also actively try to raise the profile of SketchUp in the larger 3D world and refute those who label it a toy, and try to tear it down.
I'm doing my part, including shelling out the money to make this a better program -- so I'm not one of those who like to tear stuff down just to be a sourpuss (I hate those people). However I'm not going to turn a blind eye to areas that need obvious (and major) improvement in order for the program to stay/be relevant long-term. Because of what I do for living, I pay particular attention to areas people struggle with and try to find solutions... I wouldn't be very good at my job if I did ignore this stuff.
Best,
Jason. -
Guys, If I may throw my proverbial two cents into this discussion.
Sketchup is just a tool, at least to me it is. I use Sketchup for many reasons like ease, convenience, great UI, navigation, integration, etc. However Sketchup has limitations and the sooner you realize them and find away around them the better, I spent the best part of five years complaining about them until I came to the conclusion some things can not be fixed easily and may require SU to be gutted and started from scratch and most probably would end up being something completely different from what it currently is and result in even more unhappiness.
So I found a way around it, or better still I learned to work to it's strengths and around it's weaknesses, like using 3rd party apps for UV mapping when essential (not something I'd bother with if only needing one view where a simple projection would do)
As far as vegetation goes things are a little more complicated, firstly are you rendering?
If yes then are you rendering in Sketchup? if yes then you do have an issue and maybe 2d is the answer if scene requires a lot of vegetation. If you are however using a studio based render app like Indigo, Maxwell or Thea render or even a standalone app like Vue then you can add all the vegetation you want in them without any worry.So to sum it up, find a way around SU's short comings, it may require learning another app.
-
Well said
I give similar advice often... however that often seems to be something unpalatable to other users.You know the gutting thing is inevitable -- it will have to happen sooner or later and every software I've been using for 10+ years has already rewritten their core -- which (as you say) isn't painless but is a requirement for continued relevance in the competitive software environment of today.
I guess the thing that irks me a little is the SketchUp dev team may be small, but it doesn't need to be... nobody doubts Google could finance a major overhaul of Sketchup easily if it were so inclined... which gets back to my point about Google being bad stewards of SketchUp in another thread.
Best,
Jason. -
..or maybe another application developer would realize sketchup's potential and adopt it's ease (and all other good things about SU, some mentioned already, to add accurancy and being almost perfect for architectural sketching and even developing) into their program.
Like 3ds's graphite modeling tools or Autodesk's 123D. (Still far away)
Even if it would be sad to leave SU.. i probably would
I hope SU stays in the race.
Maybe we should sign a petition to google..
They (it) could reign the 3D world as well.
-
It also helps to work with Components in large scenes e.g. master-plans with many buildings.
This Is how I make it work, each building gets roughed out in the beginning scene, then I save each building as a separate file (select all the geometry linked to the building, pres "G" to create the component, then right click the component and choose save as from the context menu. that will create a separate file for the building on your HDD), which is actually linked to the master drawing.
Then you can open the newly created building file (just remember where you saved it), detail it with windows, roofs, embellishments,when finished, save it to the same location.
Then open your master file right click on the rough building and choose from the context menu the option load. you will be prompted to confirm the replacement.
Do this for all buildings in the scene.
If you are really into it you can also save high and low res buildings and name them accordingly, that helps with setting up POV's on your map; when navigating, load the low res, set up the scenes then later re load the higher res ones where you need them.
Just wish they could add some kind of LOD manager tool.
Hope this helps.
-
Just got informed by mail about your response- the thread is almost two yrs old
But thanks for your workflow- actually it would be nice if it wouldn't disappear somewhere as it is a good how-to.
There are some more ways to handle larger scenes or objects with high poly count:
- using layers
- using ghost-components plugin
But loading / replacing components from single files is definitely good- building up some kind of library for future use is surely beneficial.
Advertisement