Unlimited Detail Technology

[Steevo]

1764000 points for one color, at one pixel depth, times 32 bit color? 56448000 bytes of color information, accurate position to within one pixel on a one dimension surface? Another 1764000 bits at 4 byte depth, 705600 bytes for location information. Lets assume a standard screen size at 1680 X 1050 of 22" diagonal.

What is a pixel depth, lets say that we want detail to speck size to the same as a pixel height. .282 mm

Every time you want to draw or render a scene with that level of precision and you add one pixel depth at .282 mm, you add another.


7,059,200 bytes. Lets say you want to render 2000 pixels deep. you would be able to see

14,118,400,000 bytes to render a depth of 56.4 cm or 1.85 feet that you could see into the game. Great for a game where you have a flashlight and its batteries are dieing. Bad for games where you want to have a real world render.

That is just one frame, no physics, no AA, object scaling. anisotropic filtering.


Add 60 times that of render and display at all new calculated depth. 847 104 000 000 bytes.

The problem with this is that EVERY pixel must be mapped, they use this for high detail single image objects as it does have high detail, it does have accurate rendering when on a single predefined machine. It is a horrible idea for any sort of 3d gaming or real time rendering.

 

[inferKNOX]

well considering this came out of no where in March and there has not been a single update to their site nor any additional information reported in the media i would say this genuinely is a hoax.

It is possible, it always is, but at this point Bruce isn't calling on any finances, so I'm not too quick to jump to that conclusion unless that changes and it seems suspicious.
It is quiet, but I'm told there is method to the madness apparently and cogs are turning behind the scenes.
For an update, look at the press release of their official page: http://euclideon.com/
The point of the petition is to have AMD work with UD and look deeper into viability of the tech, not to finance/buy it; so I don't think there is reason to be too hesitant in putting your signature down. Besides, I would like to believe that AMD would detect a fraudulent graphics tech and dump it if that is the case.

So please, join our petition.

 

[Easy Rhino]

sorry but i will not sign that petition until i see this thing in action on its own. if it really was a viable technology then intel/amd/nvidia/via would all be spending their own money looking into its development. i dont even think these guys formed their own company yet. i mean, if you truly believe there is something behind a revolutionary technology and you have the brains to bring it to market then the first thing you do is form a company and file a patent so you have legal protection.

 

[inferKNOX]

sorry but i will not sign that petition until i see this thing in action on its own. if it really was a viable technology then intel/amd/nvidia/via would all be spending their own money looking into its development. i dont even think these guys formed their own company yet. i mean, if you truly believe there is something behind a revolutionary technology and you have the brains to bring it to market then the first thing you do is form a company and file a patent so you have legal protection.

But they do have a company, haven't you followed the link?
As for the patent, it takes time to have one... registered right? Could it not be in the pipeline?
Well, demos are promised, so I hope your skepticism will be appeased then.

 

[erocker]

But they do have a company, haven't you followed the link?
As for the patent, it takes time to have one... registered right? Could it not be in the pipeline?
Well, demos are promised, so I hope your skepticism will be appeased then.

5 years at the earliest. Even so, companies seem more interested in ray tracing as the way forward. Graphics engines/software/hardware are planned out years in advance, if UDT isn't a part of that, it's going to take a long, long time as all these companies have their money into something else for the future.

 

[crazyeyesreaper]

exactly and even ray tracing might get pushed aside for Photon Mapping no one can know for sure but time will tell and even then this tech wont be around anytime soon its kind of a lost cause.

 

[inferKNOX]

Graphics engines/software/hardware are planned out years in advance, if UDT isn't a part of that, it's going to take a long, long time as all these companies have their money into something else for the future.

Doesn't that make it all the more worthwhile to petition for it to be looked at then, so that if it is viable, it's recognised and work commences towards it's standardisation sooner?

 

[crazyeyesreaper]

lol if you want people to take this seriously make Pixar do a 3d movie with the tech then it might get looked at a bit more quickly lolz

 

[erocker]

Doesn't that make it all the more worthwhile to petition for it to be looked at then, so that if it is viable, it's recognised and work commences towards it's standardisation sooner?

Not really. In the end it's up to the powers that be if they want to put their money there. They definitely know about this tech already. It doesn't hurt though.

 

[Easy Rhino]

i don't know what's worse, their old website or their new website. and one press release FTL

 

[inferKNOX]

lol if you want people to take this seriously make Pixar do a 3d movie with the tech then it might get looked at a bit more quickly lolz

According to Bruce, the tech is incomplete and in development, so I don't know if it's possible to implement at this point.

Not really. In the end it's up to the powers that be if they want to put their money there. They definitely know about this tech already. It doesn't hurt though.

The point of the petition is not have big players put money into UD, but to have AMD work with them to test viability and push standardisation if it is.

 

[Benetanegia]

lol if you want people to take this seriously make Pixar do a 3d movie with the tech then it might get looked at a bit more quickly lolz

http://features.cgsociety.org/story_custom.php?story_id=5615&page=1

Pixar has used point cloud rendering, to an extent. Read.

I don't know what to think of this Unlimited Detail Tech. The idea of the renderer seems kinda plausible, the supposed implementation of their specific point based rendering method seems plausible, but like people above mentioned, you just can't have unlimited (or really huge) point data, just like you can't have unlimited vertex data. In fact, I think point data can only be much worse than existing methods in regards to detail-per-memory usage, vertex/polygons are an aproximation of the "real" surface, NURBS and patches are also aproximations with a higher detail but slower and with their own drawbacks. The "real" thing will be much much bigger than aproximations, no matter how intelligent the "search engine" is in using only the 1680x1050 or 1920x1200 (or whatever) points that are required, the raw point data of the surfaces is going to be HUGE. Just think about walls, 4 vertex vs how many points would be required??

Point based rendering is indeed used in off-line rendering and it has many advantages in the areas where it's used (movies), where storage data is limitless and rendering/production time is limited (all relative to the timeline and level of detail). But real-time rendering is practically the opposite, storage is limited.

Then there's animation...

I'll remain skeptic until I see a real time demo from them.

All in all, I think that modern real-time ray-tracers, where a data extructure similar to the one mentioned by UDT is used, but instead of points with polys, have a better chance of becoming the future. And Carmack already said that such ways of handling data is not limited to ray-tracing or in this case point rendering, they can be used on rasterizers and he is working on them for id Tech 6, in fact. Accordingly, the "search engine" mentioned by UDT could very well be implemented in polygons. Ultimately until we have unlimited CPU/GPU power a polygon will always be better than points for real-time IMO.

 

[inferKNOX]

http://features.cgsociety.org/story_custom.php?story_id=5615&page=1

Pixar has used point cloud rendering, to an extent. Read.

I don't know what to think of this Unlimited Detail Tech. The idea of the renderer seems kinda plausible, the supposed implementation of their specific point based rendering method seems plausible, but like people above mentioned, you just can't have unlimited (or really huge) point data, just like you can't have unlimited vertex data. In fact, I think point data can only be much worse than existing methods in regards to detail-per-memory usage, vertex/polygons are an aproximation of the "real" surface, NURBS and patches are also aproximations with a higher detail but slower and with their own drawbacks.

Point based rendering is indeed used in off-line rendering and it has many advantages in the areas where it's used (movies), where storage data is limitless and rendering/production time is limited (all relative to the timeline and level of detail). But real-time rendering is practically the opposite, storage is limited.

Then there's animation...

I'll remain skeptic until I see a real time demo from them.

If you're unsure, then it's worth signing the petition. Why? Because then AMD can prove or disprove it and we can be in ecstasy or at ease.
Definitely, I don't believe the idea of it being unlimited myself, but if you compare it to current methods, it's relatively unlimited. Even if it is limited to 1000x current geometry, isn't that worth it? Even it's it's 100x? I think we have far more to potentially gain than lose from looking into this, and same goes for AMD.

I too am quite skeptical despite my tone throughout the thread, but I'm just considering the benefit to risk ratio, in which case it definitely leans towards benefit in a huge way.

 

[pantherx12]

Even if it's 4x it's still a massive jump.


I can see this being used in combination with traditional methods ( I.E like how tesselation works, as you get close to object point cloud takes over so you can have super detailed objects ?)

 

[erocker]

If you're unsure, then it's worth signing the petition. Why? Because then AMD can prove or disprove it and we can be in ecstasy or at ease.
Definitely, I don't believe the idea of it being unlimited myself, but if you compare it to current methods, it's relatively unlimited. Even if it is limited to 1000x current geometry, isn't that worth it? Even it's it's 100x? I think we have far more to potentially gain than lose from looking into this, and same goes for AMD.

I too am quite skeptical despite my tone throughout the thread, but I'm just considering the benefit to risk ratio, in which case it definitely leans towards benefit in a huge way.

It's still going to cost AMD money. Money they don't have. Bene has a good point. We need a demo.. Some hard proof that this indeed can work.

 

[Benetanegia]

If you're unsure, then it's worth signing the petition. Why? Because then AMD can prove or disprove it and we can be in ecstasy or at ease.
Definitely, I don't believe the idea of it being unlimited myself, but if you compare it to current methods, it's relatively unlimited. Even if it is limited to 1000x current geometry, isn't that worth it? Even it's it's 100x? I think we have far more to potentially gain that lose from looking into this, and same goes for AMD.

I too am quite skeptical despite my tone throughout the thread, but I'm just considering the benefit to risk ratio, in which case it definitely leans towards benefit in a huge way.

You didn't understand what I meant. IMO it's as limited if not more than current implementations. Maybe not on the real time rendering side of things (skeptic until I see something), but a game world created in the manner described by them (even with replication) would occupy Terabytes if not Petabytes. Like I said the areas in which point clouds are used (i.e medical imaging, movie creation) do not have any problem with data size, since they don't have to care about distribution, bandwidth limitations, etc. Unlike games.

 

[inferKNOX]

Yeah, I see all of your points. A demo is essential to make the talk more plausible. It is indeed hard to imagine just what has been done to achieve this, thus bringing the whole thing into question. Our failure to understand it should not hinder us to encourage those that will though, and if AMD get's in on it, that should happen.

AMD is financially low, yes. However, it should not be a significantly expense to validate the claim and cut it loose if it's false, thus I still see petitioning them as a positive move, don't you agree?

 

[Thatguy]

You didn't understand what I meant. IMO it's as limited if not more than current implementations. Maybe not on the real time rendering side of things (skeptic until I see something), but a game world created in the manner described by them (even with replication) would occupy Terabytes if not Petabytes. Like I said the areas in which point clouds are used (i.e medical imaging, movie creation) do not have any problem with data size, since they don't have to care about distribution, bandwidth limitations, etc. Unlike games.

thats not entirely ture. Using certain types of data compression could reduce the size of the object immensly. certain encryption algorythms come to mind here. If we had a fast way to place, decrompress, discover and then renders those points. It could become very doable. the big thing this new IDEA looks to do is use a search algorythm for the camera angles to determine which points need rendering. I agree storing that much cloud point data would be difficult. Petabytes might be a understatement. Maybe he figured out a better way to compress the point maps, which is very beliveable.


Which on its face looks like a great way to conserve computer power.

I don't know. they don't give enough detail about How the tech works to get a good grasp on what they are selling.

 

[qamulek]

I want a benchmark where I can vary the amount of points used in the models to graph the performance vs the number of points on the screen. The reason is to test the claim that the amount of points doesn't affect the performance(that much) using this UDT. It would be interesting to see the performance stay roughly constant while increasing the number of points or possibly zooming out to see a bunch of models then zooming in to one very detailed model then zooming so close that the skin becomes a canyon like landscape.

 

[remixedcat]

Storage is getting cheaper. GPUs aren't.

 

[Benetanegia]

thats not entirely ture. Using certain types of data compression could reduce the size of the object immensly. certain encryption algorythms come to mind here. If we had a fast way to place, decrompress, discover and then renders those points. It could become very doable. the big thing this new IDEA looks to do is use a search algorythm for the camera angles to determine which points need rendering. I agree storing that much cloud point data would be difficult. Petabytes might be a understatement. Maybe he figured out a better way to compress the point maps, which is very beliveable.


Which on its face looks like a great way to conserve computer power.

I don't know. they don't give enough detail about How the tech works to get a good grasp on what they are selling.

Yes, but my point is that any algorithm or compression technique that could benefit point cloud storage would be just as beneficial to vertex data storage and transmision. At least with current computers, you don't want to compress everything too much anyway (beyond the level that's alredy compressed I mean).

The only really big thing about this tech is the search engine without a doubt, if it really does what they say it does and in the way it does it, and I think that it could be implemented just as well to polys too. Like I said Carmack is supposedly working on something similar for rasterization, I think based in the sparse voxel octree ray-tracing that so many people are working on, which btw does something similar to what this "search engine" is supposed to do, but again based on polys. So far the sparse voxel octree implementations have been promising but have failed to completely deliver on their promise, and they have never been even close to the claim made here, both in the ammount of data which can be represented in real time at any given time, nor in the performance that is achieved.

And to me that's the problem. I am not an expert by any means, but I do read a lot and try to know about those things as much as I can and what UDT is promising sounds just like time travel. The fact that despite having videos almost 2 years ago, but they don't have even the most simplistic demo yet, does not make believing in their claim any easier.

I want a benchmark where I can vary the amount of points used in the models to graph the performance vs the number of points on the screen. The reason is to test the claim that the amount of points doesn't affect the performance(that much) using this UDT. It would be interesting to see the performance stay roughly constant while increasing the number of points or possibly zooming out to see a bunch of models then zooming in to one very detailed model then zooming so close that the skin becomes a canyon like landscape.

Ray-tracing is pretty much independent from the ammount of geometry used.

 

[Thatguy]

Yes, but my point is that any algorithm or compression technique that could benefit point cloud storage would be just as beneficial to vertex data storage and transmision. At least with current computers, you don't want to compress everything too much anyway (beyond the level that's alredy compressed I mean).

The only really big thing about this tech is the search engine without a doubt, if it really does what they say it does and in the way it does it, and I think that it could be implemented just as well to polys too. Like I said Carmack is supposedly working on something similar for rasterization, I think based in the sparse voxel octree ray-tracing that so many people are working on, which btw does something similar to what this "search engine" is supposed to do, but again based on polys. So far the sparse voxel octree implementations have been promising but have failed to completely deliver on their promise, and they have never been even close to the claim made here, both in the ammount of data which can be represented in real time at any given time, nor in the performance that is achieved.

And to me that's the problem. I am not an expert by any means, but I do read a lot and try to know about those things as much as I can and what UDT is promising sounds just like time travel. The fact that despite having videos almost 2 years ago, but they don't have even the most simplistic demo yet, does not make believing in their claim any easier.



Ray-tracing is pretty much independent from the ammount of geometry used.

well actually you could in thoery use a folding algorythm to compress the data without to much computer penalty greatly reducing the amount of data points to be stored. Sort of like a bitmap with depth information buried in it.

Theres a few ways I could see accomplishing this. But none of them come without some overhead penaltys and certainly not in software alone. It did get me thinking in some new directions on some problems I have been trying to solve on my own, even if they don;t directly apply.

 

[qubit]

I agree with those that are saying this is snake oil - a con.

I saw something similar a while back for extreme data compression (I forget the name of the company now). It was reported (skeptically) by New Scientist at the time. The company were going to exhibit at some science/computer show and "reveal all" there. Sure.

They mysteriously pulled out just before the show and were never heard of again. What these charlatans were trying to achieve is beyond me. It's like the ultimate troll, isn't it?

 

[crazyeyesreaper]

and true this has been used in offline rendering but not a pure cloud point data system its always relied on something else its an end of the pipeline situation example they use highly complex models which border on the millions of polygons but as i stated early no matter if its cloud point data thats rendered its still all done in polygons first or nurbs or what have you. Basically no matter what this tech does or dosent do or what it it becomes. Polygons will never be replaced because there easy to calculate mathmatically. Even now in 3d apps im not limited by gpu power or cpu power im limited in Ram Vram and HDD space and speeds. Zbrush uses a 2.5d system but can get into the billions of polygons and be 100% fluid to work in. Mudbox with only 4gigs ram and 1 gig Vram i can work with up to 50million polygons in real time with Occlusion shadows HDR and tonemapping. Point Cloud Data is nothing more then a pipedream an interesting side note untill we have the power of IBM's Blue Gene in are living rooms.

 

[inferKNOX]

well actually you could in thoery use a folding algorythm to compress the data without to much computer penalty greatly reducing the amount of data points to be stored. Sort of like a bitmap with depth information buried in it.

Theres a few ways I could see accomplishing this. But none of them come without some overhead penaltys and certainly not in software alone. It did get me thinking in some new directions on some problems I have been trying to solve on my own, even if they don;t directly apply.

Bruce actually spoke of bitmaps, but he was talking about improvements in scalability vs polygons, removing the need to remake the graphics when going from a high to a low polygon model.

@qubit: If we sign the petition and it is indeed snake oil, AMD would quickly identify that and put this whole argument to rest. So still, reason remains to sign the petition.