I don’t have Blender but I’m working with artists who do. Every file they send fails with the above error. The .3ds version they also send works fine however.
I’ve sent them the link to the wiki Blender tips… any thoughts I could pass along?
Thanks.
Install blender on your machine, just make sure it can launch, then you should be fine.
OK-got it 
Now a question from a LightWave user…
When I make different polys different colors in LightWave, the mesh comes in just fine as a SINGLE mesh with multiple colors (and no texture bitmaps needed).
But when a Blender artist sends me the same, every color is a different mesh. That means mesh colliders are not practical.
Is there a way to make Blender send me a SINGLE mesh, even though some polys are different colors/materials? Maybe something he can do differently in Blender?
I believe Unity 1.5.1 will include a script that will allow you to easily combine a number of meshes together using the Mesh Interface.
Other than that. If Blender allows vertex face coloring you could achieve the effect that way by painting the vertx faces (which allow for hard edges/colors). Or possibly bake out the colors to a single texture/material on the mesh.
I’m thinking the mesh-combine script might not work if the polys have different materials (even if they are simple textureless colors) but I’ll be sure to test it! Good thought. And I’ll see what my Blender folks come up with on their end too.
Ideally I want every level of the game to be a single mesh with a single mesh collider–very easy to work with, and fast,
Yes, this can be done in Blender, not sure if Unity reads Blender vertex colors though. AFAIK Unity just imports meshes and uv’s from .blend’s.
This is also quite easy to do. There is a python script for Blender called BR Raybaker that can bake textures, shadows, lighting, etc. There is also a script included with the 2.42a release called “texture baker” that will do what you want.
Great–we may try baking lighting anyway.
(FWIW, the .3ds version exported from Blender did come in with proper face colors. I’ll install Blender and test with .blend next.)
How are the colors on the model coming into Unity as a single mesh/material if it’s not using vertex coloring or textures?
To clarify, I haven’t received any versions as a single mesh–but the multiple meshes in the .3ds export did retain their material colors, so I think the .blend will too, once I install Blender.
I haven’t done any tests yet to see what can be done with ONE mesh in multiple colors (without a texture). Lightwave does this just fine: you import (via fbx) and you get one mesh, with a list of materials that affect the different faces. An easy way to get multiple (and adjustable) colors in a level, with the convenience of one single mesh collider. I’m hopeful that this can be done in Blender too, but we haven’t tried yet.
Well you said before that multiple meshes won’t suffice, but that’s what LW and 3DS are spitting out. It actually seems like Blender is spitting out the most realistic mesh by breaking it down into multiple meshes per a material. The only way to get separate colors without a texture or vertex coloring is multiple materials. Whoever is doing this modeling for you I’d ask them to UV map the color fields into a single texture instead of using separate materials for each color.
And I was wrong about the new combiner script in 1.5.1… it will only combine meshes that share the same material.
Yes, LW gives you separate materials, but only one mesh. I’m pretty sure of this from what I’m looking at. Just one mesh icon, just one mesh in the scene, and an array of 4 materials (just colors, not textures) automatically attached to it. It works well–just one mesh collider, but all the different colored walls and parts of the level have functional collision.
(A texture would be a waste in this case–of effort and kb–since solid colors on different faces is all that is needed for now.)
Separate materials are still the same as 4 separate meshes as far as the engine is concerned… whether the materials are textures or simple coloring.
And from what I’ve learned, having a single mesh with multiple materials is actually worse performance wise than having multiple meshes with a different material for each one. Besides, face coloring should only be used for blocking in colors, then you should UV map the mesh into using one texture/material.
I too have seen mention that one mesh with multiple materials is worse. But I assumed that the worst effect of this comes when those materials have textures, which ours don’t at the moment. But now I’m curious: is having multiple materials–but no textures and only one material on any given poly–a significant performance problem?
In any case, performance is a secondary goal, with ease of creation coming first: the game seems to run OK with one mesh (our low polycount gives us some cushion, maybe)–and that way I don’t have to assign a mesh collider and rigidbody (and tweak the settings of each) for every single color in the level.
Also, you say that UV mapping an object is better than face coloring? I would have thought objects WITHOUT textures were faster. Is this not true? Is some blank bitmap being created on the fly or something? (Also, a UV map wouldn’t give the nice hard edges between colors, would it?)
And I’ve also assumed that a single mesh collider is easier on the CPU than multiple mesh colliders.
But performance aside, the labor is the big thing. If a texture is faster than no texture, can Blender automatically convert from multiple materials to one UV? Or is that time my artist must spend? Is that script pretty automatic?
(As for my own labor of configuring all the meshes–which could change each time the level is tweaked–I’m sure I can write a script to help automat that. But it’s beyond me–more time than it’s worth in this case. So on my end, a single mesh would still be welcome.)
I’m glad I asked because I am learning a lot And learning to wonder about even more
PS, we’re talking 4 to 12 colors per level I’d estimate. I’ll have something to show one of these days
It’s not the textures, it’s the separate materials that cause the performance cost.
The mesh combiner script in 1.5.1 canl compute a mesh collider at start-up for the entire combined mesh, after that it’s the same as any singular mesh collider at run time.
Face coloring requires multiple materials… period. If you’re not using vertex coloring or textures then you’re using multiple materials to color the mesh.
The mesh combiner script should solve this.
Maya can sample the colors from one mesh and transfer the colors over to a clone mesh and convert them to a texture file… I doubt Blender can do this (but hell, Blender is getting pretty complex and it will probably surpass Maya soon).
I have no idea who’s doing these models for you, but i’d ask them to properly UV map the models and color them using textures instead of just colring the faces.
Thanks for the tips! Very helpful for the future. For this little informal project though, I think we’ve got the best workflow already. (Especially if Blender can do what I’ve done in LightWave.)
Anyway, unwrapping painting a texture would be WAY overkill in terms of labor (for some parts of our game)–right now we can just make walls one color, floors another, etc. and there’s no “re-coloring” of faces needed–everything is just created in the right color from the start. And I do like the crisp look that is achieved by not using textures. But I’m sure we’ll do some UV mapped textures also, for other parts of the game. (We have a mix of styles going on–some call for really flat simple coloration like this, while others could use texturing.)
[quoteFace coloring requires multiple materials… period. If you’re not using vertex coloring or textures then you’re using multiple materials to color the mesh.[/quote]
I’ve never doubted that I have multiple materials–I see them clearly in the inspector What I was wondering was whether a material with a texture is harder on the GPU than one without.
And if so, then I’m helping performance in one way (no textures) while hurting in another (multiple materials). If having 4-12 materials on a low polycount mesh isn’t really THAT bad (and it doesn’t seem to be during playtesting), plus we’re also sparing the GPU having to deal with textures, then this might not be a bad performer.
I’m all about making the game more efficient to build as long it still runs fast too
It would if you turned off bilinear or trilinear filtering and just used no filtering.
–Eric
But the bitmap itself would already have aliased diagonals, wouldn’t it? They would approximate the sharp edges I have now, but they would “leak” I’m thinking–you’d see pixels and they’d partially cross the lines–even with no added smoothing. (But if Blender can create such a bitmap automatically, we’ll experiment and verify this.)
Not if the bitmap didn’t have any diagonals. I strongly suspect that a single UV map would be faster than a bunch of materials. It wouldn’t require any unwrapping as such…just a single small texture (16x16 should do it) that contains square “swatches” of solid color. In Blender, you’d then go into UV face select mode and then into edit mode (easier to select faces that way), and select all faces of a given type (all the floor polygons for example)…naturally you’d want to be in face select mode rather than vertex or edge. Then back to UV face select mode, and make sure the UV maps are set to default (which they should be, but just in case, hit “U” and select “Reset 1/1”). Then in the UV image editor, all the points should be selected (I always hit “A”, and if that deselects them, then I hit “A” again, just to make sure I’ve got 'em all). Then scale the selected points down (probably “S” followed by “.01” followed by “return” is quickest), and position the points (which will look like a single point) over the desired color swatch. Oh, make sure you’ve loaded the “color swatches” texture of course.
The whole process should take a few minutes at most, depending on the complexity of the level. The only possible issue might be mip maps causing some color bleeding, but if that happens then increase the size of the texture (maybe 32x32 would be better) and make sure the points in the UV editor are a few pixels away from any other color.
–Eric
Thanks for the detailed overview! I’ll be sure to share that info.
Luckily we don’t have to go to that bother for this game–but when the time comes, we’ll know what to do