Molly Rocket

Introducing LibVT

julian — Sun Aug 29, 2010 10:05 pm

Author: julian

Posted: Sun Aug 29, 2010 10:05 pm

source is up:

https://sourceforge.net/projects/libvt/files/

Issues with running the demo

Bob — Thu Aug 26, 2010 12:35 pm

Author: Bob

Posted: Thu Aug 26, 2010 12:35 pm

If someone is still interested, got it running in VS2010, using a Geforce GTX 280.

Stuff I changed:
Removed one file in the project that triggered the custom build thing, it was in glsl shaders I think.
Removed the version line in virt_text.txt
Modified this line in virt_text.txt:
result.grad = vec4(dFdx(address) * gradient_scale, dFdy(address) * gradient_scale);

Carmack: Sparse Voxel Octree

icastano — Thu Jul 22, 2010 9:45 am

Author: icastano

Posted: Thu Jul 22, 2010 9:45 am

sean wrote:

This seems like it might be huge: http://alice.loria.fr/~nivoliev/Seamless/

I've always felt like something like this should be possible, although I don't think I ever managed to work out even the simple premise "if you just make shared chart edges have the same shape in texture space (i.e. just translated and 90-degree rotated), you can avoid artifacts". But it feels like that was where I was always trying to get my head to and failing.

That is pretty cool, I'm glad somebody worked out the details. However, building the initial quad-parameterization is still a challenging task. The global parameterization algorithms work well on paper, but it's not clear whether they are robust enough to be used in a production environment.

Updating the Pagetable

skynet — Tue Jun 29, 2010 11:06 am

Author: skynet

Posted: Tue Jun 29, 2010 11:06 am

Each tile corresponds to one texel in the page table texture. Depending on which tiles (a.k.a. pages) have been deleted from or uploaded into the page cache, you need to update the corresponding texel in the page table.

About the feedback buffer

sean — Thu Apr 29, 2010 4:05 am

Author: sean

Posted: Thu Apr 29, 2010 4:05 am

Cool! You're welcome.

Determing what to have in the cache

julian — Thu Mar 18, 2010 10:33 pm

Author: julian

Posted: Thu Mar 18, 2010 10:33 pm

nice idea!

handpainting is a bitch

rouncer — Thu Mar 11, 2010 9:16 am

Author: rouncer

Posted: Thu Mar 11, 2010 9:16 am

Yo everybody.
Thanks for the input, I take it you guys wanna see this happen? maybe I do to... the engine is going fine at the moment, I dont see why I cant finish it off. Ill have a small setting next, im finding using large strokes will probably get me further, Ill leave some areas solid colour - maybe even go for a cartoon look?

Who knows, but with 100% unique texels, the world could not look like anything weve seen before.

Thanks for the interest, ill definitely 100% eventually have something more for you here, just give me another month.

Anisotropic filtering

ryg — Wed Mar 10, 2010 5:05 pm

Author: ryg

Posted: Wed Mar 10, 2010 5:05 pm

julian wrote:

>log2(Pmax / N)
>= log2(Pmax / min(ceil(Pmax/Pmin), max_anisotropy))

ok of course the same

>= log2(Pmax / ceil(min(Pmax/Pmin), max_anisotropy))

still the same if the parenthesis closing min moves after max_anisotropy

>=floor(log2(max(Pmax / (Pmax/Pmin), Pmax / max_anisotropy))

ok suddenly we return integer instead of floating point values here, but even when looking at the rounded values that are written to the framebuffer i just don't get the same results after this transformation ;
-(

Woops, yeah, correct. Brainfart, I really shouldn't try to do maths just before going to sleep . Yeah, that stuff doesn't work. Just ignore it.

julian wrote:

while we are at it, i see replacing division with multiplication is popular but is there any data on how much this really gains? also if i don't have a constant for 1/max_ani but just one for anisotropy, won't the GLSL compiler still precompute the division of the two constants?

First off, current shader cores don't have a direct divide instruction, so "x = a/b" is always executed as "t = 1.0 / b; x = a * t". So even if the divide was cheap, precomputing the reciprocal is pretty much always a win. Except the reciprocal usually isn't cheap at all - how much slower depends on the exact architecture, but the usual range is 3x to 7x as high latency as a single multiplication.

Interesting raymarching preso

jai — Tue Sep 29, 2009 2:19 pm

Author: jai

Posted: Tue Sep 29, 2009 2:19 pm

In addition to Tom's link, there are a whole bunch of fantastic bits on the site. My current favorite is this brief presentation behind the scenes of the amazing 4K demo 'Elevated'. It's a complete walk through -- ideas, inspiration, implementation.

http://iquilezles.org/www/material/function2009/function2009.htm

Texture corruption on the planets in the demo

Doug Rogers — Mon Sep 28, 2009 2:31 pm

Author: Doug Rogers

Posted: Mon Sep 28, 2009 2:31 pm

I am using an NVIDIA GeForce 8800 GTS 512 with a recent driver,which should support all the same extensions. I have not investigated the source of the corruption, though.

I guess the take away here is that a robust implementation would need to be run on a variety of platforms and have fallbacks as is typical of PC applications.

This why a PC is not just one SKU.

Thanks for the presentation and posting the code.

EDIT: I am using Vista 64 as well.

Shouldn't it just be "virtual texturing"?

AndyFirth — Tue Aug 25, 2009 2:04 pm

Author: AndyFirth

Posted: Tue Aug 25, 2009 2:04 pm

one of these days i'm hoping to get a week or two to play around with this stuff... been reading on here for a while and it sounds interesting and useful.

ah... maybe ... one day... i'll get a week to myself.

Simplest Trilinear Shader

BrianKaris — Thu May 07, 2009 6:28 am

Author: BrianKaris

Posted: Thu May 07, 2009 6:28 am

Yeah, I read that but I wasn't clear what happened when the scales of s and t weren't the same or if there was sheering. What you described sounds like it should handle those cases fine.

If you need a page id texture that is the size of the page table for the find needed pages pass, it can have this info in it to. It would be sampled then by vtc and not vtc * vPageSize but the same texture can be used.

For the next 2 weeks or so I don't have time to start work on implementing this stuff so until them I'm just doing research. Once I have my hands dirty I should be able to talk about this with a lot less uncertainty.

Thanks for the help.

Microsoft demo at TED -- similar to SVT?

Corrinne — Mon Mar 02, 2009 12:33 am

Author: Corrinne

Posted: Mon Mar 02, 2009 12:33 am

Hello, Sean,

I thank you and Carmack for pioneering the early work on sparse texture. I thank Mittring for his sharing his ongoing sparse texture work on Crytek as well. Martin == great guy.

For Seadragon I think the implementation is a pretty straight forward sparse quadtree with arithmetic mean, not wavelet.

I have been working on Haar wavelet sparse texture, mostly standing on shoulders of giants, so I think maybe it's me (MGS), or Bloom (MSR), or Mike (MGS), from Microsoft working on Haar sparse texture?

I have also been working on Volterra series sparse texture. Volterra series has many highly appropriate properties that map well texture data domain.

I am trying to squeeze in my Volterra series sparse texture work into my GDC 2009 speech, but my speech is already 2 to 3 hours overly long and rambling and needs editing and cutting.

Corrinne Yu
Halo team Principal engine programmer
Microsoft game studio 1st party Technical lead
Halo lead

Sparse Virtual Texture Presentation

MSN — Wed Oct 22, 2008 9:33 pm

Author: MSN

Posted: Wed Oct 22, 2008 9:33 pm

julian wrote:

just FYI there is a new paper on the subject that reverences both your works (SVT & UTMfAM):

http://ati.amd.com/developer/SIGGRAPH08/Chapter02-Mittring-Advanced_Virtual_Texture_Topics.pdf

Hey, he references me too!

MSN

Larrabee at SIGGRAPH

TomF — Sat Aug 09, 2008 6:05 am

Author: TomF

Posted: Sat Aug 09, 2008 6:05 am

I think from the replies here that we're talking at cross-purposes some of the time - probably because of a misunderstanding about what the hardware does and doesn't do. I can't actually give you the hardware spec - I like my balls where they are - so you might have to read between the lines a bit here.

But software I can totally talk about. As of last Monday the gloves are off, and I'm doing a talk at Siggraph on Thursday that mentions all this stuff (though it's only 20 minutes, so it doesn't go into this sort of detail).

Quote:

So, from a practical standpoint, it seems like all the "workarounds" for the classic GPU just work

If you need cross-platform first and foremost, this hardware support gives you nothing but extra speed. It's quite a large amount of extra speed, but if you're already running fast enough, who cares, right? So let's leave that aside and assume we're in a world where you do care. Which is the assumption every discussion kinda has to start with, otherwise what's the point, right?

So if you just want to switch from a "software" SVT system such as Sean's or John's, to a "hardware" system (they both use a bit of both of course, I'm just using these as typing shorthand), but you don't want to change the fundamental game engine or artwork, here's where the speed increase comes from:

-No need for the first pass.

-No feedback of that data to the host to manage the page tables.

-In the second pass (which is now the only pass), you don't need 14(?) shader instructions and 2 texture reads, you just read the texture with a perfectly normal texture instruction. If it works, it gives the shader back filtered RGBA data just like a non-SVT system. If it doesn't (which we hope is rare), it gives the shader back the list of faulting addresses, and the shader puts them in a queue for later and does whatever backup plan it wants (usually resampling at a lower mipmap level).

-No memory padding needed.

-No speed penalty when you hit pages that are present.

All that is going to add up to some pretty serious speed improvements. My understanding is that Rage's lighting model is severely constrained because every texture sample costs them so much performance, they can only read a diffuse and a normal map - they just can't afford anything fancier. But if texture samples are now the same cost with SVT as without, that's got to be worth a fair bit.

Note that the page-fault handler system is basically the same in both cases - you get a fault, and you can decide to either service it then, or service it later (end of frame, next frame, whatever). It's a hugely important and gnarly part of the system - lots of prefetch heuristics and knowing what to evict and so on, but it's basically the same algorithm whichever system you use.

So that's "why is my game faster?" But there's a bunch of extra benefits that you just can't get with the software SVT in a practical manner. Again, this is only relevant if you don't mind that some hardware can't do this yet, but let's just pretend for a second:

-No significant changes to any shader or rendering code (compared to a non-SVT engine).

-Works with all filtering/wrap/clamp modes.

-Works with all texture types (cube maps, volumes, etc)

-Works with translucency and multiple layers.

Those are pretty useful things, whether you already have an SVT system up and running or not.

Quote:

Except nobody's actually sat down and implemented it, so does it really work?

Yes, it works. I was at 3Dlabs writing drivers when they implemented it and shipped hardware and wrote the drivers and so on, so yes it works in practice in real machines with real apps. And that was a far more primitive system then the Larrabee implementation - the host had to do an absurd amount of work on page faults. But it still did work. And of course Intel has people writing and testing SVT systems right now - it seems to work just fine.