Painlessly export from Sketchup Pro 2013 to Cinema4D R15 Studio
I Use Google Sketchup Pro 2013 for modeling in 3D, and then I export said models into Cinema4D for Rendering and tweaking the textures applied in Sketchup. Most of the time it works, but on the odd occasion it doesn't export into Cinema4D as it looks in Sketchup.
Recently I made a building in Sketchup based off of a real life picture from a client, and after about 3 days of solid work I'm finally finished the model. When I opened the .3DS file from Sketchup in Cinema4D, though, almost none of my materials are importing correctly if at all, and when I try to reapply the materials to the areas which don't have the right materials I end up applying materials to the wrong areas as well as the ones I meant to. Below is the model I noted earlier and the version of it in Cinema4D;
I've tried everything within my mind to fix this- I've exported under every possible format and setting but to no avail, and nothing in Cinema4D can seem to fix this either. Is there any way to import a model directly from Sketchup into Cinema4D and have the model look exactly as it did in Sketchup as it does in Cinema4D?
PS. All answers are appreciated as this is a very urgent question!
First, COLLADA is a terrible format for 3D model interchange. Yes, I know this is what it was designed for, but I have almost never gotten two unrelated programs to agree on every detail about how to interpret a given COLLADA model. There's always something screwed up after the transfer. Sometimes it's something small enough that you can clean it up and move on, while other times it's bad enough to crash the app you try to load the model up in.
(I touch on related matters in a different question.)
I have never achieved "painless," but with some grunt work and patching, I've often achieved "eventual success." Call it moving the goalposts, if you like, but I believe this is the state of the art, as we find it today.
It's been several years since I had to do this, but I believe my best results for SketchUp-to-C4D were done via OBJ format using the Riptide Pro plugin. In an ideal world, we wouldn't need the plugin, since C4D nominally supports OBJ out of the box, but the fact is that Riptide frequently gave me a better import (or export) than C4D's built-in support. I suppose it is possible that C4D's built-in OBJ support has gotten dramatically better in the past few years, but I wouldn't bet on it.
A better bet might be FBX. Although this is a closed, proprietary and undocumented format, it has one very important virtue: Autodesk offers a free SDK that 3D app developers can use to transfer assets into and out of this format. I'm only aware of one other competing implementation of FBX, and that one was created purely for licensing reasons. This means you have the uncommon case where almost every 3D app that supports FBX is using the same software library, which which eliminates a large source of idiosyncratic incompatibility.
You don't say why you want to import into C4D. If all you want is access to a photorealistic rendering engine, there are a bunch of add-ons and connectors for SketchUp that do this.
The one I see advertised everywhere is LumenRT, but I haven't tried it.
What I used instead, the last time I needed to do this, is OTOY's Octane Render coupled with the SketchUp plugin. They want 379.00 â‚¬ for this today, but I was using it back when Octane was a US $99 beta product and the SketchUp plugin was freeware distributed on the Octane forum. It worked quite well even back then, so I assume it's only gotten better.
There are many other options.
Regardless of the rendering plugin you use, you should find that it is far more reliable than a export-then-import path because the plugin is specifically designed to turn the SketchUp model into rendered pixels.
Export-then-import has a bunch of sources of impedance mismatch that you don't get in the plugin case.
First off, you're working within the confines of the Venn Diagram of Sadness:
Except in uncommon cases like FBX above, the exporter and importer implementations won't support all the features of the interchange format, and the interchange format certainly doesn't support all the features of the source or the destination app. This leaves you with a tiny overlapping area. Anything that falls outside that area doesn't transfer correctly.
Second, the two apps probably don't agree on basic facts about the 3D world, like which axis is "up", or whether 1 unit of 3D space equals 1 foot, 1 meter, or something totally arbitrary like the Poser Native Unit.