Why SMF maps look so horrible

[Beherith]

So, once I fixed the mipmap generation in mapconv, and got most of the stuff together to make smf maps look as good as they possibly can; Im totally stuck.

For some reason, the engine has an extremely wierd way of selecting which mip level of texture to use, and the main reason of map fuglyness is using very low mip levels on cliffs.

I made a map where the first level is normal colored, and the next levels gradually fade to black.
Level 1: original
level 2 25% black
3: 50%
4: 75%
5-11: all black

Allow me to show the results:







If anyone wants to test on their own, here is the test map:
http://beherith.eat-peet.net/stuff/dsu.sd7



btw ignore the funny looking grass, its because i run in windowed and alt tab during load.

[Neddie]

That certainly explains a lot.

[Beherith]

The same mips are used no matter what the view resolution is. I tried from 1920*1200 to 1024*600 fullscreen and windowed, and the pattern is exactly the same. This is extremely wasteful and sub optimal.

[Neddie]

It also seems entirely illogical.

[Kloot]

an extremely wierd way

entirely illogical

There is nothing intrinsically weird OR illogical about selecting MIP levels based on 2D camera-tile distance, which is all the engine does. Also, texture detail doesn't always need to match geometric detail.

[Argh]

Mainly what I see here is that it's not using the camera's rotation to determine the POV, and adjust the mip levels accordingly.

It seems strange to see more than one mip level on a top-down POV, though- it should be uniform, based on Y distance, while in OTA POV, imo. That would probably fix it, at the cost of some performance.

Better idea: make a variable that end-users can control via SpringSettings, if they want maximum performance, then set to "lowest detail", which shows only mip 4-5, all the way to "highest detail", where only mips 0-1 get shown. Let it be a floating-point value where anything lower than 1 or higher than 0 adjusts the dynamic distance at which mips are switched.

[Beherith]

Hmm, most interesting :)
I found the offending code section.

Spring only does down to miplevel 3 (128*128), which makes sense.

Here are my performance tests so far, they have absolutely no meaning, just curiosities:


Edit: removed for stupidity

Edit2 :

Ok, so I retested, with forcing the engine to either max mips or lowest mips. Max gave 125 fps while min gave 135. Hardly a difference for me. Extremely promising!

[Argh]

That is pretty interesting. I'd have thought there'd be a wider difference, tbh. Of course, your 10 FPS is probably something on the order of 40 over here, until my new hardware arrives Did you get that figure with a long view, or just zooming in and out of OTA view, or just from stock OTA view? I would've expected worse performance in a long view.

And I agree, mip3... meh, that's a wtf, probably was because Mother's was borked and the line problem caused by bad DDS settings was too obvious at that point.

[Beherith]

Well, mip3 still makes sense (for me at least, 1920 wide monitor means 15 bigtex squares at mip3)

I can whip up a quick test to see if it can go lower with my fixed mapconv, but I highly doubt its worth much.

Edit: cant go lower than 3.

[Argh]

Why are we building maps with 5 mips as standard, then? That is just weird. Must've been changed after Mother's was built, and Mother's source wasn't being maintained, or something.

[jK]

even the fileformat just supports 4 levels (mipmap0-3)

[Beherith]

So, who said spring cliffs have to look ugly and streched?
The mountains in the back are about 1600 elmos tall.

[FLOZi]

I have to say, that looks pretty darn awesome, Behe.

[very_bad_soldier]

love u behe

[Das Bruce]

Not entirely sure what you changed but it looks good, can we get some shots of popular maps for comparison?

[Beherith]

Should be convincing enough. The difference is forced higher level mips in my shot. All I did was tie viewradius to texture detail level.

[imbaczek]

you sir are awesome.

[Beherith]

Any way I could grab the viewport dimensions from the engine? Would make it easier to optimize.

[Kloot]

Should be convincing enough. The difference is forced higher level mips in my shot. All I did was tie viewradius to texture detail level.

That's a lot of near-Moire.

Any way I could grab the viewport dimensions from the engine?

gu->viewSize*

[Beherith]

Of course it is, thats just a test to show where I forced all the mips to highest. This is why I would like to ask how to get viewport dims, because from that and the distance to bigtexture square I can easily calc the optimal mip level.

Edit: noticed your response late, thanks!