¡Needs testing!

[chuck_starchaser]

Hell, I don't know. I assumed that LOD's *don't* specify a texture, unless they need to. Haven't messed with LOD's yet. By the sound of your post, I get the idea that I will have to specify a texture for each? If so, maybe this is something that should be changed. An LOD should get the same texture as the top LOD, unless something is specifically specified. This is what I assumed; and my suggestion was to change from THAT (assumption) to LOD's getting correspondingly lower mipmaps, --unless otherwise specified.

[safemode]

I'm starting to think this is gonna come down to the fact that the top end shader that actually uses all these textures is just gonna be relegated to Top end cards. Then we'll have to have a shader that is mid level, that uses less of these textures, and so on until we get to no shader, and graphics look similar to 0.4.3.


Combined with the better dimensions cutoff for quality setting, this should be able to handle people's varying hardware limits without causing all this overhead micromanaging textures to attempt to dynamically handle things.

That way, we avoid all this craziness, and the problem is solved. Can't run the max quality at best shader (to take advantage of all those nifty shader textures), too bad, get a better card. That's how everyone else does it.

[klauss]

No, safemode, craziness is using high-res textures to draw a pixel!
This has to be done, it had to be done even before shaders.

It's either doing it by editing the xmeshes and saying "llamaDIF.jpg|128" instead of "llamaDIF.jpg". Or simply configure a apparent-size vs max texture dimension relation that will be enforced for all textures, overridden or not in xmeshes. I don't think it can be done the way chuck wants within any reasonable effort.

[safemode]

No, safemode, craziness is using high-res textures to draw a pixel!
This has to be done, it had to be done even before shaders.

It's either doing it by editing the xmeshes and saying "llamaDIF.jpg|128" instead of "llamaDIF.jpg". Or simply configure a apparent-size vs max texture dimension relation that will be enforced for all textures, overridden or not in xmeshes. I don't think it can be done the way chuck wants within any reasonable effort.

I just dont think that method can be applied to ships in any way that's not seriously going to affect performance due to the nature that ships can be out of range one moment and in range the next and back out *10 in short order.

I'd prefer the way to minimize vram contention to make the shaders have a more memory oriented ranking, where high uses all our shader textures, and the next lower uses less, and so on. Then also combine that with the Quality setting actually enforcing a max dimension size at the loading level. This will reduce memory contention far more than i believe juggling textures will after you take into consideration that latency has to be addressed, both in disk access and scanning.


But if you really want to micromanage, then i think that mipmap shifting is the way to go. rather than multiple files.

[chuck_starchaser]

But, safemode; that's almost like "ranking craziness"
To have the full textures for ALL ship types in a system loaded in video ram ALL the time; that is the only craziness; because to say that videoram space is 99% wasted is an understatement. And what you're suggesting is, then, tantamount to saying is that one's setting the best shader should cause 99% of vram to be wasted.
My videocard is almost top of the line, an 8800. I think I spent enough money to deserve the best shader; but I only have 320 megs of vram; and I almost bought an 8800 card that had 256 megs of vram. Vegastrike steps very heavily on vram, presently, compared to most other games/engines. And this is THE primary reason.
Now that we have techniques and are about to upgrade the shaders and texture packing, we're going to start supplementing the texture sets of most models, both in PU and Vegastrike. Currently many of the models only have a diffuse texture. Some have a specular. Rarely you find damage and glow. But pretty soon we'll start having full sets for each model...

diffuse + alpha
specular + shininess
damage + is_dielectric
glow + ambient_occlusion
high quality normal map encoding using all RGBA channels
detail texture diffuse + shininess

And later we'll have Klauss' GI with PRTP and PRTN

And this is going to triple or quadruple the vram footprint.

The problem you call "craziness", namely having to switch textures when a ship comes near or departs, is insignificant. The cost of that is amortized to nothingness. Count how many frames pass by while you're flying around in a system.


@Klauss:
I don't get what the problem is, exactly; but I trust you know what you're talking about. If it is the case that this has to be done on the artistic side, then it should be made explicit, official, mandatory, death penalty...

[safemode]

according to klauss's calculations, we can render 20 different units and use up 120MB of ram with the best shader just in texture space.

It's rare as hell for you to have 20 different units in one place close enough to need the big textures, hell, it's rare to even have 20 different units even seen in one area.

So if we make our loader/unloader better, we can shuffle the textures around so that only what is coming on the screen is loaded to GL, rather than everything a system uses (which is what we do now and why we have so much in vram).

If you disagree that seeing 20 different units is rare, then you have to face the fact that VS is going to require well over 120MB of vram to render some of the scenes possible during gameplay. No amount of texture shuffling will stop that.

We have over a hundred different units, we are simulating on the order of thousands of units, and we make it common-place (for the sake of gameplay) that there are areas where units congregate. Either we agree that seeing 20 different units in close range is rare, and thus we can solve memory contention problems by simply being more aggressive with loading/unloading textures to GL, or we agree that seeing 20 different units is commonplace, in which case, we have to deal with the reality that the best shader is just going to Suck the hell out of vram.


What I am saying is not that the best shader will load all the textures at system load. I'm saying that the best shader should manage what mipmaps get loaded to GL based on distance, but it has available, all the textures for the unit.

Other levels of shaders would not have all the textures available, but they'd still operate with the managing of mipmaps.

Other quality levels would further limit graphics by reducing the max dimensions of textures.

So you basically have a 3 way management of VRAM that i'm suggesting.

1. Managing of mipmaps based on distance using a threaded lazy loader.

2. Shaders ranked such that the number of available textures to use in shading is reduced until you reach 0. Best will get all, the next down may not get glow and damage maps. Etc etc.

3. Texture Quality modes reduce max dimensions. Best has no max. Next lowest could have 512x512. Next lowest, 256x256.

All of this is to be done. I dont see how that's crazy.

[chuck_starchaser]

So if we make our loader/unloader better, we can shuffle the textures around so that only what is coming on the screen is loaded to GL, rather than everything a system uses (which is what we do now and why we have so much in vram).

The problem is that "what is comin on the screen" IS "everything a system uses". It doesn't matter if a ship is so far away that it takes a mere 1/50,000th of a pixel; it is still "on the screen".

[safemode]

if it's less than a pixel, than for our purposes, and for what klauss is saying we should be doing, it's not on the screen.

He wants a lower bound and an upper bound defined for picking what set of texture sizes to push to GL. I agree. I just dont believe that will be enough to do what the aim is, which is why i suggested the other two things too.

I'm basically saying, Fine, lets manage mipmap levels that get pushed to GL like klauss suggested, but i'm also saying we need to make the Texture Quality settings do something useful, and we need to make the shader levels use less textures as we get closer to "no shader", so that not only is the complexity of the shader reduced but also the memory footprint of the shader.

[chuck_starchaser]

I don't know about the bounds; I wasn't aware of that discussion. In any case, I still think that ships that are far away but still "on screen" should get a smaller texture; but I don't believe the idea is going to be accepted, so I'll stop talking about it.

About making lesser shaders use smaller textures, I disagree: That's mixing up things and confusing the users. Lowering the size of textures should be done with a texture quality setting; changing shaders with a shader quality setting; I see no reason why one should affect the other. If you're keen on mixing the two, then don't call it a shader setting, or a texture setting; call it a graphics quality setting; that way at least it's explicit that more than one parameter are being tweaked by it. My personal preference would be for separate controls.

[ace123]

Well the thing is that your graphics card should have enough VRAM to hold all the textures the ships need at full resolution.

If you don't have enough vram then I think the best solution is to just change the maximum texture size or use a lower mipmap. Is there anything wrong with just doing that?

It seems to me that it's not possible to reference the mipmaps as separate textures, so you will need to provide another copy with lower mipmaps. True, this other copy is a little over 1/4th the size of the big texture, but it still feels as though having this duplicate copy will add up: when a ship goes closer in view (it's in spec or something) then there will still need to be swapping, and now it's using 3/2 the space of what it would have taken.

Maybe if you go two mipmap levels down it might be worthwhile--then it will use probably somewhere between 1/10 and 1/16th the amount of space, and so you can hold all the small textures you'll ever need for the price of about 2 big textures.

[chuck_starchaser]

I thought it WAS possible, and easy, to read lower mipmap levels and send them to the videocard. But the manual method is good enough for me; I'll do that with all PU models; -we're on a crusade of remodeling and retexturing them all anyways. Thanks.

BTW, here's an example of high shader capability gpu with extremely restricted memory: 8 megs...
http://vegastrike.sourceforge.net/forum ... 8914#98914

How's the testing of techniques coming along? Can't wait to start using them.

[Neskiairti]

im no buff when it comes to this stuff, i only understand one out of every 3 words ^.~ (not quite)

but.. from the way I see it.. dont alot of games that use vast distances.. only render things within a certain sphere? outside of that sphere, they are there, but only designated by a blip on the radar? that would seem the best course for this... (planets and what not excluded of course)

[klauss]

People, I didn't read it all, but I think I know what is going on, so I'll address it.

For one, VS is smart enough not to send offscreen units or under-one-pixel units to the GL for rendering. It will compute which units are within the viewing frustum, and render only those. It will compute the apparent size of each unit, pick a LOD mesh, and draw only those meshes that have an apparent size greater than one pixel (according to the rsize, which isn't perfect BTW).

The problem isn't that VS isn't culling as it should. Granted, VS might be able to cull better. But the problem is that VS won't cull units that occupy one pixel, because it hasn't been told to (it would be possible to configure VS in such a way, but not the point).

The problem is that when VS draws a unit, be 1 pixel or 1000 pixels wide, it will draw the same mesh, with the same texture: the one specified in the xmesh. Now... VS will sort meshes by shader, texture and a few other things to minimize state changes. I not only remember it did so before, I've written it myself for the techniques branch and I've confirmed (by tracing) it is doing the best it can.

I've also confirmed (by tracing), that when you approach a jump point and performance drops (remember people complaining about that?) VS is drawing close to 20 different meshes (with possibly different textures). I've discarded sorting (and other mesh handling stuff) overhead as the culprit. The slowdown must be on the GL, and so it must be VRAM congestion.

The problem is compounded with physics, actually. When you get close to that many units (not that many, apparently, but if you take into account turrets which are subunits and thus an additional AI, may be so), python and AI code also peaks in its CPU usage.

So, when you have 20 different units on screen at a reasonable apparent size and all must be drawn with high-res maps (according to graphics settings being at highest), then it is reasonable that performance will drop. But this case was equivalent for the GL, but not the user: the 20 different meshes were rendering to 1 pixel!. What I say, regardless of any shader used, is that VS should LOD textures for distant meshes. It's ridiculous to render a 1-pixel mesh with a 1k x 1k texture. If it's not the artist defining a LOD mesh with a lower-res texture, then it is up to VS to replicate textures based on the lower MIP levels.

All commercial engines let the artists handle this: LOD meshes have each their own low-res texture sets, with lower resolution. If we don't want to burden our artists with this task, we must code it in the engine.

That's what I say. I hope I don't have to rephrase it once again.

EDIT: Safemode, I don't think lowering the lighting capabilities of the shader is that much possible. Things would look too ugly. Artists take as granted some capapbilities when they design their meshes, like black specmaps mean no shininess. If you make a shader without specmaps, every part of the mesh will be shiny (or no part of it). In any case, it's an unacceptable state of things for the artist, and the user too - things will look as crap. Now... removing the high-cost, high-bandwidth and merely detailwork stuff like PRTs, GI and stuff like that may be possible. But the current shaders do little of that. So I'd aim at the current shaders performing well enough first.

[chuck_starchaser]

Well said Klauss. The problem, the way I see it, is much more serious for Vegastrike than it is for PU. Not only in terms of number of ship types involved, but in the sense that at PU we're on a mission to redo ALL our ships and stations; and therefore we CAN plan on having smaller texture sets for lower LOD's. But Vegastrike has probably 10 or 20 times as many ships and station types as PU, and possibly LESS artists/volunteers to do the work of going through them all and fixing things (not just LOD textures, but adding spec, damg, glow, norm... not to speak of shininess and ambient occlusion).
So, the way I see it, it's more than a question of "do you want to burden the artists?" but of "can you afford to?". I think not.
But there maybe another solution: Making a script that generates smaller textures off-line and edits the bfxm's accordingly. The same could be true of other tasks, like generating normalmaps based on unsharpen masks of the diffuse (darker meaning lower), for instance.

[klauss]

So, the way I see it, it's more than a question of "do you want to burden the artists?" but of "can you afford to?". I think not.

Good point.
I guess I'll have to research our automation opitons then.

[chuck_starchaser]

Klauss, we've been thinking about installing Dr Queue on the wcjunction server.
http://wcjunction.com/phpBB2/viewtopic.php?p=9933#9933
Once we get around to it, Vegastrike would be welcome to use it. It means that you could add such things as generating ambient occlusion to the automation tasks. Through the Dr. Queue server, your ambient occlusion tasks would be assigned to connected PC's. We have a number of people eager to donate cpu time. So, you might consider a mega-script that crawls the units folders and generates LOD texture sets, adds ad-hoc generated specular and shininess where they are missing, computes a normalmap from luma, and then converts the mesh to obj, sends the files to our server with a command to execute an ambient occlusion blender script, and maybe more.

[safemode]

Let me just put it this way then.

We can improve the max texture dimension flag. This will give users the ability to control their mem usage. Definitely gonna get done.

We can do LOD's for meshes. (every different mesh needs it's own collider too however). We can support direct mapping to mipmaps so we dont load everything at once if we never need to. etc etc. This lets the game control mem usage. You only get mem savings when units are far away.

Now, when it comes to shading, if we enable the shader, we force the user to make a decision. Use shading, and increase vram texture usage by over 400% or dont use the shader at all. To me, that's pretty stupid on our part. You argue that the artists and players will have a fit if we dont use all the shader textures to play the game, but we allow the user to not use the shader at all. If not using the shader is a possibility in gameplay, the it should be possible to make some lower quality shaders use a fraction of the shader textures without having to do an all or nothing setup like you're all saying we have to.

that's all i'm suggesting with the shader levels. Why is it not possible to only use some of the textures for shading? We're going to be adding damage and glow textures where there are none now, so those obviously aren't needed for acceptable gameplay. We should be able to find a way to use subsets of the textures available and make some acceptable defaults to handle anything needed from the missing textures to make the game at least better than no shader.


I'm just wondering why we're forcing users to decide between no shader, or using a shader that requires 4+ additional textures per unit. There's gotta be a way we can put a step in the middle, and still look better than no shader.


Also, i really dont see how the artist would get upset over anything discussed here. As long as it's clear that the best way to play the game will result in a true to form rendering of what the artists have done, then why would they care? Who are these crying artists who want to make it impossible to play the game in any way other than those that will render their models to absolute perfection ?

Lower quality modes degrade quality. that's how it works, it's our job to make the degredation acceptable to gameplay. I dont know why any artist would care, providing lower quality modes doesn't hurt them.

[chuck_starchaser]

Well, speaking as an artist here ...

Seeing my textures' sizes reduced would be much more acceptable to me than seeing some textures not used. But if the issue is catering to gpu's with less than 6 texture units, where reducing the number of textures is crucial, perhaps a prioritization is crucial:

Dropping the specular texture is simply not an option. Ships look absolutely terrible without one. And I know some ships and stations don't have one, presently, but just look at them... they look absolutely preposterous.

The first two textures I'd consider good candidates for elimination are the detail texture and the damage map.

Detail textures are not in yet, in any models, afaik; and all they will do is show minute scale graininess to serve as a bridge over the pixelation threshold as you get very close to a ship or station. It's definitely a bonus feature, and one that would typically not involve much artistic input (tile-able Perlin noise, mostly).

The damage map, you know what it is and what it does, and is a part of the texturing job most of us artists hate to do; and don't invest much attachment to. Furthermore, it is easier to explain to users that "if you use shader option such and so, kiss visual damage good-by"; whereas if you were to tell users that a shader option dispenses with specular color, most of them wouldn't know what you're talking about.

If you need to eliminate more textures, next in the list would be the normalmap. Having no normalmaps shown would be a much greater pity; but, on the other hand, a shader that ignores normalmaps could save quite a few instructions... --not just the the vector equations, but it also would not need the self-shadow function.

But the glow map is not dispensable with, specially when you consider that with the next generation shaders, the ambient occlusion will be in the alpha channel of the glow map; and, you haven't seen what ambient occlusion can do for ships, but once you do, you'll agree with me 100%.

This is what an "ambient occlusion bake" looks like:



Here's some PU in-game screen-shots of the refinery and the Tarsus WIP, for an example of using ambient occlusion and light bakings in the glow map:









For reference, this is what the refinery looked like before specular texture and ambient occlusion were present:



This was with specular and glow texture, but without ambient occlusion or light bakings:



This is after ambient occlusion and radiosity light bakes:



Ambient occlusion and light bakes in the glow map are something you can only live without when you've never had them.
In fact, it would be much better to have no shaders at all, use plain open GL, than to use the best shader but to drop
either the specular or glow textures.

Diffuse, specular and glow textures are simply sacred; --untouchable.

[safemode]

If we can half the load of the shader on VRAM, then that would be cool. Basically, give users the following option.

No shader
Min Shading
Full Shading
Extreme Shading.

Extreme shading and Full shading both would use all the available textures for shading, but extreme would have maybe more or more realistic algos for computing various effects. Like how our current list of shaders are ranked by complexity and amount of what's done, even though they all load the same textures.

Min shading would have a limited subset of textures to work with, and we'd try to make the most out of them.

Now deciding that subset should be fun. We'd want to half mem requirements of the full shader, but give the best rending possible. since we currently are planning to use 6-7 shader specific textures per unit, that means we'll need to figure out what (at most) 3 textures to keep.

the shader currently wants diffuse, specular, glow, normal, damage, datail1, detail2

specular and glow are highly desired. So why cant we have a shader that just uses the spec and glow maps (along with environment)?

that would at least be a step up from using no shader, for people who just cant play the game with the current shaders due to the vram requirements.

[chuck_starchaser]

Well, the mininum requirement would be 4 textures:

Diffuse
Specular
Glow
Environment

None of these four can be sacrificed, at all, no matter how low the shader.

As for vram usage, I still say, halving the size of the textures quarters your vram requirements. That's better than what you're asking for; and much preferable to removing ANY textures.

[safemode]

You can choose to play with no shader, so saying that nothing can be sacrificed is just false. If the player is being forced to turn off shading, then it's obvious that all of the shading textures are optional. Now, what exactly is not optional if we want to do _some_ shading is the matter at hand, and what should the shader do if it's only got a limited set of textures to use.

edit: Basically, all i'm asking is that we have a shader that tries to make the most out of being forced to only access a subset of available shader textures. It's the step above no shader at all, so as long as it ends up looking better than no shader, it's a success. What do we need to simply look better than no shader at all? If we need those 3 + env then fine. If we can do without occlusion lighting via glo map, then better. Having a little bit of shading features is better than none.

Environment isn't per-unit, so i dont really count it. We use it in per-unit calcs, but it's a shared texture.

So i'm ok with that set you provided.

I really think both setups can exist. We can have settings to halve the max dimensions, and we can have setups that will let you simply reduce the amount of shading going on.

I want to see all 3 methods available for the user to use. LOD'ing meshes, shader sub-setting, max dimension fixes.

None of those things are mutually exclusive, and none of those things (cept maybe some aspects of LODing meshes), require any additional work on the behalf of content providers. So there is no reason why they cant all exist for the user to configure.

Some people may be willing to give up on the shader features to maintain resolution(bigger displays maybe), some may be willing to give up resolution (maybe their display is small) for full shader. Maybe some people will have to do both just to use any shader features. Some poeple may have to reduce resolution and turn off shaders just to play.

They can work together to bring VS to more people.

[chuck_starchaser]

You can choose to play with no shader, so saying that nothing can be sacrificed is just false.

False. No shader doesn't imply no textures. No shader means using the OGL pipeline, which is quite capable of multi-texturing.

If the player is being forced to turn off shading, then it's obvious that all of the shading textures are optional.

False. Ditto.

Now, what exactly is not optional if we want to do _some_ shading is the matter at hand, and what should the shader do if it's only got a limited set of textures to use.

Limiting the number of textures would be useful in terms of catering to GPU's with few texture units, which is unrelated to their shader capabilities.

edit: Basically, all i'm asking is that we have a shader that tries to make the most out of being forced to only access a subset of available shader textures. It's the step above no shader at all,

Ditto.

so as long as it ends up looking better than no shader, it's a success. What do we need to simply look better than no shader at all? If we need those 3 + env then fine.

And we need 3 + env all the same if we have no shader, btw.

If we can do without occlusion lighting via glo map, then better. Having a little bit of shading features is better than none.

Well, there's nothing to gain doing that. The AO will be in the alpha channel of the glow texture; so there's nothing to gain, VRAM-wise, from discarding or not using the data already coming in via its alpha channel.

Environment isn't per-unit, so i dont really count it. We use it in per-unit calcs, but it's a shared texture.

Exactly. It only counts if someone out there has a gpu with only 3 texture units; but such a GPU should be thrown at a wall, then burnt; or given to osama bin ladin as a birthday present, where it can do some good.

So i'm ok with that set you provided.

Good!

I really think both setups can exist. We can have settings to halve the max dimensions, and we can have setups that will let you simply reduce the amount of shading going on.

Sure; but these should be separate settings, IMO. Well... Okay, we have three "dimensions" of hardware constraints:

• GPU's with limited or obsolete shader compatibility, or with very limited shader instructions in the pipeline (most common)
• Videocards with too little VRAM (also pretty common)
• GPU's with limited texture units (not sure how common)

And the best thing would be to have separate user settings to address these kinds of shortcomings:
1) Shader quality choices should be about shader version compatibility modes, first of all, such as the use of texture2DLOD() instruction wich is incompatible with some older gpu's; as well as having shaders with lower instruction count; like limited to 64 for the Radeon 9000 series.
2) Texture quality choices should be about maximum texture sizes (for gpu's that can't handle large textures) and/or average texture sizes (for VRAM fitting).
3) Texture number choices could be a setting to limit the number of textures used to 6 or to 4, so that gpu's with limited texture units are not forced into two-pass mode of operation.

If you think that having 3 tweakable continuums would be too confusing for users, I would say you could force (2) and (3) into a single continuum; but I wouldn't mix (1) with either (2) or (3).

Well... On the other hand, (1) and (3) settings cause a multiplication of shaders, so we might want to combine them, even though they are hardly related, as problem domains... just for the sake of having less shaders to maintain... Tough call...

In any case, I don't think there's a justification for EVER going down to less than those four textures (diffuse, specular, glow and env map); shader or no shader.

And I would never try to combine all 3 continuums into one; as low quality gpu's with a lot of vram are common; and so are high quality gpu's with too little vram. We need to at least separate those two, independent variables. Low shaders should never imply or try to solve VRAM problems that aren't necessarily there, and viceversa. And trying to solve VRAM problems by limiting the NUMBER of textures used is equally illogical, when, as I said, you can quarter the memory use by halving texture size, without drastically changing the nature of what's shown on the screen. Limiting the number of textures used should be reserved for addressing the particular problem of gpu's having abnormally few texture units.

[klauss]

Ay ay ay... safemode... why don't you look at the code? Or the screen! It would be faster!

No shader doesn't stop using the textures. It uses them. With fixed-function techniques. Crafty, slowly, multipass techniques. No shader uses diffuse, spec, glow, damage and environment. Those are, except damage, as chuck said, the four mandatory textures. No model designed with those in mind can be deprived of the effect.

Simply put, if an artist designs a ship with glowmaps, removing the glowmap would probably kill the design.

If an artist uses a specmap, removing the specmap will probably kill the design as well.

If an artist uses an AO map... well... maybe removing it isn't that much of a kill (though certainly a hit). But if we're embedding the AO map into the glowmap which isn't killable... then there's no harm in it. We can't remove it from VRAM anyway, without removing the glow.

If you want a shading setting that only uses diffuse texture, you'll have to get diffuse-only model variants from our artists. It's definitely not the same modelling for an engine with textured diffuse + spec + glow + normals than only diffuse. As chuck said, normal maps can probably go without much fuss. But only because artists aren't used to baking normalmaps! (and because "no shader" definitely can't use normalmaps)

So... let me propose...

• Full and above: full usage of all textures and effects. Maybe adding this or that effect (planet shaders, without making use of more textures, can certainly scale in arithmetic complexity - I have ps1.4, ps2.0 and ps3.0 variants, all using the same textureset and implementing most effects - though I'll probably drop the ps1.4 variant , I was testing if it was even possible ).
• Standard: simple and standard per-pixel phong lighting with all the refinements one can come up with without going overboard in shading cost, still all texturing units.
• Light: only basic four: diffuse, spec, glow, environment. Per-vertex lighting. Ie: one-pass fixed function imitation.
• Ultra-light: if you get models for this thing, or if some models are simple enough, diffuse-only. Or for LODs. Notice this doesn't mean no-shader, to get consistent look environment has to be used too for auto-ambient if not using this as a low-quality setting.

Now... any sensible person will try lowering texture dimensions before going into "light" or "ultra-light". But artists and modders could use those as LODding tools! So...

[safemode]

I'm cool with that.

I believe combining 1 and 3 is necessary. And I dont think you'll find many cases where a user has very limited shader support, and a ton of texture units. So i really dont see many people having a problem with making the low end shaders also utilize 4 textures rather than 6 or 7.

Limited texture size is already handled in the quality setting, but that setting also controls a lot of other things at the same time. Mostly grouping options related to cpu/gpu bound tasks along with memory congestion oriented options. I believe we should have a new setting in vssetup for the max texture dimensions and maybe other vram congestion oriented options that get created.

Something like "Video Ram Usage:" "Light, Medium, Heavy"

Heavy is no synthetic limit for anything

Medium would be half size on units (2nd mipmap).

Light would be half size on everything

[klauss]

Why not provide separate caps for object categories?

Caps: "texture reduction", "shading level" and "geometry detail".
Categories: "ships", "stations" and "planets".

Makes sense if you ask me. People have preferences.