JoeJ said:
So if i would put my right finger on my left arm, your algorithm would join my limbs to form a connected cycle, which breaks the topology of my body.

Yes. These objects will be in far distance - as they are needed for geometric lod - so i figured out it doesnt matters for me, i can live with it. If you have intend an algorithm for a cad software or such, you might want to use different approach, for a game, imho, this is fine. The quality of the uv will degrade with every mesh optimize algo to some extent - with my quick solution, it notably degrades, but doesnt degrades more significantly compared to other algorithms, so i think i will not change that part of the code, as it will serve me in the future.

If i will ever use it. Because i always use low poly geometry. Now thinking on it, it was an interesting experiment but i dont think i will ever need it, because i am the type of guy (as you pointed it out) who doesnt even bothers to add light support and eye candies to his games, and i normally use like 32x32 or 64x64 textures and such - of course having this code still could be handy later on, who knows what i will have to write in the future.

@yaboiryan

In overall, i still recommending you to write your own algorithm for this. Even if you end up with a less efficient solution than that code snippet on github, you will still get a code which you can maintain easily, no surprises will get you off foot, you will be better off in the long term than relying on such.

If i continue this think-flow, i am just basically thinking this: why an rts game even needs high poly geometry? The characters on the screen will be just few pixel in size. You might just simply could get away by using characters with a few 100 polygons, and no one would notice the difference. You could save yourself from a lot of headache.

Geri said:

If i continue this think-flow, i am just basically thinking this: why an rts game even needs high poly geometry? The characters on the screen will be just few pixel in size. You might just simply could get away by using characters with a few 100 polygons, and no one would notice the difference. You could save yourself from a lot of headache.

This. Why bother creating high-poly models and then reducing them to low-poly when it's so much easier to just start out in low-poly? You don't need to model individual fingers. You don't even need to model hands. You just need the overall shape of the body. What matters is not what an individual soldier looks like, but what a battlefield with dozens to hundreds of soldiers running around looks like.

Geri said:
Yes. These objects will be in far distance - as they are needed for geometric lod - so i figured out it doesnt matters for me, i can live with it. If you have intend an algorithm for a cad software or such, you might want to use different approach, for a game, imho, this is fine.

Yeah. Our expectations differ. In fact my idea is not such different from yours: Make content creation easier and automate things. One guy should be able to make a nice game, without a need to hire artists and investing millions.
But i want the final quality to be the same than AAA game shave, while you are fine with compromise and simplicity, to get things done.
We well see how far we get, as both our visions are quite ambitious… ;D

Geri said:
but doesnt degrades more significantly compared to other algorithms

Other algorithms use UV solvers to limit texture distortion, or they can generate new, resampled textures with optimezed UV layouts. During the process they can also pack multiple textures used my the model to a single one, merge materials, etc.
You could check Simplygons documentation to see how many options they offer and to get an idea about the complexity. Implementations are heavy on advanced math and graph algorithms. No easy stuff. Programming itself is also hard, because there are always many special cases you must detect and avoid, or deal with them, so the tool is robust, does not crash and guarantees output from any input (which may already contain degenerate cases).
And you need to deal with all this no matter if you target CAD or games. (Usually, if you aim for high quality, or have other criteria to meet like a guarantee to output manifold meshes.)

Geri said:
In overall, i still recommending you to write your own algorithm for this. Even if you end up with a less efficient solution than that code snippet on github, you will still get a code which you can maintain easily, no surprises will get you off foot, you will be better off in the long term than relying on such.

I still recommend to use a library. Because the guys know what they do and probably invested moths of work hours on it, built on knowledge they accumulated over many years.
Finding and using libraries brings it's own complexities and frustration. It may even take you days to integrate it and learn to use it.
But what's that in comparison to the time needed to learn and make all this yourself? Nothing!
And if it's open source, what more do you want? You can even maintain in on your side in case the devs die in a bus accident.

That just said for discussion and providing some background.

a light breeze said:
This. Why bother creating high-poly models and then reducing them to low-poly when it's so much easier to just start out in low-poly? You don't need to model individual fingers. You don't even need to model hands. You just need the overall shape of the body. What matters is not what an individual soldier looks like, but what a battlefield with dozens to hundreds of soldiers running around looks like.

Which brings us back to the earlier idea of generating sprite sheets from the existing models. Which may be the solution, if performance can not be increased in other ways.

Anyway, before i would start to make lower poly models, i would model just one dummy character, which looks shitty but has the required low number of triangles, and the same skeleton and skinning setup.
And then try it in engine to see if it would make a difference at all.

I don't think so. I'm sure the GPU us underutilized for some reason. Too many draw calls, too many state switches, things like that.
A modern GPU will not care if you render 30 characters, each having 1000 triangles or just 300. But it might get bottlenecked from serializing draw calls and state switches, from sync with the commanding CPU. Emulation of old APIs on top of new ones may not be great in all details either.

frob said:

but a fairly common technique in the era (which we used in several games) was blending 2D and 3D. 2D items like trees could be drawn by creating a flat sprite and also writing depth information, so it interacts with other 3D rendering effects like the z-buffer.

The technical term is Impostoring if you're curious OP.