Molly Rocket :: View topic - Introducing LibVT

Molly Rocket
Molly Rocket games and everything even tangentially related

FAQ

Usergroups

Introducing LibVT
Goto page Previous 1, 2

Molly Rocket Forum Index -> Sparse Virtual Texturing

View previous topic :: View next topic

Author

Message

julian

Joined: 17 Oct 2008
Posts: 38

Posted: Tue Jan 12, 2010 8:54 pm Post subject:

thanks sean. i tried it again and it *seems* to work fine although i'm sure it couldn't be so easy:

i just chaneged

Code:

withinPageCoord = withinPageCoord * (page_dimension - border_width * 2.0)/page_dimension + border_width/page_dimension;

Code:

withinPageCoord = withinPageCoord * (page_dimension - border_width)/page_dimension + 0.5/page_dimension;

julian

Joined: 17 Oct 2008
Posts: 38

	Posted: Sat Apr 10, 2010 3:13 pm Post subject:

virtualtexturing with OpenGL / ES on the iPhone: http://img138.imageshack.us/img138/5421/vtes.png

julian

Joined: 17 Oct 2008
Posts: 38

	Posted: Sun May 16, 2010 6:55 pm Post subject:

> It allows you to specify local repeats (so you can have short-range-wrapping textures), and other reuse scenarios (e.g. multiple model instances with limited variation). can u elaborate a tiny bit on the support for texture-repeating in your implementation?

sean

Joined: 01 Feb 2005
Posts: 1392
Location: Kirkland WA

	Posted: Sun May 16, 2010 9:06 pm Post subject:

who are you quoting/asking?

julian

Joined: 17 Oct 2008
Posts: 38

	Posted: Sun May 16, 2010 9:11 pm Post subject:

uups sorry, i was quoting/asking you the quoted text is from the SVT "documentation", i.e. the big comment at the top of svt_vtex.c

sean

Joined: 01 Feb 2005
Posts: 1392
Location: Kirkland WA

	Posted: Sun May 16, 2010 10:47 pm Post subject:

A lot of that comment was design and not implementation. I'm not sure it actually suports multiple svtexspaces. But the idea is pretty straightforward. You can reuse the same physical texture at multiple places in the virtual texture space. So suppose you have one big virtual texture space for all your content, so a certain subset is the terrain/world, and then each model gets a certain subset. You can make a variation of a model by making a "copy" of it into a new area of the subspace, a copy that still shares the same underlyign texture data so it can reuse the physical texture tiles, and then repllace some small number of tiles to uniquify that texture (say, change the ID tag, or the face, or whatever). Similarly, you can repeat a single virtual texture tile (or a small block of them) over and over through the virtual space, allowing you to get a small amount of wrapping without having unique copies of the texture data in the physical texture.

julian

Joined: 17 Oct 2008
Posts: 38

Posted: Tue May 18, 2010 12:29 am Post subject:

sean wrote:

Similarly, you can repeat a single virtual texture tile (or a small block of them) over and over through the virtual space, allowing you to get a small amount of wrapping without having unique copies of the texture data in the physical texture.

ok so much is obvious, the same thing can be done when just using a texture atlas, without VT rendering. i am not sure what you mean with the limitation to a "small amount"...i think the limitation is that the all texture coordinates before texture-atlas-coordinate-offsetting fall within the [0,1] range as other values will "point to" wrong tiles after offsetting.

actually i don't see this as repeating a virtual texture tile through the virtual space, but re-using a subset of the virtual texture space (which maps to the repeated tile) from multiple parts of the virtually textured geometry. mittring calls it "non-unique unwrapping" or "overlapping primitives in the texture space".

EDIT: ok it is the same thing if "virtual space" is not "virtual texture space" but just normal world space

sean wrote:

But the idea is pretty straightforward. You can reuse the same physical texture at multiple places in the virtual texture space. So suppose you have one big virtual texture space for all your content, so a certain subset is the terrain/world, and then each model gets a certain subset. You can make a variation of a model by making a "copy" of it into a new area of the subspace, a copy that still shares the same underlyign texture data so it can reuse the physical texture tiles, and then repllace some small number of tiles to uniquify that texture (say, change the ID tag, or the face, or whatever).

i suppose in this context with physical texture you don't refer to the physical backing texture on the GPU (this one: http://img691.imageshack.us/img691/9523/phystex.png)!?

doesn't this mean there is no longer a 1:1 mapping of virtual texture space to the virtual texture? how can some tiles be replaced while others refer to shared tiles?

sorry for not following easily here, it seems my implementation is a lot simpler / straightforward in this regard.

sean

Joined: 01 Feb 2005
Posts: 1392
Location: Kirkland WA

Posted: Tue May 18, 2010 1:33 am Post subject:

By physical texture, I mean both.

If the original character model uses 4k x 4k, and you want to have 8 variations, you "allocate" 32k x 4k of virtual texture coordinates to it. You make 8 copies of the thing. But most of the 4k x 4k of each variation is identical, so you can actually make the page table entry for those tiles point to the exact same physical texture in each of the copies.

Page table for copy #1, imagining it's 8x8 tiles:

Code:

-- -- -- -- -- -- -- --
-- 01 02 03 04 -- -- --
-- -- 05 06 07 -- -- --
-- -- 08 09 10 -- -- --
-- -- -- 11 12 13 -- --
-- -- -- -- -- -- -- --
-- -- -- -- -- -- -- --
-- -- -- -- -- -- -- --

The values in the page table are shown as "indices" into the physical texture, instead of 2D coordinates, just for simplicity of illustration.

Page table for copy #2:

Code:

-- -- -- -- -- -- -- --
-- 01 02 03 04 -- -- --
-- -- 05 14 15 -- -- --
-- -- 08 16 17 -- -- --
-- -- -- 11 12 13 -- --
-- -- -- -- -- -- -- --
-- -- -- -- -- -- -- --
-- -- -- -- -- -- -- --

Note that many of the pages are the same, but the pages in the middle are different.

In practice they'd actually have different parts of the texture visible, and at different resolutions, so each copy would probably have different pages set up, rather than showing the same shape like that. But I wanted it to be clear in this illustration. (And you might update them both with all available pages, too, anyway.)

Also in practice these wouldn't be separate page tables, they'd just be different areas of the same page able (you'd use a certain region for variant #1, another region for variant #2, etc). (And I think the original design, the comment in svt_tex, was actually envisioning a separate page table texture.)

Similarly you can implement limited wrapping:

Code:

-- -- -- -- -- -- -- --
-- 01 02 03 04 -- -- --
-- -- 05 06 05 06 05 --
-- -- 08 09 08 09 08 --
-- -- -- 11 12 13 -- --
-- -- -- -- -- -- -- --
-- -- -- -- -- -- -- --
-- -- -- -- -- -- -- --

reusing the same physical tiles. the drawback is that it still takes up virtual texture space, and requires page table entries.

julian

Joined: 17 Oct 2008
Posts: 38

	Posted: Tue May 18, 2010 8:49 pm Post subject:

ok thanks that clears things up a bit. however this only works on the lowest mip map level. on the next level you still need separate pages because one page is necessary that downsamples (02, 03, 05, 06) but in the copy it needs to combine (02, 03, 05, 14). maybe in a procedural streaming system this can be handled somehow, but when doing tile streaming from HD these are pre-calculated. so, this is a technique that saves a bit of the cost of replicating the same tiles throughout the virtual texture... thanks

sean

Joined: 01 Feb 2005
Posts: 1392
Location: Kirkland WA

	Posted: Tue May 18, 2010 9:28 pm Post subject:

Yep, it only works on some mipmap levels. (It can work for more than one if the region is large enough, but yes, only one level in the example.) Also, I never actually implemented it; as I said, the comment was written while I was designing it so I was expressing the possibility.

julian

Joined: 17 Oct 2008
Posts: 38

	Posted: Sun Aug 29, 2010 10:05 pm Post subject:

source is up: https://sourceforge.net/projects/libvt/files/

Display posts from previous:

	Molly Rocket Forum Index -> Sparse Virtual Texturing	All times are GMT Goto page Previous 1, 2
Page 2 of 2

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