Google is Listening!
-
Hi Adam!
I guess the best I can hope for (for now) is just place low-polygon count files in SU and then replace them at export time in Vue with the Hi-polygon count files there; retaining the orginal position and scaling of the low-polgon count files placed originally in SU.
-
Well lets not confuse different issues here...
There is the issue of improving the load balancing of SketchUp in general use, so it degrades more gracefully with large models.
There is a related - but different - workflow question about managing HD assets.
The latter can be handled right now with Proxy objects - I know LightUp allows you to right-click on a Group/Component and replace it with a simple Proxy while in SketchUp that will be replaced with the high resolution geometry when in LightUp Tourtool. I'm sure other Apps can do the same.
Adam
-
@adamb said:
There is no silver bullet here. There is just one - and only one - way of solving the issue and that is to keep a fat, easy-to-edit format as primary data and cache lean, fast-to-draw versions of it. What method you choose to use for this is, as they say, an exercise for the reader.
Right... well put, Adam.
john
. -
@adamb said:
Well lets not confuse different issues here...
There is the issue of improving the load balancing of SketchUp in general use, so it degrades more gracefully with large models.
There is a related - but different - workflow question about managing HD assets.
The latter can be handled right now with Proxy objects - I know LightUp allows you to right-click on a Group/Component and replace it with a simple Proxy while in SketchUp that will be replaced with the high resolution geometry when in LightUp Tourtool. I'm sure other Apps can do the same.
Adam
Hi Adam
Perhaps If we could get Google to support the full .rpc file format we could side step this issue of huge files.
s.
-
@adamb said:
@kydbmaster said:
Hi John,
What about letting an outside program like xFrogTune generate the files and just build the mechanism inside SU that calls the different files in as the distance from the camera to the object changes. SU would have to support the .LOD file format. It would not matter about the compatibility of the modelers in that case. Both programs do what they do best. On another note, does SU support the .FLT file format?
Well the runtime graphics library Google SketchUp uses does support model switching ("igLod" if I remember correctly), so that part is trivial. The problem for the Sketchup team is how do you solve - in a general way - the issue that this isn't static geometry. SketchUp is a modeler, not a Viewer. So while its possible to export geometry, generate some reduced complexity geometry and chain it into a viewing pipeline, that is a complete non-starter for a dynamic modeler in which users, well, model stuff.
There is no silver bullet here. There is just one - and only one - way of solving the issue and that is to keep a fat, easy-to-edit format as primary data and cache lean, fast-to-draw versions of it. What method you choose to use for this is, as they say, an exercise for the reader.
Adam
Hi Adam,
I have pondered your post for some time and I have some additional observations. First, we would be placing Geometry for Plants. Since Plants do not have legs the placement of the tree geometry is static. As a Landscape designer, the whole point of our work is space management. We must leave enough space between plants and other objects such as buildings (in the model and in real life) for growth of the plants. (Since shortly after planting, the plants can't be transplanted (esp. Trees) if they are planted to close.) Therefore The Geometry is static. To a point anyway. The center of the geometry is always in the same place in the model. The issue is that plants grow over time. We plant them when they are young and years later they reach their mature size. Using .LOD or .RPC files (.RPC files do support keyframe animations as well) would help us visualize the process. An Oak tree planted initially may only be 10 foot tall. In 80 years the same tree may be 80' tall and have a spread 6 or 8 times of that initial planting. Also Landscapes are constantly changing with the change of season. Using .LOD or .RPC files and some mechanism to advance the model through time would allow us to visualize the model correctly over time. If the geometry in the model expands into the geometry next to it that is what we are looking to eliminate. (sometimes the designers want the canopies of trees to grow together.) Landscape designers today are lucky to generate just one or two perspective renderings of a model. (because of cost and time constraints.) Using plant models from a company such as Bionatics (they use the .lod file format) would allow a designer to generate an unlimited number of rendered models on the fly. One of the problems Landscape Designers have is visualizing what a landscape design will look like when it is mature. The Client will have an even more difficult time visualizing what the landscape will look like years down the road (because of their unfamiliarity of how the plants grow.) By implementing .lod and a time mechanism, We could eliminate the tendency of designers to over plant and clients to better visualize what the design they are buying will look like long term. The result would be better designs that are more sustainable. My focus is obviously plant geometry but this could also be applied to other geometry in the model. People in the model for example. People placed in a landscape design generally are either standing or walking down a street or sidewalk. Using models of people in .lod or .rpc format would allow for realistic movement in the model (down a pre-defined path). And maybe this is the answer to dealing with .LOD and .rpc files in general. That is associating a predefined path with the placement of the file. Note: that ArchVision has native and plug-in RPC support now exists in 3dsmax, Autodesk VIZ, Autodesk Civil 3D, Bentley MicroStation, Newtek's LightWave 3D, Maxon's Cinema 4D, AccuRender from Robert McNeel & Associates, Revit, Piranesi from Informatix, Adobe Photoshop, Graffiti RenderPro, Arc+ Render, VR4MAX, and SGI Performer.
s.
-
Hey Google!!Rhino has UV-unwrapping!
http://news2.mcneel.com/scripts/dnewsweb.exe?cmd=article&group=rhino&item=358869&utag=
-
I've always had this wish, amongst others:
Alpha channel support when exporting images.
Extremely handy for grafic post production works..
-
Hello everyone,
Just wanted to ask the forum if there is anyway to map solids on a curved surface to follow a curved path. Is it easy to do with 2D shapes and textures but not 3D objects....
Thanks Alot..
-
<shameless_plug>LightUp gives you unwrapping and alpha texture support.
</shameless_plug> -
@kostas_designer said:
I've always had this wish, amongst others:
Alpha channel support when exporting images.
Extremely handy for grafic post production works..You can export images with transparent backgrounds on the Mac today. Unfortunately, it isn't easy for us to support the same on Windows at this time.
john
. -
@kostas_designer said:
I've always had this wish, amongst others:
Alpha channel support when exporting images.
Extremely handy for grafic post production works..Fortunately ThomThom came to the rescue with this plugin for Windows: http://forums.sketchucation.com/viewtopic.php?p=270998#p270998
-
@d12dozr said:
@kostas_designer said:
I've always had this wish, amongst others:
Alpha channel support when exporting images.
Extremely handy for grafic post production works..Fortunately ThomThom came to the rescue with this plugin for Windows: http://forums.sketchucation.com/viewtopic.php?p=270998#p270998
Well-well, i didn't notice that!
Great work Thomas, as always!
Google people, I think you should PM the guy
-
Wouldn't it be the same as Parallel projection under the Camera menu combined with (in this case) a Top (standard) view?
-
1/2 a sec while I climb up on my soapbox.
OK. I made it through to page 4 of this, and after Coens comments (all too true) I have to add my $0.02CDN.
First, 64bit is a red herring. If the hardware, the operating system AND the application s/w are all 64bit compliant, the throughput of the machine MORE than doubles. I have heard the same bitches when we went from 8bit to 16bit, from 16bit to 32bit. And on the mainframes, going on to 128 and 256bits.
Long register adds are sped up by 4 at least because there is little overflow checking required.
GRAPHICS is a long register hog.Generally speaking when a "64bit" app performs less than expected on a 64bit CPU, it is all the more likely it is not optimized for 64bit throughout and still depends on legacy 32bit functions, which will slow down any 64bit CPU.
As for Google not listening.......
LadyBugz (Carolyn) posts only the first post, then NOTHING for 19 pages so far.
Same sort of response the last 4 1/2 years I've been using SU, and posting to the other SU BBS's including Googles "official" forum. A very typical "Post, Promise, Disappear" like they are training to become politicians.I've said this many times before..... Google SU developers are more interested in adding new bells and whistles than fixing perennial problems. (a few of the many I've complained about follows)
Like "Hyper zoom"
Like Failing to indicate WHERE the problem lies in face forming (gaps and non-planars). If SU can find a problem, TELL ME WHERE IT IS, not a simply useless error message. In fact SU8 is worse than SU6 in saying what the problem is.
Like gaps in intersecting
Like Feet-Inch-Decimal inch units
Like an Icon to toggle snapping
The list goes on...YES, I am fully aware of the selfless magicians who dedicate countless hours writing Ruby scripts to fix major deficiencies in SU, both bugs and "function not present" but should be.
Like Startup, which defaults the select cursor rather than the pencil
Like ThomThom's TT-Select toys and others
Like Fredo's JPP, Curviloft, and Onsurface
and my pluggin list goes on.Most of my plugins are FIXES to SU shortcomings, not added functionality.
Most of those plugins SHOULD HAVE BEEN PART OF SU, and some a long time ago.Yeah, Google listens
-
@jgb said:
1/2 a sec while I climb up on my soapbox.
....
Yeah, Google listens
Lots to agree with there.
-Brodie
-
-
I agree too but instead of creating some topics here, contact em each times I got new suggestion or waiting for a real wide 3weeks survey (lol) I prefer post here (as a wailing wall)
Also need a dialog box on new doc creation which propose us a template like all other soft do in fact... (quite bored to change it in preferences window before launching new document)
-
@sm4rt
Mate you should invest more time in the sketchup learning -
@jgb said:
As for Google not listening.......
er... how many times have I posted so far in this thread? Half dozen times, maybe? I think I lost count a few weeks ago. If you haven't picked up on this yet, I'm actually the Product Manager for SketchUp– which means I'm exactly the person you want to be reading your posts if you desire something about SketchUp to change in the future.
It may be useful to remember that having an idea yourself doesn't automatically mean that the feature should be implemented. It may not be something that legitimately benefits every user. Also, it may be that we like your idea, but can't implement it for any of a hundred valid reasons that have to do with time/money/resources or just some limitation in the way that SketchUp is designed to work.
Our occasional surveys and "Moderator" voting series' are a way for us to make some sense of the inbound feature requests. They aren't the sole source of input, but they are quite helpful. If you'd like to discuss new features you think we should implement or old features you think we should have implemented differently, I'm open to doing that. Ordinarily I do that on our Help Forum (in the "Feature Suggestions" category), and I post there quite regularly. Occasionally, I also read posts here on SketchUcation. I think I've responded in great detail to most of the concerns you've raised previously, but I don't mind doing so again.
john
. -
Hi John, don't get pissed off! We know you are a big SCF fan!
Advertisement