Tell me again: How is it running on a laptop in real-time that most likely only has 4 TB's of HDD space, likely lower?
Thought the memory requirements were too much for today's hardware, yet there it is, running in real-time on a laptop. A good laptop of course, but in software mode on the laptop's CPU no less.
Memory requirements aren't too much for today's laptops. Memory requirements are too much if you actually have unique detail, not tiling instanced geometry. They don't have unique geo, but they're pretending their tech can actually do that, and they're just not there because you "have to forgive their artists lol".
They can run this, but they can't make an island like Crysis and run that. No way. Unless they're wizards.
Please try to understand that their tech approaches voxels differently than traditional methods. Until we know more about their approach then these conversations are pointless, because nether you nor I know for a fact if this is a hoax or not.
Even if polygon meshes were instanced to be as big as their demonstration map, it would never run even if the polygons were instanced.
I suggest doing more research into the tech. Seems too many of you are basing your statements on personal biases and continue to ignore my posts explaining how this tech is possible.
I'm not trying to get involved in this, but i couldn't resist and I find it rather funny, that Rexm talks about statements based on personal biases and no research, when all he is doing is spouting the same thing Mr. Dell said over and over, and not providing an ounce of research, or proof.
Where as it's evident that vargatom has done a great deal of research, complete with supporting evidence as have a number of other posters.
It's fairly obvious to me at least, based on the detail they go into, and the links they post. Where as Rexm just posted Euclidian? links for the most part - don't remember him posting a non Euclidian link.
I'm not sure if Rexm has been to university, but if he had, he should understand critical thinking, and how to do research, providing sources, and backing up his claims, and not just recycling what he's said time and time again, based on obvious marketing bullshit.
Please try to understand that their tech approaches voxels differently than traditional methods.
And you know this how?
Until we know more about their approach then these conversations are pointless, because nether you nor I know for a fact if this is a hoax or not.
This is a contradiction to what you said above.
You don't want us to make assumptions, but at the same time, you will tell us that something you have absolutely no way to know, is definitively "how it works". This makes sense to you somehow?
Really guy, just drop it. You realize that you're the only one in here that actually expects this to turn into something real, a real product that you could use to make a game. Polycount is composed of about 50% industry veterans, but you think ALL of these people are just clueless and only you really understand what is going on here? Really?
When presented with a far fetched concept, skepticism is natural. Its really the reaction you would expect someone to have until these grandiose claims can actually be substantiated. So getting worked up that people aren't buying into it is just pointless. Why would that upset you?
Rexm you are still stuck on the "it only renders the pixels on the screen, hence there is no limit on scene complexity and unique data". I am not sure you have real industry experience with things like cache, ram, streaming and diskspace and how this data travels from one to the next.
I remember running a old ogre demo about 6 or so years ago which had one robot (3-4k tris) with a walking animation instanced about 8 thousand or so times on a old dell crap box at 20 fps and thinking that it was amazing and why didn't games have like 300 or some baddies on screen at once.
I think we've reached a point of no return when RexM actually believes in the word of bruce dell rather than that of industry veteran and mastermind graphical engineer John carmack (who actually incidentally has traversed these voxel grounds before and actually has experience in the ups and downs of graphics implementation in game engines)
Rexm you are still stuck on the "it only renders the pixels on the screen, hence there is no limit on scene complexity and unique data". I am not sure you have real industry expeince with things like cache, ram, streaming and diskspace and how this data travels from one to the next.
i like you fuse and your cuddly avatar....no dont find that weird...stop running away
You can define tons of useless geometry using trillions of voxels compressed down to one kilobyte. But you cannot store a megabyte of useful information of high entropy in the same way. At least not in our Universe. So on the current hardware you can either have quadrillions of boring, almost useless atoms or just billions of interesting , useful ones.
The point is in storing only the relevant part of the information in the most efficient way possible while making the data structure fast and versatile enough for the renderer, physics simulator, AI, etc. The only such way I know is using a versatile fully-volumetric (not a SVO) multi-level-of detail voxel-based data model with incomplete data sets (AE uses one such).
The repetitive geometry presented in the UDT videos says nothing about any of these key aspects of a high-end realtime atom-based technology.
i like you fuse and your cuddly avatar....no dont find that weird...stop running away
Bwahahah! Thanks mate I am sure the Russian polycounters here know who the little critter is..
More on topic though, I guess I can see how that flawed logic can steer someone the wrong way. I guess if IdTech5's Megatexture promises to fill your screen with unique texture pixels indefinitely then UD "should" do the same, right? Well no, but I suppose I can see how it can be misleading.
Still the numbers they are presenting are easy to understand. The level of realism provided by the atom-based content is not proportional to the number of atoms used. It is proportional to the amount of information present.
You can define tons of useless geometry using trillions of voxels compressed down to one kilobyte. But you cannot store a megabyte of useful information of high entropy in the same way. At least not in our Universe. So on the current hardware you can either have quadrillions of boring, almost useless atoms or just billions of interesting , useful ones.
The point is in storing only the relevant part of the information in the most efficient way possible while making the data structure fast and versatile enough for the renderer, physics simulator, AI, etc.
The only such way I know is using a versatile fully-volumetric (not a SVO) multi-level-of detail voxel-based data model with incomplete data sets (AE uses one such). The repetitive geometry presented in the UDT videos says nothing about any of these key aspects of a high-end realtime atom-based technology.
Not only does the Atomontage creator go on to say it is very possible even within the claims made, but gives an example as to how it could be accomplished.
Here the creator of Atomontage is describing their approach:
Not only does the Atomontage creator go on to say it is very possible even within the claims made, but gives an example as to how it could be accomplished.
Err, he says the exact opposite. That their approach is reasonably clear and that it's obvious they haven't managed to address any of the issues tens of people are bringing up in this thread.
Most of you have already brought up the tessellation issue, and how bruce dell gives a very biased comparison. And i'm sure most of you have seen this before (1 year old)
It looks better than "UD" runs better than "UD" etc, yes, it's just a character, but it's dynamic multi layered tessellation on an animated character.
In the end, in "UD", yes you can zoom all the way and see amazing "little" grains of dirt that literally look like dog turds, but in reality, you're playing a game, with most likely a fixed zoom, where you won't zoom into the ground hoping to see dog turd shaped grains of sand.
"Unlimited Detail" < Useable Detail!
Pretty much sums it up to me, i don't want detail i'm not going to see, I want detail that improves my gaming experience, yes objects are made up of atoms in the real world, but we don't interact with those atoms, we interact with the objects as a whole, or if the object breaks, fragments of the object - still not atoms.
I'm excited about Atomontage's tech and where they are going with it, not interested in "UD"'s.
Well I think mixing in voxel tech with polygon tech could be a good way to solve destructibility issues. But as a full game engine for a AAA title? Not for a while.
Oh boy, here we go again. Unlimited Detail is everywhere.
So, first of all, the guys from Euclideon probably don't use voxels rather than point clouds. Where voxels are grid aligned data points and are usually associated with the "blocky" look, point clouds are just that - a set of points freely positioned in 3D space with associated color/normal/material information.
Voxels have seen a lot more use than point clouds, which is probably why most people automatically think of voxels if something is not made out of polygons. However, from the few "wireframe" shots from the Euclideon team we've seen so far it becomes pretty clear that point clouds are at work.
There are a lot of differences between the two, mainly stemming from the nature of how they're being stored. Since voxels are gid-aligned data points, most rendering algorithms struggle with the blocky look that arises naturally. Also, since we're dealing with a regular grid, it's hard to concentrate detail in one point and discard it in other places where it's not needed. Both of these problems have been fixed by the introduction of sparse voxel octrees, which trade the dynamic nature of the voxel grid for efficient rendering, level-of-detail and non-blocky surfaces using contours.
Point clouds, on the other hand, have a lot of trouble when it comes to efficient rendering. Since no assumptions about the regularity of the points can be made, it is hard to develop a spatial datastructure both memory efficient as well as fast at traversal/depth sorting (depending on the rendering method). It seems the guys at Euclideon have solved these problems at least partially, which is quite impressive in itself.
The other problem is that there is of course a limit on the amount of memory available, so the amount of points available for a model are not endless. As a result, even with high-resolution point models, there are gaps between the points (since they don't take up any area). As a result, if one were to render the points directly, it would look very poorly since the models would look like a collection of points rather than a closed surface. To solve this, implementations either resort to converting the point cloud to a ponygonal mesh with the points as vertices, or rendering the points in the cloud as flat discs to fill the gap between each other. The problem with the first approach is of course having to fall back on rasterization (which is slow for this kind of detail), whereas the second approach suffers from "blurry" models since the point color information is essentially interpolated across the disk. Euclideon seems to employ the latter, the artifacts of which are visible on some of their earlier shots.
Regardless of whether or not real-time rendering is possible (since they apparently achieved that), there are a few still unsolved issues with both voxels and point clouds.
1. Memory consumption. Since the points/voxels in a model are by requirement unique, the memory consumption is outrageous. There are compression schemes available that help somewhat, but building huge levels still seems to be quite difficult. The island they showed with oh-so-many trillion(!) points is a bit of a joke, since only a tiny fraction of them are unique points. Their videos rely on instancing so heavily it's laughable. They may be able to zoom to the crumbs of dirt on the ground, but as long as these crumbs of dirt look exactly the same as the other five hundred billion crumbs in the level, that's really not a useful feature.
2. Animation/dynamic deformation. Fast rendering of point clouds/voxel models always rely on efficient spatial datastructures that store the complete dataset of the scene. These datastructures are very time expensive to build, but once they're ready, they allow a set of queries (e.g. intersection tests) to be executed really fast. The problem is that once the data is stored, it's impossible to modify it without having to rebuild the whole thing or at least an unpredictably sized chunk of it. This means that dynamic deformation is completely out of the question (required for procedural animation such as ragdolls) and predefined animation is very hard to do. The guys from Euclideon clearly didn't solve this problem, since the only animated object we've seen so far was a keyframed bird flapping its wings (no bone animation, no skinning, just prerendered frames displayed in sequence - it's a joke).
So, ultimately, this kind of technology could (and probably will) find application in the next few years as a solution for static environments with polygonal models used for the dynamic objects (e.g. characters). However, the guys from Euclideon claim to have found a solution to EVERYTHING and that it has no drawbacks and allows UNLIMITED detail, all of which is simply a lie. While I salute them for their results so far (some of the models look quite amazing), their arrogant way of presenting them, the lack of any information about why this technology doesn't suffer from the already well-studied problems and their boldness to claim to have found something completely new that will revolutionize the graphics industry while just showing a new take on a concept that has been around for several decades just seems very unprofessional and makes their claims very implausible to me.
But either way, we'll see whether they were right when they release the SDK as they said in the newest video. While I hope their technology holds up to the expectations, I suspect it won't.
@Cooljay in this post: Wow, I just found this over my referrals - I made that picture almost two years ago and it was crappy even back then (in my defense, it was WiP). If you must link something by me, then I'd rather have it be the more recent SVO implementation I did (or in fact, link something from the Atomontage engine, since it's about five million times better than anything I did):
[ame]http://www.youtube.com/watch?v=TgIXwF53j6I[/ame]
its pretty clear, there is some potential in voxels for the future. but not for those guys and their publicly announced goal of combating polygons, its a shame they got the funding which could have went to better investments, imo i predict the closure of euclideon within the next 2 years.
its rather pointless arguing as to why, it has been for over 18 pages
as far as dropping polygons are concerned
Polygons have been around for 2000+ years and are very well-suited, established mathematical functions used for describing any kind surfaces and has proven itself long before computer where even around. I doubt we will just drop that to move through the big cloud.
Pior is right on the money here where a voxel coat over a simple mesh is more useful and I think this is what carmack is attempting. along with physics simulations (that still need to be EXTREMELY tight if on atom level)
Unlimited Detail is a silly joke. its another voxel engine -this time with a diffrent approach - but with the same crappy result and problems that come along with it.
RexM: Get a job seriously though, in Cryengine 2, if you disable all AI, lighting, sound, shading, post, particles, like basically everything that UD is lacking and fire of your 20000 rockets with whatever instanced geometry, it will still run butter-smooth at 60fps on a gaming laptop.
So, first of all, the guys from Euclideon probably don't use voxels rather than point clouds.
Actually Dell himself admitted several times that it's voxels but he doens't like to use the term because it hasn't got enough prestige in game development or something.
However, from the few "wireframe" shots from the Euclideon team we've seen so far it becomes pretty clear that point clouds are at work.
If we're both thinking about the same shots (namely the elephant statue), it was actually demonstrating their engine's new ability to convert polygonal models to their "atoms" model structure, rather than revealing the raw data format they're actually using. Given the manner and layout of the content they're showing, everything still points to SVOs rather than point clouds, to the best of my knowledge.
Like you said though, whether it's point clouds or voxels is far less important than the major drawbacks that remain blatantly unresolved. In my mind, memory and animation problems are less problematic (via advancing hardware and introducing a hybrid system with polys), than their static rendering's apparent total inability to place instances of static objects at arbitrary translations, rotations, and scales. At least, as far as the project's usefulness for real-world game development goes.
Actually Dell himself admitted several times that it's voxels but he doens't like to use the term because it hasn't got enough prestige in game development or something.
If we're talking about the same video, when asked about whether it was voxels Dell replied "If we define voxel as a little freely floating atom, then yes, it is voxels". So basically, point clouds, not voxel grids
If we're both thinking about the same shots (namely the elephant statue), it was actually demonstrating their engine's new ability to convert polygonal models to their "atoms" model structure
Actually, I was referring to a short scene in their first video (I think he demonstrated some sort of editor), where the point cloud visualization is shown.
... than their static rendering's apparent total inability to place instances of static objects at arbitrary translations, rotations, and scales.
Actually, that is possible and they've also shown it quite a few times (basically when they wanted to demonstrate how animation was not impossible by showing skeletal animation without skinning).
But as you mentioned, whether it's voxels or point clouds doesn't really matter, since both suffer from similar drawbacks.
@eld: That looks more like a poorly converted mesh, considering the models right next to it don't show any signs of voxelization
But as you mentioned, whether it's voxels or point clouds doesn't really matter, since both suffer from similar drawbacks.
@eld: That looks more like a poorly converted mesh, considering the models right next to it don't show any signs of voxelization
Hm maybe you're more of a knowledgeable person about this subject. http://homepages.slingshot.co.nz/~tmulgrew/VoxelOctree/ Could you check out the app in this link and tell me whats up. Slowly zoom inside one "melon thingies", you'll see more, use the control scheme to slow your movement down, and zoom into the next inside, keep doing that, then look out the way you came into them. You can clearly see that all the voxel areas are represented by different scales per iteration. So isn't it at all possible that they can be drawn at independent resolutions even if they're voxels? Especially if SVO's are involved? Again that isn't to say "unlimited detail" is possible, I'm just wondering if you can scale voxels based on rendering method.
Unlimited Detail is a sorting algorithm that retrieves only the 3D atoms (I won't say voxels any more it seems that word doesn't have the prestige in the games industry that it enjoys in medicine and the sciences)
He's just avoiding the term to get more publicity, by confusing the general audience... which as others have pointed out is strange in itself, marketing his tech to gamers instead of developers...
From what I understand about gpu tessellation its not a "fixed function" feature. Its actually achieved with "geometry programs" in the shader, in between the vertex program and the fragment program. Tessellation is just one example of what you can do inside that geometry program, the applications of the feature go far beyond simply tessellating the surface geometry and applying displacement.
In fact the geometry program would probably be a good way of rendering point cloud data.
I think its kinda like when FrameBufferObjects became standardized. They were mostly used for simple post process effects, but now have much wider of common applications such as advanced realtime lighting calculations and general purpose gpu processing.
Actually Dell himself admitted several times that it's voxels but he doens't like to use the term because it hasn't got enough prestige in game development or something.
I don't blame him because Novalogic really crapped on the reputation of voxels with the second/third Delta Force games.
That was like ten years ago, most gamers today don't know anything about Novalogic, Commanche, Outcast or voxels...
And yeah, GPUs are becoming more and more capable. A lot of people are looking into doing micropolygons on GPUs, which is how Pixar's Renderman works. That's why I try to repeat that in the 5 to 10 years that it'd take to get a fulyl voxel based engine to work and have hardware for it too, the current poly based approach might be getting a bit ahead as well
That was like ten years ago, most gamers today don't know anything about Novalogic, Commanche, Outcast or voxels...
And yeah, GPUs are becoming more and more capable. A lot of people are looking into doing micropolygons on GPUs, which is how Pixar's Renderman works. That's why I try to repeat that in the 5 to 10 years that it'd take to get a fulyl voxel based engine to work and have hardware for it too, the current poly based approach might be getting a bit ahead as well
So we will be able to 'render everything you ever saw'?
Don't really have them at hand, I think it was in either GDC or Siggraph presentations but can't even tell which year Most of the presentations are on the office computer, will try not to forget to look for them on monday.
See I try to at least peer into as much of this stuff as I can, there's always a chance to learn something good and new. Some of them are production related, and the other half is theory. Micropolygons are such a field, But there's many different teams looking into it, from universities to game devs - I think Tim Sweeney at Epic is seriously interested too.
Thunabrain et all stuck on cubes: You illustrate why he's avoiding the term voxel.
Voxels are not by nature cubic.
Voxel is a portmanteau of a portmanteau. Voxel means volumetric pixel. Pixel means picture element.
So volumetric picture elements are all that voxels are. They are analogous to the concept of hypertexture, as developed by Perlin and others.
Early voxel renderers appeared as stacks of cubes due to the algorithm used to evenly and efficiently traverse Euclidean space. There were two main algorithms, marching the cubes, and marching tetrahedrons, which is he same thing but tweaked enough to get around a patent. Both of these are cubic and neither is the only way to break up 3d space. Just remember that we were dealing with hardware that makes your cellphone look like a super computer when these algorithms were developed.
But since people in general seem to think voxel = cube, this guy's settled on "little atom" or "point cloud" so people will quit thinking in regular cubic data sets.
Yeah, Dell's sort of right about that if he wants to sell this stuff to the public.
Voxels today can be filtered, even sort of re-vectorized during rendering by algorithms that try to give back curvature to small voxel sized details (although his demo probably doesn't do anything like that, yet).
Thing is, why would you want to sell such an early tech demo to the general public... why go for publicity and all, I don't really get it.
So isn't it at all possible that they can be drawn at independent resolutions even if they're voxels? Especially if SVO's are involved?
Applying transformations to individual objects is not a problem, since you can always transform the ray into the local coordinate system before raymarching. What is not possible is trying to apply different transformations to the individual voxels inside an object, which is required for e.g. skinning.
The program you posted is very interesting though, since it uses a sneaky way to build the scene. You probably know how an octree is constructed: Fit the whole scene inside a cube. If there are voxels inside the cube, subdivide the cube into 8 subcubes and repeat the process for them. This way, you ultimately end up with a hierarchy of cubes, with the root cube containing the whole scene and the leaf cubes containing individual voxels.
What this guy (probably) did was first convert the melon model into an octree and then edit the octree manually to have the cubes in the center of the melon point back to the root of the hierarchy. That way you have an infinite recursion of melons inside melons (melception, if you will) with no additional memory cost. Since the size of the cubes are implicitly given (a cube is always 1/8th the size of his parent), the inner melons will automatically get smaller and smaller without having to apply individual transformations.
So yeah, this is actually a really cool way of abusing the octree. Though I am a bit disappointed - I would have expected something like this to come from the demo scene
Actually, they are - the same way a pixel is inherently rectangular.
Depending on the context, it doesn't mean you have to render them cuboid though. If enough information is available (i.e. object density at every point), it is very well possible to extract a smooth isosurface covering the object. This is essentially what the marching cubes algorithm does (and, contrary to what you said, it generates a smooth surface, not cuboid voxels).
Unfortunately though, this kind of information is really expensive to keep in memory, so usually real-time renderers resort to 'binary' voxels (solid or non-solid, nothing in between), which are very hard to render in a non-cuboid manner. Only recently have we seen a solution to that with SVOs, where some of the original information about the surface is kept.
But since people in general seem to think voxel = cube, this guy's settled on "little atom" or "point cloud" so people will quit thinking in regular cubic data sets.
Once again, voxel datasets and point clouds are different kinds of things.
To be quite honest, I think Dell chose "Atom" because he has no idea about common terminology in visual computing. He said he worked on his own, with practically no connection to other people specializing in computer graphics and built everything on his own from scratch. While that is admirable, it becomes problematic if he doesn't know what he's talking about. If you've watched the interview, you may have noticed him calling LOD "level of distance", or explicitly saying that they don't do raytracing but do a "search algorithm" instead which searches one atom per pixel (+additional ones at reflections), which is exactly raytracing, or calling cheap instancing "unlimited detail" and effectively not understanding the asymptotic running time of his datastructure since he thinks it won't get slower with more data, or freely redefining voxel as he pleases ..... the list goes on.
He is very hazy when it comes down to explaining how it works, and after the interview I've come to believe that it's not because he chooses to (so no-one can expose his technology), but it's more because he simply doesn't know any better.
[ame]http://www.youtube.com/watch?v=_5hg9VfbyYg[/ame] Shadows in a finite space! Clearly we're all wrong about everything! Get Down on your Knees and REPENT! Haha! I'm sorry, but they'll show us Cam data and shadows in a limited rendering environment, but not fps readouts for a good reason. I still don't see a game anywhere, do you?
EDIT missed the last couple of pages sorry to double post but yeah i was interested in the atrefacts tat eld pointed out on the last page...also it looked as though there were tiny cascade shadow triangular artefacts...which was curious as i didnt think you would get those in a voxel engine
http://www.youtube.com/watch?v=_5hg9VfbyYg Shadows in a finite space! Clearly we're all wrong about everything! Get Down on your Knees and REPENT! Haha! I'm sorry, but they'll show us Cam data and shadows in a limited rendering environment, but not fps readouts for a good reason. I still don't see a game anywhere, do you?
Haha, I like how they position game screenshots against blatant photos.
I was under the imprsesion things like photofly ran just fine on my computer in polygons, and i don't need any voxel silliness to get a really realistic looking static 3d image of a tree and some grass
Replies
Thought the memory requirements were too much for today's hardware, yet there it is, running in real-time on a laptop. A good laptop of course, but in software mode on the laptop's CPU no less.
They can run this, but they can't make an island like Crysis and run that. No way. Unless they're wizards.
Actual games require far more than 30 objects.
Thus the demo works, but a real game can not work.
Please try to understand it.
No, it doesn't. Every bit of the demo is supporting that. Notice how it's all quadratic tiles repeating over and over, that's because it's an OCTREE.
I'm not trying to get involved in this, but i couldn't resist and I find it rather funny, that Rexm talks about statements based on personal biases and no research, when all he is doing is spouting the same thing Mr. Dell said over and over, and not providing an ounce of research, or proof.
Where as it's evident that vargatom has done a great deal of research, complete with supporting evidence as have a number of other posters.
It's fairly obvious to me at least, based on the detail they go into, and the links they post. Where as Rexm just posted Euclidian? links for the most part - don't remember him posting a non Euclidian link.
I'm not sure if Rexm has been to university, but if he had, he should understand critical thinking, and how to do research, providing sources, and backing up his claims, and not just recycling what he's said time and time again, based on obvious marketing bullshit.
And you know this how?
This is a contradiction to what you said above.
You don't want us to make assumptions, but at the same time, you will tell us that something you have absolutely no way to know, is definitively "how it works". This makes sense to you somehow?
Really guy, just drop it. You realize that you're the only one in here that actually expects this to turn into something real, a real product that you could use to make a game. Polycount is composed of about 50% industry veterans, but you think ALL of these people are just clueless and only you really understand what is going on here? Really?
When presented with a far fetched concept, skepticism is natural. Its really the reaction you would expect someone to have until these grandiose claims can actually be substantiated. So getting worked up that people aren't buying into it is just pointless. Why would that upset you?
Class Polycount_Filters extends Polycount_UI
{
local string Voxel;
local string Popcorn.Gif;
Voxel = Popcorn.Gif;
}
Just started hacking unreal kismet node scripts together this week, feel free to laugh at my non-programmer artist based assumptions.
He may be just trolling now, I can't tell.
i like you fuse and your cuddly avatar....no dont find that weird...stop running away
http://deltagamer.com/12583/interview-atomontage-engine
Do you understand now ? If not, I give up...
Bwahahah! Thanks mate I am sure the Russian polycounters here know who the little critter is..
More on topic though, I guess I can see how that flawed logic can steer someone the wrong way. I guess if IdTech5's Megatexture promises to fill your screen with unique texture pixels indefinitely then UD "should" do the same, right? Well no, but I suppose I can see how it can be misleading.
....what?
Here the creator of Atomontage is describing their approach:
Not only does the Atomontage creator go on to say it is very possible even within the claims made, but gives an example as to how it could be accomplished.
Err, he says the exact opposite. That their approach is reasonably clear and that it's obvious they haven't managed to address any of the issues tens of people are bringing up in this thread.
[ame]
And guess what, there's a playable demo:
http://www.nvidia.com/object/cool_stuff.html#/demos/2508
It looks better than "UD" runs better than "UD" etc, yes, it's just a character, but it's dynamic multi layered tessellation on an animated character.
In the end, in "UD", yes you can zoom all the way and see amazing "little" grains of dirt that literally look like dog turds, but in reality, you're playing a game, with most likely a fixed zoom, where you won't zoom into the ground hoping to see dog turd shaped grains of sand.
"Unlimited Detail" < Useable Detail!
Pretty much sums it up to me, i don't want detail i'm not going to see, I want detail that improves my gaming experience, yes objects are made up of atoms in the real world, but we don't interact with those atoms, we interact with the objects as a whole, or if the object breaks, fragments of the object - still not atoms.
I'm excited about Atomontage's tech and where they are going with it, not interested in "UD"'s.
So, first of all, the guys from Euclideon probably don't use voxels rather than point clouds. Where voxels are grid aligned data points and are usually associated with the "blocky" look, point clouds are just that - a set of points freely positioned in 3D space with associated color/normal/material information.
Voxels have seen a lot more use than point clouds, which is probably why most people automatically think of voxels if something is not made out of polygons. However, from the few "wireframe" shots from the Euclideon team we've seen so far it becomes pretty clear that point clouds are at work.
There are a lot of differences between the two, mainly stemming from the nature of how they're being stored. Since voxels are gid-aligned data points, most rendering algorithms struggle with the blocky look that arises naturally. Also, since we're dealing with a regular grid, it's hard to concentrate detail in one point and discard it in other places where it's not needed. Both of these problems have been fixed by the introduction of sparse voxel octrees, which trade the dynamic nature of the voxel grid for efficient rendering, level-of-detail and non-blocky surfaces using contours.
Point clouds, on the other hand, have a lot of trouble when it comes to efficient rendering. Since no assumptions about the regularity of the points can be made, it is hard to develop a spatial datastructure both memory efficient as well as fast at traversal/depth sorting (depending on the rendering method). It seems the guys at Euclideon have solved these problems at least partially, which is quite impressive in itself.
The other problem is that there is of course a limit on the amount of memory available, so the amount of points available for a model are not endless. As a result, even with high-resolution point models, there are gaps between the points (since they don't take up any area). As a result, if one were to render the points directly, it would look very poorly since the models would look like a collection of points rather than a closed surface. To solve this, implementations either resort to converting the point cloud to a ponygonal mesh with the points as vertices, or rendering the points in the cloud as flat discs to fill the gap between each other. The problem with the first approach is of course having to fall back on rasterization (which is slow for this kind of detail), whereas the second approach suffers from "blurry" models since the point color information is essentially interpolated across the disk. Euclideon seems to employ the latter, the artifacts of which are visible on some of their earlier shots.
Regardless of whether or not real-time rendering is possible (since they apparently achieved that), there are a few still unsolved issues with both voxels and point clouds.
1. Memory consumption. Since the points/voxels in a model are by requirement unique, the memory consumption is outrageous. There are compression schemes available that help somewhat, but building huge levels still seems to be quite difficult. The island they showed with oh-so-many trillion(!) points is a bit of a joke, since only a tiny fraction of them are unique points. Their videos rely on instancing so heavily it's laughable. They may be able to zoom to the crumbs of dirt on the ground, but as long as these crumbs of dirt look exactly the same as the other five hundred billion crumbs in the level, that's really not a useful feature.
2. Animation/dynamic deformation. Fast rendering of point clouds/voxel models always rely on efficient spatial datastructures that store the complete dataset of the scene. These datastructures are very time expensive to build, but once they're ready, they allow a set of queries (e.g. intersection tests) to be executed really fast. The problem is that once the data is stored, it's impossible to modify it without having to rebuild the whole thing or at least an unpredictably sized chunk of it. This means that dynamic deformation is completely out of the question (required for procedural animation such as ragdolls) and predefined animation is very hard to do. The guys from Euclideon clearly didn't solve this problem, since the only animated object we've seen so far was a keyframed bird flapping its wings (no bone animation, no skinning, just prerendered frames displayed in sequence - it's a joke).
So, ultimately, this kind of technology could (and probably will) find application in the next few years as a solution for static environments with polygonal models used for the dynamic objects (e.g. characters). However, the guys from Euclideon claim to have found a solution to EVERYTHING and that it has no drawbacks and allows UNLIMITED detail, all of which is simply a lie. While I salute them for their results so far (some of the models look quite amazing), their arrogant way of presenting them, the lack of any information about why this technology doesn't suffer from the already well-studied problems and their boldness to claim to have found something completely new that will revolutionize the graphics industry while just showing a new take on a concept that has been around for several decades just seems very unprofessional and makes their claims very implausible to me.
But either way, we'll see whether they were right when they release the SDK as they said in the newest video. While I hope their technology holds up to the expectations, I suspect it won't.
@Cooljay in this post: Wow, I just found this over my referrals - I made that picture almost two years ago and it was crappy even back then (in my defense, it was WiP). If you must link something by me, then I'd rather have it be the more recent SVO implementation I did (or in fact, link something from the Atomontage engine, since it's about five million times better than anything I did):
[ame]
its pretty clear, there is some potential in voxels for the future. but not for those guys and their publicly announced goal of combating polygons, its a shame they got the funding which could have went to better investments, imo i predict the closure of euclideon within the next 2 years.
its rather pointless arguing as to why, it has been for over 18 pages
as far as dropping polygons are concerned
Polygons have been around for 2000+ years and are very well-suited, established mathematical functions used for describing any kind surfaces and has proven itself long before computer where even around. I doubt we will just drop that to move through the big cloud.
Pior is right on the money here where a voxel coat over a simple mesh is more useful and I think this is what carmack is attempting. along with physics simulations (that still need to be EXTREMELY tight if on atom level)
Unlimited Detail is a silly joke. its another voxel engine -this time with a diffrent approach - but with the same crappy result and problems that come along with it.
RexM: Get a job
Actually Dell himself admitted several times that it's voxels but he doens't like to use the term because it hasn't got enough prestige in game development or something.
If we're both thinking about the same shots (namely the elephant statue), it was actually demonstrating their engine's new ability to convert polygonal models to their "atoms" model structure, rather than revealing the raw data format they're actually using. Given the manner and layout of the content they're showing, everything still points to SVOs rather than point clouds, to the best of my knowledge.
Like you said though, whether it's point clouds or voxels is far less important than the major drawbacks that remain blatantly unresolved. In my mind, memory and animation problems are less problematic (via advancing hardware and introducing a hybrid system with polys), than their static rendering's apparent total inability to place instances of static objects at arbitrary translations, rotations, and scales. At least, as far as the project's usefulness for real-world game development goes.
Actually, I was referring to a short scene in their first video (I think he demonstrated some sort of editor), where the point cloud visualization is shown.
Actually, that is possible and they've also shown it quite a few times (basically when they wanted to demonstrate how animation was not impossible by showing skeletal animation without skinning).
But as you mentioned, whether it's voxels or point clouds doesn't really matter, since both suffer from similar drawbacks.
@eld: That looks more like a poorly converted mesh, considering the models right next to it don't show any signs of voxelization
Hm maybe you're more of a knowledgeable person about this subject. http://homepages.slingshot.co.nz/~tmulgrew/VoxelOctree/ Could you check out the app in this link and tell me whats up. Slowly zoom inside one "melon thingies", you'll see more, use the control scheme to slow your movement down, and zoom into the next inside, keep doing that, then look out the way you came into them. You can clearly see that all the voxel areas are represented by different scales per iteration. So isn't it at all possible that they can be drawn at independent resolutions even if they're voxels? Especially if SVO's are involved? Again that isn't to say "unlimited detail" is possible, I'm just wondering if you can scale voxels based on rendering method.
It's a possibility, but these were scanned stones, which would translate directly into point cloud data, not geometry.
Also, if you oversampled a triangle, the pointcloud data would end up being a triangle made out of a bunch of points.
Here's a linky:
http://www.eurogamer.net/articles/digitalfoundry-vs-unlimited-detail
He's just avoiding the term to get more publicity, by confusing the general audience... which as others have pointed out is strange in itself, marketing his tech to gamers instead of developers...
In case it hasn't been posted: www.rockpapershotgun.com/2011/08/02/notch-vs-unlimited-detail
http://unlimiteddetailtechnology.com/pictures.html
Was this written by a 12 years old kid?
In fact the geometry program would probably be a good way of rendering point cloud data.
I think its kinda like when FrameBufferObjects became standardized. They were mostly used for simple post process effects, but now have much wider of common applications such as advanced realtime lighting calculations and general purpose gpu processing.
I don't blame him because Novalogic really crapped on the reputation of voxels with the second/third Delta Force games.
And yeah, GPUs are becoming more and more capable. A lot of people are looking into doing micropolygons on GPUs, which is how Pixar's Renderman works. That's why I try to repeat that in the 5 to 10 years that it'd take to get a fulyl voxel based engine to work and have hardware for it too, the current poly based approach might be getting a bit ahead as well
So we will be able to 'render everything you ever saw'?
any links?
See I try to at least peer into as much of this stuff as I can, there's always a chance to learn something good and new. Some of them are production related, and the other half is theory. Micropolygons are such a field, But there's many different teams looking into it, from universities to game devs - I think Tim Sweeney at Epic is seriously interested too.
Voxels are not by nature cubic.
Voxel is a portmanteau of a portmanteau. Voxel means volumetric pixel. Pixel means picture element.
So volumetric picture elements are all that voxels are. They are analogous to the concept of hypertexture, as developed by Perlin and others.
Early voxel renderers appeared as stacks of cubes due to the algorithm used to evenly and efficiently traverse Euclidean space. There were two main algorithms, marching the cubes, and marching tetrahedrons, which is he same thing but tweaked enough to get around a patent. Both of these are cubic and neither is the only way to break up 3d space. Just remember that we were dealing with hardware that makes your cellphone look like a super computer when these algorithms were developed.
But since people in general seem to think voxel = cube, this guy's settled on "little atom" or "point cloud" so people will quit thinking in regular cubic data sets.
Voxels today can be filtered, even sort of re-vectorized during rendering by algorithms that try to give back curvature to small voxel sized details (although his demo probably doesn't do anything like that, yet).
Thing is, why would you want to sell such an early tech demo to the general public... why go for publicity and all, I don't really get it.
The program you posted is very interesting though, since it uses a sneaky way to build the scene. You probably know how an octree is constructed: Fit the whole scene inside a cube. If there are voxels inside the cube, subdivide the cube into 8 subcubes and repeat the process for them. This way, you ultimately end up with a hierarchy of cubes, with the root cube containing the whole scene and the leaf cubes containing individual voxels.
What this guy (probably) did was first convert the melon model into an octree and then edit the octree manually to have the cubes in the center of the melon point back to the root of the hierarchy. That way you have an infinite recursion of melons inside melons (melception, if you will) with no additional memory cost. Since the size of the cubes are implicitly given (a cube is always 1/8th the size of his parent), the inner melons will automatically get smaller and smaller without having to apply individual transformations.
So yeah, this is actually a really cool way of abusing the octree. Though I am a bit disappointed - I would have expected something like this to come from the demo scene
Actually, they are - the same way a pixel is inherently rectangular.
Depending on the context, it doesn't mean you have to render them cuboid though. If enough information is available (i.e. object density at every point), it is very well possible to extract a smooth isosurface covering the object. This is essentially what the marching cubes algorithm does (and, contrary to what you said, it generates a smooth surface, not cuboid voxels).
Unfortunately though, this kind of information is really expensive to keep in memory, so usually real-time renderers resort to 'binary' voxels (solid or non-solid, nothing in between), which are very hard to render in a non-cuboid manner. Only recently have we seen a solution to that with SVOs, where some of the original information about the surface is kept.
Once again, voxel datasets and point clouds are different kinds of things.
To be quite honest, I think Dell chose "Atom" because he has no idea about common terminology in visual computing. He said he worked on his own, with practically no connection to other people specializing in computer graphics and built everything on his own from scratch. While that is admirable, it becomes problematic if he doesn't know what he's talking about. If you've watched the interview, you may have noticed him calling LOD "level of distance", or explicitly saying that they don't do raytracing but do a "search algorithm" instead which searches one atom per pixel (+additional ones at reflections), which is exactly raytracing, or calling cheap instancing "unlimited detail" and effectively not understanding the asymptotic running time of his datastructure since he thinks it won't get slower with more data, or freely redefining voxel as he pleases ..... the list goes on.
He is very hazy when it comes down to explaining how it works, and after the interview I've come to believe that it's not because he chooses to (so no-one can expose his technology), but it's more because he simply doesn't know any better.
http://vimeo.com/27522131
EDIT missed the last couple of pages sorry to double post but yeah i was interested in the atrefacts tat eld pointed out on the last page...also it looked as though there were tiny cascade shadow triangular artefacts...which was curious as i didnt think you would get those in a voxel engine
Thats the same video posted quite a few pages back, did you have a specific opinion on it?
Haha, I like how they position game screenshots against blatant photos.
nah those ARE 3d scans you can see the fuckups in the grass...
seen here -> [ame]