[UNIT] Europa Universalis IV Renaissance Units

Yes, they have such problems. Earlier I uploaded airplane models from HoI4 to this thread. You can see that the textures are completely different both in size and in quality of execution. It is obvious that completely different artists are working on models, who do not even communicate with each other. In any case, each model requires certain improvements before it can be converted into a Civilization.
But I don't think it's the models that make their games work slowly. However, this happens more often due to the large number of executable scripts. I remember what a torment it was to play HoI2 approaching 1950. And there is not a single 3D model.
Scripts, models, large number of units where less would do... Paradox is just really bad at optimization in general. The models are just the low hanging fruit in this case.

Surely these are my early models :) Regarding ropes, it's still a matter of taste. I believe that not everyone likes them. Nevertheless, I like it this way more.
Yep. I just checked the Credits.txt I include with all my models. Excellent work extracting those.

As for the ropes I don't really see is as a matter of choice. As a visual thing physical ropes do look better. No questions asked. But from the perspective of having them in large numbers on screen in a game that is from the 32 bit era like CIV4 and thus has limited hardware support AND in a mod that already has lots of high detail complex units it's something I considered essential to making everything run.

And I do maintain that for a game like EU4 where the ships are literally going to be something like 10x10mm on my monitor it's just not worth it at all.

Than again, I am the guy that fit the entire NOD ancient infantry line into a single texture. So I might not be the guy to ask about sane optimization.
 
Models and textures both. Paradox makes their 3D art far more detailed than it needs to be. I mean, these are games where the maximum zoom state is still smaller than the default CIV4 zoom we most play on. They absolutely could get away with art no more detailed than what we use here. And yet they basically do zero model minimization.

Well, I didn't mention that because downsizing a texture is infinitely easier than a model. But yeah, obviously when I converted stuff from EU4 the end result on my side usually had 256x256 textures.

As a visual thing physical ropes do look better. No questions asked.

I will disagree actually. Rigging done via texture transparency to me looks better at Civ 4 scale, for a simple reason - it actually behaves well anti-aliasing-wise, while 3d modelled rigging reduced to a single line of pixels at that scale is usually terribly aliased.
 
I will disagree actually. Rigging done via texture transparency to me looks better at Civ 4 scale, for a simple reason - it actually behaves well anti-aliasing-wise, while 3d modelled rigging reduced to a single line of pixels at that scale is usually terribly aliased.
There is merit to that. Than again CIV4 can have interesting issue with transparency under certain conditions. Like I've run into problems with the ladder rigging on the side of the ships being too transparent and showing the sea behind the ship or the deck but not the mast and stuff like that. It can be cleared up but is a hassle.

Either way on the CIV4 scale everything is academic aside from how do we make it as small and as lightweight as possible to make sure the game works.
 
Like I've run into problems with the ladder rigging on the side of the ships being too transparent and showing the sea behind the ship or the deck but not the mast and stuff like that. It can be cleared up but is a hassle.

Oh, I've seen this one, yeah. IIRC it is resolved by enabling alpha testing in addition to alpha blending in NiAlphaProperty. Interestingly, some stock Civ 4 units have wrong alpha settings leading to that.

I also recall a trickier issue with alphas that occurred for me when making some helicopters from which I've learned that the actual numbering of blocks matters, as they are "resolved" graphically according to their numbering.
 
Oh, I've seen this one, yeah. IIRC it is resolved by enabling alpha testing in addition to alpha blending in NiAlphaProperty. Interestingly, some stock Civ 4 units have wrong alpha settings leading to that.

I also recall a trickier issue with alphas that occurred for me when making some helicopters from which I've learned that the actual numbering of blocks matters, as they are "resolved" graphically according to their numbering.
Could you explain that a bit? I am not sure what you mean.
 
Oh, I've seen this one, yeah. IIRC it is resolved by enabling alpha testing in addition to alpha blending in NiAlphaProperty. Interestingly, some stock Civ 4 units have wrong alpha settings leading to that.

I also recall a trickier issue with alphas that occurred for me when making some helicopters from which I've learned that the actual numbering of blocks matters, as they are "resolved" graphically according to their numbering.
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.

Frigate_Shroud_Alpha.jpg


I'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.
 
My solution for the problem was honestly to mess around until I randomly stumbled upon something that worked and than copy paste that mindlessly. We in the computer science industry call that "code reuse".

But I'd love to learn what he has to say as it has the potential to actually teach me how to do it properly.
 
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):

frigate1.png

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.

frigate2.png

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.

frigate3.png

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:

frigate4.png

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:

heli1.png

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):

heli2.png

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:

Heli3.png

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.
 
Last edited:
:thanx: Awesome post. :worship: I had no clue about either of those. I would have never guessed the engine draws the parts in order.
 
Aren't the number on the niNodes set up automatically when exporting? I mean can I safely modify that number? If not do I just copy paste and generally muck about until I line them up just right?
 
Aren't the number on the niNodes set up automatically when exporting? I mean can I safely modify that number? If not do I just copy paste and generally muck about until I line them up just right?

I haven't found a reliable way to edit the numbers (though I haven't searched too hard for it), but if you paste something new into the nif, it obviously gets the new number of +1 to the previous largest. By copying/pasting the same meshes one can reorder their numbering in relation to each other. Basically what you want is the stuff that uses transparency to have the largest number among all the TriShape nodes - if you're getting weird transparency artefacts as I described. It's really a kind of an edge case that one doesn't run into all the time though; just wanted to share because once one does, it is rather puzzling to figure out by oneself.

Just checked, and NifSkope seems to have two useful functions that would do it in non-hacky way: under "Spells" there are "Sort by Name", which sorts the blocks of the same tree depth by their alphabetical names, and "Reorder Blocks" which actually numbers them the way they're sorted. So if you have Mesh A that you want to have a lower number than Mesh B, simply call them that (or any other way that would make Mesh A earlier alphabetically), sort by name, reorder, rename back if needed.
 
I haven't found a reliable way to edit the numbers (though I haven't searched too hard for it), but if you paste something new into the nif, it obviously gets the new number of +1 to the previous largest. By copying/pasting the same meshes one can reorder their numbering in relation to each other. Basically what you want is the stuff that uses transparency to have the largest number among all the TriShape nodes - if you're getting weird transparency artefacts as I described. It's really a kind of an edge case that one doesn't run into all the time though; just wanted to share because once one does, it is rather puzzling to figure out by oneself.

Just checked, and NifSkope seems to have two useful functions that would do it in non-hacky way: under "Spells" there are "Sort by Name", which sorts the blocks of the same tree depth by their alphabetical names, and "Reorder Blocks" which actually numbers them the way they're sorted. So if you have Mesh A that you want to have a lower number than Mesh B, simply call them that (or any other way that would make Mesh A earlier alphabetically), sort by name, reorder, rename back if needed.

I hasten to note that Nifskope allows you to manually sort the nodes.
In this way, you can create absolutely any order, and I didn't notice that it somehow affected the game.
128.jpg
 
I have created and modified so many models over the years that I have lost all count. And yet this is something I have not known.
I am happy now.
 
Ramzay I can't wait for you to release these samurai and eventually the berber ships, the samurai are gorgeous
There is still a lot of work to do with the samurai, but there is progress.
Berber ships-I don't know, maybe, someday... I can't finish them without inspiration.
Civ4ScreenShot0385.JPG
 
Dear Ramzay, my friend and I also tried to convert the units of eu4, we successfully converted out the model, but I have a problem binding the bones, I don't understand the binding of blender 2.49, what software did you bind with?
 
Top Bottom