Unlimited Detail
Pages: 12
http://www.youtube.com/watch?v=Q-ATtrImCx4
If you can get past the strange-sounding spokes-person that explains the whole system like we're mentally handicapped, you'll see what the system is (if you haven't seen the video before) and so I won't have to explain what it is here.
So what do you think? Is it "FAKE AND GAY" or could this be the real deal?
My opinion: I can see the algorithm being possible, but it's the amount of data that it says that it can support that phases me. Well, not so much the data it can sort through, but the amount of data he expects a computer to be able to hold. The average computer has about 4GB of RAM (remember, this is supposedly software-based), approximately 1GB goes to the system and other applications running in the background (often more, but I'll just say 1GB for now) and while more goes to other parts of the application I'll leave that out for now since it doesn't make any difference whether or not that memory is being used.
Assuming that doubles are being used (unlimited detail, can assume that floating points will be as accurate as possible) for positions, that's 24 bytes just for the position of the point. Then we get the color (4 bytes), and in a minimalistic system that's 28 bytes per point. Doing some short-hand math here, 3GB/28B comes to about 110,000,000 points being available. Obviously much less when actually applied. 110 million is a far cry from billions of points, but this is the only problem I see with the system they have going on. You'd need something like a server to be able to run something using that much RAM.
If you can get past the strange-sounding spokes-person that explains the whole system like we're mentally handicapped, you'll see what the system is (if you haven't seen the video before) and so I won't have to explain what it is here.
So what do you think? Is it "FAKE AND GAY" or could this be the real deal?
My opinion: I can see the algorithm being possible, but it's the amount of data that it says that it can support that phases me. Well, not so much the data it can sort through, but the amount of data he expects a computer to be able to hold. The average computer has about 4GB of RAM (remember, this is supposedly software-based), approximately 1GB goes to the system and other applications running in the background (often more, but I'll just say 1GB for now) and while more goes to other parts of the application I'll leave that out for now since it doesn't make any difference whether or not that memory is being used.
Assuming that doubles are being used (unlimited detail, can assume that floating points will be as accurate as possible) for positions, that's 24 bytes just for the position of the point. Then we get the color (4 bytes), and in a minimalistic system that's 28 bytes per point. Doing some short-hand math here, 3GB/28B comes to about 110,000,000 points being available. Obviously much less when actually applied. 110 million is a far cry from billions of points, but this is the only problem I see with the system they have going on. You'd need something like a server to be able to run something using that much RAM.
It definitely sounds interesting, if those videos are truly being rendered in real time. Although I wish he stopped saying "unlimited". The proper word is "arbitrary". And what's so strange-sounding about the guy, anyway?
As for the data volumes, in the Sierpinski... tetrahedron demo, he mentions there's billions of points on screen; let's say 2*10^9. If we assume the points have no color and use floats, that's 24 billion bytes in raw point data, assuming absolutely no overhead for data structures. Just a simple single array of points. Since they're supposedly using some kind of clever search algorithm, there should most likely be some overhead for structures. I think it's fair to say that, unless they're running this on a small supercomputer, the points are generated procedurally, presumably from mathematical formulas.
EDIT: By the way,
1. Search "atomontage" on YouTube.
2. Your head asplode.
As for the data volumes, in the Sierpinski... tetrahedron demo, he mentions there's billions of points on screen; let's say 2*10^9. If we assume the points have no color and use floats, that's 24 billion bytes in raw point data, assuming absolutely no overhead for data structures. Just a simple single array of points. Since they're supposedly using some kind of clever search algorithm, there should most likely be some overhead for structures. I think it's fair to say that, unless they're running this on a small supercomputer, the points are generated procedurally, presumably from mathematical formulas.
EDIT: By the way,
1. Search "atomontage" on YouTube.
2. Your head asplode.
Last edited on
This guy seemed to be putting far more stress on "how unfair the industry was" and blah-blah-blah, instead of explaining what are they doing, and what are the approximate requirements of his system.
Also the camera didn't zoom much either, which makes me suspicious.
At any rate, if once you have the point cloud and you do have such a speed in software, you should be able to use a combined approach - that is, keep 3d objects in memory; each time you get closer to one such object, you compute a point cloud corresponding to the object and its texture.
This will be very quick, since computing point clouds for spheres and primitive shapes is very fast. Also, you will be able to do plenty of other simple mathematical shapes (paraboloids, cones, hyperboloids, cubic surfaces) with the same blazing speed.
That is, if he is not bullshitting us (which he appears to be). Anyways, he promised a SDK soon - if he does come up with one, his company will be famous :)
Also the camera didn't zoom much either, which makes me suspicious.
At any rate, if once you have the point cloud and you do have such a speed in software, you should be able to use a combined approach - that is, keep 3d objects in memory; each time you get closer to one such object, you compute a point cloud corresponding to the object and its texture.
This will be very quick, since computing point clouds for spheres and primitive shapes is very fast. Also, you will be able to do plenty of other simple mathematical shapes (paraboloids, cones, hyperboloids, cubic surfaces) with the same blazing speed.
That is, if he is not bullshitting us (which he appears to be). Anyways, he promised a SDK soon - if he does come up with one, his company will be famous :)
Last edited on
My thought is it's got a chance at being real...as what would this company gain by lying about what they've done, built up a fan-base and then never delivering a product?
There's no proof that this is an actual company. All I've seen in an e-mail address, for all we know some guy could just be trollin'.
They're probably a few guys coding in their spare time. That's why they're looking for venture capital.
If the videos are prerendered, they could be trying to attract investors with something they don't (and may never) have. Of course, anyone with more brain cells than pennies would first like to try the software live.
| as what would this company gain by lying about what they've done, built up a fan-base and then never delivering a product? |
They have a website: http://unlimiteddetailtechnology.com/
I think that it's either "a few guys coding in their spare time" or a startup company.
I wonder if the SDK is going to be commercial, closed-source software or FOSS...
I think that it's either "a few guys coding in their spare time" or a startup company.
I wonder if the SDK is going to be commercial, closed-source software or FOSS...
It's hardly difficult to make a website, especially one as simple as what they have. 1 guy could definitely be just trollin' around. I'm not saying that this is the case, but I'm saying that we shouldn't rule that possibility out.
I only said it's got a chance at being real through my logic, mind you not a very good one.
I think it possibly sounds real; I can sort of see it working. The way I understood it (maybe) was that it only renders what you can see, and everything else is compressed. So all it has to do is figure out what you can see (everything in your viewing range that isn't blocked by something else) and then decompress those parts and copy them into video memory.
The only problem I can see with it is the amount of time it would take to calculate what is visible and decompress them. And also how good the compression algorithm is.
The only problem I can see with it is the amount of time it would take to calculate what is visible and decompress them. And also how good the compression algorithm is.
| So? I was just saying, they have a website. |
I disagree with your comment on chris's post, but w/e thats not the point. the point is That there is a CHANCE that they can do this. and if they really can games and simulations are about to get intense.
If it's real, and they're committed to this, then why in god's name didn't they spend an extra 5 minutes on the website...
The videos kinda makes me believe it, but the website..
It's not a deciding factor, but still - the website damnit!
The videos kinda makes me believe it, but the website..
It's not a deciding factor, but still - the website damnit!
| Assuming that doubles are being used (unlimited detail, can assume that floating points will be as accurate as possible) for positions, that's 24 bytes just for the position of the point. Then we get the color (4 bytes), and in a minimalistic system that's 28 bytes per point. Doing some short-hand math here, 3GB/28B comes to about 110,000,000 points being available. Obviously much less when actually applied. 110 million is a far cry from billions of points, but this is the only problem I see with the system they have going on. You'd need something like a server to be able to run something using that much RAM. |
Didn't the spokesman say you would only need as many points as pixels on the screen? 1024*768=786,432 seems within that range easily, but HD 1920*1080=2,073,600 might have some trouble... The possibility of graphics being rendered this way seems very real though.
That's the points visibly being rendered, that doesn't determine the amount of points in a whole scene.
Let's say you have a house in a forest. You got all of the points you need to render the forest. At least, from that angle. Move to the left a bit and you need the points for the side of the house, for the side of the plants, you need all of those points. I could see this working if they just had models stored in memory, points that dictate the origin of where a copy of the model would be located, and the system would work from this data. But all that would have to be copied over and everything would need to be in place in order to be able to determine which point to be used for each pixel.
Let's say you have a house in a forest. You got all of the points you need to render the forest. At least, from that angle. Move to the left a bit and you need the points for the side of the house, for the side of the plants, you need all of those points. I could see this working if they just had models stored in memory, points that dictate the origin of where a copy of the model would be located, and the system would work from this data. But all that would have to be copied over and everything would need to be in place in order to be able to determine which point to be used for each pixel.
Last edited on
I can't wait until they release their SDK. If this stuff really works, I WANT IT!
I didn't hear him say that he compressed it, I must've missed that. In which case, I can see it being possible. But that must be one amazing compression algorithm if it's meant to also be used on Smart-Phones, since some still only have 128MB of RAM.
Also, I wonder what this means for the Vertex Shader? They can't exactly have a Point Shader, that's a lot of points to iterate through...
Also, I wonder what this means for the Vertex Shader? They can't exactly have a Point Shader, that's a lot of points to iterate through...
Last edited on
Pages: 12