As for my opinion on renderers?

Internal's still needed for some effects though (Cycles doesn't have everything yet, like fire/smoke), but Cycles is a better render environment in terms of how lighting is handled. Nodes for building materials in Cycles is also pretty awesome once you get your head around it. Yet some things are still faster to knock out using BI even though it may be considered depreciated in terms of future development. The original render engine also tends to be faster for animation in most cases. (Unless you're willing to turn down samples and have noisy grainy renders in Cycles.)

I'd say to learn both, and also put in practice with how scene linking works and making use of the compositor to get the best of both worlds. (You get to use the FX Cycles doesn't have, and apply them to Cycles renders.)

It's funny though, I tried Blender a few times in the past and could never get anywhere. Then saw some Cycles stuff and tried one more time with 2.68 and found the new (2.5+) UI easier to navigate, so now I'm hooked. Let's just say I find it amusing to see people come back to it and be as confused as I was when I couldn't manage to do anything more than a cube with the old UI.

---(Edit)---

One more note. Nodes in Blender Internal and Cycles are not the same. You may experience oddness or crashes trying to use same mats for both engines. What you may want to do is duplicate a scene and have different material sets made for the different render engines. Something you may want to keep track of if getting into compositing work between the two renderers available to Blender.

You just have to weight paint manually after having automatic weights applied. Automatic weighting does a very good job, but usually it seems to get 95% of it. That last 5% (like the inside of a mouth or exents of the head or limbs) is what you have to get.

However it's not too hard, and you can even select bones to see the vertices that are weighted to them... I found a video that explains it. (I even remember seeing a better video, but can't seem to find it again. This one lays out the basics needed to do it though.)

https://www.youtube.com/watch?v=W_sfan8OchA

One last bit... If I recall, if some stray verts are a problem you may need to check the auto-normalize and/or multi-paint options. Also you can re-pose and go back to weight painting to get those pesky stray vertices assigned to the proper bone vertex group. (Not to mention re-posing before going back to painting makes it really obvious which verts aren't moving with the armature as they should.)

dr_bernie...

I'm surprised you didn't mention the 800lbs Gorilla sitting in the room which the other 3D software makers should worry about. Blender isn't that bad right now (I find it reasonably usable despite it's reputation and my own failure to get anywhere with older versions) and it costs $0.00. With a few more features tacked on, and a bit more polish, even the likes of C4D or 3DS/Maya might have to worry.

Only thing Blender misses vs. Carrara are some presets, add-on content libraries, and quick loading of DAZ3D or Poser figures. Some of the other aspects in terms of producing FX, rigging, material setup, Python plugins/add-ons, or render settings are already (don't want to say it here, but being honest) better.

I even made a video comparing the two. I think there are some other Carrara users more apt to make a proper comparison with Blender, yet my video may give some users an idea of how to do the same things with both software if they want to give it a try.

I know this is an older thread, but did you check all the material slots for a given object? Your material might be just fine, but if's not assigned to the right slot it's not going to show up.

a.) Baking was under 5min.

b.) Started render somewhere around 4 in the morning, and it finished sometime around 2 in the afternoon. Default animation times were left alone, so 250 frames total.

Of course that's on CPU using Cycles at about 20 samples. Not to mention I was using one core less than my total (3 cores rendering out of 4 in my case) so I can hop on the computer and do other things while it's rendering in the background without lag. Using a 32 bit build on WinXP and CPU is AMD PhenomII 940 X4. Depending on what you have, YMMV. If you have a better setup or CUDA graphics card, you might be able to cut the time down significantly.

They might have a hard time selling it, as other apps have too much development in their own pipelines, and it's hard to see what benefit they would gain.

The other thing is that 500lb gorilla that snuck in the backdoor of the 3D software industry because few were taking it seriously enough. It's the one to set the bar for any 3D production suite, and as development continues, it's likely going to be an 800lb gorilla that steals bananas from the likes of C4D, Max, and Maya... (And if you haven't checked on it in a coulple of years because your last experience with it, give it another shot. It has improved a lot.) That 500lb gorilla is named Blender.

Seriously though, add a few more features like model and texture libraries, and some UI changes to make it even easier to start with... DAZ and a few other companies will be hard pressed to beat Blender (not just on price) unless they come up with something really special.

I'm much of a noob at Blender myself. So it might take some looking at the file to see what's going on. (And what they usually do at other Blender forums, provided you can share the file.)

However, you don't need to do a whole lot to make a mesh hidden from the camera. The Blender camera has a clipping values you can adjust. Select the active camera and go through its properties. Anything outside the bounds of the inner and outer clipping distance is hidden. Great for seeing through walls or any other nearby object that can get in the way.

Not sure if that helps, but it's something to be aware of.

Thanks! Tried it out real quick, it's a lot faster than the manual method I've been using.

Two downsides on this script though: only works in object mode, and no way to copy-paste the calculated output.

(I'd guess there's probably some edit that could be done to the script to make the value copy-able, but that's going to take some digging again.)

But it's still a lot better than dragging out an array of objects until it gets close.

And I still don't understand why something like this isn't built in to begin with. I'm sure if you compared most of the commercial apps Blender is almost ready to take on, they have this in there somewhere.

Funny you mention joining and such...

When I UV'd and charted the model in Wings3D (I still model meshes in Wings, it's faster for me), I had different pieces joined in order to share the same maps for multiple parts. But separated everthing again afterwards. That way all the textures for adjacent parts can use a common map as their UV coords from the mapping process are retained. Keep in mind each part being separate makes mechanical models work easier for rigging, etc. (Something also seen a lot with game models.)

But regardless of how they're mapped, I still wish there were a way to paint textures on multiple parts by some group selection in Blender. (Without any need to join meshes.) Such a thing would definitely save time and improve workflow.

For now, texturing in a separate file with all the parts joined does seem to be the fastest way. Since the UV coordinates are the same for the model in both files, the texturing and resultant imagemap done on the one with joined parts will work just fine on the other where the parts remain separate. (More process to get stuff done, but ideally it shouldn't be necessary.)

Transforms modifier wasn't exactly right either. And I figured out scripts had to be purposely enabled to work and such...

Going back to animation drivers is the right way. Particularly if it's distance along path and not just a particular direction which you want to affect rotation. So another video...

http://www.youtube.com/watch?v=h9V_47SD7wg

Only oddball thing is that I had to use an array object to find the path length in Blender units. (Shown in video.) If there's an internal property for that, it's somewhere where I couldn't readily find it.

There's more than one kind of fire in Blender. There is fluid-based (smoke simulator) flames and there is particle flames. I'm still too much a noob to explain adequately, but they behave quite a bit different. Maybe somebody who has been at it longer will chip in and explain where each works best.

I think Cycles mats are handled separately from those in the internal renderer. However you do have to build them separate, since they work differently in some cases. So you can have internal and cycles versions of the same mat, and it uses the shader setup specific to the selected render engine.

However it seems I get crashes if I use nodes on the internal renderer materials, there might be a bug or two there. So it might be best to stick with the old way of doing things when using internal render, if you have Cycles settings for the same mats.

Not sure how much that makes sense.

I don't think most people do vertex coordinate lists like that since the 1980s. Software does that part now. Very few 3D artists would be familiar with that aspect.

But if you open a .obj file with a text editor, you may find similarly formatted coordinate lists. OBJ format is pretty common (if not the most common), so you shouldn't have problems finding models of whatever made in it. Associated materials are referenced in the .mtl file that is normally included with the OBJ.

Outside of .obj, I think Collada and VRML are in plaintext too. (There may be others, but just going with what I'm familiar with. Other formats tend to be proprietary binary stuff or compressed in various ways.)

Of course you're the one with the programming background (which is out of my area of knowledge), so it'll be up to you to figure out how to parse it.

I know it's not much, but I hope that points you in the right direction.

I think it gets tricky when the wing attaches to the fuselage at the very top or bottom. There's different sets of edge flows that you have to make work together. If the wings are attached midway, it's a heck of a lot easier since you can let Catmull-Clarke take care of most things for you. (And if not wing/fuselage edge flows, then there may be wing/nacelle-bulge edge flows, or similar topology occuring with tail surfaces.)

Not sure if it'd be any help, but I have a few free aircraft at ShareCG that you could download and study. I think all of them have the wing attach at the bottom, and for the most part I think I've done what I can to take care of edge flows in a reasonable manner. Sometimes you also have to tweak those verts manually to get the tension or transition right.

Also if the mesh doesn't deform, and you don't plan on smoothing it anymore, it's ok to have a few tris here and there. And sometimes a tri may be needed to split what would be a non-planar quad in order to take out any ambiguity a render engine might have.

BTW, that screen grab looks like Blender there... I'm not new to 3D, but I'm starting out at Blender after they got to the 2.6x versions and sufficiently noob-proofed it. So I've been using it a lot now. Great rendering and animation (Cycles is awesome), but for working with polygon meshes - I still prefer an old version of Wings3D. You might want to give that a shot since it seems to deal with edge flow better than Blender (imo), and has faster workflow when it comes to models and how their own geometry relates to them. (Blender might be able to do some of the same things, but it's not as obvious or involves a lot more steps.)