Unlimited Detail Technology
category: offtopic [glöplog]
I'd buy it for a dollar.
The company's logo looks like the "Spice" one.. a in some countries now illegal drug...
mmmmmmhhhcat :)
interstingly Brisbane has the highest MDMA usage in the world :P
interstingly Brisbane has the highest MDMA usage in the world :P
Quote:
no I think it was running on a shitty old laptop (no ghz but I recon 1-2ghz) - 1 core @ 1024x600 (resolution wtf?) @ 28.1fps
coded in C by someone who didn't know what a data cache was. Which is all good news - I found another interview where BD said that they hope to get double the speed when they start to optimize. Greg somebody joined and is now CTO in charge of optimizing/vid card support (guess that means handling blitting to vid mem?).
If that's the case, it's a bit more reasonable. I'm sure somewhere he said the hardware had only recently caught up though. Greg's comments are interesting too - a demo with actual artist art could be awesome.
Maybe by 'vid card support' they mean putting the colour + z buffers on the GPU and integrating it with regular 3d/pixel shaders/etc? With the CPU doing the heavy labour of the scenery, the GPU could be put to work doing super high quality rendering for the rest of it, as there wouldn't be that much left to do. And perhaps applying some post-AA, SSAO, or whatever to the background.
yeah - I think the vid card support is exactly wot u explain - doubt it would just be blitting - else they'd use getobject() on a tagbitmap. so I agree it's some kind of ZBuffer integration so they can use gpu poly's as well.
If it were my tech I would be using the gpu as a post processor - bloom/ssao e.t.c.
Yeah I think with some awesome art from say 3d coat/mud box/ sculptis e.t.c. it could be great!
there was some interesting news on the FB group posted earlier today:
"bruce got interviewed by Englands 2nd largest computer magazine, and Germanies largest computer magazine yesterday. God willing the business will all be signed and official in 3 weeks"
6 hours ago · Report
If it were my tech I would be using the gpu as a post processor - bloom/ssao e.t.c.
Yeah I think with some awesome art from say 3d coat/mud box/ sculptis e.t.c. it could be great!
there was some interesting news on the FB group posted earlier today:
"bruce got interviewed by Englands 2nd largest computer magazine, and Germanies largest computer magazine yesterday. God willing the business will all be signed and official in 3 weeks"
6 hours ago · Report
may he come with a mindblowing real demo at the next breakpoint!
had a "rethink" on how this could be working based on what Bruce has said in his previous posts
maybe it's this:
Traverse the tree
calculate node size on the screen
calculate child node sizes on screen
if Parent>Pixel && Child<Pixel - draw and exit. node.
Means u'd have to have some sort of occlusion system in place
might have a bash at this!
maybe it's this:
Traverse the tree
calculate node size on the screen
calculate child node sizes on screen
if Parent>Pixel && Child<Pixel - draw and exit. node.
Means u'd have to have some sort of occlusion system in place
might have a bash at this!
ey ZJ, are you actually saying you are going to make your own UD?
still wondering about the trans-/rotations !
even if you have like 6 octrees... every array starts far from the actual "side of the cube" ( containing the graphics ) , which leads to enormous RAM-needage already...
...providing an "atom" per pixel in 1024*600 at every cam-angle == 614400 "atoms" ;)
...would mean, you need arrays with enuff "atoms" to choose from for wherever you look or move !
i cant see how this could work at all...never tried octrees tho !
but there cant be enuff RAM on ordinary machines ! considering you need to store the original data aswell for every object in the scene ! ( if its not procedural...but who wants graphics to be procedural only anyway ? )
even if you have like 6 octrees... every array starts far from the actual "side of the cube" ( containing the graphics ) , which leads to enormous RAM-needage already...
...providing an "atom" per pixel in 1024*600 at every cam-angle == 614400 "atoms" ;)
...would mean, you need arrays with enuff "atoms" to choose from for wherever you look or move !
i cant see how this could work at all...never tried octrees tho !
but there cant be enuff RAM on ordinary machines ! considering you need to store the original data aswell for every object in the scene ! ( if its not procedural...but who wants graphics to be procedural only anyway ? )
this said ( if anyone got what i wanted to say, haha ) i lean myself wide outta the window:
the voxel-technique could be the future ! who needs polygons, if voxels are small enuff to not be recognized as voxels anymore anyway !
but this technique is not yet ready, as it needs "GPU"s which are nothing more than a Processor with onboard-SDK ( atleast i wish they do so in the future...no DLLs would be awesome, just as on Amiga, some Registers to work with :) ) and a lot more RAM !
those were my 2bits to this "Joke", as i still consider it !
the voxel-technique could be the future ! who needs polygons, if voxels are small enuff to not be recognized as voxels anymore anyway !
but this technique is not yet ready, as it needs "GPU"s which are nothing more than a Processor with onboard-SDK ( atleast i wish they do so in the future...no DLLs would be awesome, just as on Amiga, some Registers to work with :) ) and a lot more RAM !
those were my 2bits to this "Joke", as i still consider it !
whynot2000: I'm an engine coder - it's my nature to absorb and copy :)
there's nothing I want more than a few lines of pure code to render something complex and at speed.
Hardy: the tree is self referencing - and can be made with parts of itself (it's almost fractal in nature) - coupled with zsprite spheres (and it now does look like the're using z sprite spheres) - u don't need too many nodes.
for example - If u think about trying to render the menger sponge - it's just a 3x3x3 tree with 2 nodes:
node 0 {0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0}
node 1{1,1,1,1,0,1,1,1,1,1,0,1,0,0,0,1,0,1,1,1,1,1,0,1,1,1,1}
thats probably the best reuse/fractal examples.
the trans/rotations stuff - there's plenty of workarounds - read the ompf.org forum - ppl using warp nodes and the like - none 100% ideal but it is do-able
there's nothing I want more than a few lines of pure code to render something complex and at speed.
Hardy: the tree is self referencing - and can be made with parts of itself (it's almost fractal in nature) - coupled with zsprite spheres (and it now does look like the're using z sprite spheres) - u don't need too many nodes.
for example - If u think about trying to render the menger sponge - it's just a 3x3x3 tree with 2 nodes:
node 0 {0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0}
node 1{1,1,1,1,0,1,1,1,1,1,0,1,0,0,0,1,0,1,1,1,1,1,0,1,1,1,1}
thats probably the best reuse/fractal examples.
the trans/rotations stuff - there's plenty of workarounds - read the ompf.org forum - ppl using warp nodes and the like - none 100% ideal but it is do-able
after 7+ years of game industry experience all i can say is: "what's new these days?"
gta's "learn start doing" becomes "learn start forgetting"
gta's "learn start doing" becomes "learn start forgetting"
with that ZSprite-Spheres-stuff it makes sense !
but still sounds like a "game-level" f.e. would consist of the same stuff allover again...like in Doom or just goodóle´Bitmap-Stuff a la Turrican !
even more bad: moduloed instances of same geometry as in my 4ks, haha.
so my thinking of nowadays everybodysPC couldnt handle it is still valid !
if you are at it anyway:
how are you going to rotate ? rotating the octree itself lets say x-wise leads to bigger artifacts the more you rotate at the left/right...
...ok, he states he doesnt need to travel the tree...but i still think this would lead to more artifacts !
for this tech a general rule then must be: first translate, then rotate and generate the octree afterwards ..with no marching, just sorting, it should be fast, but i still dont see how to not march at all !
^^ i was close to delete all this bullshit, but i hit SUBMIT instead !
but still sounds like a "game-level" f.e. would consist of the same stuff allover again...like in Doom or just goodóle´Bitmap-Stuff a la Turrican !
even more bad: moduloed instances of same geometry as in my 4ks, haha.
so my thinking of nowadays everybodysPC couldnt handle it is still valid !
if you are at it anyway:
how are you going to rotate ? rotating the octree itself lets say x-wise leads to bigger artifacts the more you rotate at the left/right...
...ok, he states he doesnt need to travel the tree...but i still think this would lead to more artifacts !
for this tech a general rule then must be: first translate, then rotate and generate the octree afterwards ..with no marching, just sorting, it should be fast, but i still dont see how to not march at all !
^^ i was close to delete all this bullshit, but i hit SUBMIT instead !
hehe :)
umm I'm gonna start coding it in a few mins/hours
View rotation/scale is simple as
internally rotating stuff - I'd don't know now because the algo has changed - before I was gonna mark nodes at rotated and rotate my mid point. Now thats alll gone with the new algo.
my current algo is this:
find out the node traversal order (simply calc the distance from each of the 8 top level nodes to camera - and traverse every node in that order)
for each node -
is Fully behind camera - exit;
is Fully off screen - exit;
calc node pixel size nps
cale child node pixel size cnps
if (nps > pixelsize) && (cnps<pixelsize)
{
// prolly do some zbuffer stuff here
Calc screen pos
render z sprite
}
else
recurse child nodes
umm I'm gonna start coding it in a few mins/hours
View rotation/scale is simple as
internally rotating stuff - I'd don't know now because the algo has changed - before I was gonna mark nodes at rotated and rotate my mid point. Now thats alll gone with the new algo.
my current algo is this:
find out the node traversal order (simply calc the distance from each of the 8 top level nodes to camera - and traverse every node in that order)
for each node -
is Fully behind camera - exit;
is Fully off screen - exit;
calc node pixel size nps
cale child node pixel size cnps
if (nps > pixelsize) && (cnps<pixelsize)
{
// prolly do some zbuffer stuff here
Calc screen pos
render z sprite
}
else
recurse child nodes
"Unlimited Detail Technology" - the marketing department's way of saying "more voxels than you can count in an octree"
hehe - they're soxels tho :)
sproxel-4ks ahead ! :D
I can't figure it out.
eyactly ! ( formerly known as "exactly" )
when round ain´t round anymore !
when round ain´t round anymore !
just tested that algo - works a treat!
pretty sure that's wot they're doing - or a variation of it
pretty sure that's wot they're doing - or a variation of it
Code:
-(NSColor*)computeColor:(Ray)r {
// TODO: insert stuff here
Ray r2;
r2.recursion_level = r.recursion_level + 1;
r2.path_x = r.path_x * 2;
r2.path_y = r.path_y * 2;
r2.path_z = r.path_z * 2;
r2.pixel_x = r.pixel_x;
r2.pixel_y = r.pixel_y;
r2.pixel_w = r.pixel_w;
r2.pixel_h = r.pixel_h;
r2.siz_x = r.siz_x / 2;
r2.siz_y = r.siz_y / 2;
r2.siz_z = r.siz_z / 2;
r2.cam_x = r.cam_x;
r2.cam_y = r.cam_y;
r2.cam_z = r.cam_z;
int vx[] = { 0, 1 };
int vy[] = { 0, 1 };
int vz[] = { 0, 1 };
// sort by camera direction
if(r.cam_x > 0) { vx[0] = 1; vx[1] = 0; }
if(r.cam_y > 0) { vy[0] = 1; vy[1] = 0; }
if(r.cam_z > 0) { vz[0] = 1; vz[1] = 0; }
int ix, iy, iz;
for(iz=0; iz<2; iz++)
for(iy=0; iy<2; iy++)
for(ix=0; ix<2; ix++) {
int vix = vx[ix];
int viy = vy[iy];
int viz = vz[iz];
unsigned int node_index = viz * 4 + viy * 2 + vix;
Node* child = m_nodes[node_index];
if(!child) continue;
r2.pos_x = r.pos_x + vix ? r2.siz_x : 0;
r2.pos_y = r.pos_y + viy ? r2.siz_y : 0;
r2.pos_z = r.pos_z + viz ? r2.siz_z : 0;
// clear last bit and store the taken path
r2.path_x = (r2.path_x & ~1) | vix;
r2.path_y = (r2.path_y & ~1) | viy;
r2.path_z = (r2.path_z & ~1) | viz;
NSColor* color = [child computeColor:r2];
if(color) return color;
}
return nil;
}
Not working..
Is computed per pixel. My first octree code ever, not optimized, objc..
Any ideas how to improve on it?
1) u only have to find the node order once at the start - not every time
2) u can unwrap the recursion with a pointer system:
/*
while hasleftchild(node) do
node = node.left
do
visit(node)
if (hasrightchild(node)) then
node = node.right
while hasleftchild(node) do
node = node.left
else
while node.parent ? null and node = node.parent.right
node = node.parent
node = node.parent
*/
not my code btw - some standard way of doing it, havn't plugged this into my code yet coz i'm too lazy :)
my current code is this:
void RenderNode(u16 Node,int SX,int SY,int Level)
{
if (Level>32) return;
for (int a=7;a>=0;a--)
{
int Me=TraverseOrder[a];
if (Nodes[Node][Me])
{
int MySize=SphereSize[Me]>>Level;
if (MySize>3)
RenderNode(Nodes[Node][Me],SX+(ScreenDX[Me]>>Level),SY+(ScreenDY[Me]>>Level),Level+1);
else
if (MySize>1)
{
gScreenBuffer->Canvas->Brush->Color=Level*32;
gScreenBuffer->Canvas->Circle((SX+(ScreenDX[Me]>>Level))>>16,(SY+(ScreenDY[Me]>>Level))>>16,MySize);//MySize);
}
}
}
}
2) u can unwrap the recursion with a pointer system:
/*
while hasleftchild(node) do
node = node.left
do
visit(node)
if (hasrightchild(node)) then
node = node.right
while hasleftchild(node) do
node = node.left
else
while node.parent ? null and node = node.parent.right
node = node.parent
node = node.parent
*/
not my code btw - some standard way of doing it, havn't plugged this into my code yet coz i'm too lazy :)
my current code is this:
void RenderNode(u16 Node,int SX,int SY,int Level)
{
if (Level>32) return;
for (int a=7;a>=0;a--)
{
int Me=TraverseOrder[a];
if (Nodes[Node][Me])
{
int MySize=SphereSize[Me]>>Level;
if (MySize>3)
RenderNode(Nodes[Node][Me],SX+(ScreenDX[Me]>>Level),SY+(ScreenDY[Me]>>Level),Level+1);
else
if (MySize>1)
{
gScreenBuffer->Canvas->Brush->Color=Level*32;
gScreenBuffer->Canvas->Circle((SX+(ScreenDX[Me]>>Level))>>16,(SY+(ScreenDY[Me]>>Level))>>16,MySize);//MySize);
}
}
}
}
an improvement that wont help, but makes code shorter:
Ray r2=r;
this way lesser re-initialisations !
if it REALLY doesnt work, try:
Ray r2=r;
this way lesser re-initialisations !
if it REALLY doesnt work, try:
Code:
for(iz=0; iz<2; iz++)
{
for(iy=0; iy<2; iy++)
{
for(ix=0; ix<2; ix++)
{
[...]
}
}
}
return NULL;
ZJ: how do you assign RAM? starting at the middle of memory ? seems unnecessary as the tree just spreads out in one way...i´m still at my theory of 6 trees to save lots_of_RAM !
...imma get new beer and make a 4k about it then ! ;P
...imma get new beer and make a 4k about it then ! ;P
I'm using c++ builder my tree is currently random and solid (I need to make a tree with hollow shapes):
tree init code:
for (int a=0;a<8;a++)
{
Nodes[0][a]=0;
Nodes[1][a]=1;
}
for (int x=2;x<256;x++)
for (int a=0;a<8;a++)
Nodes[x][a]=random(x-1);
if I wanna draw a solid cube - my root node is 1
if I want random test data my root node is anything above 1
tree init code:
for (int a=0;a<8;a++)
{
Nodes[0][a]=0;
Nodes[1][a]=1;
}
for (int x=2;x<256;x++)
for (int a=0;a<8;a++)
Nodes[x][a]=random(x-1);
if I wanna draw a solid cube - my root node is 1
if I want random test data my root node is anything above 1