|
View previous topic :: View next topic
|
| Author |
Message |
bengarney
Joined: 25 Feb 2008
Posts: 7
|
| |
 Posted: Wed Mar 05, 2008 5:40 am Post subject: Bilinear Contraction, Tile Size, Managing SVT space |
 |
|
Hey Sean,
I went over the original slide deck you included in the SVT sample app and had some questions. Here they are! Thanks for taking the time to write all this up and answer questions.
For SVT Bilinear Contraction - you mention that you can either keep UV coords as is and pad out the tile size (so UVs are 0 to 1 and you have 66px tiles instead of 64px) or shrink the the UV coords and have "normal" tile sizes (so UVs go from 0.01 to 0.99 and tiles are 64px). It seems like if you take the latter case you would break your mip estimation unless you actually resample every tile to be shrunk down slightly... which seems like it would introduce a lot of aliasing and other problems. The implementation just uses odd size tiles, I think, so I'm guessing you kind of sidestepped this issue? Or is there a solution I'm not seeing?
For tile sizes - id is using 128px tiles, at least based on their papers, was there a significant reason you went with 64px tiles?
For multiple SVTs and managing space within SVTs - it seems like there should be a way of mapping texture data into an n-dimensional space that gets away from the "global unwrap" requirement that SVTs seem to need now.
For instance, say you held your world geometry in a coarse octree. You could unwrap the geometry in each node independently of every other node, track and store the texture data independently, and have a much easier time of it when it came to editing geometry. Before you rendered any chunk for the first time you'd just find a free spot in your virtual texture space and adjust its UV coordinates before you upload the VB. Then everything would work normally, except you'd have a much easier time of it if you wanted to do some editing or otherwise update your database. This sort of thing would also be helpful for people who want to do large streaming worlds that they can't possibly unwrap all at once.
I can't help but feel that there's an even more general approach along this direction but I'm not sure what it is. Having multiple SVT support is really smart, and your demo made excellent use of it, but I think it addresses a different problem.
Thanks!
PS - the slide generation system is really cool.  |
|
| Back to top |
|
 |
sean
Joined: 01 Feb 2005
Posts: 1392
Location: Kirkland WA
|
| |
Posted: Wed Mar 05, 2008 9:11 am Post subject: Re: Bilinear Contraction, Tile Size, Managing SVT space |
|
|
| bengarney wrote: | | For SVT Bilinear Contraction - you mention that you can either keep UV coords as is and pad out the tile size (so UVs are 0 to 1 and you have 66px tiles instead of 64px) or shrink the the UV coords and have "normal" tile sizes (so UVs go from 0.01 to 0.99 and tiles are 64px). It seems like if you take the latter case you would break your mip estimation unless you actually resample every tile to be shrunk down slightly... which seems like it would introduce a lot of aliasing and other problems. |
Ok, first of all, you always have to do contraction: you have a physical page which is larger than the logical page, and you have to remap your coordinates between them. This can get rolled into the conversion from within-page 0..1 tc to physical tc, though.
So it's really just a question of whether it's better to be power-of-two for the physical page or for the logical page. (You can think of the logical page size as being the chunks the virtual texture space is divided up into.)
The mip estimation needs a bias anyway, and this is just a slightly different bias. (E.g. the page-table bias is something like log2 of the logical page size, and that just works regardless of whether it's power-of-two or not.)
There may be disadvantages to padding the physical to be non-power-of-two, in that it messes with the addressing of the physical page, but I doubt there could be enough precision issues for it to matter. Since I didn't try anything, it's possible there's issues I didn't see.
The biggest advantage to having logical sizes be power of two is using multiple SVTs; you can just turn on wrapping in the page table and get a wrapping texture that's power-of-two in size. If the logical size isn't a power of two, you can still create a wrapping texture by wrapping the page table, but now it's non-power-of-two in size, which is kind of dumb.
| Quote: | | The implementation just uses odd size tiles, I think, so I'm guessing you kind of sidestepped this issue? Or is there a solution I'm not seeing? |
I'm just not seeing the problem you're seeing. But then I never tried implementing it.
| Quote: | | For tile sizes - id is using 128px tiles, at least based on their papers, was there a significant reason you went with 64px tiles? |
Nah, I just picked one out of a hat (when I started, I didn't know id had published anything). 64x64 was 4K texels, so it resonated with 4K pages, but mainly I picked 64x64 for the granularity of generation. With the heavy constraint I have on how much I generate per frame, larger sizes would be insufficiently granular (I think I'm limited to 20 64x64 pages; the same amount of texel data would be 5 128x128 pages, which might pop more noticeable).
But I definitely think 64x64 is too small. Larger sizes will cut down on page traffic and increase the number of texels you can address with a single SVT or on a readback.
| Quote: | | For multiple SVTs and managing space within SVTs - it seems like there should be a way of mapping texture data into an n-dimensional space that gets away from the "global unwrap" requirement that SVTs seem to need now. |
I don't really conceive of the problem this way. If you go with the readback approach and a straightforward (non-multiple-render-target) approach, you have 28 bits of page ID, so 2^28 possible pages. Yes, that's not enough for sub-centimeter texels on a huge world, so yes, you'd have to do some kind of dynamic swapping of those. But if you don't use readback, you're not constrained at all in how your address space is mapped, it's just up to whatever's in however many page tables you use.
But I chose this model because it allows you to use it straightforwardly with the existing rendering model. Where currently you have distinct textures (used non-uniquely), you could just replace those textures with unique page tables textures, change all your shaders, and drop SVT into your system, and suddenly up the resolution on all your existing textures.
If I wanted to do a big world, I'd probably chunk the world in very coarse lumps, say 2 miles on a side, and give each chunk its own page table. You could do this in octtree fashion instead, and connect it to LOD if you wanted.
But, basically, yes, if you want more pages than fit in GPU memory page tables, you have to do something else, and I have no opinion on that subject. Are you really better off trying to pack one big virtual space on the fly (updating texture coordinates as you load) and deal with fragmentation of the virtual space, or just put them all in separate virtual spaces and pay the texture change overhead? I dunno. |
|
| Back to top |
|
|
bengarney
Joined: 25 Feb 2008
Posts: 7
|
| |
Posted: Wed Mar 05, 2008 11:08 am Post subject: |
|
|
Re: Contraction
Hmm... Well maybe I'm just confusing myself. (I spent a lot of time on this issue when I was implementing a quadtree texture LOD system for a terrain engine a while back. Ended up using pow2 physical pages, which resulted in my logical pages being slightly smaller, and some minor alignment issues cropping up at the "far" end of the texture space. No visible seams between tiles though!)
| Quote: | | There may be disadvantages to padding the physical to be non-power-of-two, in that it messes with the addressing of the physical page, but I doubt there could be enough precision issues for it to matter. Since I didn't try anything, it's possible there's issues I didn't see. |
Wait, are you saying you didn't actually address this in your implementation, and that there are seams due to lack of padding? I'm probably misreading you here, sorry.
Re: Tilesize
Makes perfect sense. Thanks.
Re: Managing Space in SVTs
That makes sense. Drop in is smart. (Clearly my bias is towards more complex solutions. I'm not convinced this is a good bias to have.
My thought is this: You have the texels to texture a big chunk of world no problem. Even more so with multiple SVTs active. But you have to unwrap the world into one big UV space ahead of time, which is computationally costly. In addition, most UV unwrappers I've seen tend to totally change their output if you tweak the model at all, so editing your geometry except in limited ways is out.
However, there's nothing in the SVT that requires the global unwrap - just that unique UV coordinates go on unique geometry. So that becomes a resource you can allocate, just like memory in a virtual memory scheme.
Another related situation - suppose you have a bunch of character models. You could run them off of separate SVTs, or reserve some UV space in your world texture SVT and run things out of that. But that case feels like you're just trading off the SVT ID bits for more page ID bits, whereas in the other one you're getting a more flexible means of dealing with complex world geometry.
I guess this SVT space management stuff is fairly theoretical in terms of it being much more "interesting things to do with an SVT once you have it" rather than "fundamental issues related to SVT implementation." |
|
| Back to top |
|
|
sean
Joined: 01 Feb 2005
Posts: 1392
Location: Kirkland WA
|
| |
Posted: Wed Mar 05, 2008 11:30 am Post subject: |
|
|
| bengarney wrote: | | Wait, are you saying you didn't actually address this in your implementation, and that there are seams due to lack of padding? I'm probably misreading you here, sorry. |
Yeah, I wasn't clear enough. I only implemented power-of-two physical (and it was seamless for bilinear). It's possible there's issues with power-of-two logical that I didn't think of, since I never tried it.
| Quote: | | However, there's nothing in the SVT that requires the global unwrap - just that unique UV coordinates go on unique geometry. |
Well, this is one of the big fake-outs of SVT--there's really nothing about them particular to doing unique texturing. It's just the most obvious and easily demo-able thing. But you can just as easily use it to implement a game with 256 8k x 8k textures that are totally non-unique and used traditionally.
There may be trickier things to do for fully-unique, and fully-unique may be the most interesting application, but I don't consider that part of SVT. But yeah, whatever set of pages you have is certainly a resource you can allocate and manage however, if you have more pages in the game than fit in the GPU.
| Quote: | | But that case feels like you're just trading off the SVT ID bits for more page ID bits, whereas in the other one you're getting a more flexible means of dealing with complex world geometry. |
Yes, the trade off between those bits was why I punted discussing it from my talk. I'm not sure what all the constraints are affecting the trade-off.
| Quote: | | I guess this SVT space management stuff is fairly theoretical in terms of it being much more "interesting things to do with an SVT once you have it" rather than "fundamental issues related to SVT implementation." :) |
Yep, exactly. |
|
| Back to top |
|
|
sylvan
Joined: 29 Feb 2008
Posts: 8
|
| |
Posted: Sun Mar 09, 2008 9:55 pm Post subject: |
|
|
| sean wrote: |
| Quote: | | But that case feels like you're just trading off the SVT ID bits for more page ID bits, whereas in the other one you're getting a more flexible means of dealing with complex world geometry. |
Yes, the trade off between those bits was why I punted discussing it from my talk. I'm not sure what all the constraints are affecting the trade-off.
|
I mentioned this elsewhere, but one way of solving this is if you have hardware that can do arbitrary memory writes from the shader (like the 360:s memory export). You don't need to store the page table ID that way, since you just write to the "active" page table for whatever it is you're rendering at the moment. I.e. you don't have a separate pass to do the readback, you just do it in the actual rendering pass itself (when you've already done the vritual address translation anyway). This means you can have an arbitrary number of SVTs, and you could just slot them in as replacements to regular textures (which seems attractive to me, you're basically just lifting texture size restrictions from the artists, rather than imposing new restrictions about having to atlas all the textures in this one (or N) big uv space). |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Usergroups
Log in
Register
