I’m not sure what you mean dorbie. Are you talking about each leaf node renders, say, a geogroup in a scenegraph, from different points of view into buffers, then composite the appropriate render into the final scene?
Exactly, a leaf is held on a system with a graphics pipe, for something like volume rendering you store a region of the volume in texture memory locally on the card. Of course that’s not a hard limit you can hold more on each leaf e.g. for stuff like animation. You can zbuffer within a leaf etc, and even clip between leaves along BSP boundaries, the important thing is that the planes (hardware switching video compositing nodes) define the boundaries between the leaves. Now, some of this is similar to the way the existing compositor works (or was intended to) but it’s fugly the way they’ve built it compared to my BSP and a binary hardware tree design.
To recap, imagine a classic BSP where each leaf is a graphics card and each plane is a switching compositor (using video alpha), your software to run the thing becomes trivial and applications can easily exploit it with very minimalist middleware support.
Dorbie, that sounds extra cool. I like anything with trees in it :-). I like the idea of taking the problem to the streets, as it were. It really makes sense, with a clever node/leaf/zone manager. A wired version of this thing would make for some heavy metal kick ass.
On a slightly different tack, I’m reminded of some research done at UNC, quite a few years back, where they had what amounted to a dedicated GPU for each pixel on the display (or maybe it was just a 4x4 block). I don’t know where that research went, but it sounded promising albeit somewhat expensive at the time (1995?). They had a demonstration simulation of several highly detailed F-15 jets flying in formation and it looked great, very smooth.
Originally posted by Hlz:
I like anything with trees in it :-).
Yeah, me too
Especially forests
Originally posted by knackered:
I’d imagine that in the end, using opengl in a windowed app will be exactly the same as now, except instead of blitting the framebuffer into video memory the driver will copy it into a d3d texture. I can’t imagine why it would be anymore complex than that.
I just wonder how quad buffered stereo is going to work…and gen-locking, for that matter.
… or high precision accumulation
… or overlay planes
… or …
I agree with you – it shouldn’t be that hard to connect the OpenGL buffer to a Direct3D surface. The graphic card vendors could all implement an extension that lets the application make the connection:
HANDLE WGL_TRA_BindContextToSurface(HGLRC hRC, LPD3DXCONTEXT pCtx);
void WGL_TRA_ReleaseContextBinding(HANDLE hCtx);
These objects are known to the driver (LDDM, DDI, ICD, etc.) and there would only be minimal D3D setup required. The tricky part would be to implement a reliable way to get to the ICD without it being installed (i.e., I seriously doubt that the extension mechanism in “OpenGL on D3D” would pass that on to the driver). I think this is the enhanced “security” that Aeroglass is “providing”. Depending on which side of the politcal spectrum you are on, one person’s idea of security is another person’s idea of protectionism 
– tranders