View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000092 | FSSCP | DirectX | public | 2004-02-03 18:33 | 2006-11-01 14:59 |
| Reporter | RandomTiger | Assigned To | FSO 4 | ||
| Priority | normal | Severity | feature | Reproducibility | always |
| Status | closed | Resolution | no change required | ||
| Summary | 0000092: When d3d mipmapping is enabled fs2_open uses its own smaller bitmaps when a ship is far away | ||||
| Description | This is a waste of memory and could lead to inconsistancys. Not that easy to fix since I cant work out how to identify smaller versions of bitmaps from the higher res ones. | ||||
| Tags | No tags attached. | ||||
|
|
should this realy be in hear as a bug, it doesn't seem like there is anything we can do about it, other than have people make future models with only one texture. |
|
|
Its a bug, therefore it should be in our database. I would not want to delay 3.6 to try and fix this bug but we should not pretend it doesnt exist just because we dont intend to fix it in the near future. |
|
|
Bumping it, any resolution? |
|
|
Reassigning to FSO 4. |
|
|
I agree with Bobboau that this is more of a content issue than a code one. Regardless of the fact that identifying different LOD textures would be cumbersome, I can easily see instances where a truely different texture would be wanted for a far away LOD and assuming that it should be a mipmap would hinder that ability. It would seem like the best thing all around would be to just tell model makers to use one, or one set, of DDS textures with full mipmaps and use that set of textures for all LODs that need them. That would solve the mipmap problem, reduce memory usages (both system and API), reduce needed bmpman slots, increase rendering speed, decrease mission load times, allow more flexibility for the model maker, reduce the time needed to texture map a model, and not get hackish with the code. Hell of a lot of "wins" for doing nothing on the code side and letting the content providers deal with this. |
|
|
So uh, would that mean that the optimal way to texture a ship is to use one big single map, and make all the lods use that one map as well? |
|
|
You would just try to use one map for as many LODs as possible. This doesn't mean one really big map (I'm going to propose limits on that at the next coders meeting, 2048x2048 max with quality based directories or filenames like WMC has suggested) but in most models that I've seen it's possible to have the texture for LOD0 also work for LOD1 and possibly even LOD2. Obviously this wouldn't work in every case but the more times that you can use the same LOD0 texture the better. We are pretty much at the point where we have one of two options: use less textures overall, or restrict the size of each texture (such as 512x512, 1024x512 max). Memory usage is just taking too big of a hit and is getting considerably worse with each new hi-poly model that gets released. I've resisted all such limits before and have talked others out of it as well but the time is approaching where hard coded limits are going to be forced on the content makers if things don't start getting better. Reducing the number of textures per model and trying to reuse them on multiple LODs would help alleviate the problem at bit longer before hard limits start getting seriously considered again. |
|
|
It'd probably be well worthwhile then to post a thread in the upgrade project forum detailing exactly what is the most efficient setup. For example: 1) What does FS do with LOD textures? Ie, does it load them all into memory and switch when needed, or does it only load them when it needs to switch? 2) Do different formats of textures affect performance/memory taken up? And if so, by how much? 3) Approximately what would be the 'perfect LOD' consist of? 4) Is it more or less efficient to have a really big ship use 2 big 2048 res maps as opposed to say, 8 smaller ones (256), and is the vastly superior visual quality worth the cost in terms of RAM usage? 5) Are nameplates fine as they are or are they costing us precious frames per second/megs of RAM? 6) Big one: Is the cost of storing even efficient LODs in the RAM worth it? (Especially on the highest detail settings, where the lods don't appear to be used anyway?) Could it be more efficient RAM-wise to keep using the highest detail model, but with smaller textures? 6.5) And might it be only in some cases, such as say, the Colossus, better RAM-wise to just have the one LOD and a scaled texture/texture set? And while I'm here, might it be possible to dynamically resize textures based on the in-game detail settings? Before they're loaded into RAM in the first place that is? Ie, if they have it at 50% detail, all the textures above say, 512 res are halved in size. At 80%, they get 80% of the full textures etc. Basically it puts the efficiency cleanly in the end users control. If they have trouble running at full, they can just bite the bullet and tone down the settings, that way those who've paid for powerful rigs can get the best graphics, and those with less powerful rigs can get as much as they can. So,....yeah - long bugnote, ;) but if you can tell us modders what makes up the Holy Grail of model efficiency, we can start shooting in the right direction. It's especially important as more and more ships are built, and with many of them getting bigger and more detailed than ever. |
|
|
Ok, I'll make a post in the forum with answers to those questions and a few suggestions on how to handle things. It is from a coders point of view though so some of what I suggest is likely to get some opposition (probably deserved). |
|
|
Ok, here it is: http://www.hard-light.net/forums/index.php/topic,37158.0.html Edit: Oops, wrong link. :) edited on: 12-10-05 10:22 |
|
|
Well, going by community response to the suggestions and the fact that no one has said otherwise, I assume this is going to be fixed with better creation of models. That's about the only way to properly deal with this and not have mapping issues or big slowdowns. Closing a not-a-bug since the artwork change is really the only way to properly fix this and no change to the code could do it as well. Closered. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2004-02-03 18:33 | RandomTiger | New Issue | |
| 2004-02-03 18:34 | RandomTiger | Status | new => assigned |
| 2004-02-03 18:34 | RandomTiger | Assigned To | => RandomTiger |
| 2004-03-08 17:40 | Bobboau | Note Added: 0000391 | |
| 2004-03-08 18:55 | RandomTiger | Note Added: 0000399 | |
| 2005-03-14 13:40 | administrator | Assigned To | RandomTiger => user303 |
| 2005-04-04 17:18 | kasperl | Note Added: 0002097 | |
| 2005-09-06 18:54 | Goober5000 | Note Added: 0003279 | |
| 2005-09-06 18:54 | Goober5000 | Assigned To | user303 => FSO 4 |
| 2005-12-09 05:45 | taylor | Note Added: 0003979 | |
| 2005-12-09 23:52 | VA | Note Added: 0003980 | |
| 2005-12-10 01:52 | taylor | Note Added: 0003981 | |
| 2005-12-10 12:00 | VA | Note Added: 0003982 | |
| 2005-12-10 13:10 | taylor | Note Added: 0003983 | |
| 2005-12-10 15:21 | taylor | Note Added: 0003984 | |
| 2005-12-10 15:22 | taylor | Note Edited: 0003984 | |
| 2005-12-18 01:25 | taylor | Status | assigned => closed |
| 2005-12-18 01:25 | taylor | Note Added: 0004007 | |
| 2006-11-01 14:59 | taylor | Resolution | open => no change required |
