OK, these are two different problems/solutions, and I'll try illustrating those.
Yeah, I've been wondering about this as well. Here is how the shrouds on the frigate are set up. This is a vanilla unit, and it doesn't work.
The first one, at least, I assumed, was common knowledge - but as it turns out it isn't, I'll gladly elaborate.
Let's take vanilla frigate as you already showed it to be faulty. If you start turning it around, a part of the shroud disappears when it's not supposed to. To fix vanilla frigate, we actually have to take two steps:
1) Let's kill the NiZBufferProperty. It is behaving absolutely maliciously in this case: its purpose in life is to determine whether something is in front or behind the mesh it's applied to - and in case of frigate, the shroud mesh is
at the same time both in front and behind the hull, when viewed from the side. No wonder the little fella goes crazy. So let's just kill the poor thing (generally speaking, you almost never need to use this one):
As you can see, now when we rotate it, it no longer disappears (or, to be more precise is no longer obscured by something
behind it). But there is still a nasty pop-in of grey "dirt" around the actual shroud. This is actually due to a very badly tuned NiAlphaProperty.
2) So let's now take a look at that. Essentially, it has two important functions - alpha blending and alpha testing. Alpha blending is basically the relation of a semi-transparent image with its background. All alpha blending in Civ 4 is configured in the same way and I never saw any reasons to mess with it. Alpha testing, OTOH, is a bit trickier. Alpha testing is what tells the engine to display or NOT to display that particular pixel by checking its alpha channel. As you can see above, default Civ 4 frigate has its alpha testing set to "greater than 1", which basically means "any pixel whose alpha channel's intensity is more than 1 (so basically everything but 0) will be displayed". Alpha channel is a monochrome channel ranging from 0 (black, meaning totally transparent in case of alpha) to 255 (white, meaning totally opaque). So to translate it further into human language, the engine is instructed by this setting to display all of the texture except for the pixels with 100% black alphas. It might have been a good idea IF our alpha channels didn't have anti-aliasing.
Here's a zoomed-in part of frigate's texture's alpha. As we can see, there are lots of pixels that aren't 100% white or black - this is where the "dirt" comes from, as the engine currently grabs all those grayish pixels. Let's be more reasonable and instruct it to instead test for greater or equal to 128; so in other words display only parts of the texture where alpha is closer to white than black. Then (combined with the above lack of z-buffer), we get a shroud that looks like this:
No mud! Or almost none, someone a bit more perfectionist might tinker further, setting the test threshold to 160 or 180 or something. But more importantly, it looks consistent from any angle, no more sudden disappearances or nasty pop-ins.
'm not sure what you meant by numbers of the blocks. Unless you are refering to the order in the properties. Typically it is: material, alpha, and finally texture. In this case it also has the "zbufferproperty". That solves the problem of only the ocean showing in the alpha areas, but makes the entire texture invisible in the foreground as you can see from the screen shot.
This problem is 75% of the reason I abandoned using alpha textures for things like shrouds.
And this is a whole separate issue, into which I ran when working on a helicopter. See, the helicopter blades on this Mi-24 are a solid grey plane on which a shape is "drawn" with transparency:
Which works quite all right in theory, but in practice I
sometimes got a helicopter with this very noticeable artefact (and
sometimes I didn't):
It's the "sometimes" factor that annoyed me the most. For seemingly no reason this came and went as I worked on units. After
lots of trial and error, I actually realized what was causing it. The engine draws NiNodes
in order. Here are NiNodes of a
properly working helicopter:
Note how "Mi24" (the body) is numbered "40", and the "MainRotor" is numbered "50". Which means the engine first renders the body and then the rotor with its transparency
over the body.
But if "Mi24" is numbered anything
above "50" in this example, the rotor gets drawn first, and then the poor engine can only draw the body where it isn't "obscured" by the rotor above it, including its transparent parts (as the rotor has already been drawn, and the engine can only paint over it - which it reasonably doesn't want to do for the object that's underneath it). Which leads to the faulty case displayed above.