Asking Basics About Models

[aple]

So I'm just wondering out of curiosity, what exactly are the limitations for a model in WC3? All I know for certain is that:

A) Textures can only be 1 of 2 or 3 different resolutions if I recall correctly. (256x256, 512x512, or 1024x1024, right?)
B) Game will not render models that are "off screen" despite that they should still technically be visible.
C) There is a limit of 256 animations, if I recall correctly.

So what are some other limitations?

Is it possible to make many different meshes that use different textures, so you can more or less effectively get around the texture size and compression limitations?

Is there a limit to the amount of meshes?

Is there a limit to the amount of vertices, edges, and/or faces a mesh can have?

Is there a limit to the amount of textures a model can use, period?

Is there a limit to the length of animations, and if so how long?

How bad does performance get the more you try to max out these qualities?

What are the limits for ubersplats?

Can ubersplats be used to create more realistic shadows?

Is something fully sprite/2D-based possible?

That's about all the questions I can think of for now. I don't really have distinct plans, I'm just asking because I wanna know.

 

[Mister_Haudrauf]

Well i know that the limit of the Polycount (Faces) is 100000. Higher than that and the model will be corrupted.

 

[GhostWolf]

A texture can be of any multiple of 2 up to 512, on both axes (that is, it doesn't need to be square).

Every application in existence ideally doesn't render things that are not visible. This is called culling.
Think what happens when you zoom all the way out in a map, and how it kills your FPS.
This is what you say should happen 100% of the time?

There is indeed an artificial limit on the amount of sequences. I can't tell why.

Geosets reference a material. Materials have N layers. Each layer can use a separate texture, and also a different texture coordinate set.
Some people used the latter for interesting effects (e.g. fake baked shadows), however it's mostly unknown, since almost no community-made program supports it.
As to whether this helps with texture size and compression limitations, I honestly do not understand this sentence.
Having a 2048 pixel texture will not look good at all on a 300 polygon unit.

How many X can I have?
This is hard to answer.
As far as the format as we know it is defined, there are mostly no limits, or the limits aren't practically reachable (unless you can get a model with 2^32-1 geosets?)
Therefore, the question is where did the game put hardcoded limits.
From these questions, I can answer that:
- Vertices are limited to 65536 per geoset, since they are indexed by unsigned 2 byte integers (aka short).
- Sequences are artificially limited to what seems to be 256, for no reason I can tell.
I have never seen anyone claim there's a limit on the amount of faces. Are you sure about that?

As far as performance goes - the most important thing when it comes to rendering, is reducing draw calls.
Draw call = tell your GPU to use data you previously told it about, and draw it.
For MDX models, the more important draw calls are obviously the geosets.
However, you actually get a separate draw call per geoset per material layer.
So if a geoset references a material with 3 layers, that's 3 draw calls.
More draw calls = worse performance.
That's on the GPU side.

However, there's also the CPU side, which is mostly where the amount of vertices matter.
Not because your GPU cannot handle the vertices (it can easily handle them, unless you have some ancient beast), but rather because all of these vertices need to be transformed by the skeletal animation, every frame, on the CPU.
Nowadays you do this on the GPU, but Warcraft is old.
This is referred to as software skinning (CPU) and hardware skinning (GPU) for further information.

In addition, the skeletons themselves need constant updating every frame, meaning you go down the hierarchy of nodes, and update each one.
Updating nodes requires lots of linear algebra math and is quite expensive, especially in Warcraft models, where there are way too many nodes.
There are Warcraft 3 models with over 100 nodes, which is pretty ridiculous.

Can you do something sprite based - I actually don't see why not, since there are multiple ways to change textures dynamically on run-time.
You can even let the game handle the sprite animation logic itself, if you can hack around with, say, particle emitters type 2, which already have the capability to run sprite-based animations.

 

[Talavaj]

Ubersplats suck, they are kind of hard coded and you would probably have to go through a lot of pain to add new ones.
Just use the "image" triggers, but yeah you can make shadows that way.

Fully "2d" graphics are possible, if you are fine with muddy ass textures.
The textures are filtered, so you can't do pixel art.

What is "off screen" is determined by extents, but strangely in some cases (destructibles) only the origin point determines where "off screen" is and the extents are ignored.

Also another thing to mention is that having enough matrix groups/skinned vertices is going to eventually mess with the rendering.

Moreover the terrain mesh itself also seems pretty unoptimized, probably because of the game being a strategy where drawing distance wasn't really of a concern.

 

[aple]

As to whether this helps with texture size and compression limitations, I honestly do not understand this sentence.

As in getting around the texture size limit of, what is it, 512x512 and the bad compression that TGA and BLP textures have by using multiple textures that have less compression on them individually so the textures themselves look higher quality.

Every application in existence ideally doesn't render things that are not visible. This is called culling.
Think what happens when you zoom all the way out in a map, and how it kills your FPS.
This is what you say should happen 100% of the time?

That's not what I meant. What I meant was in a lot of cases there should still be faces and vertices on screen, but because of the way it cuts stuff off it just completely stops rendering even though they are still technically on the screen.

 

[Cuore]

That's not what I meant. What I meant was in a lot of cases there should still be faces and vertices on screen, but because of the way it cuts stuff off it just completely stops rendering even though they are still technically on the screen.

I understand you're referring to parts of very large models, that you would expect to see on screen but are instead culled because the center of the model is located off screen. I wonder if this culling process can exclusively target entire models or can be selective for specific subcomponents of models, like specific geosets for example?
A hypothetical method to overcome this kind of undesired culling might be to make very big models using smaller individual .mdxs that represent components parts, so that individual parts don't get culled. I suppose it would only be viable for doodads however.

 

[GhostWolf]

BLP by default uses JPG compression. It's not that bad.
If you don't want compression, you can change to a palette with BLP related programs.
Note that the latter will not necessarily give you better results visually, since it supports 256 colors.

The question is though, does this matter?
Sure, if you'd be able to use modern resolutions, you would be able to have way more details, but will your details be seen by anyone? not likely.
You do need to remember the context is Warcraft.

In the end, you can have a texture per as many geosets as you want.
Meaning you can have one texture for all of them, as is usual, or you can split it however you want.
I doubt you will get any results that matter to other people when they play a map.


Culling comes in many flavors, and like all things computer-science, is mostly a tradeoff between to extremes that affect each other inversely.
In this case they are accuracy and efficiency.
More accuracy means it's slower.
Less accuracy means it's faster.
Generally speaking culling is done in stages.
The first one can instantly remove many game objects that are not visible.
The second removes some.
The third removes a few more.
Etc.
(read about quad/oct trees if you care)
At some point you get to the actual object itself, who's culling can be done in stages similarly.
For example, the first stage culls whole geosets, and the second stage culls polygons in specific geosets.

While culling geosets isn't hard, assuming you have proper bounding shapes, culling polygons is very expensive, just for the sheer amount of repetitive data you need to go through.
Therefore, the GPU generally handles the low level culling.

The game clearly implements the first part, otherwise it would run like poop. Especially when running Jass functions such as picking units in an area.

I assume it doesn't implement the second part (or rather, it implements it differently for different types of objects, as was suggested above, but none of them seem to do a per-geoset test).

The models do actually have extents for every geoset for every sequence. Whether the game uses that data, I don't know (e.g. it could be used to check when a projectile hits a unit)

If you have some issues with your own model disappearing prematurely, you can make the extent bigger. Ideally to the exact size of your spatially-largest sequence.
Of course, this means the model will also get rendered sometimes when it can't actually be seen.

 

[aple]

BLP by default uses JPG compression. It's not that bad.

Hahahaha, what? Are we talking about the same JPG here?

Yes there is a point where extra quality doesn't make a difference from WC3's distant RTS perspective, but vanilla WC3 is hardly coming close to that point and many, many custom models, textures, and maps prove that Lol. In some cases people may not use such a far camera as well, they may want it to be closer for some of their maps, or at different angles, or in some cases maybe they actually want it further zoomed out,, and in those cases the quality ceiling, if you will, changes drastically (Raising or lowering depending on how close they are to models and at what angles).

 

[Talavaj]

You can use tga instead of blp for textures.
By default tga stores images raw without compression, and there is no 512p limit on targa textures.

The most common reason why your model stops showing up on the screen is that you have raised its size in the editor.
Making scale bigger in the editor does not scale its extents.
Though as I said some object types don't care about extents (destructibles, units??) so they will get removed whenever the origin point is off screen no matter what their extents are.