SM3 (split from Mesh Deformation, Skeletal Animation, ...)

SM3 (split from Mesh Deformation, Skeletal Animation, ...)

Requests for features in the spring code.

Moderator: Moderators

User avatar
smoth
Posts: 22309
Joined: 13 Jan 2005, 00:46

SM3 (split from Mesh Deformation, Skeletal Animation, ...)

Post by smoth »

THIS POST IS A REPLY TO: http://springrts.com/phpbb/viewtopic.ph ... 09#p396509

that is a load of horseshit.

Image
You see this? rub your nose it it, bad dog...

This is what detailed work looks like in teh spring engine. So you lot want all this bullshit, mesh deformation, normal maps, skeletals etc... so you can have finer detail control of your models and hey that is great..

except for the fact that most of you have not really looked at how detailed work looks in spring. I have and for years I saw this coming but held silent faith that sm3 would come. 2 years later nothing.

so I am moving ahead...

and I will have gorgeous models on a terrain map that looks like it is from the 90s. Because the 8:1 texture detail of the maps means that a PIXEL of map texture is as big as my tank barrels and if yo cannot see how that pretty much means all this other crap you lot want is pointless then well frankly. you are asleep.
User avatar
Gota
Posts: 7151
Joined: 11 Jan 2008, 16:55

Re: Mesh Deformation, Skeletal Animation, Bypass of UpSpring

Post by Gota »

Actually the first thing I thought of when i saw that picture is exactly the sharp contrast of the nice models and map quality.
The day SM3 becomes usable will be the day Spring's visual quality will take a big step forward.
User avatar
Neddie
Community Lead
Posts: 9406
Joined: 10 Apr 2006, 05:05

Re: Mesh Deformation, Skeletal Animation, Bypass of UpSpring

Post by Neddie »

Address my point, not some implication you drew from it.

I NEVER said our map format was acceptable, I've been trying to find somebody from outside the community willing to finish or replace SM3 for two years now, but there are multiple things which need to advance, including the animation and model formats. I'll settle for somebody doing something rather than nobody doing anything because nobody wants to deal with one element from a collection of problems.

Yeah, the maps suck, but we can hide it with ubiquitous features, groundscars and grass as we have done for many years. Do I want a new map format? You bet your pasty, concave arse.

The point remains that there are people who want better model and animation formats, particularly for organic models. These people include two teams I'm a part of, so don't tell me different. I know you're moving ahead, I am very appreciative and usually supportive. I can't implement a map format, though.
User avatar
smoth
Posts: 22309
Joined: 13 Jan 2005, 00:46

Re: Mesh Deformation, Skeletal Animation, Bypass of UpSpring

Post by smoth »

neddiedrow wrote:Address my point, not some implication you drew from it.
I did.
neddiedrow wrote:including the animation and model formats.
What formats support named hierarchy and subobjects? do you even know? I don't and when it was being looked at just the other day it we found about 4-5 formats that pretty much were useless. You don't see everything neddie.
neddiedrow wrote:I'll settle for somebody doing something rather than nobody doing anything because nobody wants to deal with one element from a collection of problems.
I am. see lua forum
neddiedrow wrote:Yeah, the maps suck, but we can hide it with ubiquitous features,
What like the fucking great features I just made which only exemplify how bad the maps look?
neddiedrow wrote:groundscars .
only applicable durring a firefight, most users have it off or low.
neddiedrow wrote:and grass as we have done for many years.
No. I turn grass off.
neddiedrow wrote: Do I want a new map format? You bet your pasty, concave arse.
I work out. not a proper description no appropriate.
neddiedrow wrote:The point remains that there are people who want better model and animation formats, particularly for organic models.
PFFFFT it isn't like they will animate anyway. 99 percent of this community cannot animate
neddiedrow wrote:These people include two teams I'm a part of, so don't tell me different. .
have they ever animated anything? I have... it is not easy.
neddiedrow wrote:I know you're moving ahead, I am very appreciative and usually supportive. I can't implement a map format, though.
you cannot do this either... but My point still stands that you guys have not really looked at the disappointment you are setting yourselves up for. Maybe I should not have used cart before the horse, it seems to have lost you.

You are trying to put lipstick on a pig.
User avatar
Neddie
Community Lead
Posts: 9406
Joined: 10 Apr 2006, 05:05

Re: Mesh Deformation, Skeletal Animation, Bypass of UpSpring

Post by Neddie »

You did not address my statement. You still haven't, you just resort to telling me I am misinformed or an idiot. I am, thus, going to disengage.
User avatar
lurker
Posts: 3842
Joined: 08 Jan 2007, 06:13

Re: Mesh Deformation, Skeletal Animation, Bypass of UpSpring

Post by lurker »

He responded that it was lipstick on a pig, he used a poor analogy at first, while you think it's a valuable improvement to work on at the same time. You two disagree, but I don't think any points are going ignored.
User avatar
smoth
Posts: 22309
Joined: 13 Jan 2005, 00:46

Re: Mesh Deformation, Skeletal Animation, Bypass of UpSpring

Post by smoth »

I really am not ignoring you.

I am saying I think you are not looking at the fact that you are doing something that is only going to have a minor effect on the way things look/function. There are many many issues that pretty much mean this will be a disappointing pursuit.

I posted my models because they are NOT organics.. but need humanoid esq movement. Spring pretty much ruins that at different points.

Want a large behemoth? something big enough the players will see the great mesh deformation? spring handles large units like ass!

Make it a flyer then? yeah because the aircraft handling is GREAT....

oh well my infantry will look good and the player can enjoy... oh wait the map format..


Lipstick on a pig. you made one part of it pretty and the rest is fucking hideous.
User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Re: Mesh Deformation, Skeletal Animation, Bypass of UpSpring

Post by Argh »

I will have gorgeous models on a terrain map that looks like it is from the 90s. Because the 8:1 texture detail of the maps means that a PIXEL of map texture is as big as my tank barrels and if yo cannot see how that pretty much means all this other crap you lot want is pointless then well frankly. you are asleep.
Well, duh... why do you think I asked about half-resolution heightmaps, etc? I was hoping that maybe we could get the short, easy improvement to SMF, just a couple of factors, no dice.

On SM3, I have very serious reservations about making it work as designed- the problem you're going to hit is geometry optimization and fillrate. Today's computers may be able to brute-force it, but it's just not that elegant. To get anything like a totally professional and natural look, you'd need so many layers to avoid obvious tiling that I just don't think it's realistic. If you look at everything being used in commercial engines, it's pretty obvious nobody's using anything like SM3, and I am fairly certain it's not because it hasn't been tried.

Don't get me wrong, Smoth- you want to get it working and find out, and I understand that and will offer moral support and point you towards the few bits of OpenGL that I've done that might be really useful. I just don't think it'll work all that well in the end, even if it works. The quality just won't be there- it'll look like layers of tiles, and the amount of specific detail will be lacking.

When I compare your SM3 demo maps you made with your later stuff... mainly, I see that the later stuff looks a lot more natural, but is being held back by the limitations of SMF's rendering process.

Instead, I am hoping that if I can get invisible heightmaps and shadowmaps that actually work right, I can go another way, build "maps" that are essentially placeholders for the "real" geometry- the stuff people will see won't be what they're interacting with, but it won't be that important. Since that more-or-less will need either Unit or Feature support to work (or an arbitrary S3O geometry loader), it's actually the first thing where I've been thinking about LODs seriously, instead of just regarding them as a total waste of time.

But that's the radical-experimental path. I don't even really think it's the best solution, at least if we want broad adoption. I am fairly certain I can make it work, but I am also equally certain that very few other people have the skill or can commit the time that would be required to make maps this way.

IMO, the fastest midterm solution is that we simply need a version of SMF with at least double to quadruple current resolution per heightmap pixel, and support for three textures in the shader pass, with explicit support for GLSL shaders implemented through Lua. This could be achieved by minor changes to Mother's sourcecode- three textures, and their spec would be different- and fairly minor changes to Spring- it'd use a different factor when pathfinding, etc., based on the flag that's set, so that it would handle the effectively-larger heightmap squares better.

Maps would become less detailed in their heightmaps, but the effect wouldn't be visible, because the normalmaps and a depthmap (or even distortionmap) shader would allow for final geometry that looked way, way, way more detailed than can be achieved right now. Mappers would do a low-rez heightmap from the master, which would be at the same resolution as their diffuse map... and with a third texture, we could support glow, reflectivity and specularity, which would result in massive improvements in terms of perceived detail.

And all of this without any radically-new technology, or stuff that mappers couldn't pick up easily. This is all just fairly minor changes to the way SMF works now. We could keep ROAM, etc.

This would result in smaller map upper limits, probably, and larger download sizes for certain, but practically nobody can play the largest sizes Spring can theoretically support right now anyway, and the download sizes of maps (within reason) has rarely been a significant obstacle to end-users who want them.

In the meantime, though, there's nothing wrong with getting rid of the utterly arbitrary mess that is Features vs. Units, unifying the underlying technology, and providing for a future art pipeline that makes sense. Until the "pig" gets renovated one way or another, it's one of several things that needs doing. I agree, this isn't everything that needs doing... but it helps make certain things possible, and would certainly help straighten out some of the mess that has generally made progress on this stuff difficult.
User avatar
smoth
Posts: 22309
Joined: 13 Jan 2005, 00:46

Re: Mesh Deformation, Skeletal Animation, Bypass of UpSpring

Post by smoth »

Argh wrote:
I will have gorgeous models on a terrain map that looks like it is from the 90s. Because the 8:1 texture detail of the maps means that a PIXEL of map texture is as big as my tank barrels and if yo cannot see how that pretty much means all this other crap you lot want is pointless then well frankly. you are asleep.
Well, duh... why do you think I asked about half-resolution heightmaps, etc?
I replied to that fucking suggestion. Don't just start again please, I hate arguing any point with you.

so lets say we had a 4:1 texture to height ration..
that means the texture is 2x as big... maps are 2x as big in memory etc.

NO that is NOT the solution, I debated it before with you and your wall of text... godfffffffffffffffffffffff
User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Re: Mesh Deformation, Skeletal Animation, Bypass of UpSpring

Post by Argh »

Why isn't that the solution?

I mean, right now, we're basically looking at maybe 3-4 1024s on a downwards POV (more or less, I know it's not quite that simple), this would go up to 6-8, trebled per render pass. It's not cheap, but it's not unrealistic, either- Fallout 3 runs almost that many bitmaps per character on the screen, Smoth. Even this machine's hardware will handle that much texture load without breaking a sweat. And for each piece of geometry, there would be only one render pass.

So, instead, you want to try re-rendering the visible heightmap geometry 20+ times? Because that's a requirement, with anything like SM3.

If you want to invest time coding it, that's cool with me, and I already pointed you towards something rather important, so don't be all emo, if I wanted to be a dick about it I'd just say nothing at all and watch you flail. I just think you're going to be sorely disappointed with the results, in terms of quality vs. rendering speeds, because you can't avoid fillrate, nor can you do it all in one rendering pass (due to limitations of GLSL that you will, obviously, need to encounter yourself).
User avatar
lurker
Posts: 3842
Joined: 08 Jan 2007, 06:13

Re: Mesh Deformation, Skeletal Animation, Bypass of UpSpring

Post by lurker »

Your argument about it looking obviously tiled seem odd when you're fine with using very large textures.
Your stance is that it's terribly expensive to blend several textures when rendering, but that it's not to feed three textures into a shader that are 4 times the resolution, 16 times the amount of data?
User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Re: Mesh Deformation, Skeletal Animation, Bypass of UpSpring

Post by Argh »

Your argument about it looking obviously tiled seem odd when you're fine with using very large textures.
Not really. You're confused about the issue.

Look, with SMF 2.0, you'd load up your textures, call the shader, and run one pass over the geometry. Your main slowdown's texture loading time across the bus, which can be reduced using PBO.

With SM3, you'd load up your textures per layer, call the shader, and run a pass over the geometry. Then you'd do it again. And again. And again. Why? Because you can't just throw unlimited textures at GPUs running GLSL. IIRC, I hit the limit at 16 while working on P.O.P.S. (this is hardware-dependent, so welcome to driver hell btw).

For a 20-layer SM3, my theoretical bare-minimum where it would start not looking like ass, you'd have 80 texture loading calls, if you want the full treatment- diffuse, specular/glow/reflectivity, normalmap/depthmap, and 20 8-bit grayscales to give you interpolation values per layer. 80, vs. 12.

The number of calls matters, btw. I tested that, and regardless of the texture size, it still matters. IIRC, it's something to do with memory handling, but tbh, I couldn't follow it, all I know is that it actually matters and that it's testable- hence why I've been doing more stuff with atlases lately, btw, it's starting to make more sense.

You could cut it to two main tiles, and just keep specularity in texture1, but I really think we need all three, and possibly another 8-bit channel for advanced water, but that's another subject. So, 60 textures. 20 of which need to be heightmap -1, btw. So they may be larger than 1024!!!

So, how many times are we re-rendering the geometry? A lot, because otherwise the GLSL won't compile on most end-users' hardware. That's a huge amount of load on the GPU side of things, even if we're maybe saving some time moving the textures across the bus. Hence why fillrate will kill you in the end.

Meh. Smoth, go build a test SM3, using the current stuff, with 20 layers with different tiles and normalmaps. Just see it, it doesn't require anything more than some colored noise per tile, same for the blenders.


Look, just to prove my point that I'm actually interested in being helpful, though, here's a free idea:

Instead of having tiles loaded per rendering pass, reduce the number of gl.texture calls by slicing up the blend textures into sectors and atlasing them. This obviously would put an upper limit on the number of blending levels that could be used, but that can get really high, depending on how many slices you use.

Make it a requirement that all tiles be the same size, and atlas them as well at runtime. Then you can reduce the number of texture calls considerably- three-four blenders per visible sector, maybe 15 tile atlases, depending on how many blend layers and the size of the tiles and the size of the atlases you want to throw across the bus. That's still a lot larger load than SMF 2.0, but it would be a considerable improvement over loose tiles, and atlases are fairly easy to code (although the GLSL side would not be so fun, I ran into that with P.O.P.S.... but that's another story).

The only major problem with this is determining which blender sectors are in POV, but that's something where SMF's source should be very helpful.

Anyhow, that should help, once you get the basics working, in terms of optimizing it. IDK whether JC used that strategy for SM3 or not, but it seems like a good way to reduce the load across the bus each frame to me.
Last edited by Argh on 09 Dec 2009, 06:41, edited 1 time in total.
User avatar
lurker
Posts: 3842
Joined: 08 Jan 2007, 06:13

Re: Mesh Deformation, Skeletal Animation, Bypass of UpSpring

Post by lurker »

So you're saying that if you do it your way it won't work.

Okay.

Let's talk about what smoth wants. What you seemed to be replying to.

16 textures, what can we fit in that. How about 12 layers with RGBSpecularity, plus 3 textures x 4 channels for alpha. I think 12 layers in any particular region of the map could work out fine. And that's only one pass.
User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Re: Mesh Deformation, Skeletal Animation, Bypass of UpSpring

Post by Argh »

No, I'm saying to meet a level of quality where it's an improvement over SMF, it won't work. To get there, you need more textures than that.

Otherwise, you just have worlds that are very tiled-looking, and that's not an improvement.

I mean, I've seen Smoth's shots of his SM3 demos, and they look very artificial. Beautiful, sure- but they don't look natural at all.

I've played Forb's SM3 extravaganza, and I've built my own SM3 maps to test things out. I am not at all convinced that you can achieve anything remotely convincing and detailed until you hit a much higher limit of layers, basically. I mean, I know how many textures I use in SMFs- 20+ is typical, and they don't tile, they have a lot of noisy stuff going on that can't be replicated with tiles.
User avatar
lurker
Posts: 3842
Joined: 08 Jan 2007, 06:13

Re: Mesh Deformation, Skeletal Animation, Bypass of UpSpring

Post by lurker »

Using a different 12 texture subset in each area of the map won't help? Fine, 24 textures, just flat textures, is only 2 passes, isn't it?
User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Re: Mesh Deformation, Skeletal Animation, Bypass of UpSpring

Post by Argh »

2 passes, 24 textures, just one sector.

What happens, when you zoom out, or use Smoth's favored POV?

That's why I posted that atlas idea above, btw. It means the increase in load doesn't go exponential on you.

It'd still be a lot heavier than 12 1024s for my theoretical 4-sector POV, but it'd be superior for really long POVs. I just figure that mipmaps would reduce the load enough, and on each render pass of my theoretical SMF, the shader would be a lot less complex, far fewer steps to unpack, sort, and blend things.
User avatar
lurker
Posts: 3842
Joined: 08 Jan 2007, 06:13

Re: Mesh Deformation, Skeletal Animation, Bypass of UpSpring

Post by lurker »

uhh, Argh.

I already took out the different textures per area thing for now.

So.

2 passes, 24 textures

Zoom out.

Still 2 passes, still 24 textures.

Where is the issue?




And your atlas idea is.. you turn a bind of 16 textures into a bind of a texture 16x larger, and add more math slowing down the shader. How does this help in any significant way?
User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Re: Mesh Deformation, Skeletal Animation, Bypass of UpSpring

Post by Argh »

IDK where you're getting the numbers, basically.

Look, you have to use blendmaps per tileset, to do the blending step. So, each tile requires 3 textures, bare minimum- blend, diffuse, normalmap.

24 unique tiles == 72 textures. If you atlas it, you can cut that down a lot- 512 tiles would work out to 36 textures per pass, and remain constant, no matter how many sectors you were viewing- the primary increase in load would be geometry. But then the GLSL would have to unpack the atlas inside the shader. Not saying that that's not trivial, it is, but it's additional math steps that you don't even have to do, in my theoretical SMF 2.0.

Moreover, you're forgetting... that for-->each within the shader massively increases the load. Each 3-texture pass is as slow as the entire pass of my theoretical SMF 2.0, per fragment (for each layer, we need to do the full treatment again, unless the value of the blendmap at that texture coordinate is zero), only you have to do it many times per fragment.
Last edited by Argh on 09 Dec 2009, 07:29, edited 1 time in total.
User avatar
lurker
Posts: 3842
Joined: 08 Jan 2007, 06:13

Re: Mesh Deformation, Skeletal Animation, Bypass of UpSpring

Post by lurker »

lurker wrote:So you're saying that if you do it your way it won't work.

Okay.

Let's talk about what smoth wants.
I'll say it again for you, since you missed it the first time.

I am showing you the math for SMOTH'S method. NOT YOUR METHOD.

SMOTH'S method does not have a diffuse texture. It does not have a normal map. Each layer has ONE RGB texture, and there is one channel of a blend texture, A.K.A. 1/4 of a blend texture, dedicated to it. This lets you do 12 layers in a single pass.
User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Re: Mesh Deformation, Skeletal Animation, Bypass of UpSpring

Post by Argh »

But... that's fucking ridiculous, as a point for serious discussion.

SM3 without normalmaps looks like ass.

And the shader instructions will still end up being far, far, far longer per texel than SMF 2.0 would be.
Last edited by Argh on 09 Dec 2009, 07:31, edited 1 time in total.
Post Reply

Return to “Feature Requests”