Improving the tool chain for bringing Sketchup models into realXtend
Posted by Peter Quirk under Uncategorized | Tags: Google 3D warehouse, Ogre mesh, realXtend, realXtend_0.4, rexmeshtool, Ruby, Sketchup, xml2mesh |
Back in July I posted a tutorial on how to use Google Sketchup to bring models from the Google 3D Warehouse into realXtend. It proved to be the most popular article ever, and has been translated into a number of languages. The process has a number of manual steps which annoyed me. Another concern was the way that the exporter script dumped all objects in the same directory, but the xml2mesh tool (or rexmeshtool?) would crash if there were .material files from multiple models in the directory. My original process included a batch file to cloak all .material files from other models by adding a .cloaked suffix and another script to uncloak It was also clear from questions from readers that the process was error prone. Yesterday I decided to fix it.
The solution involved hacking the Ruby scripts to create a separate folder for each model exported from Sketchup, and invoking the rexmeshtool application after the OgreXmlConverter was run. A side benefit of the process is that the log files for each export and conversion are stored in the model’s folder.
Since I was using a newly built PC, I installed the just-released Sketchup 7 and started to modify the scripts mentioned in the tutorial. (The scripts were written by Fabrizio Nunnari, based on the initial script by Kojack.) When I finally tested the results this morning, realXtend 0.4 wouldn’t import the meshes. Since I was using a new version of Sketchup, a new version of realXtend and a freshly rebuilt laptop, I had to test a number of configurations to determine where the problem lay. I was able to import the meshes produced by Sketchup 7 into rexserver 0.31 using rexviewer 0.31 on an older laptop, but could not import them using the rexviewer 0.4 connected to rexserver 0.31. I logged a bug report in SourceForge this afternoon and posted a message in the realXtend group. Eight minutes later Gustavo Alberto Navarro Bilbao confirmed that he had discovered the same problem with realXtend 0.4. I have subsequently verified that the meshes can be loaded without errors by the Cegui Mesh Viewer.
Since I had to learn Ruby yesterday to modify the exporter script, and the author of the script was also a first time Ruby coder, I’ll do a little cleanup before I post the revised scripts here (today or tomorrow). The scripts are not backward-compatible with Sketchup 6. If possible, I’d like to address that problem before I release them. If any Sketchup plugin developers have pointers to the API documentation for chdir, mkdir_p and similar calls for Sketchup 6, please drop me a comment.
First of all, sorry for my bad English. Thank you very much for your work. Good thing than you are working on it, because otherwise I do not think anyone will be to resolve that bug.
RX developers now have other priorities, and our mesh are there, unable to be uploaded to RX 4.0
Incidentally, another problem is the limited size of the mesh. While locally, with version 3.1, I was able to upload mesh of 5 or 6 Mb, when we tried to upload a public servant that we are setting up, uploaded mesh can be no higher than 1'2 -1 '5 MB.
I asked for this limit in the RX forum, but the answer was a little "abstract", becuase a developper answer than it's cuased for the limitations of the LAN, but I was not using a LAN, we was was trying to upload the mesh to a server on which we are working. That requires chopping buildings ;-)
Again thank you for your dedication, in the name of all the suffering people that are fighting with the mesh and realXtend.
Muchas gracias ;-)
Posted by: Gustavo Alberto NAvarro Bilbao | December 18, 2008 at 09:10 AM