Google is Listening!
-
By the way- it looks like this thread is starting to collect technical support issues for SketchUp 8 rather than discussing feature requests and our 2010 "Questions & Ideas" series. If you're in need of technical support, you're more likely to get a response from the SketchUp support team on our SketchUp Help Forum than you are 17 pages deep in this topic.
john
. -
Wow. Quite the ordeal. I've upgraded 3 times now with no issues. O.ly time I had serious lag was waiting for a path / response to a question on transferring my license to a Mac from my PC. That took quite awhile. Bit otherwise - easy.
-
Thanks for responding so quickly, John. I apologize for not checking back sooner.
I do have a license for SU pro, though the program thinks it's a trial version and has expired on me. Ironically, it happened just after I entered the license and key.
-
That was easy to fix— I just installed the key a second time and it worked. Don't know why it didn't the first time, the program acknowledged the license.
Jim
-
I am interested in achieving better quality organic models in SU. My question is xFrogxTune has an innovative way of displaying organic models:
"XfrogTUNE uses algorithms that are specially adapted to manage the complexity and the level of detail in tree models. The basic concept behind XfrogTUNE is the reduction of complexity according to the distance between the viewer and the object. If the object is far away, the viewer cannot discern fine details anymore and thus the effort to calculate and display this detail is not necessary. XfrogTUNE allows for a dynamic reduction of complexity: When the viewer approaches an object more detail is added to the object and when he moves away from the object, more and more detail is removed. You can use XfrogTUNE to import models created in Xfrog and generate different versions of this model with different degrees of complexity. In this process the original Xfrog model stays untouched and keeps it’s full detail and complexity. Any reduced version is converted into the XfrogTUNE format that allows for very fast rendering and calculation of the model. This makes XfrogTUNE the perfect tool for the creation of organic models for the use in real time environments. The algorithms that are used in XfrogTUNE are also available as a programming library that can be integrated into any real time environment and thus allows you to use this high definition technology for dynamic complexity management in your own game application etc." 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? I know that xTune was designed for the gaming community but could it be adapted to SU? This would give the user a more realistic experience with organic models in SU. and also give the user upon export to a higher end modeler/renderer such as Vue to treat those xTune models in SU as proxies that could be swapped out through Vue's scripting language (python) with the original images designed in xFrog and saved in Vue's .vob file format. -
@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
. -
"ghost components" plugin accomplishes this.
-
@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..
Advertisement