Google is Listening!
-
@krisidious said:
"ghost components" plugin accomplishes this.
Not automatically and dynamically though. However TIG's MatrixProximity plugin does (somewhat):
http://forums.sketchucation.com/viewtopic.php?t=7612It works by scenes, so you need to set the three, different versions for close, mid and far distance manually - then it "remembers" these settings.
Certainly a general (and native) LOD engine in SU would be nice.
-
@gaieus said:
Certainly a general (and native) LOD engine in SU would be nice.
I'm hoping to be able to add something like that into BezierSurface. Though no need to manually create different types of geometry, the nature of bezier surfaces lets you avoid that - but it won't be changing the LOD live as you move the camera.
-
@jbacus said:
@kydbmaster said:
I am wondering if the xFrog programing library could be incorporated in to SU perhaps as a SU plug-in so that organic models would change in complexity as you zoom in and out and as a user moves closer to organic models in SU.
Fundamentally, the xFrog library is automatically creating multiple geometric LoD's (Levels of Detail) and swapping them in and out of the model as the camera position changes. This is possible primarily because xFrog models are so parameterized to begin with. Unfortunately, SketchUp models aren't parameterized in the same way– which means that the xFrog library doesn't provide a solution that would be of any benefit to SketchUp users.
john
.John,
Obviously you can go down the route of (1-ring) decimation etc, but I'd suggest you revisit Impostors. While its true the free form nature of SketchUp makes LOD a tougher problem, I think the Group/Component structuring could be leveraged to partition your heavy weight models into chunks that could cached as Impostors.
Adam
-
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?
-
@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 modeller, 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 modeller 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 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
Advertisement