New book: Google SketchUp Workshop

When it comes to instructions for building your first house, or your first bench, or your first Google Earth model, there is no shortage of available materials. But what happens after you’re a SketchUp rockstar? Where are all the tomes full of delicious inspiration for those of us who have mastered inference locking and nested section planes and scene properties? It’s all fine and well to read about how SketchUp works, but real progress comes from peeking over our peers’ shoulders to see what they’re working on.

And that’s exactly the concept behind Laurent Brixius’ brilliant new book Google SketchUp Workshop. Translated from the original “Créer avec SketchUp” (originally published a few years ago in French) this full-color volume presents sixteen beautifully illustrated case studies authored by expert SketchUp users from a multitude of different disciplines. Each one includes high-level workflows, tips and techniques for using SketchUp in a different field of design. Architecture, urban design, engineering, process plant design, woodworking, theater set design and architectural graphics are all represented.

Our friends over at SketchUpArtists.org conducted a nice interview with Laurent (the book’s editor) before the English edition came out. An architect, architectural 3D artist and author from Belgium, he’s done an amazing job of assembling a collection of projects that are pure inspiration. This is a book that belongs on the shelf of every SketchUp aficionado.

Google Code-in Winners Arrive at the Googleplex

Earlier this month the Google Open Source Programs Office hosted the Grand Prize winners of the Google Code-in contest, a contest designed to introduce pre-university students (age 13-18) to the many kinds of contributions that make open source software development possible. Students worked on many types of task including: writing or refactoring code, documentation, translations, outreach/marketing, quality assurance (testing), conducting research, training, and user experience research. Students earned points for each task they completed, with the top 14 point accumulators winning a trip for themselves and a parent to the Googleplex in Mountain View, California.

Day 1
Upon their arrival in the San Francisco Bay area, students had their first meet-and-greet dinner at their hotel near Google. Many students had worked with the same open source organizations so they had ‘seen’ each other in chat rooms, on IRC, and on group lists but this was the first time the students actually met one another. The bonding began right away as students quickly started moving tables together as more students arrived so that all of the students could talk to each other.


Day 2
Students and parents spent the next day at the Googleplex. The morning began with an introduction by Google Code-in Program Manager, Carol Smith, congratulating the students on their achievements and giving them a talk on Google Summer of Code, our worldwide program for university student developers giving them stipends to write code for various open source software projects.

Next, the students were treated to a talk by Alan Eustace, Google Senior Vice President of Knowledge. Alan discussed the evolution of search and where we go from here.

Three engineers in our Open Source Programs Office, Shawn Pearce, Junio Hamano and Dave Borowitz, chatted with the students about their roles at Google, their work in open source and specifically with Git.

Lilli Thompson, Game Developer Advocate for Google, discussed her role at Google and her experience as an engineer in the gaming industry.

Lunchtime at Google’s largest cafe was next on the agenda followed by a tour of the Google campus. One of the stops on the way was the picturesque front lawn of Mr. Android, complete with all of his releases: cupcake, donut, eclair, fro-yo, gingerbread and honeycomb. Perfect place for a photo op….


…then on to the Google onsite store to pick up some fun schwag to take home to friends and family.

When the students arrived back to our conference room they were welcomed with large plush bug-droids, compliments of Dan Morrill and the Android team. Dan chatted about Android and took questions from the students and parents.

Jutta Degener discussed her job as a Software Engineer working on the Borg cluster management system.

Jeremy Allison, co-creator of Samba and Open Source Programs team member, engaged the group in a lively discussion about why open source development is important to the world and the important role these students can play in the years to come.

Chris DiBona, Manager of open source at Google, encouraged the students to continue working on open source software development as they move into university. He also discussed the importance of open source software at Google and more history on the Google Summer of Code program. Then it was time for the awards ceremony for these amazing students. Chris DiBona presented each student with their engraved, very substantial (ie. heavy) awards.

We wrapped up the day with chief Java architect and Open Source Programs Office team member, Josh Bloch, running through a few Java puzzlers with the students.

Day 3
Students spent the next day of their trip in San Francisco enjoying a behind the scenes tour at the California Academy of Sciences complete with a planetarium show. To have energy for their next adventure, the group filled up on chocolate ice cream and banana splits at Ghirardelli Chocolate shop. Then the parents and students spent 2.5 hours on segways touring around Fisherman’s Wharf and the North Beach neighborhood.


The students traveled to Northern California from 8 countries: Austria, Brazil, Canada, India, The Netherlands, New Zealand, Romania, Turkey, and the United States. This group was a great representation of the talented students around the globe interested in open source software development.

The students left all of us in the Open Source Programs Office feeling lucky to have met these rising stars in the open source world. We hope to see them again in Google Summer of Code (once they are old enough) and at future open source events around the world. We’re sure this is not the last we’ll hear of these bright, hardworking, humble, gracious young adults.

Google Earth: The New Acceptance Criteria for 3D buildings

It was over five years ago when we came up with the initial Acceptance Criteria for photo-textured 3D buildings in Google Earth. Since then, we’ve learned many things and have also made many improvements to the 3D modeling process—including the release of Building Maker and two updated versions of SketchUp. Given all of these changes, we realized that our Acceptance Criteria were due for an overhaul.

Our new Acceptance Criteria have been completely rewritten with the goal of making them clearer and easier to follow. Issues relating to photo textures, permanence of structures, splitting, and entourage have proven to be the most common areas of confusion in the past:

Photo Textures

Our new minimum requirement for photo textures is more lenient than it’s been in the past. Photo textures are only required on upward facing surfaces of the model and on the main facade. We encourage you to photo texture the entire model, but we also understand that it may be difficult to get accurate imagery on every side of some buildings. Any remaining, non-photo-textured faces in your model should be painted with realistic-looking textures that match the color and look of the building in real life.

Permanent Structures

Beginning today, only permanent structures will be accepted. As we constantly refresh our satellite imagery, temporarily-positioned entities like vehicles and people don’t belong in Google Earth’s 3D Buildings layer.

Model Splitting


From now on, all submitted models should contain only one structure each. Each structure should be uploaded as a separate model file. This includes properties that have multiple buildings on them such as a house and a shed or garage. If buildings are all connected in a city block, they should be split into separate models based on building type, function or address. When our review team is assessing connected block models for splitting issues, we will look at the facade and roof textures to see if there are changes in material that signify where a split should have occurred.

Entourage


In addition to splitting buildings, we are now requiring all models of trees and other permanent entourage (such as signs, light posts and benches) to be uploaded separately from the buildings with which they may be associated. This ensures that when another building is uploaded in the same location, we are only judging the quality of the new building model versus the original. It’s a shame to have to remove good tree models just because they’re attached to a building model when a better building model is submitted that doesn’t contain trees.

Also, multiple, related trees and other entourage objects can be grouped into a single model as long as they are located in a relatively concentrated area. This means a single model can contain all the trees for a block or a park, but it shouldn’t contain all the trees for multiple blocks or an entire city. Remember that only permanent entourage is acceptable—cars and pedestrians move around, and thus don’t belong in Google Earth’s 3D Buildings layer.

Other improvements

One other big improvement we’ve made is the addition of tips and suggestions to each of the thirteen individual Acceptance Criteria. If a model you submit isn’t accepted, you’ll receive an email notification (opt into these emails via your preferences) that includes a direct link to concrete information about how you can improve it before you re-submit.

What about models that have already been accepted?

To help make this transition easier, we won’t be going through all the models we’ve already accepted in order to remove ones that fail to meet the new Acceptance Criteria. If your model has already been accepted, it will stay in the 3D Buildings layer until and unless it is sent through the evaluation process again. There are four actions which can cause a model to re-enter this process:

  1. You make an edit to your model and re-upload it to the 3D Warehouse, replacing the previous version.
  2. Someone else submits a model in the same location as your model.
  3. Periodic terrain and aerial imagery updates cause your model to go through our automated alignment process.
  4. Someone clicks the “Report a problem” link for your model in Google Earth.

It’s still a bit of a subjective process

Keep in mind that judging 3D models is still a difficult task and is prone to subjectivity. All submitted models are reviewed by real human beings who take time to ensure that they meet our standards. Because human beings sometimes make mistakes, we have a way for you to appeal negative judgements. If, after reviewing the Acceptance Criteria, you feel we’ve made the wrong decision, use the “Tell us why we’re wrong” link (at the bottom of the model’s 3D Warehouse page) to ask us to take another look. You’re encouraged to include links to photos of the actual building or other online resources to will help us to understand your point of view.

We know how much time and love goes into making beautiful 3D models for Google Earth, and we greatly appreciate all the effort you put into your work. Here’s hoping that the changes we’ve made will make for a smoother, more enjoyable geo-modeling process for everyone.