Sketchup 64 bit?
-
@unknownuser said:
Have to admit it's not just because of lacking with 64 bit, but simply they need a tool that can produce and handle huge amounts of polygons
And this is my only concern, I care less how it's done just that it's done. I come up against this daily as the nature of my work requires higher poly modeling, so I'm at the proverbial fork in the road, do I continue my convoluted and rather hefty workflow by patching all high poly models in studio or do I move on to an app that can handle more poly's?
basically my laziness to learn a new app to the extent I know SU has been the only reason I'm still here.
-
I can only go by how often the issue pops up for Maxwell users, where the problem is the 4 Gb limit on RAM, and various workarounds must be used... which I suppose is tolerable for full Render Suite users (like myself), but useless for stand-alone plugin users.
Not knowing the particulars of how Thea implemented rendering inside SketchUp, I would hazard to guess that those users will run up against this issue where, whether they want to keep using SketchUp or not, they will be forced out into the "studio" component simply because SketchUp can't handle the job.
I suppose the situation is even more dire for rendering engines that are run solely inside SketchUp... but I'm not sure any of those would benefit from the extra polygon detail the way unbiased engines do (Twilight would be my only guess here).
I've said it for a long time -- that Maxwell (and Unbiased rendering in general) and SketchUp are working towards contrary goals... meaning the way SketchUp wants to work, and the way a Unbiased engine wants things to be, are not really ideally compatible. I am of the opinion that SketchUps way of working is antiquated, and no longer useful the way it was even as recently as 5 years ago... low-poly modeling is no longer the order of the day -- even in poly-count sensitive areas like video games. The very last place this was useful was Google Earth... but who cares about that now that Google is gone.
SketchUp feels old and clunky -- in more than one way.
Best,
Jason. -
Regarding high poly modelling, aren't most engines supporting proxies now? Even V-Ray for SketchUp is getting proxies in it's next release.
All modelling tools will struggle under heavy poly count. And if you compare against other applications you can see how they usually provide a much more degenerated view of the model and leave the presentation to the render engine. While SketchUp has its real time sketchy render engine running at all time - generally providing a better presentation of the model in the viewport than what other engines do. It's quite a different animal from most out there.
-
External Proxies/Instances are besides the point -- the geometry must be still loaded into the 32-bit SketchUp process in order to be rendered inside SketchUp... so even proxies can put you into a RAM based failure to launch the render.
The reality is that SketchUp cannot adequately support the tools visualizers are using as a host app... and the concept of SketchUp as a platform is a failure because of that.
Every workable solution I've seen requires the user to leave SketchUp -- which by definition means it fails as a host.
I've not seen any other modern software that struggles as badly as SketchUp -- the "real-time" rendering in SketchUp might be part of the problem, and obviously you can also blame the inferencing engine as well to a certain degree. But better packages allow you to disable/enable those features as needed, rather than forcing you to suffer through them because of some philosophically misguided rationale of "simplicity trumps all"... which to me reads more like the developers (Bacus) saying "I know what's better for you than you do".
Best,
Jason. -
@thomthom said:
SketchUp has its real time sketchy render engine running at all time - generally providing a better presentation of the model in the viewport than what other engines do. It's quite a different animal from most out there.
If I had my way I'd relegate this to Stylebuilder.
Tyler built a robust tool to load, generate and save styles. It could easily be used to display models to clients.
You could even safely send a client a .style file that contained a model that is locked from editing.
At least this is how I see it in my brain....
-
If I had my way I'd relegate this to Layout -- which is natural environment for real rendering of SketchUp Styles. Layout has presentation mode which is far more suitable to the task.
Best,
Jason. -
@jason_maranto said:
Every workable solution I've seen requires the user to leave SketchUp -- which by definition means it fails as a host.
The render engine can pipe the data to a 64bit process - so only the UI is hosted under the 32bit environment of SketchUp.
-
True, but it's a complete cop-out...
Each developer would be required to redo the work to make this happen -- which I've already covered the ridiculousness of.
If SketchUp was any kind of competent platform, it should not require 3rd party developers to repeatedly do extra and unnecessary work. I think if most of the 3rd party developers felt free to be honest they would publicly agree with me...
But honestly these conversations keep going in circles.
Best,
Jason. -
@jason_maranto said:
Each developer would be required to redo the work to make this happen -- which I've already covered the ridiculousness of.
One could ask why these developers did design their system like this to begin with...
It's not like they where not aware of the limitations. And it's not like they had been promised it would come in the near future.@jason_maranto said:
But honestly these conversations keep going in circles.
This is all too true.
-
At the end of the day Sketchup is now owned by Trimble, and we know what they do, so I believe my concerns regarding SU limits is also theirs as lets be honest low poly terrains for such sophisticated surveying hardware will not work out that well, they are gonna need to up the polys at some point.
-
I could put it another way -- do you know that of all the modeling platforms Maxwell supports with plugins (15 and counting) Sketchup is the only one without built-in 64-bit support.
Which means any work done for this type of kludge would have absolutely no benefit for any of their other platforms -- it's wasted energy.
SketchUp is deservedly the red-headed stepchild of the 3D world... not because of it's users, but because of it's developers.
Best,
Jason. -
I've red-hair
Now the gloves are off
-
So does my best friend -- and he's a step-child as well, so he gets indignant when I use that phrase...Best,
Jason. -
@thomthom said:
@jason_maranto said:
Every workable solution I've seen requires the user to leave SketchUp -- which by definition means it fails as a host.
The render engine can pipe the data to a 64bit process - so only the UI is hosted under the 32bit environment of SketchUp.
Perhaps platform specific solutions (http://msdn.microsoft.com/en-us/library/system.servicemodel.netnamedpipebinding.aspx)? If so, then multiplatform programs could have issues (or at least do require more work). Like said, communication between 32 bit process and 64 bit is possible, but for some reason it's not used that often... I am pretty sure that there must be some good reasons for that
-
@jason_maranto said:
External Proxies/Instances are besides the point -- the geometry must be still loaded into the 32-bit SketchUp process in order to be rendered inside SketchUp... so even proxies can put you into a RAM based failure to launch the render.
The reality is that SketchUp cannot adequately support the tools visualizers are using as a host app... and the concept of SketchUp as a platform is a failure because of that.
Every workable solution I've seen requires the user to leave SketchUp -- which by definition means it fails as a host.
I've not seen any other modern software that struggles as badly as SketchUp -- the "real-time" rendering in SketchUp might be part of the problem, and obviously you can also blame the inferencing engine as well to a certain degree. But better packages allow you to disable/enable those features as needed, rather than forcing you to suffer through them because of some philosophically misguided rationale of "simplicity trumps all"... which to me reads more like the developers (Bacus) saying "I know what's better for you than you do".
Best,
Jason.The real time rendering or viewport performance don´t get any advantage from the jump to 64bits, I think also there is no viewport performance gain in any 3d software from going 64 bits or more CPU cores. On the other hand taking advantage of the GPU its exactly what matters in this case, I´ve been using blender for about two years and before that 3dsmax, In fact the viewport in sketchup are ages in front of these two, as there is a clear and unique hierarchy in the visualization as a whole: lines, hidden lines, smoothed lines, faces and textures.
In other apps to have this control over all the meshes of my scene I´ll usually have to jump in specific view preferences, modifiers preferences, proxy object propriety etc. and still only one at a time.
In fact I can only imagine using any other viewport at all it´s because the modifiers, that enable you to manipulate the high poly meshes or polys, they have some LOD setting and don´t display the complete mesh all the time.
And if I want to produce hi-poly renders I´m happy to work with my model surrounded by low poly avatars of the objects. But really for me the unique feature that make me use sketchup it´s about visualize and explore so this is the completely the other way.In my opinion you should take a look in another software, I did some years ago when I was needing to produce and control heavy poly models, and at that time I was feeling refreshed for all the new possibilities, still after some time I´ve came back to sketchup and even became a PRO user for what it is.
-
I wasn't referring to any advantages of 64-bit in regards to viewport rendering (which is open GL/video card based) -- there are several competing points being argued here, of which 64-bit is only one small part.
Also, I have said repeatedly (elsewhere) I already do use several other 3D modeling packages (subD, Sculpting, etc.) -- it's not any mystery to me how the other parts of the 3D world live.
I know few people here know much about me, but I do get tired of repeated shooting down the same arguments... I dislike repeating myself, and this conversation has become almost entirely repetitive at this point -- So I'm going to bow out.
I've said what I've said -- I meant it all, and nobody has convinced me otherwise... so I'll let that stand.
Best,
Jason. -
@thomthom said:
And if you compare against other applications you can see how they usually provide a much more degenerated view of the model and leave the presentation to the render engine. While SketchUp has its real time sketchy render engine running at all time - generally providing a better presentation of the model in the viewport than what other engines do. It's quite a different animal from most out there.
i don't know about that thom..
here's a little vid showing an xfrog tree in rhino.. at first, i show the wireframe or degenerated view.. then the shaded view which is, as far as i can practically gather, the same thing we see in sketchup.. then i switch to rendered viewport which shows all the textures along with soft shadows etc..
that's on a 3yr old laptop which is also running a screencapture software at the same time.. do it on a more suitable workstation and it takes a few of those trees just to show any sign of weakness..
also, it takes about 1 second to import that into rhino.. we're looking at maybe 30 minutes to get it into sketchup at which point, the model is all but unusable anyway because sketchup becomes so sluggish..
so from a user standpoint, i'm actually seeing better real time rendering at a very (very!!) noticeable performance increase compared to sketchup.. when using the same exact geometry and textures..
so when i see this type of stuff with my own eyes on my own computers and my own projects, i can't help but wonder "what in the duck are those su devs sitting around doing all day??!!... it's obviously (very obvious!) possible to get way better performance out of a 3D modeler " ..or whatever..
-
@unknownuser said:
so when i see this type of stuff with my own eyes on my own computers and my own projects, i can't help but wonder "what in the duck are those su devs sitting around doing all day??!!... it's obviously (very obvious!) possible to get way better performance out of a 3D modeler " ..or whatever..
and seriously.. i'm open to other people showing my the flaws in my logic here.. i mean, if I'm incorrect in my thinking here, how should i be processing the above scenario in my head?
.
[edit] i should also add that this is mac rhino.. the rendering engine being used at this point in the beta is the old rhino4 engine.. i imagine things are way better on the official 5 release..[edit2].. see this as well:
http://blog.rhino3d.com/2012/04/neon-10-beta-1-now-available.html -
My comments and opinions are mine and mine alone. My goal is not to argue, debate, or sway. I simply want to express myself.
I've worked with John for a little over 7 years now. He is a decisive, intelligent, and fantastic leader whom I would follow to any company. Period. I understand that excuses are not requested here, only results. Well, we've been hiring roughly a new person every month since beginning with Trimble. A huge breath of fresh ideas and innovations have been infused into SketchUp's (pale?) skin. It's no mystery that development on the SketchUp client slowed near the end of our time at Google. However, the improvements that I've seen over these short months have been astounding to me. I feel like everyone is very excited for the huge potential and future for SketchUp. Albeit, many wholes have yet to be filled, but that's a challenge we're prepared to face. Will you be blown away with the next version of SketchUp? I don't know. We'll find out. Ripping a software infrastructure out of a company (especially Google) and setting it up in another company isn't exactly like moving a tent between two camp grounds. We're working fast and furious to deliver great products (because SketchUp is only part of our portfolio), but it may take some time to see the strides of innovation that we expect from ourselves (let alone the expectations of SketchUp's passionate community). Patience is a luxury that no software company can ask of its users, and I won't do so today. If you've used SketchUp to successfully complete a project in the last month, year, or eight years, then we've done our job. Of course, we want all SketchUp users to continually find success with SketchUp every day, and if they don't they should absolutely explore other options. Competition does wonders for innovation as well (I learned that at Google
.Many thanks for lending me your time and attention.
Cheers!
-
Thanks for chiming in Tommy. I do look forward to seeing what SketchUp 2013 brings. I realise it takes a while to reorganize and that lots of the time spent the last year has been restructuring from Google to something new, but just the fact that SketchUp is now looking get annual release cycles gives me good hopes. My expectations of the next release is a small indication to what I could expect in the future - contrasting it to the direction we saw Google taking it.
It'll probably be of no surprise to anyone that I'll be looking more toward what the Ruby API will give than anything else.
Advertisement