Just a new alien ship

[Kangaroo]

Today while I was playing around in Blender, I got an idea for a ship. There's only one problem. I'm not sure if it will fit into any of VS lore. The ship already looks very alien and my plans for texturing it are for making it look even less like a human craft. Can anyone tell me if you need this ship?

Two renders with HDRI lighting



And a plain render:

[hurleybird]

Even if it doesn't fit the description of known race designs, VS might have room for an 'unknown' alien vessel or two, who knows.

[chuck_starchaser]

Gorgeous! How do you get HDR lighting? Is this using the yaffray renderer?

(BTW, if Vegastrike don't want it, we have an opening for an alien ship in WCU's Privateer 3 storyline, which requires a Mantu ship. The Mantu are mentioned in WC canon, but never shown or described in detail.)

[Kangaroo]

You got that right, I used Yafray for the render. Too bad it's not available yet for Blender Internal.
Chuck, I have some problems with the Texture Baker script. Every time I attempt to use it, it returns that the active object is not a mesh or has no UV coordinates. Although the Save UV Layout works fine.

[chuck_starchaser]

I was editing the previous post, check it out again.

I had the exact same problem you describe when I downloaded an unofficial version of Blender that was out of synch with the raybaker script. I used to have a link to an updated script that solved the problem. Which Blender version are you using?

[Kangaroo]

I'm using a compiled snapshot of 2.43 version.
I'd be glad to make it a WCU ship if needed. By the way, the ship is currently about 1100 polys.

[chuck_starchaser]

That's very efficient; looks like a 3k poly model.

There are better scripts that do work. Go to the scripts window, and into the Image menu of scripts; try those.

[Kangaroo]

Can I ask you to examine the UV map of this ship? Tell me where have I made mistakes? I don't know UV mapping very well yet.

[chuck_starchaser]

Sure; post the file, or email it to me.

[Kangaroo]

Sent an email to you.

[chuck_starchaser]

I had no problem baking a texture; I used, from the scripts window,
Image -> Bake texture image from UV's

Try it, see if it works for you.
The UV layout is okay, pretty efficient. My only remarks would be:

a) you are re-using the islands for both sides of the ship. This is good and efficient, BUT, it won't work with Klauss' new shaders' Global Illumination (GI). So, the current guidelines are to have a one-to-one (no folding, no overlap) UV layout. Or, better yet, to have two UV layouts: One WITH folding and overlaps (like yours) and one without. Blender now handles multiple UV layouts, and so does Ogre, but I'm not sure whether Blenders Ogre-exporter handles them yet.
The UV layout without folding or overlaps will then be used for the PRT-P and PRT-N bakings (long story, needed for GI), normal mapping (I think), and static light map from self-illumination; wheras the UV layout that uses folding and sharing of UV islands is used for the diffuse and specular textures.

b) The layout is a bit TOO efficient: You need at least a few pixels of space between islands. The reason is that filtering, by the video card, specially anisotropic filtering, reads neighboring pixes, and begins to bleed color between neigboring islands as the viewing distance increases. The standard is to scale down the islands a tiny bit, so as to leave room between them. Once you have your texture done, you fill the unused space between the islands with a color that's somewhat of an average color for the whole texture, for starters. Then, in Gimp, you can use the tool to select contiguous regions by color to select all unused areas. With them selected, you do a gaussian blur, and you'll see the blur pass only modifies pixels in the selected areas, but reading pixels from across selection boundaries. What this does is it bleeds your textures out of the UV islands and into the background. Repeat the blur a good 5 to 10 times, so that when the filtering hardware in the videocard filters the edges of your texture islands and looks at neigboring, background pixels, it sees pretty much same colors. It will greatly diminish the artifacts.

c) You might want to re-orient the texture islands so that front of the ship is always to the left, say, and back to the right. What this will do for you is strategic: You could generate, for instance, micrometeorite impacts, or smoke/air marks that fade towards the back of the ship, by, in Gimp, starting with a random snow and blurring it to the right. You can then pretty much apply that to the entire texture. Otherwise you have to rotate such effects to match the angle the pieces make to the front-back direction...

[Kangaroo]

Thanks for your help, Chuck. I totally forgot about the alignment, though I read that in your previous work (probably with Hornet). I'll start with the non-overlapping UV map tomorrow - my sister wants to sleep and I have to share a room with her .

[jackS]

Pretty, but, as you yourself suggested was the likely case, not something that matches up with any particular VS group.

Anything this well made will find surely a home somewhere (such as the Mantu ship mentioned above) .

[klauss]

I suggest you turn the facecount up to 3k and smooth it a bit, to get rid of some of those interpolation glitches (weird reflections).

[chuck_starchaser]

Great! I've posted a question at the WCU forum, about its suitability as a Mantu ship, just to make sure.
Indeed, this ship deserves more polys. There's something about Blenders' Smooth and Subdivide Smooth, though; they never work just right, at least for me (mesh edges pulled in, vertices moving in unexpected directions...).

[Kangaroo]

Next level of subsurf would bring it to 9k polys, so it's not acceptable either.
I could place edge loops, maybe that would work.

[Kangaroo]

No, wait, subsurf level 2 makes it 4,7k.
Here's what it looks like:

[chuck_starchaser]

Yeah, that looks much better --smooth reflections. Yeah, I'd forgotten; Smooth never worked for me, but subsurf did.

Don't need to worry that much about poly count, IMO, Kangaroo; poly count was more of an issue two or three generations of videocards ago. Today's hard limit on performance is more the memory bandwidth, which is much more affected by the size of the textures than by the size of the mesh. The concern with poly count, IMO, is a klingon from days long gone.

[Kangaroo]

I believe the smooth tool blends the shape closer to a sphere(?)
Well, I don't know, my card is perhaps 6 years old? My computer's still running with acceptable performance because of it's motherboard's optimization with RAM and processor.

I guess I have to rally myself and start working on the non-overlapping UV map and redo the existing one.

[chuck_starchaser]

It will be a good exercise. Once you got the two UV's I'll show you how to generate PRT-P and PRT-N bakings, maybe make a tutorial out of it. If you're up to it, could make a normal map baking. Dual Joe is the one that knows that well, though; wish he'd write a tutorial on that, but he's busy nowadays. Basically, creating a temporary model with a lot more subsurfing (~100k polys) and baking the difference between it and the regular mesh into a normal map.

[klauss]

Normalmapping isn't needed if all you'll do is subsurfing, though.
Only if you intend to then edit the subsurfed mesh it's worth it.
And... in many many cases (mostly for tiny greeble details), a normalmap derived from a old-fashioned bumpmap (gimp tools all over the place for that) is much easier to do, and more than enough.

Remember that per-pixel lighting shaders already smooth out the normals and such, so you get the same smooth appearance without normalmaps - normalmaps are for when the surface isn't smooth, or when it doesn't match the geometry, rather than for when it is.

[chuck_starchaser]

I've seen normal maps baked out of subsufs of pretty smooth surfaces, in the Ogre forum, and noticed they produced subtle --but definitely there-- normal map corrections. I think the subsurf algorithm used by Blender is a lot more sophisticated than linear normal interpolation done in the gpu; could be wrong.
As far as deriving a normal map from a bumpmap in Gimp, xNormal, for example, allows you to include a bumpmap with the geometry. Not sure if it would be better than Gimp; just mentioning it.

[Oblivion]

Cool ship.

However i suggest to keep clear of automatic modifiers (like subsurfing, which i presume is the equivalent of 3dsmax's meshsmooth function) , they often give you speed at the expense of more polies than is actually needed. It doesn't give you much control (or any control at all) over the triangulation and stuff.

I know that doing something like this by hand is difficult and might be messy, but I suggest doing just that. Does blender support smoothing groups? Those can give nice smoothened surfaces with only a few polies.

[chuck_starchaser]

Oblivion, smooth groups give you nothing of the sort. A smooth group is a grouping of polygons that you split from the rest, in order to have them appear smooth shaded as a group, but with a sharp crease around them. Each of those (windows?) in Kangaroo's model is a smooth group.
http://vegastrike.sourceforge.net/wiki/ ... oth_Groups
Smooth grouping doesn't add detail, nor does it move any vertices. It's a totally different and unrelated concept.
In Blender, you designate a smooth group by highlighting the polygons you want to separate and pressing Y, for split. It splits (duplicates) the vertices surrounding the smooth group, allowing smooth shading on both sides of the split, but a sharp crease where the vertices are split.
Understanding smooth groups is very important in modelling. You want to use smooth shading and smooth groups in place of flat shading, in many cases, particularly large, flat surfaces, for performance reasons. Check this:
http://vegastrike.sourceforge.net/wiki/HowTo:Bevel

Blender's subsurface feature works fairly well. Sometimes you have to manually fix vertices around the edges; but other than that it does a pretty good job.

[klauss]

I've seen normal maps baked out of subsufs of pretty smooth surfaces, in the Ogre forum, and noticed they produced subtle --but definitely there-- normal map corrections. I think the subsurf algorithm used by Blender is a lot more sophisticated than linear normal interpolation done in the gpu; could be wrong.

I see. Makes sense.
Still, I wouldn't use a NM on that case.
Think of the overhead, both at production and runtime.
At runtime, the increased memory bandwidth, not only from the NM itself but also other maps that might need now a non-overlapping unwrap (though a separate coordinate set might mitigate that second issue). Plus increased shader complexity.
At production time, the work need to bake a NM isn't negligible, and if it's the only reason to produce a non-overlapping unwrapping worse. Perhaps a quick LSCM would work, but still.
Unless they're big differences in quality, which I doubt can't be accomplished with some clever beveling at selected places, I doubt it's justifiable.