|
|
|
[
Permlink
| « Hide
]
Lex Neva added a comment - 08/Jun/07 12:17 PM
I could be wrong, but I think SL does do mip-mapping.
Hmm, part of the problem with straight-up mip-mapping is that it only really reduces the amount of information that needs to be drawn on screen, but tends not to actually reduce the amount of texture information ending up on the graphics card. This is fine in games as it means you just put all the full-size images into the graphics card memory, and then only sample parts of it if it's far away. This reduces draw-time, but doesn't do anything for memory efficiency.
However, this isn't the same as actually sending smaller version of textures to the GPU, as this will reduce texture load which isn't as much a problem in main-stream games as the number of textures per scene is controlled. Meanwhile in SL unfortunately you could have hundreds, if not THOUSANDS of different textures in a scene at once, all having to be swapped in and out of the graphics card continuously because you have 1gb of de-compressed textures trying to fit onto a 256mb VRAM card for example. This is really more a suggestion that a similar idea be applied to be the actual texture detail being used in the first place. So instead of a full-size 2mb texture being sent, a 512k one might be if it's in the distance. It's one of the reasons that high-speed systems with the highest performing graphics card might not actually perform as well as a slower system with lots of RAM and/or VRAM, as the swapping because of SL seems to become horrendous and really starts to kick the ass out of a system. I mean, I've not tested it but if I could get a 512mb graphics card with similar (or worse) spec to my current one, then I would fully expect performance to improve in areas with a ton of textures. Purely because so much information is trying to get onto my graphics card all at once that it can't cope. When I was at a mall recently, a big, open-plan place with far too many vendors visible all at once, I found SL was pushing my 2gb of RAM to the limit. 2GB!!! I've ordered another 2gb that I wanted anyway, and expect that to make a huge difference as well if I go back, or go to a similar place, since less data will have to be swapped out to virtual memory. I especially feel that avatar texture detail level should be progressive. People can wear clothes with huge textures, and there can be a lot of avatars in the same scene. A simple option to limit texture size to 512x512 would mean a 75% memory save, and progressively loading smaller textures for people farther away would have an even more dramatic impact.
Buildings etc. are trickier, as there can be a lot of text embedded into some images. The limiting algorithm needs to make sure that textures load at full detail up close. But this is something that needs to be done. It is probably infeasible to educate all residents on the fact that a texture is always uncompressed in the gfx pipeline. People tend to think that if it will compress well it's not a problem. SL already absolutely has this in multiple methods. Textures are always downloaded in progressive increments, the detail only coming in to the highest levels when you zoom in to them or they are drawn large on the screen or very close to your av. In addition depending on the setting you pick for your 'video card memory' SL will cap you at specific steps of this progression... i.e. if you pick you have a 32 meg graphics card, you will NEVER be sent 1024x1024 levels of detail, SL will send you the 256x256 stage and stop there. You can test this easily for yourself.
also for avatar clothing and skins those are 'baked' on your local computer, and absolutely will only be sent to/from SL for other people to see with a total resolution of 512x512 for the head, the torso, and the legs. You can 'use' a 1024x1024 texture for a shirt, but no one will actually be shown it, it will re-bake to a 'final' texture to be sent out on yer machine, as 512x512. On the flip side i believe if you use a 256x256 it will up-sample to 512 when combining with all the other texture layers for the final burned skin The question then is if you see a texture at full-detail (you're close to it) and then move away, what detail level is it loading at? The performance problems in high-texture areas (e.g malls) implies that once you've downloaded a texture at full detail, the full texture will be swapped in an out of VRAM until you can no longer see that texture, even if you're far away.
What I'd like to see is textures only being swapped into VRAM at full-detail if you can still see that detail. Basically when deciding which textures to display. So scanning a scene might go like: The end result is that Texture B will sit in RAM as the 512 x 512 version (if there is a version with even more detail then this will be cached but not in RAM unless it becomes needed). Texture A will be held in RAM at 256 x 256, with a higher detail version again being left on the hard-drive cache. But surely what is proposed is how things are working now to some extent? I see a higher resolution kick in in steps as I get closer. But admittedly it often seems to get stuck at low resolution, which I tend to assume is my fault for having an old machine/graphics card.
Surely it is fundamental to jpeg2000 streaming that a low resolution version comes first, and then, as more data arrives, the resolution clicks up stepbystep. I assume that the viewer either requests a certain LOD, or else declines further data when the necessary detail is reached. Does anyone have a good source on exactly what LL are doing ? |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Major
Texture LOD
