Author Topic: Creating efficient models, a coders point of view... (very long post)  (Read 84639 times)

0 Members and 1 Guest are viewing this topic.

Offline taylor

  • Super SCP/Linux Guru
  • 212
    • http://www.icculus.org/~taylor
Creating efficient models, a coders point of view... (very long post)
There is a growing problem of large and detailed models, which do look great, but their use causes big slowdowns and excessive memory usage.  There have been conversations about this stuff before but most of those were between Lightspeed and myself when he was making all of the new texture map for old models.  Similar conversations have taken place over effects but most of those too were more private than public.  In a Mantis bug about mipmaps and LODs, VA asked numerous questions about how to do some the things that I was hinting at for reducing memory usage.  Considering he is making a lot of the really nice models, the fact that he asked those questions made me a happy man.  There isn't going to be one solution to all of this but at some point it's the model makers that are going to have to take blame for the ever increasing memory usage and slower render times.  As coders we can only do so much until our fixes no longer do enough to control the problems.  At that point there gets to be more pressure inside the ranks to impose certain limits on effects and texture sizes.  I don't think that's a good thing for anyone but it's up to the makers of the content to do the right thing, impose some creative controls on themselves, and provide the rest of the help needed to keep the main game and mods working as well as they really could.

I'll go over the basic problems we have first and then get to questions/solutions:

1) Too many bitmaps are being used.
There is currently a limit of 4,750 bitmaps that can be loaded at one time.  Not all of those will actually be in memory at any given moment but all of them need to be available for use constantly.  That number may appear high but a typical mission with MediaVPs in use will easily use over 3,000 of the available slots.  When it goes over the max is when we have the texture corruption and various other rendering issues that we used to have really bad.  3,500 used to be the limit for retail and after considerable work on changing how bmpman works a new limit of 4,750 was put into place.  THAT LIMIT WILL NOT BE INCREASED AGAIN.  The limit was calculated (by myself) based on the code changes to bmpman, the largest texture map using mission available at the time, plus an extra buffer factor for the future.  In theory, if the effect and model producers followed certain rules (which almost no one knows at this point), then it would actually be possible to drop that limit to a lower level given the changes to bmpman.

2) Textures are too large and detailed.
While this may not seem like a real problem, I guarantee you that 2048x2048 model textures serve almost no purpose in any game.  99% of the time you just can't see that much detail, especially in the FS2 engine, but you have this massive texture stuck in memory anyway.  Now I'm not about to say what size textures should be since that will always depend on the model or effect but this is where the self control comes into play.  You should always try to use the smallest texture map possible to not only improve rendering speed but decrease memory usage.  Just because a compressed DDS texture allows you twice the map size for the same memory usage does not mean you should actually do that.  Remember that this is a game not an art show.  There is a ton of content that needs to be loaded and rendered, and you have to remember that any model is nothing but a very small part of a very big game.  Mods get a bit more play with that statement than anyone making upgrades for standard ships but mod makers probably know this already since they must take the mod as a whole into account when doing anything.


---2011 Addendum---
While this was certainly true back in 2005, recent releases have used 2048^2 as the default texture resolution. In the end, the specific size used doesn't matter, taylor's main point is still valid. Just because modern cards can handle texture sizes up to 16k^2, doesn't mean you should use them. At the moment, 4096^2 is the maximum resolution that is still practical, there are only very few scenarios where going beyond that makes sense.

3) Inefficient use of technology.
Stay away from TGA textures unless you really need them.  Reuse textures from other models when possible rather than including a copy with a different filename.  Use compressed DDS whenever possible and make sure that mipmaps are generated with it.  Include IBX files with all models that get released.  Keep animation frame counts to a minimum.  The list goes on but you get the idea.  There is lots of advice for making things work more efficiently so just pay attention to that and apply as many of those things as possible to whatever you are making.  Too many people don't.


Now to those questions:

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?
When a model is loaded all of the textures used by that model are also loaded.  Switching LODs would be painfully slow unless all of the needed content was already in memory, plus there will be many times that the same basic model is going to be on the screen many times using various LODs.

2) Do different formats of textures affect performance/memory taken up? And if so, by how much?
A DXT5 texture will take at most 1/4th of the memory of a TGA texture of the same size.  A DXT1 texture will take between 1/8th and 1/6th of the memory of that TGA texture.  If you feel the need to use TGA then make sure to use 24-bit TGA if you don't need an alpha channel.  All DXT1, DXT3, and DXT5 textures are used as is, there is no additional processing on the images before they get shown on the screen.  All other textures require some amount of work before they can be shown and so are inherently slower.  Those compressed textures come at a price or course, quality.  That loss of quality will have to be considered by whoever is making the images.  As a general rule you can determine memory usage like this:  (width * height * bytes_per_pixel).  An 8-bit file is 1-byte per pixel, a 16-bit file is 2-bytes, a 24-bit file is 3-bytes, and a 32-bit file is 4-bytes.  So, a 1024x1024 32-bit TGA needs 4meg of RAM (1024 * 1024 * 4).  A PCX image is 8-bit but used as 16-bit in the game so you always use "2" for the bytes_per_pixel when looking at PCX.  JPG images are always 3-bytes and use the same formula for size calculation.  The DXT? formats do not use that formula, when loaded in memory they will use the same amount as the size of the file (ie. a 1meg file will take 1meg of RAM).

3) Approximately what would be the 'perfect LOD' consist of?
The fewer textures the better.  Lots of polys can usually be handled pretty well but you don't want to be wasteful with that.  If you are really close to something then more polys is great.  The further away you are then you'll tend to get more models in view so if you aren't dropping enough polys going from LOD0 to LOD1 to LOD2 then it hurts overall performance.  You don't want it to look like crap of course but if LOD1 looks exactly the same as LOD0 then you are probably doing something wrong, or you are really, really good at what you do.  Todays graphics cards are very fast at rendering the basic model but it's the texturing always tends to slow things down.  Use few textures, try to keep the overall dimensions of those textures as small as possible without losing too much detail, use DXT? textures with mipmaps, try to use those same textures on as many LODs as possible.  If you can get away with using the LOD0 texture on LOD1 then do so, if it has mipmaps then you get faster rendering, better quality, and a significant reduction in memory usage.  Use smaller textures for subsequent LODs if you aren't reusing the same texture, if LOD0 is 1024x1024 and you use a different texture for LOD1 then that LOD1 texture shouldn't still be 1024x1024.  Remember that LOD2 and beyond are used when the model is getting far away so keep making smaller and smaller textures for those (or reuse the same texture, with mipmaps, from earlier LODs).  If using animated glowmaps then drop the number of frames as well as the dimensions for different LODs, by LOD2 you usually can't see the animation anyway.  And when I say to try and use the same texture for LOD0 that was used for LOD1 I don't mean one really big texture but the same texture.  If it's mipmaped then it will work much better than a different texture.  Doing it this way can't always be done but it should be whenever possible.

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?
The fewer textures the better.  Try not to waste the texture, nearly every part of the texture image should apply to some part of the model.  If you've got a bunch of black space in the texture then you didn't map it very well.  As mention in the above responses you have to try and control the want of quality with the need for usability.  Not only is the visual quality usually not worth the RAM and general slowdown of a 2048x2048 texture but since the texture will have to get resized 99% of the time it's on the screen the visual quality will actually decreased in when use.  Use the fewest and the smallest textures that you can in order to get the required detail across to the gamer.  This will mean sacrificing something but when it comes down to sacrificing some detail in order to keep the game playable I would think that no hesitation would come from ditching that extra detail.  Remember than each model is just a piece of the game and needs to be created knowing that the more detail that's included in the model's textures is a price that the game as a whole has to pay.  What you can get away with will always differ based on the model but that's why this is a consideration for the model makers and those that create textures.  Oh and never, EVER use a texture larger than 2048x2048.  That's the largest size that most cards can use and anything larger will get resized to that automatically but will also seriously hurt rendering speed, memory, and image quality.
Again, modern GPUs, even Intel chips, can be expected to support texture resolutions going up to at least 2048^2. That being said, this does not mean every fighter needs a map that detailed, so choose your battles. As a rule of thumb, the larger the ship, the greater the impact of a high-res map.

5) Are nameplates fine as they are or are they costing us precious frames per second/megs of RAM?
They should be fine.  Those are extra of course but generally add enough to the game experience to justify them being there.  Just remember to use PCX or DXT5 for those so you don't waste unnecessary memory on TGA versions.  It's quite likely that nameplates will be automatically generated at some point down the road since that's possible with render-to-texture and future font code.  That's not going to happen tomorrow or anything but is something to look forward to.

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?

LODs do get used always but the distance at which they change will vary when using the various detail settings.  If you don't LOD efficiently (ie. you don't drop enough model detail to really justify LOD drop) then that can hurt efficiently.  Properly using DDS textures with mipmaps will greatly help speed though.  Even on the same LOD the mipmap levels will automatically change to help speed rendering and reduce visual quality loss from resized textures.  Use fewer/smaller textures and let that be how you save RAM.  As already mentioned, most modern video cards to fully capable of rendering very detailed models without skipping a beat.  The OpenGL code especially has been optimized to deal with complex models effectively and there is still room to improve the code in the future.  It's just the textures that cause the problems.  For some like the hi-poly Triton for example, I use the highest detail version but with lower quality textures (even if I just resize the hi-quality ones myself).  It still looks great and renders fast but I come out way ahead on memory saving.  There is a comment I added to bmpman.h when I rewrote how it handles most images.  This comment is something of a flame since I was pretty pissed about having to deal with this problem because of the artists.  I used as an example the Terran Mara (before the hi-poly one) as an example of the texture abuse that was going on.  The Terran Mara was using 117 bitmaps, taking into account the glow maps where each frame is considered one texture by the game.

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.

This is already controlled by the "3-D Hardware Textures" slider in the detail options in game.  There are two problems with this though, it doesn't have any affect on compressed DDS textures, and it doesn't save any system memory.  That option only does anything to help rendering speed.  There has been something else proposed recently though.  WMCoolmon proposed different filenames so that high, medium, and low quality textures could be always be available and a new setting would choose what gets loaded by default.  I rather like the idea of different directories myself, use controlled by an existing in-game detail setting.  For the directory option you would have "data/maps_lo" for low quality maps, "data/maps" would be for medium quality, and "data/maps_hi" would be for high quality maps.  "data/maps" would always be a fallback if the other directories didn't have the file.  Both proposals are possible, we just have to decided which is better for the modders to use (obviously with their input).

And something that wasn't asked but an old feature that I wish more people would use, special models for the hud target box.  The ships.tbl has an entry for a special model to use for the hud target box, this model is always rendered at full detail.  Using a much lower poly model for this would seriously help rendering speeds when you have something targeted.  Also be sure to use as small of textures as possible since that model won't ever be rendered very large.  That's extra work so it's not something that I would want to force on anyone.  It does help rendering speeds though and it would allow something like TBP to use quick rendering wireframe models for the targetbox since wireframe hi-poly models are chaotic to look at and very slow to draw.

In summary:
  • Use LODs effectively
    Try to use the same textures on more than one LOD, but be sure so include mipmaps with the texture.  This will reduce memory usage and rendering time.  Make sure that there is enough geometry difference between LODs to help rendering.  Always test in game when deciding how much geometry you can drop, but drop as much as you can.  LOD changes are based on distance and detail levels.  The "Model Detail" slider in the options screen can set these levels, it takes effect instantly and you can adjust the slider during a mission (by pressing F2 and going to the Details tab) to see the various effects.

  • Use smaller textures
    Try to keep textures at or under 1024x1024 if at all possible.  Going with 1024x512, 512x512, or 512x256 should take care of most models without sacrificing much, if any, detail.  Include mipmaps so those textures are used effectively.  The graphics API will scale up textures if need be and you should let it rather than trying to make the texture as large as possible.  Use smaller glow and spec maps whenever you can, those tend to not need as much detail as the main texture.

  • Use a special hud targetbox model if you can
    This won't save any memory, it will actually use more.  But it can greatly increase rendering speed which would negate any impact the small amount of extra memory might take.  It would also allow effective use of wireframe views in the targetbox since they are much slower to draw with complex models.

  • Use DDS textures when at all possible
    There are compressed (DXT1, DXT3, DXT5) and uncompressed DDS images available so use compressed when you can and go with uncompressed otherwise.  Compressed images are both faster to process and use and consume at least 1/4th of the memory as uncompressed versions but do decrease quality to some degree.  Always generate mipmaps for your DDS images.

  • Always use power-of-2 textures
    Textures are much faster to use if they are power-of-2.  Power-of-2 textures are some combination in width or height of these dimensions: 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048.

  • Choose your texture sizes sensibly
    While the usable texture sizes increase regularly as new GPU generations are rolled out, be aware that there's a point where increases in size do no longer yield appreciable differences in quality. In addition, note that textures use the lions' share of GPU memory, and that texture lookups are rather expensive to perform. Right now (Right now being defined as 2011), a resolution of 2048^2 is established as the standard size, with some mods offering 4096^2 sized maps as optional downloads.

  • Try to reuse other people textures when possible
    Things like cockpit graphics, glow points, and even some base textures may be shareable between models.  Rather than create a copy of the same image with a different filename just use the same filename.  This lets other models use the same texture which saves memory.

  • Stay away from animated glow maps when at all possible
    They look cool but every frame of that animation counts as another texture that your model uses.  If you feel the need to use an animation then try to use an EFF with compressed DDS frames when at all possible.  Keep the number of frames used for your animation to a minimum.  25 frames for a glow map would be considered high, not average.  Try not to use animated glows for anything less than LOD1, you probably couldn't see it anyway, go with static glows instead.  Reusing the LOD0 glowmap (with mipmaps when using EFF/DDS) for at least LOD1 is also a good option.

  • Always try to include the .bx file(s) when you distribute a model
    This isn't required of course but it would save everyone who uses your model from having to do generate it themselves.

  • Remember that one model is just one model, a small piece of the game
    There are many other models and textures and effects that need to get loaded every mission.  The more detail and the larger the textures used for one model the more it hurts the game as a whole.  Every model needs to be designed with the knowledge that it's only one piece of the experience and compromises may have to be made to enhance the experience rather than the model.


Anyway, everyone feel free to comment on this stuff.  It would be nice to get opinions and feedback, or even more suggestions, and then maybe something easier to follow can get added to the wiki for everyone follow.
« Last Edit: March 19, 2011, 06:09:33 am by The E »

 

Offline DaBrain

  • Screensniper
  • Moderator
  • 212
    • Shadows of Lylat board
Re: Creating efficient models, a coders point of view... (very long post)
Very very interesting. I knew a lot of this before, but the mipmapping issue was new to me.

I remember everyone told me to avoid mipmaps, cause FS2_open didn't use them or would just create it's own mipmaps anyway.

So should I use DXT1/3 textures with mipmaps for standard maps?

The '-mipmap' flag turns on automatic mipmapping, right?


Edit: This should really be sicky!
--------------------------------------------------
SoL is looking for a sound effect artist
Please PM me in case you want to apply
---------------------------------
Shadows of Lylat - A Freespace 2 total conversion
(hosted by Game-Warden)
----------------------------------

 

Offline Martinus

  • Aka Maeglamor
  • 210
    • Hard Light Productions
Re: Creating efficient models, a coders point of v
Kudos, I think it was about time somebody tackled this subject.

I really love some of the artwork that you guys create for Freespace but every time I turn my fighter and bring a new Orion or a science vessel (I think this has since been resolved though) into view my framerate takes a massive hit. I consider my computer to be fairly powerful and this makes me wonder how many new people have been put off trying SCP/FSU material because their computer simply wasn't up to the job.

I think there's a certain amount of detachment between what a model looks like when it's being worked on and what it looks like when you're burning past it in a fighter. I know as well that when you're building a new model you're almost entirely fixed upon it and forget that it has to work in game with other meshes and perform well.

Although I haven't built anything for FS2 in a while I give it a decent amount of thought.

 

Offline Singh

  • Hasn't Accomplished Anything Special Or Notable
  • 211
  • Degrees of guilt.
Re: Creating efficient models, a coders point of v
animated glowmaps could be done away with once hte materials.tbl comes out, saving a significant amount of memory, from the looks of it....
"Blessed be the FREDder that knows his sexps."
"Cursed be the FREDder that trusts FRED2_Open."
Dreamed of much, accomplished little. :(

 

Offline taylor

  • Super SCP/Linux Guru
  • 212
    • http://www.icculus.org/~taylor
Re: Creating efficient models, a coders point of view... (very long post)
I remember everyone told me to avoid mipmaps, cause FS2_open didn't use them or would just create it's own mipmaps anyway.
That did used to be the case but that's slowly been changing over the past year and a half.  I'm still not sure of how D3D handles this but OGL is getting a mipmap overhaul and D3D can do the same things, if it doesn't already.  There is the difference between mipmaps and LODs which is where some of the confusion is coming from.  LODs are basically mipmap levels.  In the case of models this means both textures and polys, in the case of effects it's just textures.  That's basically what the original bug report was about, the game using LODs rather than mipmaps.  That's not true, the game will use LODs for polys and textures but the basic use of mipmaps still applies to the textures regardless of what LOD is in use.  Use of mipmaps is automatic and not determined by the game engine but by the graphics API.  Use of LODs is done by the game engine.  The idea here is to reduce what the LODs do (ie. use the same textures for multiple LODs and let the graphics API deal with the mipmaps) so that we can save memory by not using textures which may not really be needed in the first place but still get the reduction in number of polys that lower LODs allow us.

So should I use DXT1/3 textures with mipmaps for standard maps?
Yes and they will always get used automatically (same for DXT5).  What ever you use to create the DDS textures with should give you the option as to how many mipmap levels to create so you don't have to make all of them.  It usually goes all the way down to 1x1 for mipmap generation but you just go down as far as 64x64 if you wanted.  For effects using DXT? you would want to create only one LOD but with mipmaps.  Then set that effect as having just one LOD in weapon_expl.tbl and then the graphics API will use the mipmap level automatically to speed up rendering.

The '-mipmap' flag turns on automatic mipmapping, right?
That option turns on automatic mipmap generation but actual use of mipmaps is automatic whether you use the option or not.  Use of mipmap levels for compressed DXT? will get used automatically and automatic mipmap use for uncompressed DDS will get fixed for OGL real soon.  Basically use DDS (either compressed or uncompressed) for pretty much everything and you will not ever need -mipmap since the image should already have to mipmaps created.  Uncompressed DDS is basically TGA so you don't have to lose any quality using it and you get the option of having mipmaps already generated.

animated glowmaps could be done away with once hte materials.tbl comes out, saving a significant amount of memory, from the looks of it....
Well I don't know if they could actually be done away with on a whole but many of the same effects could probably be done without animated maps.  Also remember that we have texture translation which could be used to similate a moving texture when it's really not.  This is used in the subspace effect but there is no reason that we couldn't apply it to anything else, if it's not already.  Some effects can really only be done with an animated texture map but more options to not require that would only benefit everyone.

 

Offline Galemp

  • Actual father of Samus
  • Moderator
  • 212
  • Ask me about GORT!
    • Steam
    • User page on the FreeSpace Wiki
Re: Creating efficient models, a coders point of v
It seems these comments are focused towards VasudanAdmiral and myself, and we will take note of them in the future. I've always used the medium- or low-detail textures VA provides, particularly on the shine and glowmaps, while I try to use existing FS2 textures that are used on other models.
A big offender in the texture department is the Mjolnir; I wasn't as familiar with the standards as I am now, so (if someone could direct me to the Max scene used for conversion) I'll bake those maps onto a single texture when I can.

And something that wasn't asked but an old feature that I wish more people would use, special models for the hud target box.  The ships.tbl has an entry for a special model to use for the hud target box, this model is always rendered at full detail.  Using a much lower poly model for this would seriously help rendering speeds when you have something targeted.  Also be sure to use as small of textures as possible since that model won't ever be rendered very large.  That's extra work so it's not something that I would want to force on anyone.  It does help rendering speeds though and it would allow something like TBP to use quick rendering wireframe models for the targetbox since wireframe hi-poly models are chaotic to look at and very slow to draw.

This is something that's bugged me a lot in recent builds. The target view box used to render LOD1 in retail, but now it's rendering LOD0, which is totally unneccesary. The 'simplified model' you want already exists, and is even already in memory, AND was originally coded in, so it's up to you guys to fix that.
In fact, it may be forcing LOD0 down to LOD1 anyway; going into the Lab, all the LOD1s are using LOD0 geometry. Turning down the detail settings doesn't change anything so it must be something else. We go to a lot of trouble to make LODs, it would be nice if they were used. :(

I recommend stickying this thread, and/or copying its contents to the Wiki.
"Anyone can do any amount of work, provided it isn't the work he's supposed to be doing at that moment." -- Robert Benchley

Members I've personally met: RedStreblo, Goober5000, Sandwich, Splinter, Su-tehp, Hippo, CP5670, Terran Emperor, Karajorma, Dekker, McCall, Admiral Wolf, mxlm, RedSniper, Stealth, Black Wolf...

 

Offline taylor

  • Super SCP/Linux Guru
  • 212
    • http://www.icculus.org/~taylor
Re: Creating efficient models, a coders point of view... (very long post)
It's really directed at everyone who makes either models or textures and especially at mod makers so that they can get a better idea on how to properly balance the user experience.  Although I used VA's work as some examples (even if I didn't actually say it was his model) it wasn't really directed towards him or you.  Most of that was actually directed towards Lightpseed at one point and I just rehashed those talks from memory and added some new stuff.

As far as the targetbox goes, it does use LOD1 and that has never changed.  Detail settings don't affect that since it's independant of the forced detail level use to render the model.  Even so though the current crop of hi-poly models are so detailed that even LOD1 is much more geometry than is needed there.  "simplified" doesn't mean what it used to and I'd bet that there are LOD2 models now that have more polys than even LOD0 of the original :v: models.  Using the special models for the targetbox isn't about reducing memory but about increasing rendering speed.  It's a lot of work on the GPU/CPU to render those detailed models in that little box.  The textures have to be scaled to fit the scaled geometry and that's processing power better spent on the rest of the models on screen.  I'm sure that there are some models that probably increase the drawing time of the hud by a factor of 3 just because of what's needed to render that high quality model in that tiny little box.  I know it's extra work which is why I've never really mentioned it before but it is one very effective way to speed things up.  It's an option.

 

Offline WMCoolmon

  • Purveyor of space crack
  • 213
Re: Creating efficient models, a coders point of view... (very long post)
Not only that, but target box models have to be drawn last, so the textures may have to be copied to the video card again.
-C

 

Offline Sandwich

  • Got Screen?
  • 213
    • Minecraft
    • Skype
    • Steam
    • Twitter
    • Brainzipper
Re: Creating efficient models, a coders point of view... (very long post)
SERIOUSLY...! | {The Sandvich Bar} - Rhino-FS2 Tutorial | CapShip Turret Upgrade | The Complete FS2 Ship List | System Background Package

"...The quintessential quality of our age is that of dreams coming true. Just think of it. For centuries we have dreamt of flying; recently we made that come true: we have always hankered for speed; now we have speeds greater than we can stand: we wanted to speak to far parts of the Earth; we can: we wanted to explore the sea bottom; we have: and so  on, and so on: and, too, we wanted the power to smash our enemies utterly; we have it. If we had truly wanted peace, we should have had that as well. But true peace has never been one of the genuine dreams - we have got little further than preaching against war in order to appease our consciences. The truly wishful dreams, the many-minded dreams are now irresistible - they become facts." - 'The Outward Urge' by John Wyndham

"The very essence of tolerance rests on the fact that we have to be intolerant of intolerance. Stretching right back to Kant, through the Frankfurt School and up to today, liberalism means that we can do anything we like as long as we don't hurt others. This means that if we are tolerant of others' intolerance - especially when that intolerance is a call for genocide - then all we are doing is allowing that intolerance to flourish, and allowing the violence that will spring from that intolerance to continue unabated." - Bren Carlill

 

Offline StratComm

  • The POFressor
  • 212
  • Cameron Crazy
    • http://www.geocities.com/cek_83/index.html
Re: Creating efficient models, a coders point of v
The target box issue is something that should illustrate a point.  If the model shown there is LOD1, then LOD1 should be made to offer minimal visual difference from the lowest LOD at the point when it is the same size on screen as it is in the target box.
who needs a signature? ;)
It's not much of an excuse for a website, but my stuff can be found here

"Holding the last thread on a page comes with an inherent danger, especially when you are edit-happy with your posts.  For you can easily continue editing in points without ever noticing that someone else could have refuted them." ~Me, on my posting behavior

Last edited by StratComm on 08-23-2027 at 08:34 PM

 

Offline Vasudan Admiral

  • Member
  • Moderator
  • 211
    • Twisted Infinities
Re: Creating efficient models, a coders point of view... (very long post)
Awesome, thanks mate. :)
Mipmaps are new to me - I've known roughly what they are, but not how they work or even if FS used them at all. So, for the first of my next set of questions:
- How do we go about getting our ships to use them so we don't need lod textures? (ie, is there something we need to do to the dds texture or some way we need to set up the model?)
- How does the game know(or how do we let it know) when to use a mipmap instead of the full texture?
- Should shine and glowmaps also be mipmapped?
I ask because I've hated creating yet more textures for LOD use, and if mipmaps mean I can get all lods to use the same 1 texture and save memory and save loading time all at the same time, I'll be very happy indeed. :D

Quote from: taylor
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?
The fewer textures the better.  Try not to waste the texture, nearly every part of the texture image should apply to some part of the model.  If you've got a bunch of black space in the texture then you didn't map it very well.  As mention in the above responses you have to try and control the want of quality with the need for usability.  Not only is the visual quality usually not worth the RAM and general slowdown of a 2048x2048 texture but since the texture will have to get resized 99% of the time it's on the screen the visual quality will actually decreased in when use.  
^That question was pretty much refering to the Arcadia I'm in the very early stages of building. The arcadia has a lot of surface area that needs to be textured, and I'm completely torn about how to go about it. :\

The problem is, I really hate how texture tiling looks unless it's done really, REALLY well (such as on Omni's Galactica), but in the case of the arcadia, the shear size of the thing means that it will be very difficult if not impossible to get a decent level of detail on it when close up with UV mapped big textures.
What I'm currently considering is pretty much having the Arcadia's basic hull use texture tiling, so that's how it'd be seen from medium range, and using detail boxes to create localised detail all over it, hopefully covering up any shortcommings caused by the use of tiling.
Can you recommend a better solution? Cos I still don't much like this one. :\

Quote from: taylor
It's quite likely that nameplates will be automatically generated at some point down the road since that's possible with render-to-texture and future font code.
Now that would be seriously cool. :D

Quote from: taylor
WMCoolmon proposed different filenames so that high, medium, and low quality textures could be always be available and a new setting would choose what gets loaded by default.  I rather like the idea of different directories myself, use controlled by an existing in-game detail setting.  For the directory option you would have "data/maps_lo" for low quality maps, "data/maps" would be for medium quality, and "data/maps_hi" would be for high quality maps.  "data/maps" would always be a fallback if the other directories didn't have the file.  Both proposals are possible, we just have to decided which is better for the modders to use (obviously with their input).
That does sound like a good idea. :) I imagine the simplest way to go about it would be to organise the media VPs so that all textures (and effects??) have 3 levels. The default set is medium, recommended for most users. This would have nothing bigger than 1024 anywhere, except perhaps in special cases like the lucifer, where it looses huge ammounts of detail and becomes rather blurred with a half size texture.

Then you'd have something like the aeffects VP we currently have. This would include all the huge textures (mostly 2048) that were shrunk for the regular media VPs. It would work by being a sort of expansion VP for the regular texture VP.
And finally, you'd have a low detail set, which would completely replace the regular texture VP - downloaded in it's place really. It would contain everything in the medium VP, but they'd all be halved in size.

This way, if someone wants to go with medium, all they need to do is install FSO, download the default media VPs and play. This would be the default option.
Then, if someone has a lot of RAM, they can decide they want the highest quality stuff - which would only require them to download an additional hi_textures VP and play.
If someone has very little RAM and wants to go with the lowest resolutions possible, they can download the lo_textures VP instead of or to replace the regular texture VP.

Quote from: taylor
Also remember that we have texture translation which could be used to similate a moving texture when it's really not.  This is used in the subspace effect but there is no reason that we couldn't apply it to anything else, if it's not already.
We can translate textures?!?! How do we do that? That would be incredibly awesome for a number of things we have planned in TI. :D


Ok, so having taken all this into account, would this sort of release be best (using the Triton as the example):

Main Release (this would go into the media VPs)
This would include the following attributes:
  • Three mesh detail LODs: Highest quality, Target box quality, and very distant quality
  • A single 1024 res DDS texture, fully mipmapped for use on the lods
  • A 512 res DDS shinemap
  • A 512 res DDS glowmap
  • A 512 res DDS debris texture
  • A 256 res DDS debris glowmap
  • A PCX/DDS nameplate
  • The IBX file

Highest Detail Expansion (This would be downloaded in addition to the main release if wanted)
This would include the following attributes:
  • A single 2048 res DDS texture, fully mipmapped for use on the lods
  • A 2048 res DDS shinemap
  • A 1024 res DDS glowmap
  • A 1024 res DDS debris texture
  • A 512 res DDS debris glowmap

Low Detail Release (this ones textures would go into the lo_textures VP)
This would include the following attributes:
  • Three mesh detail LODs: Medium quality, Target box quality, and very distant quality
  • A single 512 res DDS texture, fully mipmapped for use on the lods
  • A 256 res DDS shinemap
  • A 256 res DDS glowmap
  • A 256 res DDS debris texture
  • (No debris glowmap)
  • A PCX/DDS nameplate
  • The IBX file

Now, is there anything you see in the above that you reckon could be optimised further? I need a good idea of what the optimal release would consist of, so I can follow it on all future ones (and more than likely, I'll end up doing it for all the older HTL ships too). ;)
Get the 2014 Media VPs and report any bugs you find in them to the FSU Mantis so that we may squish them. || Blender to POF model conversion guide
Twisted Infinities

 

Offline taylor

  • Super SCP/Linux Guru
  • 212
    • http://www.icculus.org/~taylor
Re: Creating efficient models, a coders point of view... (very long post)
I don't really want to quote everything so hopefully this isn't too difficult to follow and just gets the past couple of posts at once :) ...

LOD0 through LOD3 is assumed to be usable by the engine for distance use, ie. at 1000 meters it would use LOD1, 1500 meters LOD2, etc.  Or at least I think that's right.  Bobboau would probably be able to answer that better than I can explain it.  Based on the code though that's what it does and the distances are specified in ships.tbl ($Detail distance:).  If you have a low quality LOD1 then you have to make sure that the tbl allows for this or it's going to look like crap when it hits that distance and converts to that LOD.  The targetbox uses LOD1 because :v: wanted it faster but still basically good looking.  This is something that you just need to play with, but the best way (though probably not from the modeler point of view) to handle the targetbox is to make a separate low-detail model with a special/small/single texture and with only LOD0.  If there is no LOD1 then it will just fall back on what's available.  You may just be able to take LOD1 or LOD2 and make a POF with just that one LOD and use it with a custom texture map which is smaller and wouldn't have a seperate glow map or anything.  I can only come at this problem from a coder point of view so I'm biased.  One of the model makers will just have to sit down, take a model and play with it, figure out what really works best for them and report back as to whether it's actually worth the work.  Some models will get a bigger boost from doing that than others.  You probably don't need to worry about it for a fighter but capital ships (and something like the large BSG and TBP models) could see a big improvement from this.

Mipmaps:
 - When you create a DDS image it should give you the option to create mipmaps with it.  This is usually done by default unless you specifically tell it not to.  If you get the option to specify the number of mipmap levels to create then you really just need to go down to 32x32 and that's it.  You would typically just specify the number of levels than an actual size but just consider that each level is exactly half the width and height of the prevous level.  If you use NVIDIA's nvdxt cmdline tool then you can just convert an entire directory of TGA images to DDS with mipmaps at one time.  nvdxt has a lot of options but most are useless.  I'll be happy to point out the best options to use if you don't have/use the Photoshop plugin or the GIMP plugin.
 - Mipmap use is determined by the graphics API.  When you render some textured geometry on the screen it knows what size that geometry is and picks the mipmap level which is a closest match to that size.  This is automatic and requires nothing from the user side and other that just making sure you create the mipmaps it doesn't require anything from the model maker side either.
 - Both shine and glow maps can and should be mipmapped.  Animated glowmaps using an EFF with DDS frame can also have mipmaps and they will get used the same as anything else.

Regarding the Arcadia question, fewer maps is better but few small sized maps is better than that.  So if you can get away with 2 2048x2048 textures then ok.  But if you could make use of 3 1024x1024 textures instead then that's even better.  This, like the Colossus and Lucifer, are cases where the model will dictate slightly different rules.  Tile where you can if possible, map when otherwise needed.  As long as you aren't being wasteful then you won't get any complaints from me.  Some models are just going to require that extra couple of maps and/or those slightly larger maps.  Be smart about it but in the end you have to go with what works best.

Texture translation/panning is just where you give a new set of UV coords and the texture translates to that position.  Right now it's only used to make the subspace effect appear to be animated.  The same effect could apply to most in-game effects as well with a little work.  When that might happen I don't know.  My todo list is already long enough and until I get some more of my bigger code changes finally into public hands the first of next year I'm not really taking on anything else.

Those releases look good.  The main release is just what I would expect to see, it should still look good and even more it will perform well on most everyone's system.  I would probably try to go with an even smaller main texture (main release) if possible and smaller specmap on the high detail version but if using only the one set of textures for all LODs it will be a tremendous improvement either way.  Your average planet in a mission is 1024x1024 and its typically larger than any ship texture in the view.  Graphics cards today can do some great filtering when magnifying textures so try and let it do it's thing when possible.  Better filtering control (at least with OGL) and support for more techniques (ATI and NVIDIA specific stuff) is in the works, anisotropic filtering level just became a registry option for instance.  Either way what you've got listed there is a great improvement so run with it.  As the graphics capabilities start getting even better perhaps it can be revisited in another year and we'll see what can be done with textures then.

Remember that PCX nameplates won't be able to use mipmaps and a compressed DDS nameplate, with mipmaps, will use half the memory of the PCX version plus offer a full alpha channel.  If you don't need the alpha channel then go with DXT1 and it will use even less memory.  Nameplates are typically simple graphics so compression artifacts shouldn't be an issue.

 

Offline Vasudan Admiral

  • Member
  • Moderator
  • 211
    • Twisted Infinities
Re: Creating efficient models, a coders point of view... (very long post)
Right, thanks. That pretty much answers all my questions. :) (for now anyway ;) )

Having looked at the triton and aeolus at 512 res textures, I think I'll stick with 1024 sizes as the main release size for ships of similar size. At 512, most of the details make you think you need glasses, and edges become....bluredly jagged. :\
As a main release for a fighter/bomber it might be ok, but not really a cruiser sized freighter. :)

Quote from: taylor
So if you can get away with 2 2048x2048 textures then ok.  But if you could make use of 3 1024x1024 textures instead then that's even better.
Well, the main problem is texture area->ingame surface area, and 2 2048 res textures would give me the area equivilant to 8 1024 res ones, but that's already a heck of a lot of memory. :\

I *think* what I'll do is to aim for 1 2048 res, but probably end up with two. These would obviously go into the highest detail release, with 2 1024 res versions as the main. (I wouldn't dare go lower for a station the size of the Arcadia - it's huge!

Thanks again. :)
Get the 2014 Media VPs and report any bugs you find in them to the FSU Mantis so that we may squish them. || Blender to POF model conversion guide
Twisted Infinities

 

Offline Taristin

  • Snipes
  • 213
  • BlueScalie
    • Skelkwank Shipyards
Re: Creating efficient models, a coders point of v
Why not 1x 2048^ and 1x 1024^ ?
Freelance Modeler | Amateur Artist

 

Offline Vasudan Admiral

  • Member
  • Moderator
  • 211
    • Twisted Infinities
Re: Creating efficient models, a coders point of view... (very long post)
Because of the weird shape of the Arcadia, there are actually very few places where I can get away using the same texture portion twice, so to get an even and not-blurred coverage, I'll need a lot of texture area to play with. A single 2048 is....rather optimistic. ;)
Well, we'll see how it goes at least. ;)
Get the 2014 Media VPs and report any bugs you find in them to the FSU Mantis so that we may squish them. || Blender to POF model conversion guide
Twisted Infinities

 

Offline WMCoolmon

  • Purveyor of space crack
  • 213
Re: Creating efficient models, a coders point of view... (very long post)
Actually I suggested a table. I didn't want to bring that in to the discussion, since it's not particularly relevant, but I hate being misquoted.

Hmm, what about some kind of quality table? This would hook into the bm_load and bm_load_animation functions. Essentially, how it'd work would be that whenever bm_load or bm_load_animation receives a name for an image to load, it checks the quality table. If the quality table exists, it checks the quality that the user has specified, and retrieves the name of the texture with that quality.

So let's say...

Code: [Select]
#Qualities
$Name: Low
$Name: Medium
$Name: High
#End

#Images
$Name: fighter2t-01
+Low: low_fighter2t-01
+Medium: med_fighter2t-01
+High: hgh_fighter2t-01

$Name: cruiser01
+Low: low_cruiser01
+Medium: med_cruiser01
+High: hgh_cruiser01
#End

Replace the model names with the appropriate texture names.

That gives us a much more expandable + flexible quality system for mods or whatever, (ie a mods or materials section would be possible since it's just simple string replacement) and would really only require a command-line option and/or dropdown box in the upcoming options screen.

Although with mipmaps and LODs, it would probably be better if people just used the options screen to lower the values to fit their computer. :p
-C

 

Offline CP5670

  • Dr. Evil
  • Global Moderator
  • 212
Re: Creating efficient models, a coders point of view... (very long post)
Good read and I agree with most of that. The biggest issues were actually with some of the effects a while ago, as there were a lot of unnecessarily large TGAs that could be made smaller and into PCX or DDS files without any loss in quality. Most of that stuff has been fixed now, but I think a few bloated effects may still remain.

However, I actually really like the 2048x2048 textures, provided that they are used judiciously and have the detail to justify their size, in which case they can make a remarkable difference when running the game in high resolutions. They shouldn't be in the standard textures package, but a separate adveffects style file sounds like a good idea. Large textures are something sorely lacking in most modern games and they are in my opinion one of FSO's biggest assets as far as the graphical quality is concerned. A detail texturing technique in FSO might make the largest textures unnecessary (I brought this up about two years ago and Bobboau said he had plans for it in the long term future), but for now they seem to be the way to go for high end systems.

On this point, one thing I think is worth mentioning is that these huge textures (and in general high polygon counts as well) should only be used for big capital ships. The new fighter models look great in the tech room, camera mode and so on, but you don't really notice their increased detail anywhere nearly as much as that of, say, a destroyer while actually playing the game.

Do the shinemap textures need to be the same size as the base texture? I'm wondering how much quality would be lost by making those smaller.

[q], anisotropic filtering level just became a registry option for instance[/q]

What's the flag? I would like to try this out.
« Last Edit: December 11, 2005, 04:02:23 am by CP5670 »

 

Offline DaBrain

  • Screensniper
  • Moderator
  • 212
    • Shadows of Lylat board
Re: Creating efficient models, a coders point of view... (very long post)
However, I actually really like the 2048x2048 textures, provided that they are used judiciously and have the detail to justify their size, in which case they can make a remarkable difference when running the game in high resolutions.

Good point. That's correct. So it's for high-end PCs anyway. High-res maps will look a lot better with a higher screens res.

Do the shinemap textures need to be the same size as the base texture? I'm wondering how much quality would be lost by making those smaller.

NEVER use a lower res for the shine maps when you're texturing a usual ship. The optical result is weird. You could even say 'ugly'.

This only works in some special cases.

Example: Shadows of Lylat is using 3d landscapes with gigantic maps, but the shinemap is very small, cause we don't need it. (AFAIR 4*4 or 16*16).

In some other cases the shinemap is just white (glass or something like that). In this case you can also stick to a smaller shinemap.

--------------------------------------------------
SoL is looking for a sound effect artist
Please PM me in case you want to apply
---------------------------------
Shadows of Lylat - A Freespace 2 total conversion
(hosted by Game-Warden)
----------------------------------

 

Offline Flaser

  • 210
  • man/fish warsie
Re: Creating efficient models, a coders point of v
The target box issue is something that should illustrate a point.  If the model shown there is LOD1, then LOD1 should be made to offer minimal visual difference from the lowest LOD at the point when it is the same size on screen as it is in the target box.

Not necessarily. A good LODing offers a good performance/visual curve based on the size of the model. (Bigger = more detailed and generally *more* LODs).

Just because a LOD1 is not a good model for targeting box rendering doesn't make the LODing bad.
IMHO the best approach would be if it would be possible to set which LOD of the given model is to be used.
"I was going to become a speed dealer. If one stupid fairytale turns out to be total nonsense, what does the young man do? If you answered, “Wake up and face reality,” you don’t remember what it was like being a young man. You just go to the next entry in the catalogue of lies you can use to destroy your life." - John Dolan

 

Offline taylor

  • Super SCP/Linux Guru
  • 212
    • http://www.icculus.org/~taylor
Re: Creating efficient models, a coders point of view... (very long post)
Actually I suggested a table. I didn't want to bring that in to the discussion, since it's not particularly relevant, but I hate being misquoted.
Yep.  Sorry about that.  I wanted to see if there was interest in either idea without going to much detail for either proposal but I did completely forget about the table.

And I do think that lowering the detail levels can help decide the top-level mipmap that gets used.  I'd thought of that before but never really looked at what would be needed.  Probably worth looking into in a few months since if everyone is going to finally start making use of mipmaps then we can drop detail levels with those and there won't be a real need to make high, low, and medium detail textures.  You may have to remind me of that though, I'm far to forgetful.

IMHO the best approach would be if it would be possible to set which LOD of the given model is to be used.
Now that's a damn good idea.  It could be added to the ships.tbl entry and if it's specified it will use that LOD number of the original model rather than the default.  I'll see if I can't add that sometime next week, or WMCoolmon can do it if he has time.

[q], anisotropic filtering level just became a registry option for instance[/q]

What's the flag? I would like to try this out.
It's a string value, "OGL_AnisotroicFilter", but it only takes numbers (a float value).  Minimum value is 1.0, which is to not enable the filter, max value is determined by the video card (will likely be 16.0 on current cards).  It will cap the value if you go out of that range.  Also, if using a debug build, you can change the setting in game by bringing up the debug console with "Shift-Enter" and using the "ogl_anisotropy" command.  Use "help ogl_anisotropy" to get a general idea of it, "ogl_anisotropy" with no options will reset to the default/registry value, "ogl_anisotropy x" will set the filter to "x" value.  The default value is 1.0.

The anisotropic filter did work before but not properly, and it was always set to the max.