Hard Light Productions Forums
Modding, Mission Design, and Coding => The Modding Workshop => Topic started by: TrashMan on April 03, 2011, 10:34:30 am
-
What approach to take?
I'm thinking of fully UV mapping the Archangel, and I initially thought that two 2048x2048 textures (one for each half of the ship) might be enough...but give that it's a 4,5+ km ship...that gives me a surface area of 1024 pixels per kilometer of ship...whish in really not enough IMHO.
Are 4096x4096 textures too large? Should I use more textures? I'm not sure.....
-
You can safely use 4096^2 as your base texture size. Once you release the model though, I would recommend giving out 2048^2 maps for those poor souls stuck on Intelgrated crap.
-
For large ships, 4096² is pretty standard nowadays. Newer MVP ships (Hattie) and optimized BP ships (Solaris, Optirayana) use textures of this size without any issues. All those use 2048² textures in the default VPs but the 4096 ones in their respective advanced VPs.
-
Really? That's good news I guess...
Now..to actually make two textures of that size.... :P
-
... The Hattie does not use any 4096^2 textures.
-
Esarai uses 4096^2's for fighters.
That's right.
Fighters.
Not implying in any way that that is sensible (it's not).
Which reminds me that I should probably go through and whip out the friggin' shrinkhammer on all of those textures so my textures folder isn't several GBs.
-
ive been using 4096^2 textures on up to corvette sized ships with much success. theres always the possibility of using more than one, but that should be used rarely if ever considering the memory usage.
-
Trashman?!? UVing?!?
:yes:
-
... The Hattie does not use any 4096^2 textures.
If you happen to have high-res sources, though, it could still benefit from them in the Advanced MVP! I see some pixellation when I fly close to it! :p
-
Trashman?!? UVing?!?
:yes:
Hey! I do it for all the fighters/bombars!
And pratially for some capships. But I never fully UV mapped a massive capship before..
-
... The Hattie does not use any 4096^2 textures.
If you happen to have high-res sources, though, it could still benefit from them in the Advanced MVP! I see some pixellation when I fly close to it! :p
And that's what worries me.
We're talkign about 5KM of ship here ... I'm conteplating the number qand size of textures carefully.. On one hand I want it to look good, on another, I don't want it to choke the game on slower machines.
-
if you use your UV space well, even a 4.5km capship can look good with only 2 2048x2048 maps, and another 1024x1024 map for the smaller details, that worked out for me :yes:
also don't forget the UV layout is the most important, you can always increase the size of the texture, but the UV needs to be good in the first place
-
You need to keep in mind something.. 3 separate maps may seem innocent enough. But once you add Shine, Glow, and Normal we will all of a sudden have 12 maps. Heck, I'm shooting for 2, maybe 3, for the Arcadia.
-
Well, i have to admit I don't know much about how the shine or other fancy maps are working ingame, but when I want to have as much detail (sharpness) on a modell by using as less textures as possible, I try to make the model as symetrical as possible. So every part that can be mirrored, can use up more texturespace and is therefore sharper textured than a complete object, that needs to be UV'ed in the entire texture file. But as I said, I don't know if that breaks shinemapping, like tilling is doing (that is being told to me).
Not to mention, it saves you quite some time UV-Mapping when you do that mirror part
-
Well, i have to admit I don't know much about how the shine or other fancy maps are working ingame, but when I want to have as much detail (sharpness) on a modell by using as less textures as possible, I try to make the model as symetrical as possible. So every part that can be mirrored, can use up more texturespace and is therefore sharper textured than a complete object, that needs to be UV'ed in the entire texture file. But as I said, I don't know if that breaks shinemapping, like tilling is doing (that is being told to me).
Not to mention, it saves you quite some time UV-Mapping when you do that mirror part
it can "break" normal mapping in some cases... hard to spot usually.
-
A big ship? Like, say, a Gargant? :drevil:
-
That would require at 16384^2 map.
-
id just resort to tiling on very large ships. a single 4096^2 or 4096*2048 makes an excellent corvette map. and for a very large ship, i would use tile textures, but the destroyer class would kind of be somewhere in between. 2 or 3 4096^2 would do, but you could save some memory by using a couple tiles with it. 4096^2 cost about 8 megs for a dxt1 and 16 megs for a dxt5. so if all map sizes are the same resolution were talking 8(or 16 if alpha is used)+8+16+16 megs for the entire set or 48 (56 with alpha) for the set. considering the amount of video memory on modern video cards, this is tiny, but i would aim for less than 100 megs of textures for any model. and greatly limit the number of ships that use that much texture space.
-
I used one 2048x2048 and one 2048x1024 for my Dreadnought class heavy cruiser. It's about 600 m, and the maps turned out pretty good I found.
On a 3km ship I'd probably use three 2048x2048 textures. I don't think it's possible to scale up the texture at the same rate as the surface area of the ship.
-
MV_Assets as a general rule will not exceed 2048x2048 (or 1024x2048/2048x1024), this is to make it as accessible as possible to all.
(try to make it look as good as possible at this res, but don't stress too much if it is not as sharp as a block of cheddar)
MV_Advanced will do 4096x4096 because that is the usual maximum.
(you want to make the previous as a down-scale of this, not make this as an upscale. I generally recommend doing initial mapping at this res, but distribute it as an optional extra after making the above baseline maps from this.)
Even though there are many folks who CAN do 8192x8192, that's not a frequent enough occurrence to be a new baseline.
And the count that can handle 16384x16384 can probably be counted on 1 hand, -maybe- two.
-
my gtx260 will do 8192x8192, but at the 4/8 bpp for dxt1/5 respectively, your talking about a 32/64 meg texture. but thats one texture, with our texture system, you need 4 of them, 2 of which absolutely must have alpha support. so were talking 32 (64 with alpha)+32+64+64, thats 192 (224 with alpha). mind you this does not include mipmaps (which at this resolution would be huge by themselves) considering a video card with a gig of ram (and mine has less than that), this is about 1/5th of the memory on the card. therefore this resolution is not even remotely sane for this type of application. these texture resolutions are mostly reserved for world geometry textures in other types of games. if you want a mission where two super-caps duke it out, youve used up half of your video memory.
i kinda have to agree with the mediavps methodology here. its not about supported maximum texture size but in the amount of video memory on the card. 4096^2 should be the absolute maximum right now, and lower res textures should be made available to those who have hardware that does not support those resolutions. but a good practice is to draw textures at a much higher resolution than supported, and down sample to the maximum and sub-maximum sizes. that way when the average video memory goes up, you can release super high detail textures from existing sources.
-
Exactly.
-
My Sath currently uses 3 4096^2 textures, but I will provide 2048^2 in additon for older machines. It should be of note that, in a crude beta test involving multiple Saths on screen, my Sath actually had improved performance over the tile mapped retail. It doesn't make sense, considering the sheer poly count, but the numbers are what they are. Also, I have detail boxed the bejesus out of this thing.
-
since down-sampled images are already present in the mip maps of a texture. is there any way to make the bitmap management code automatically toss the first mip level when it loads large 4096^2 textures into memory? this would really simplify mod distribution and installation. some kinda flag like -toss4096, could be used on low end machines.
-
since down-sampled images are already present in the mip maps of a texture. is there any way to make the bitmap management code automatically toss the first mip level when it loads large 4096^2 textures into memory? this would really simplify mod distribution and installation. some kinda flag like -toss4096, could be used on low end machines.
Maybe. The issue there is knowing -when- and getting appropriate talk back from the hardware to know to do so and doing it BEFORE the hardware tries to choke on it.
But not a bad idea, really. Definitely an interesting possibility. And it would mean that more artist would have to verify the MIP layer output. (I always examine the mip layers myself and have adjusted Photoshop for what I believe to be the best results).
-
Interesting...Now if only 3D Max would cooperate..I moved from 7 to 8, and the UV mapping works differenlty here....
-
since down-sampled images are already present in the mip maps of a texture. is there any way to make the bitmap management code automatically toss the first mip level when it loads large 4096^2 textures into memory? this would really simplify mod distribution and installation. some kinda flag like -toss4096, could be used on low end machines.
Maybe. The issue there is knowing -when- and getting appropriate talk back from the hardware to know to do so and doing it BEFORE the hardware tries to choke on it.
But not a bad idea, really. Definitely an interesting possibility. And it would mean that more artist would have to verify the MIP layer output. (I always examine the mip layers myself and have adjusted Photoshop for what I believe to be the best results).
last night i combed over the dds file specs and talked to the e about this. and from my investigations it would be possible to do this at file load. after loading the file header into memory, but before loading image data, the resolution data can be checked to see if it is beyond a previously set limit (perhaps as a command line flag or other setting). if it is not, then file load goes as usual. however if it is, then the header is tweaked (i think only 4 values need to be changed), and the read pointer advanced to start of the next mip level. so the first mip will never be loaded into memory while still maintaining the format. and the engine never knowing that the image on disk is actually much larger than the one in memory. actually i kinda think the format was designed specifically for this kinda application.