10/17/2008

10-17-08 - 3

I've been feeling a little lost the last few days working on Oodle. The low level stuff is coming along well, but the high level APIs are a big scary void of possibilities. I feel like I need a more realistic test app to really stress the system and to see how easy the APIs are to work with and all that. I've got unit tests and such but that doesn't really do it, I want a mini game that loads data the way games do and pages data the way games do, with stuff streaming as you walk around, and then big loads at area boundaries with a prefetch and a transition area. I'm uncomfortable writing libraries without a user; I at least like to have *me* as a user, but more would be even better.

One of the tricky things about the high level is how easy should I make it for games to do the broken stuff they do now, like for example the Unreal style of having everything in giant packages. I generally want to make the APIs encourage people to do things the "right way", and make that as easy as possible, but at the same time I do have to provide some reasonable fallbacks for more broken behavior.

Basically the "right way" is having static resource usage information and letting me make bundles of resources however I see fit, and then letting me load the bundles in and out of memory based on the game's usage and prefetch hints (or, you know, if you want to define bundles in logical units that are reasonably small and atomic that's okay too). There are two main kinds of "wrong way". One is a system that just says "okay load everything" at the start of the game. The other "wrong way" is just randomly requesting content synchronously in the middle of frames with no static resource analysis or prefetch to help me out, like just randomly going "texture * cur = load( rand() ); int a = cur->bytes[3];"

I've got a few ideas of little fake games to make. One idea is to make a "Sparse Texture Buffer" (STB) (aka SVT) test app that does the whole texture-page loading thing. I could cook up 1 GB of texture and put it on a quad and fly around on that and page texture. That might be amusing and make people say "oo" but it's not really a very good test of general game content loading. I might do it anyway just because it's easy and sounds fun.

Another idea is to try to do some geometry loading for an actual walkthrough type of thing. One problem with that is getting enough geometry to actual be too big for memory and stress and the paging. I'd have to somehow find a hell of a lot of geometry, or just fake it by duping a few files and calling them different names, or do some procedural geometry generation which I guess could be fun.

One idea that popped in my head was doing a little real-time raytracer. The fun thing about doing a realtime raytracer for paging is that I can do the infinite geometry load-on-demand thing. The basic idea goes like this :


Fire all the rays from the camera
	(group in packets of 4 or 16 or something)
	(process in a coherent tile order for locality)

Intersect rays with objects in front-to-back order

When a ray collides with a resident object its done

If a ray hits a non-resident object, request that object to page in,
	and push that ray to the deferred queue

After you process all the rays you can, see if any of the objects we requested became resident
	if so, collide them
	if not, wait a little if we have enough frame time

If we're running out of frame time and the objects still aren't resident,
	then collide the lower LOD version that's in memory, or some other fallback

this gives you perfect object residency which is just-in-time (if the IO returns fast enough and you don't stress it too hard). Because the rays tell you what to load you get perfect occlusion residency information. There's other paging stuff to make it work better, such as prefetching objects that are very likely to be hit at the start of the frame and also prefetching in the direction of camera translation to anticipate.

I could do the Id oct-tree thing, or just do a more normal objects that are made of kd-trees and triangles kind of thing. Writing a little packet kdtree raytracer is actually pretty easy, but I still might not do this because it seems like getting off track a bit too much. And I still have the problem of getting enough geometry to actually stress the pager.

ADDENDUM : hmm , yeah I should probably just find some reasonably simple open source game to plug into and replace its IO. Anybody have a good idea of a game I can adapt whose code base won't break my brain?

No comments:

old rants