Here's a link on how to configure grids for the viewer, http://opensimulator.org/wiki/Viewer

If they're running a mesh enabled simulator and running a stand alone simulator, instead of using hosted service like Second Life or Inworlds, they need to configure the sim, http://metatek.blogspot.com/2011/07/multi-user-sim-on-stick.html also check http://opensimulator.org

If you have a mesh enabled browser, when you click build, select upload and don't see model, either the sim or the region isn't mesh enabled. If it's standalone they need to back up their inventory, OAR files then install a newer version, OpenSim 0.7.2 is mesh enabled. If you're using a hosted service, you're SOL.

As a precaution, export the model as both obj and collada, and use MeshLab to import the obj to export as a collada. There's still a problem with uploading SketchUp exported collada files, it's either the exporter or artifacts in the model.

So the problem is in the collada file exporter instead of the issues with the model's geometry, grouping, and textures? If so, would the simplest workaround be to use a converter like FBX? Or would there be an issue involving reworking/cleanup that would require the file to be imported in another modeler?

One virtual world allows collada file uploads for content. There's some issues involving files that SketchUp exports. Any thought on what's causing a lot of very, very small meshes, the mesh acting as if it were partially exploded, the extra vertices, the extra textures, and what can be done to prevent these from occurring?

Runitai Linden said about SketchUp at SLCC, during The Future of Mesh presentation: "We have a list of applications we test against. Blender ... we wanna make sure we're compatible with Wings3D ... and 3D Studio and Maya because they're the big players from Autodesk. ... and Zebra. You'll notice that I didn't say SketchUp, and that's intentional. SketchUp's exporter creates content that just isn't very efficient for the Second Life importer. You end up with a lot of very, very small meshes, and there's a lot of overhead in Second Life for each individual mesh object."

Besides the numerous small meshes, people importing in Blender to export mention having to clean up the numerous extra vertices. Some texturing in SketchUp to upload instead of importing in another program to texture mention about it causing mesh issues as follows.

When you rotate a texture on a face, SketchUp interprets that as a new material, and saves it as a secondary texturable surface. When you get it into SL, you'll now have "2 textures" on the cube.It causes a problem if you're building a semi-complex object, with let's say 10 sides. The max number of "faces" (textures) that a mesh in SL can have, is 8. So even if you're using the same texture over and over again, and just scaling and rotating it, it can unexpectedly create more than 8 faces in the mesh... resulting in the mesh uploading as "more than one part".

Another issue about the mesh that after uploading it's not grouped as a single mesh, with or without textures. It doesn't matter if you exporting the model "as is", make the entire model into a group before exporting, or make the entire model into a component before exporting. If you click on the mesh then try to move it, only a small part follows, leaving the rest behind, as if it were partially exploded.

That answers it partly, the normal map goes in the layer above the diffuse map and blend is set to multiply. But for multiple maps, how are the layers supposed to be organized (with the diffuse map always the bottom layer)?

Is the layer order supposed to be as follows from top down or does it matter with the exception that the diffuse map is always the bottom layer?:

1. ambient occlusion
2. displacement
3. specular
4. normal
5. diffuse

Is blend mode for maps 1-4 except normal map set to multiply, or is normal set to multiply and maps 1-3 (ambient occlusion, displacement, and specular) set to overlay?

Do normal and ambient occlusion maps need to be desaturated first or does it matter that these are not greyscale?

I'm wanting to tweak a texture by extracting maps out of a texture then merge the original texture with the maps in a photo editor and import the final texture in SketchUp. The books I found for PhotoShop or PS Essentials don't cover using it for this purpose. Are there any online guides that cover the steps and suggested settings after the maps and the original textures are first brought in the editor up to the point just before the layers are merged into a single layer?

One program doesn't generates an ambient occlusion map but does generate normal, diffuse, specular, and normal maps. Is there a simple way to make a "fake" ambient occlusion map using PhotoShop or PS Essentials with the original texture and the maps, or to compensate for the lack of an ambient occlusion map?

After running a search on compatibility files I read one of the older threads, http://forums.sketchucation.com/viewtopic.php?f=323&t=17947&p=203864&hilit=Compatibility+files#p203864 that mentioned that the Smustard Organizer plugin caused errors similar to the ones I was having with LibFredo6 instead of the compatibility files system being the perpetrator. I tested this theory by changing the file extensions of Organizer.rb, SmustardOrganizerExcludeFolders.txt, and restarted SketchUp 3 times without an error message. It doesn't make sense that all the other plugins loaded without a problem. The last plugin I installed, LibFredo6 caused error messages, but first plugin installed, Organizer caused the problem.

Another thing that doesn't make sense is the compatibility files system. When I deleted the organizerEdit.log from the virtualstore directory, the compatibility files button on the explorer window dissappered, but I didn't delete the defparms folder (contained no files) and the twilight folder (only contained the twilight license). Why would the compatbility files button dissapear even though not all of the content has been deleted?

Is there any workaround to get this plugin to load?

Nothing from LibFredo6 is in the directories listed above. I had SU v7.1 with LibFredo6 installed without getting the errors. The only difference is that I've just installed SU v8.0 then LibFredo6 in it's plugins folder and now experiencing the errors.

I uninstalled the directories and scripts for each plugin, restarted Sketchup with no errors, then extracted LibFredo6 3.4c to keep the file directory structure intact, then reinstalled. Starting Sketchup shows the following errors, is there a bug using SketchUp v8 with LibFredo6 3.4:

Error Loading File C:/Program Files/Google/Google SketchUp 8/Plugins/LIBFREDO6_Dir_34/Lib6Config.rb
uninitialized constant Traductor::T6Error Loading File C:/Program Files/Google/Google SketchUp
8/Plugins/LIBFREDO6_Dir_34/Lib6Palette.rb
uninitialized constant Traductor::T6Error Loading File C:/Program Files/Google/Google SketchUp
8/Plugins/LIBFREDO6_Dir_34/Lib6Plugin.rb
uninitialized constant Traductor::T6Error Loading File C:/Program Files/Google/Google SketchUp
8/Plugins/LIBFREDO6_Dir_34/Lib6Protractor.rb
uninitialized constant Traductor::T6Error Loading File C:/Program Files/Google/Google SketchUp
8/Plugins/LIBFREDO6_Dir_34/Lib6Selmode.rb
uninitialized constant Traductor::T6Error Loading File C:/Program Files/Google/Google SketchUp
8/Plugins/LIBFREDO6_Dir_34/Lib6Startup.rb
uninitialized constant Traductor::T6Error Loading File C:/Program Files/Google/Google SketchUp
8/Plugins/LIBFREDO6_Dir_34/Lib6Tool.rb
uninitialized constant Traductor::T6Error Loading File C:/Program Files/Google/Google SketchUp
8/Plugins/LIBFREDO6_Dir_34/Lib6Web.rb
uninitialized constant Traductor::T6