By Alec Meer on March 10th, 2010 at 12:05 am.
Jim pointed me at this video earlier, presumably believing that my knowledge of, for instance, how to overclock a processor without setting my house on fire means I can say whether there’s any water to its boasts. Um. Maybe? Unlimited Detail Technology reckon their clever tech is the biggest leap in realtime 3D graphics in decades. If what they say is true, we’re going to wave goodbye to games rendered in polygons, and hello to games free from cubist edges and limited model counts. Take a look below, and see what you think.
It’s eight minutes long, but they’re worthwhile minutes. Apart from the one powerpoint slide about why polygons are bad that it shows about 15 times, anyway.
(Before the ‘but that looks rubbish’ comments arrive – the reason Unlimited Detail give for the stuff they’re showing looking a little rustic is that the artwork is created by programmers, not artists.)
Let’s leave aside the fact that the voiceover alternates between chirpy educational TV and a strange creeping menace, and instead concentrate on what it’s promising. To whit, games that can show as much or as little as the creators wish, with no apparent concern as to the hardware they’re running on. It’s done by using points instead of polygons, it runs purely in software, and it can even do its thing on a mobile phone. It sounds amazing. It sounds crazy. Maybe it is – grud only knows we’ve seen plenty of wondrous-sounding technology promises fail to arrive over the years, but let’s hope this one can pull it off. The rough concept behind it is that the game is only ever rendering the pixels you can see at any one time, rather than trying to muster the whole shebang on a constant basis. Or, to use their words:
“Unlimited Detail is basically a point cloud search algorithm. We can build enormous worlds with huge numbers of points, then compress them down to be very small. The Unlimited Detail engine works out which direction the camera is facing and then searches the data to find only the points it needs to put on the screen it doesn’t touch any unneeded points, all it wants is 1024*768 (if that is our resolution) points, one for each pixel of the screen. It has a few tricky things to work out, like: what objects are closest to the camera, what objects cover each other, how big should an object be as it gets further back. But all of this is done by a new sort of method that we call MASS CONNECTED PROCESSING. Mass connected processing is where we have a way of processing masses of data at the same time and then applying the small changes to each part at the end.”
There’s another video on the site – I can’t find an embeddable version yet, but it’s got much more footage of the tech itself in action. It’s the Comparison one at the bottom of the page that you’re after. Oh, be warned Voiceover Guy gets even stranger in it, possibly due to the insane bell-based soundtrack.
With the released footage only demonstrating static environments rather than an interactive landscape, and anything playable apparently being some 16 months off, it’d be reckless to start shouting “THE FUTURE! THIS IS THE FUTURE!” just yet. The theory seems sound, but the practice can only be complicated. Creating content, for one thing – it’s expensive enough for developers to create a current-gen AAA game, so how do they muster the resources to fill a photo-real world with, ah, unlimited detail? It’d be lovely to see it, of course, but it may take some doing.
Secondly, the tech’s strength seems to be in geometry – real-time animation, lighting and shadowing seems a little skipped over thus far, and may be an area in which UDT lags behind the otherwise more old-fashioned polygon-based rendering system. Again, though, the stuff on show is terribly early and wasn’t created by pro artists. Moreover, even if it can’t ultimately compete with high-end traditionally-rendered games, it could well be a fantastic way to make low-end machines create far more complicated scenes than they’d otherwise be capable of.
Keeping an eye on this one. The potential is incredible, whether or not the industry picks it up.
10/03/2010 at 00:13 Snuffy (the Evil) says:
Neat.
10/03/2010 at 00:14 A-Scale says:
So I can play games with unlimited detail via On Live on my netbook? I’ll believe it when I see it.
And for the record, their city looks much less realistic than one in say Crysis. Granted I’m certain they could have done a lot more work on shaders and what have you, but the structures in their tech demo look bubbly and strange to me.
10/03/2010 at 00:28 Deuteronomy says:
A-Scale, the whole point of this is that there are no “shaders” per se. I suppose creating the point cloud could be done by converting conventional polygon based data from high resolution renders. There is a lot of merit in the approach these guys are taking, but I’m not sure how this differs from voxels.
The main issue I see is generating the point cloud on the fly algorithmicly, because there’s no way in hell I’m downloading a 5 terabyte game any time soon. Lighting this is going to be a bitch too. You are going to still need a video card for lighting and dynamic scenes.
Tesselation seems to sidestep the issues they highlight in polygon based rendering, and is a way of creating a “point cloud” on the fly.
10/03/2010 at 00:15 Heliocentric says:
So… Its a poor mans ray tracing?
10/03/2010 at 00:16 llama says:
No….watch the video before you post.
10/03/2010 at 00:19 Heliocentric says:
Posting from a mobile, in bed no less.
10/03/2010 at 00:42 Stephen says:
Cool but you really need to watch the video before you comment on the new graphics technology.
10/03/2010 at 01:22 Noc says:
…so they’ve working on a more efficient ray-tracing algorithm, and are using voxels. All of that “performing a spacial search” stuff…that’s all a raycast IS. They’re finding out which voxel (oh, I’m sorry, “point”) is in front of a given screen pixel, and have apparently found a way to do this that doesn’t involve shifting through massive amounts of junk data for each search.
This is pretty cool, honestly, but it’s not like we haven’t already heard about this sort of thing. This isn’t some Crazy Revolutionary New Idea That’s Going To Change Everything That The Man (the “Polygon Companies”) Don’t Want To Hear About.
It’s…another stab at voxels and raytracing. I’m totally in favor of people working on new sorts of graphics tech, but the theatrics are kind of making them look a little sketchy.
10/03/2010 at 02:40 Biz says:
Not a poor man’s raytracing
a rich man’s raytracing :)
10/03/2010 at 08:13 Steven Wittens says:
Noc is right. Look at the debug rendering at the end (green glowing matrix-style)… this is exactly what you’d get if you were raytracing a sparse multi-resolution voxel octree.
You wouldn’t do strictly classical raytracing, you’d be doing a sort of “fat” raytracing where you actually trace viewing cones with volume instead of infinitely thin rays. This lets you use the octree structure for maximum effect. You would start with a fat ray representing macro-blocks of pixels, only splitting up the fat ray into smaller blocks when it hits something. You stop the process when your rays become pixel-sized, and you never inspect octree nodes smaller than your ray is wide.
Also notice, for as much as they put down voxels for their memory usage, the only scenes where they have a large viewing distance is where geometry is repeated *perfectly* on a grid. I.e. they’re just wrapping their rays around the same voxel structure, hiding this fact by using a simple rejection test to build those pyramids of monsters.
10/03/2010 at 00:24 Seol says:
Meh, that’s rubbish. Their main point about the angular look of polygons is rendered moot since DX11 cards can run adaptive continuous level of detail entirely on the GPU thanks to their tessellation stage.
Also I shudder at the thought of the amount of memory their point cloud data must consume (specially when animated and with complex material parameters, not to mention the cost of creating it), and I wonder if, being a software based solution, the CPU will have enough power left to, I don’t know, run a game at the same time.
10/03/2010 at 00:27 Javier-de-Ass says:
that’s nice
10/03/2010 at 00:30 Axiin says:
This really excites me! People can eliminate 3d graphics cards, spend more money on processors…. in the process get better graphics AND run bigger Dwarf Fortress worlds!
12/03/2010 at 11:34 Nesetalis says:
You Sir win a new kitten! :D
10/03/2010 at 00:31 Wulf says:
It’s all incredibly static and pre-processed, isn’t it? I mean, you could use this for prototyping terrain, landscapes, and architecture, sure, but it’s still going to be static. And everything in the video seemed to nod toward that, from my limited understand. And again, from my limited understanding, the more animation/physics that a game has bouncing around, the more limited (ironically) this technology will be.
Considering that everything is about lifelike this, interactive that, all with physics doodads and procedurally-generated what-have-you’s, this isn’t really going to be of a lot of interest. The thing is, at the end of the day it looks like the challenge is going to be a completely prefabricated and static world with limited animation versus a slightly (almost visibly, but not quite) angular world with complete interactivity borne of everything rendering real-time.
Unless this can compete on the interactivity front, what chance does it have?
– Edited to add… –
Not to mention that something’s been bugging me about this, and it took me a while to figure out what it was. It’s the same problem that some fractal renderers have.
Basically, with no anti-aliasing, and a potentially low-resolution, the entire video reminds me of a 2D game from the mid 90′s, perhaps with a pre-rendered backdrop.
You know what I mean, it has very obvious pixels that make up the image, it doesn’t have smooth colours or patterns because of that. And I don’t know if it would be able to.
So potentially we’d all go back to playing games that looked like they were in the 90′s, with almost the same level of pre-processing, it’s just that our computers will be doing the crappy rendering rather than the developer.
10/03/2010 at 00:54 JuJuCam says:
Think of it as exploring an alternative timeline from the 90′s when polygons didn’t take hold in the way it did. Yes, we’re back to 90′s graphics because we have to start over from there and relearn all the tricks that make polygons look realistic all over again without polys.
10/03/2010 at 02:14 Down Rodeo says:
Anti-aliasing wouldn’t be that difficult, if their tech scales well then you could simply render at higher resolutions and resample it downwards, which is of course what quite a few games do already. Not sure how they’d do adaptive anti-aliasing though… some kind of edge detection? It looks impressive I suppose but many people in these comments have already raised issues.
Also that guy is camp as.
10/03/2010 at 03:46 Bonedwarf says:
BRING BACK VOXELS!
10/03/2010 at 04:10 Wulf says:
Voxels, yes. Voxels I don’t mind. But everything in that video looks like a griany, low-res GIF image from the early days of the Internet, or from old game rendered backdrops and FMVs. Remember the FMV in stuff like The Pandora Directive? Great game, but that poor quality video did a number on one’s eyes, and still does (I’ve replayed it recently). I could see much eyestrain coming from this, and even Outcast looks better.
10/03/2010 at 00:33 M says:
Hmm.
It looks alright; we can emulate this to some extent already, though, by ‘guessing’ what’s between the points on a polygon. We do this all the time to smooth out models.
I was going along with it until he started to get more technical. Then it seemed a bit weird.
It sounds like they’re using something a little bit graph-like (not statistics-based graphs, but this kind – http://people.brunel.ac.uk/~mastjjb/jeb/or/gt1.gif) to represent what can and can’t be seen at any one time. The way it renders for “each pixel” despite apparently providing infinite detail sounds a bit like a fractal – they’re mathematical functions and so are infinite in size, but your monitor has a finite number of pixels so it just colours them in accordingly.
Assuming they’ve got a really nice representation, they’re able to somehow explore the vast spaces required in order to render thirty scenes in a single second, then it might work. But there’s certainly some questions to be asked – like you say, lighting and collision detection would seem to have a different meaning for a system like this. You can’t collide infinitessimally small points – you’d have to put a bounding object around it. And that object would be polygon-based, presumably. The same goes for lighting.
The other thing I wonder is how it looks in motion, because the computer will frequently try to decide between a bunch of different, equally infinitessimal points to display. There’d need to be some clever checking to stop the world from fuzzing and vibrating horribly.
Ultimately, the work can’t disappear. Even if we transform a polygon problem into a state space search, computational work is still being done. As you say, sixteen months is a long time, and until we’re looking at a perfectly round tree in Elder Scrolls V, who knows.
10/03/2010 at 00:34 Dave says:
I can’t suspend my disbelief enough to buy into this, without a better explanation. Also, programmer art aside, what we aren’t seeing:
– animation
– lighting
– alpha blending
– running in a real game engine where CPU time is consumed by other things.
10/03/2010 at 00:37 K.Boogle says:
Now let’s all pray NVidia and ATI (and even M$) don’t get a whiff of this, or we’re all screwed out of the future =(
10/03/2010 at 00:43 JuJuCam says:
Colour me skeptical till I’ve got it in my own hot little hands, but if it’s true it would be a gamebreaker.
10/03/2010 at 00:47 Diziet says:
Why the hell is it voiced by Graham Norton? That video also appears to assume it’s own audience is dumb. Also gave me flashbacks to Elixir and Republic: The Revolution.
10/03/2010 at 00:52 Dominic White says:
“That video also appears to assume it’s own audience is dumb.”
It’s a Youtube video. Have you ever seen Youtube comments? Dumb is an understatement. Mind-crushingly moronic is just about par for the course there.
10/03/2010 at 01:03 Diziet says:
@Dominic White
Good point. I’ll shut up on that count.
On another note I want 8 minutes of my life back. I mean it’s a great idea if it could actually work but it mentions nothing at all with regards to the following:
- Great you’ve picked a point from the ‘cloud’ that you know you need to display, where’s the texture details? How the hell do you texture this stuff?
- Great you’ve picked a point from the ‘cloud’ that you know you need to display, how do we calculate lighting?
- Great you’ve picked a point from the ‘cloud’ that you know you need to display, oh shit is that a graphics card built to display polygons. Guess I’ll have to chew up some cpu time that should have been running the game code for you. This one is actually a minor consideration though as if we thought like this we’d never have got decent 3d cards in the first place.
I know it’s madness but really the only way to create amazing real computer graphics, which I’m not even convinced we need but then again I do like the artistic aspect of some games, is to simulate reality. This pretty much means ray tracing, no?
10/03/2010 at 01:25 solipsistnation says:
I think you can’t think of texturing in the same way as you do for polygons– that is, rather than a texture being an image and a bumpmap projected onto a polygon, each atom (or point or whatever) has a location (replacing the bump map) and a color (replacing the image).
Lighting would mean computing whether each atom is in shadow or not, and from each light source in a scene, and adjusting the color of that atom accordingly.
The CPU question is the important one. This is all stuff that we can do now, clearly, but I think it doesn’t scale very well.
There are questions that aren’t obvious, too, like, how do you store the location of the atoms? Are they on a grid? They have to be, so you can keep track of where they are, but how big is that grid? How big are the atoms? At various angles, light sources can potentially cast a shadow from one point onto 2 other points. How does that work?
10/03/2010 at 06:28 Tom Camfield says:
@ Diziet
He sounds like he’s been educated in a private school. They tend to pronounce some words a little prissily, for example pronouncing data “daaarta” instead of “dayta” (or, /ˈdɑːtə/ rather than /ˈdeɪtə/, at least I think that’s the IPA). This is part of Received Pronunciation or Oxford English or whatever you’d like to call it.
10/03/2010 at 07:38 Lemon scented apocalypse says:
^ ‘Darta’ is the correct english annunciation. ‘Dayta’ would be american.
In terms of the new technology: colour me suspicious.
10/03/2010 at 07:40 Lemon scented apocalypse says:
pronunciation even. Must have catholics on the brain
12/03/2010 at 11:46 Nesetalis says:
From what I gather, he is using point data.. which would contain color, alpha, and any other variable associated with it. Similar but not necessarily the same as Voxels
if I was doing it, I would create objects from point data, and each point reference a sub object. so that as you zoom in, you then start rendering data from this sub object positioned at the point you are looking at.. or as you zoom out you figure out where the point you are looking at belongs in the grand scheme… and so forth.
i gather hes doing similar, since he said search engine.. it can be done very easily with individual objects in a common database. Objects for shape, perhaps even proceural color applied to them via parent object.. inheritance.
10/03/2010 at 00:51 Casimir's Blake says:
After a few seconds I realised what the visual style of this tech reminds me of.
The Shamen – Axis Mutatis. William Latham cover art.
10/03/2010 at 03:47 Bonedwarf says:
I always wanted software to create art like that. The Shamen put out a screensaver along with that release but that was about it.
10/03/2010 at 08:33 Casimir's Blake says:
Nemeton still has a demo of Latham’s Organic Art software.
Oh and The Shamen put Lady Gaga to shame, on every possible level.
10/03/2010 at 00:57 fulis says:
Isn’t this similar to what Carmack has been talking about with virtualizing geometry and essentially removing the polygon budget?
10/03/2010 at 00:58 HermitUK says:
I agree with a lot of the comments here. It’s interesting, but it seems to be ignoring some pretty big parts of games. Reminds me a bit of something like Riven or Myst 3 – something which looks fantastic but isn’t fantastically interactive.
One interesting thing I did notice is that they’d avoided animating of any kind. “Programmer art” doesn’t prevent them from showing bit of wind swaying leaves and grass, or having those pyramids of 2000-odd monstrosities doing a little dance.
It’s entirely possible that there’s potential here, but for now I have to file this in the same place as streaming games – can’t really believe it til I see it on the screen in front of me.
10/03/2010 at 01:00 Phydaux says:
Wow, I think my hoax alarm just exploded.
10/03/2010 at 07:56 PaulMorel says:
yours too, huh?
10/03/2010 at 01:01 Mwalk10 says:
Seems like it would take an infinite amount of hard drive space to hold an infinite amount of detail.
They say they can compress it into something very small, but then that would make animation difficult when you need to change the state of things.
10/03/2010 at 01:01 EBass says:
I mostly understand the concepts here, but I’m still skeptical. I mean his assertion that the way it’ll be done is it searches for the pixels it needs to display and then only displays them? Ok, but so what? We still need a massive amount of these being rendered in order for it to actually look good?
I mean hell even in the demo we get framerate drop.
10/03/2010 at 01:16 solipsistnation says:
That’s actually what poly-based rendering does– unless you’re playing Trespasser, the game engine doesn’t render all the polys in the level you’re exploring and all the polys in the items and creatures you encounter– it clips polygons on the backs of things and that are outside your field of vision.
That’s an interesting point, too– if I want to not show the backside of, say, a crate, I have between 3 and 5 polygons I don’t have to render (3 for the straight-at-the-corner view, where you see 3 and 3 are masked, and 5 for the right-up-against-one-side view, where you see 1 and the other 5 are masked). For a crate rendered in points, there are potentially UNLIMITED points that don’t get rendered– that’s a lot more data manipulation than just skipping out on 3-5 polygons. On the other hand, because points are either behind something or not, that check may be much simpler and thus much cheaper as far as compute time– and no having to compute how much of a poly that is partially behind another object should be rendered…
I think the scale, however, makes computing clipping for a zillion points take enough longer than computing clipping for a handful of polygons, even on zippy computers.
10/03/2010 at 01:04 Mwalk10 says:
One thing they didn’t touch on is the ability to now store the insides of things. Fully deformable environments + characters here we come.
10/03/2010 at 01:04 kyrieee says:
I’ll tell you what isn’t unlimited:
Disk space and memory access times
This sounds too good to be true, but I guess time will tell. I don’t see how you could bypass projective geometry using some weird search algorithm, but I don’t know much about search algorithms… I do know a bit about projective geometry though :P
Also, the issues with LODs and popin they’re talking about are completely solved by tesselation which almost here now
10/03/2010 at 01:07 alinkdeejay says:
To use an engine like this to the fullest, you’d also have to manually create these actual details. That by itself is a crazy amount of work, too much for the already huge teams of developers from the largest companies. Games like that will simply be too expensive and too much of a risk to develop.
How would textures work? The good thing about polygons is that you can apply 2D textures on top of them. With these strange dots floating in space, it seems a little …impractical and annoying to apply textures.
10/03/2010 at 01:10 solipsistnation says:
Yeah, it would mean a totally different style of tool, since textures would be a combination of different displacements of dots and different colors of dots…
10/03/2010 at 01:25 Tacroy says:
It wouldn’t be that different, and might even be easier. For instance, instead of drawing something that looks like a flat brick wall and pasting it on one long flat rectangle, you’d draw a brick and tell the engine that there’s a hundred of them arranged in such-and-such a fashion, and each one should have this much noise added to its appearance so they’re not all exactly the same.
10/03/2010 at 01:45 Spod says:
Perhaps it’d be possible to digitise real world items using some sort of “LASER” scanning.
10/03/2010 at 02:44 Deuteronomy says:
What is this “LAZER” you speak off?
10/03/2010 at 01:07 solipsistnation says:
Okay, at about 3:50 in the first video, a plant passes really close by and you can see that it is, indeed, made up of loads of floaty points. But at that range, the points are HUGE. It’s like that “Voxelstein 3D” game. Say what you want about textured polys, if the texture is at a high enough resolution and you have filtering and anti-aliasing and so on turned on, if you get that close it’ll still look smooth. Perhaps a bit weird, but not like giant floating matchboxes.
You can see some of that in the comparison “propaganda2009″ video, at about 1:22, when he zooms in close on the ground (“They’re real pebbles.”). Everything that gets close to the screen gets very strangely blocky and it becomes more obvious that it’s a bunch of floaty “atoms.”
I also note that the horizon (or at least where the view cuts off) is pretty close in most of their demos. I’m a bit skeptical of how well it really scales, although I’m sure there are point-reduction algorithms just as there are poly-reduction algorithms currently…
So, yeah. It’s interesting, but I don’t think it’s as unlimited as they want to think. I’m curious about the memory usage of those scenes, too.
And dear lord, they should hire a professional to do the demo videos. And not release a demo video with weird software bugs that the narrator has to explain away.
10/03/2010 at 06:02 captain fitz says:
Comment retracted–I just saw one of the other videos. And what’s with the noise on the right side and bottom of the screen in the comparison video? Looks terrible, I hope that’s not being rendered.
10/03/2010 at 01:10 Velvet Fist, Iron Glove says:
The biggest thing that struck me about all the samples they showed was that they had a tiny number of different “models” on the screen. They were instancing the creature in pyramids many many times over, but even the jungle and town scenes were instancing a very small number of models.
What that suggests about their algorithms’ bandwidth requirements and cache coherency I can’t say, but it doesn’t give a good impression.
10/03/2010 at 01:31 Tacroy says:
To me, it suggests that each model is much larger than with traditional methods. You would have to push a lot more data over the bus to the graphics card per model, if you want to have multiple different models.
This is not necessarily a problem, however; you could get around the samey-ness relatively easily by telling the GPU “here’s our point-cloud model; here’s a function that you can apply on the model to change it with a seed value; now put f(model, seed) here, and f(model, seed+1) there.” – kind of a mixture of this stuff and the procedural content generation you find in some games. After all, it’s not like you need two different models for bad guy one and bad guy two; they’re both people with some slightly different coloration and maybe a couple of accessories.
10/03/2010 at 01:16 Mark says:
Well, speaking with my experience in computer science, using search methods for a problem like this does seem to be an effective way to handle the issue. Some of my colleagues have done some pretty astonishing things with search algorithms. It doesn’t smell too much like snake oil to me.
Of course, there’s more to rendering than pushing pixels. While an efficient search algorithm can lower the overall requirements needed in comparison to brute force, the algorithm itself will still have pretty high overhead. The complexity of the scene would still represent a limit to what can be rendered in a timely manner on a given system; it’s just that the bottleneck is now more likely to be memory or processing. Even if you’re not rendering all the geometry every frame, you still have to store it and you still have to search through it, which are both tasks that this method makes significantly more demanding.
Doesn’t have the smell of snake oil to me, though.
10/03/2010 at 08:17 dantokk says:
Really? Comparing the problem of visibility “search” to Google and Yahoo search doesn’t smell like snake oil to a computer science guy?
12/03/2010 at 12:03 Nesetalis says:
from what i gather that they are doing, search is exactly the term they should use. and exactly what it is on the package.. so no, to me, its not snake oil.
10/03/2010 at 01:25 gulag says:
Hmm, virtual dirt. That’s what it is. Particles stuck together to make stuff.
I was having this discussion today with some mates. What if we could model soil in a game? Rocks and mountains and cliffs are easy to do with hard-edged polygons, but what about the soft, maliable blanket of soil that lies over an environment? What if you could keep track of enough of it that you could model earthworks, or trenches, or a landslide? Let players change the terrain, or use it as a way to encourage exploration.
This seems like a step in the right direction, but as commenters have pointed out above: If it doesn’t move, it ain’t much use.
10/03/2010 at 01:37 A-Scale says:
I know this isn’t in the sense you’re talking about, but Tiberian Sun had a flame tank that could dig through the soil and Stronghold had sappers that dug tunnels. Interesting concept that, dirt digging.
10/03/2010 at 01:38 The Snee says:
I’m pretty skeptical of this for a number of reasons.
1) I’m not sure exactly how this point cloud system differs from things like voxels, or how it is more efficient than your current industry standard (a low poly mesh covered with a material that simulates the lighting for a high poly mesh). Because of the way things work now, you’re usually getting a smooth-ish transition between polys on the majority of surfaces, to the extent that it’s hard to actually find the surfaces unless you really know what you’re looking for. And once you get to that point, you start noticing the polys in real life, and commenting on how the texturework on that newly painted bench is fairly shoddy. It happens, trust me.
2) Someone already mentioned this; the pipeline. At the moment you have loads of programs set up for poly based editing. You make your model, bake out normals, paint on textures, etc etc, import it as a mesh into engine and so on. I’d really like to see their toolset to see what you actually work with. The way textures are applied is a particularly weird one.
3) Unlimited. Unlimited. The phrase keeps popping up in the video. I find that hard to believe. Even at it’s smallest possible size, each point in thier cloud system will be a few bytes of three dimensional positional data. There’s no way it could be unlimited, there’s a limited amount of memory on any machine. Instancing will help, as the animal pyramid shows, but that video was a little less than smooth.
4) The video itself. Its presentation was awful. Artistic choices aside, the video and it’s narration seemed to be laced with an amount of bitterness and self absorbed superiority so high that i couldn’t bear to watch the whole thing. It gives me the feeling that while there’s talent there, there’s a bad direction behind the project, and they need someone who knows what they’re doing to take control.
So in essence, if that video is a representation of their project, I can pretty much disregard it. Until I see some facts, proper, high resolution tech demo that show how the environment can be interacted with, and a demonstration of toolsets, I can’t make a proper judgment.
10/03/2010 at 08:30 dantokk says:
Yeah what’s with the whole “unlimited” thing. Despite his claims, the jump to 32-bit colour is not a jump to unlimited, just high enough to be indistinguishable by the eye. I’m sure there are imaging applications that use more than that.
Similarly, when we finally do get true-to-life visuals they will be of limited precision, just enough to fool the eye and mind.
The whole video shoots out little fallacies like that at pace designed to confuse, not inform, and it drives me bonkers!
12/03/2010 at 12:08 Nesetalis says:
highest color we usually go is 48bit color. most of those colors cant be displayed on a monitor or seen by the eye.. but they can be very necessary when doing advanced graphics editing.. (to get proper effects between color interaction and with things like anti-aliasing)
this doesnt strike me as BS.. personally.. depending on exactly what they are doing it is very likely conceptualized from voxels.
10/03/2010 at 01:45 Mario Figueiredo says:
This whole thing smells to prank. A few points to take into consideration:
- It’s not polygon count actually that is an issue with current polygon-based architecture. It’s textures. If it weren’t for textures, we could increase polygon count to unimaginable levels.
- The author doesn’t explain very well how they zoom into a point cloud. This is the big issue with voxels. They don’t scale well. This is their bottleneck. And let me tell you, a huge one. The amount of processing needed to recalculate the whole screen is today much higher than that needed to redraw a polygon scene. If the argument is new processors will be able to handle this, well so will they be able to handle more and faster polygons.
- On the issue of zoom, there’s also the problem of voxel data scalability. As you get closer, points start to become evident, in order to avoid this, higher resolution data needs to be stored, which carries more points than the previous resolution. With big enough resolutions levels (akin to what we have in modern games) the amount of data needed is huge. I’d wager something like 10x to 100x to store a modern game with half the zoom capabilities of it’s polygon-based original.
- A revolutionary new technology is never presented with such amateurish screens and dialog. The issue is not the quality of the graphics. That’s secondary. The issue is programmers showcasing something that has really nothing to do with what they allegedly been programming on. Point cloud techniques could better be showcased with morphing scenes, scenes with many moving objects in various directions, image destroy and rebuild scenes, discussing textures and how they are achieved, showing bump map effects and how they are calculated, rapid color changes, slow-motion zoom effects, etc. And all in a more adult-like tone. I went to they website and saw nothing of that.
- The simple mention of the word “unlimited” completely destroys their case. It’s just not serious talk. If they mean unlimited because computers processors have the potential for unlimited development, well, so is polygon-based rendering unlimited, for the exact same reasons. If on the other hand they say unlimited because it’s really already unlimited (like they tried to imply with the pyramids), then it’s complete BS. As there is no such thing as unlimited processing capabilities. A scene rendered on a given resolution may also seem “unlimited” by employing polygons. The limit is not in the amount of polygons in a frame, but the amount of frames per second.
- Finally… where’s the mandatory FPS readout?
10/03/2010 at 04:55 Soobe says:
I think the biggest problem with this idea is that we’ve already started to bump into the realism ceiling. Take Modern Warfare 2. You’re simply not going to find a game with higher production values until the next one comes out, and I have a hard time quantifying how that game would have been better, both in terms of game play and quality, had this tech been employed.
Our problem isn’t polygons, it’s art department budgets.
Of course that’s to say nothing of animation. I’m sure any solution would have to be of the reductionist sort anyway, in that you’ve have to subdivide and most likely create polygons of particle clouds!
Who knows though, let’s wish these guys god speed!
11/03/2010 at 16:08 godwin says:
Excuse me here, but MW2 is hardly the apex of quality whether in terms of gameplay, writing or production.
10/03/2010 at 01:51 JuJuCam says:
Forgive my ignorance, but would it be possible to integrate elements of this model with the polygon model so you could have, for instance, point based static environments but polygonal interactive / animated characters and features? Or are they mutually exclusive graphics engines?
Something like the first two Wing Commanders, which had a polygon model that was replaced wholesale by a bitmap that changed depending on players perspective rather than textured in the now traditional way. A compromise between old and new technology.
10/03/2010 at 01:54 Mario Figueiredo says:
Yes, it is. And it’s being done for quite some time. See Voxel in Wikipedia.
10/03/2010 at 01:57 LionsPhil says:
As noted, this is “just” voxels + raytracing, perhaps with some overblow pixie dust on top.
Voxels mean lots and lots of drawing frames to do animation. You ever notice how the units in C&C2 and RA2 didn’t really have much at all in the way of animation, just rotation of the entire model, despite being from an era where polygon-based games like TA had spider K-bots scuttling around? It’s a lot easily to animate something that you’ve defined as a set of shapes than it is as a grid of 3D pixels.
I don’t think nVidia nor ATi need panic.
10/03/2010 at 02:03 noom says:
I can’t be the only person that found the voice-over guy rather endearing can I..?
10/03/2010 at 02:15 SFLegend says:
I thought that he sounded like Jim Sterling from Destructoid, which is kind of the exact opposite of this.
10/03/2010 at 02:24 Bhazor says:
I thought he was great. Just the right measure of smugness and condescension without being unlikable. I Imagine that is how Jeeves/Stephen Fry would talk. If they knew what cloud points were.
10/03/2010 at 02:10 Pijama says:
For us gamers with a basic grasp on graphic technology but not enough to understand the finer points of it, WHAT THE HELL ARE YOU GUYS ON ABOUT, please?
Pretty please?
10/03/2010 at 02:25 Mario Figueiredo says:
That it could be cool. But it’s too cool to be true. And our current processors and storage capacity agree it will not be true for a long while.
In terms of game development, if we had the capacity to render entire voxel-based scenes in modern 3D games in real-time at rates above 30 FPS, the possibilities in terms of art design would be nearly unlimited. Think movies, now think games that look like movies (which for many of us may not be that cool anyway).
10/03/2010 at 05:52 solipsistnation says:
Current graphics cards treat everything as a bunch of triangles– a rectangle? Two triangles. Thus a crate is 12 triangles– 2 per side. A tree trunk? A bunch of triangles arranged into a cylinder wider at the bottom than at the top. And so on.
What these guys do is, instead of taking all those triangles and turning them into pixels with are then displayed on your screen, they start off with the pixel as the basic unit. So while traditional video hardware represents a crate in memory as 6 triangles and a graphics file (a jpeg or .bmp or whatever) wrapped around it, these guys want to represent that crate as a bunch of individual dots. It’s the difference between representing a tabletop as a flat surface and representing it as the atoms that make up that surface.
The problems come when you decide what to draw. Polygons present one set of problems to solve, and atoms represent another, similar but not identical set of problems. The question is whether the atom problems or the polygon problems are more complicated and take longer for your CPU to work out.
Currently, polygons are winning because they are relatively fast to work out and draw on your screen– this is partially because it’s how we’ve been doing it for years, and partially because you have a video card that does most of the hard work instead of your CPU doing it. These guys want to take that back from the video card and make the CPU do the work, since CPUs today are much faster (not just in clock speed, but in how rapidly they can process instructions) than they were a few years ago.
It’s an intriguing idea, but I suspect that in practice it won’t work as well as polygons. It may look better if artists take the time to really get into the system, but it will be slower. Unless of course we had atom-cloud acceleration hardware, video cards that can work with tons of atoms rather than tons of polygons…
10/03/2010 at 02:21 Gorgeras says:
I think you’re all missing the point.
This is the Matrix. I swears. OMG, that means that voice belongs….to the Architect.
10/03/2010 at 02:22 Daniel Klein says:
Trips all my many bullshit sensors. They say it’s different from Ray Tracing, but they never explain how. From what I can tell (have a point of origin, lines of sight, figure out which points of the geometry are needed) this is EXACTLY ray tracing. But the main reason my BS sense is tingling is that computer graphics is a highly lucrative, highly studied field, and they claim to have just come up with a cold fusion reactor wrapped in a perpetual motion machine. That they use all the usual snake oil peddler tropes (“we showed this to Big Company XX and they didn’t like it because they LIVE IN THE PAST!!! There is a conspiracy to keep us silent just like Big Pharma doesn’t want you to know that you can cure cancer with the power of CRYSTALS!!!”) doesn’t help their cause either.
Basically, this is bunk.
10/03/2010 at 08:11 lonkero173 says:
I don’t think raytracing is usally done with point based data, so it’s not exactly raytracing as we know it. (Sounds a lot like some raytracing/voxel combination) Also like others have pointed out no animation is shown, and animation is typically the achilles heel of raytracing/voxel based solutions as that forces you to (at least partially) reconstruct the data structure you are using. And building the data structure is generally a slow operation while seeks are extremely fast (albeit they do get slower with larger data structures, usually O(log(n)) complexity). And do take this with a grain of salt, they don’t tell much and I’m not exactly and expert on these things.
Anyway, looks interesting but I doubt it’ll get anywhere, too many problems. Also the gratuitous use of UNLIMITED is rather frustrating.
10/03/2010 at 02:51 shai says:
It took some time before i noticed i wasn’t on ./ after reading this thread
11/03/2010 at 19:46 Boldoran says:
+2 Funny
10/03/2010 at 03:01 DMJ says:
More details please. Not just “it’s like Google and it isn’t voxels and it isn’t raytracing even though it sounds awfully like exactly that”.
We need something meaty and terrifyingly technical, using big words that we can look up on Wikipedia and nod sagely to ourselves as we raise a quizzical eyebrow.
10/03/2010 at 03:16 xrabohrok says:
I’m with him on that. I have a feeling that this movie is more aimed towards the venture capitalist crowd, whoever that is. But at the same time, its still belittling. I know what a polygon is, dammit!
10/03/2010 at 03:02 Deuteronomy says:
Please go to youtube and type “Atomontage”. Prepare to have your mind blown into little voxels.
10/03/2010 at 03:19 u335 says:
Well, you obviously can’t store an unlimited amount of points in a computer – so the point cloud must be procedurally generated. So, instead of 1 trillion points in a “cloud” actually stored somewhere, you only have 500 equations that produce 1024×1024 points of color. Ok. Thats fine, I’ll go with that.
Methinks the crux of the matter is having those points INTERACT. Polygons give you useful little units that may interact with one another. It seems to me that you must re-invent this concept of ‘useful little units’ in order to make the point cloud method work for animation…which I would say most gamers are rather interested in. Otherwise, it seems the CPU load will be untenable. Any ideas on this anyone?
10/03/2010 at 03:35 JKjoker says:
you could also build the world with polygons behind the scenes but with a much lower count that would look horrible visually but works perfectly for calculations, a whole new technology always needs some tweaking, new ideas and time to mature
you could still have a “gpu/physics card” for calculations, but without the need to be as powerful and expensive as they are now
10/03/2010 at 04:43 u335 says:
What you say is interesting, joker. I agree that it’s a good idea to keep an eye on this one, but I keep having a nagging feeling that something about this is bullshit. I guess we can maybe think of an example to test the waters: what if someone reprogrammed Asteroids using the point cloud method? Can we intuitively understand how rendering would be just as easy – or easier – using point cloud rather than vectors/polygons?
Hmmmm…. /puts on thinking cap
10/03/2010 at 03:25 JKjoker says:
sounds interesting, i can buy that a 3d search engine can find 1024×768 pixels faster than what it takes to build a 3d world with polygons, apply whatever they do to make it look nice and show it at that resolution, the cost of building “unlimited detail” worlds makes me a little uneasy tho, but i guess that could be fixed by deciding a quality/budget goal during development
assuming it actually works i think they should start with portable consoles/pcs/cellphones first where they can make things that look better than anything with polygons, it will take them a while to reach a level where they can compete with the much more mature polygon technology on big consoles/pcs where processing power is available (which is why a lot of posters above are noting the demo doesn’t look better than current games)
polygons didn’t get where they are now in a day you know, they started looking like crap, ill give these guys a chance, lets see what they can do
10/03/2010 at 03:31 WilPal says:
I guess collisions could be checked like this:
Check which layer the player is at in the “Point Cloud”, if he intersects, stop applying gravity/velocity etc.
Obviously it would be far more complex than that, as that would only give very basic interactions, but you get the idea.
Now i’m going to bed because that doesn’t make much sense.
10/03/2010 at 03:43 Scundoo says:
if he intersects, stop applying gravity/velocity etc.
You are forgetting a little thing called inertia.
10/03/2010 at 04:37 u335 says:
Nah, not inertia. If there is an intersection the player character needs to experience a force. Inertia is just a general statement about motion in the absence of force, i.e. you never write an equation with “inertia” as a variable — but that’s all a bit OT.
10/03/2010 at 06:34 Dave says:
My guess is you do the traditional thing for collision: low-poly models and/or combinations of geometric primitives. The technology for automatically turning models for rendering into models for collision/physics is pretty well established.
10/03/2010 at 03:37 bbot says:
Nothingdamn! Get this guy a PR agency!
The video was just eye searingly bad. The voiceover was bad, the script seemed to spend most of its time insulting the audience, and the rest of the time skipping over technical details, the editing was lousy, the screen capturing was a slideshow, the phrase “unlimited detail technology” is and out and out lie, and for some reason this graphics demo was in 480p.
Technically, it’s interesting. The point cloud geometry would be hard to fake, and the laggy video convinces me that it was actually some twat sitting in front of a keyboard and mouse controlling the thing, rather than an offline renderer. The lighting is realtime, as eagle-eyed viewers may have noted half-way through, when he messed around with it.
Never saw any of the models move, though.
10/03/2010 at 03:41 Scundoo says:
but that looks rubbish
10/03/2010 at 04:10 Bruno Daniel says:
THE FUTURE! THIS IS THE FUTURE!
No, seriously, it’s too good to be true. Perfect geometry? Sounds a bit like electric cars: awesome in paper, but simply too expensive for our current economy. But just as electric cars, this thing could very well be the standard in the future…
I sure as hell can’t wait to see the SDK they mention in the video!
10/03/2010 at 04:19 MrBRAD! says:
This will be suppressed by the big businesses so they can keep selling us expensive cards in the same way that pharmaceutical companies don’t want to find a cancer cure so the only choice for people is expensive chemotherapy.
IT’S A CONSPIRACY MAAAAAAN
/tinfoilhat
10/03/2010 at 04:38 JKjoker says:
i was thinking the same thing but then i remembered that both the cpu and gpu grind has been kind of frozen for the last few years, that neither Microsoft or Sony want to release a new generation of consoles any time soon (which would make software that could breath new life into them very tempting) and that the fastest growing gaming platforms right now are portable consoles, cellphones and netbooks which have little power and could make good use of this tech
10/03/2010 at 04:24 Justin says:
Looks terrible, how computationally expensive is collision detection and animation going to be with “unlimited geometry”. Not to mention the hoax factor is at 11. Phantom and OnLive eat your heart out. Really not even post worthy, but apparently an effective troll.
10/03/2010 at 04:27 Batolemaeus says:
So, they’re actually using tools for voxel editing to make their stuff…ho-hum.
I’m interested, since it does seem like a nice improvement on voxel and raytracing/raycasting, somewhat of a blend between them. However, i doubt it will make much of an impact on traditional polygon based rendering.
In my opinion, if they stopped pretending this was some groundbreaking stuff that has never been tried before, they’d gain a lot of credibility. The longer demonstration video goes into a bit more detail (not enough for my taste) and he did admit to rushing out the video and having some issues with their system, so apparently they do have something. Mentioning programmer art as an excuse gives them a thumbs up at least.
However, I’ll wait until they can put some meat on the table. The videos just show a highly detailed voxel world, and that’s just not enough to get me excited.
10/03/2010 at 04:31 Tunips says:
It seems that the good idea here, underneath the questionable mumbojumo, is that this display method would have a fixed computational intensity. So as computers get more powerful, there’ll be more time left over to layer more and more fancy shaders and lighting effects and such, rather than the current GPU race to hurl out more and more polygons.
It does seem like the tomorrow’s tech. One rather suspects it will need the day after’s hardware before it looks as good as yesterday.
10/03/2010 at 05:09 MWoody says:
Why do it on the CPU? Why not do it on the GPU, with something like CUDA?
10/03/2010 at 06:07 namuol says:
The SIMD (single-instruction, many-data) architectures present in modern GPUs aren’t nearly as versatile as the MIMD (multi-instruction, multi-data) architecture of modern (multi-core) CPUs.
Basically, SIMD lets you perform the same (single) operation on a huge list of data (for instance, multiplying sets of two numbers together) all at once, since the GPU has many (hundreds) of little “processors” that perform this specific operation, while MIMD allows you to simultanously perform different operations completely seperately; that is, in an 4-core CPU, you could use one core to do such a multiplication, while the other does division, etc.
While today’s best CPUs only have about a tenth of the number of “processors” as today’s best GPUs, the ability to perform operations independent of others is very valuable, simply because many rendering techniques (including the raytracing/voxel/”point cloud” varieties) involve lots of conditional branching (better known as “if statements” ;) ).
It *is* possible to generate “branchy” SIMD code, but you usually end up with a lot of waste since what happens is that you need to compute the result of each conditional branch at a time, and discard the ones that are irrelevant.
10/03/2010 at 05:18 Tejlgaard says:
I call bullshit too.
Someone above said that you obviously can’t store unlimited points in a computer. No, no you cannot.
He suggested that the points were somehow stored in equations. Well, uhm, yes, how exactly?
Because that’s how polygons work. Equations and vectors signify surfaces, that the rasterizer can then populate with pixels by using textures.
I spent the past hour thinking about this. Let’s say we don’t want unlimited points in a scene. Let’s say, we want a billion. A billion points. And no, you can’t say you want these points to be generated by equations, because you used a _fucking laserscanner_ as he suggests in another video. How are you going to compress that? You’re not. You can’t. The best you can possibly do is to map your points straight to memory addresses, and then have each point defined in relation to a neighbor, which must be the previous point; even if you could do this, that’s _still_ 4-6 bits per point, depending on how clever you are.
Notice, that’s not even storing the colour with the point (this could, arguably, be done by using a texture, weird as that may sound, so that’s no different than normal, but it does count against the infinite detail idea)
So nomatter how you look at it, to get a billion unique points, you need at least 500 megabytes worth of storage in ram. And the storage algorithm I outlined above? it would be very hard to code a search algorithm for.
At the very most, with modern day computers, the upper limit would be 4 billion points. Not unlimited. Well…….
Supposing you mounted one of them SSD’s that cost 5000+$ on your pci express bus, I suppose you’d have the bandwidth to swap in points fast enough that there’s a theoretical upper bound for a pc maybe 1000 times higher. Presuming they wrote a magical logarithmic search function for what’s an otherwise linear data structure, which is what they clain to have done.
But a trillion points is mentioned in the video, and he goes on to say that this stuff has unlimited detail. That’s plainly nonsense. nomatter what or how you do this, they have not written something that supercedes previous experiments run on supercomputers.
And from the looks of the video, they don’t actually render unique points; they render the same points, but from different angles. That’s not unlimited detail, that’s unlimited sameness, and I can do that too. It’s called a for-loop, and it’s how they did the pyramid monkey thingies.
This is not a breakthrough, this is a small time company with a small time owner looking to make a quick buck by being sold to a major player.
10/03/2010 at 06:16 namuol says:
I think the memory requirements could be a lot lower than you predict since there’s a lot of repeating objects (instances) in these scenes.
10/03/2010 at 12:08 Tejlgaard says:
namuol:
That’s exactly the point; repetition does not detail make. I’m talking about unique points in my analysis, since that’s what the video guy is talking about in his comparisons.
These guys undoubtedly have _something_ it just isn’t the something they’re saying it is. What they’re saying is _physically impossible_.
10/03/2010 at 17:37 u335 says:
I think you nailed it, Tejl. And that was my point (haha!) above. You can come up with algorithms to make “unlimited points” and you can find the points you want using a search algorithm…but it seems to me that once you start animating all this stuff you are going to find yourself coming back to polygons (or, at least clumps of points) to make a game that, as others have pointed out, isn’t essentially like Myst — i.e. you want something interactive.
This seems like a longwinded and ’round-yer-ass-to-reach-yer-elbow’ way to reinvent polygons. Which I find fairly unexciting. There may be nifty applications to this point cloud business (embedding point clouds in traditionally animated polygon scenes? — don’t people do that already with particle systems?), but I call bullshit on this reinventing games as we know it…not to mention all the other complaints others have made concerning the professionalism of the video, the rigor with which the technology is described, etc.
12/03/2010 at 12:23 Nesetalis says:
lets say you have object rock.. and object rock was made of points, each referencing object (material type) and object material_type has points in a crystaline shape that reference to atom and atom references to particle… :p
thus.. every rock could render every single atom and every single particle… but the only data you need is a single instance of each particle, each atom, each material used, and then 1 rock with its numerous different points…
for a curious fun.. you could make it so each particle references object rock :P suddenly.. infinite detail….. albeit repetitious.
10/03/2010 at 05:23 nine says:
“We have this revolutionary idea, but those mean old game companies are totally ignoring us!”
This is so obviously a fraudulent or at least delusional product I’m surprised you posted it here.
10/03/2010 at 05:24 Berzee says:
Regardless of the technology, those were some of the most entertaining videos I’ve ever watched. Bruce is a great man!
10/03/2010 at 05:26 Helis says:
My brain. It has exploded.
10/03/2010 at 05:41 Red Avatar says:
Sounds a lot like voxels. Interesting but they leave out some crucial data: how easy will it be to create meshes & textures for this? How practical is the system?
10/03/2010 at 07:07 Jeremy says:
It seems to me that they are saying, theoretically, that textures wouldn’t be necessary. For instance, if you use points to create a brick, then you’re looking at the actual texture of the brick being shaped by the layout of the points. Textures create the illusion of depth and detail, points could, in a way, eliminate the need for illusion and create actual depth. Very cool concept, I would love to see it work out.
10/03/2010 at 10:18 Dan Puzey says:
@Jeremy: can you imagine specifying the variable colours of a brick one voxel at a time? :-)
10/03/2010 at 13:52 RC-1290'Dreadnought' says:
Maybe the ‘texturing’ is done with complex gradients? I think its annoying that they tried to dumb down the explanation. All the technicalities and practicalities are missing.
10/03/2010 at 15:13 Jeremy says:
I’m not saying it’s entirely plausible, just stating their theory :)
10/03/2010 at 16:16 Ian Moriarty says:
I wouldn’t be surprised if the actual asset creation was not unlike using something like zBrush and vertex coloring.
Rather than individually specifying points, sculpting and painting would be somewhat more organic – we certainly don’t specify each pixel point by point now, there’s no expectation that would change.
My concern lies with lighting, animation, reflection and other things not covered by the above video, each of these things has a cost, and is becoming expected as a feature in next-gen games. Also, resolutions in general are increasing, so the 1024×768 is not entirely realistic.
In all, this is interesting, but until they can show that they improve detail without sacrificing *anything* else, they won’t supplant the entrenched companies.
On the plus side, if/once they do, ATI and nVidia will just make their cards accelerate the point based tech, offloading the work from the CPU (which is still necessary – AI, Scripting, etc still want all the CPU they can get.).
~I
10/03/2010 at 17:53 MDevonB says:
@Dan, You can create everything in the regular way, make the mesh, texture the mesh, normal map the mesh, the run it through a program and have that make the the points automatically. Thats how I’d set it up at the very least.
I think I see where they’re going with this, and I guess I need to do a bit more research, because this is hitting me as if it’s raytracing and voxels. Ray tracing to figure out what points are relevant and the colors they display as to the camera, and voxels to store the geometry. Lower powered processor, lower the resolution, lower resolution, less calculations needed. Either way, to alter the point resolution based on your distance is going to require some interesting method to perform well, or you’re going to need a massive amount of RAM.
10/03/2010 at 06:00 TheSombreroKid says:
this is a joke. point cloud data is another phrase for a voxel engine, they don’t talk about shaders or tesselation at all as a competitor to voxels they don’t actually mention thier render method but i suspect it does use some ray tracing at least.
they didn’t explain anything at all they just claimed to be explaining stuff and real computer scientists would have released a paper or been at siggraph or had some credability to back up thier claims and actually use real computer science terms and not make up thier own terms.
10/03/2010 at 06:05 TheSombreroKid says:
oh and the reason nothing moves around and you can’t get reflection is because voxel engines can’t move stuff around without millions of multiplications a frame and voxel engines using the older render methods (i.e. not ray tracing) couldn’t do reflection.
10/03/2010 at 06:10 nate says:
time cube
10/03/2010 at 06:12 captain fitz says:
A lot of these comments are overblown–a lot of people are flat out denying that this is possible or making assertions about things that only the devs could know as if they were facts. Sure, it’s OK to be skeptical and present possible problems, but don’t pretend like you know exactly how it works after you’ve seen a short video which revealed almost nothing really substantial about the process.
10/03/2010 at 08:50 Skurmedel says:
True, but perhaps these amazing technological men of bold claims could actually present something to go on other than weird fractal triangles made up with animals.
10/03/2010 at 12:24 Tejlgaard says:
Oh nono nono – this is not an oppinion. These guys are lying.
As I lined out before, _even if_ you design the most optimal data structure possible, 1 billion unique points (which they’re claiming— infinite detail, remember?) in ram takes up at least 500 megabytes of physical memory, as a _theoretical lower bound_. The only reason they can display a billion dots in those pyramids is because the dots are not unique; they all come from the same model. It’s a parlor trick. Nothing more.
That is not to say that voxels won’t make a comeback at some point…it’s just not now.
10/03/2010 at 06:16 Miles of the Machination says:
Okay, so I see that people have drawn comparisons to other like technology here, but I’m not at all familar with it. The system itself seems very interesting, but the thing that kept bugging me was how it all went together. Are they saying that ever pixel of geometry is going to be mapped using a collection of points? If this is so, then just how would you edit and create content? It sounds like trying to model a NURB with infinite control points, unless these points are generated after the shape is formed. Regardless, I’d like to look a lot more into just how the software is used.
10/03/2010 at 06:22 the_fanciest_of_pants says:
This is a lot further off then 16 months I’ll tell you that much. Before this sort of thing can even have a chance of becoming a mainstream graphics method there needs to be point-cloud modelling software on par with industry standard packages that exist now, otherwise it’ll just go nowhere.
Also the concerns about shaders etc. Anyway, interesting to see a realtime point-cloud simulation running so well.
10/03/2010 at 06:32 Telperion says:
This is very interesting. I’m really looking forward to the software development kit.
10/03/2010 at 06:37 Taillefer says:
I work with point clouds all the time so I found this particularly fascinating. The real advantage here is modelling the real world because you don’t need to do any modelling at all, you just use a laser scanner and it’s done for you. We scan entire buildings and sites, and at the moment we have to convert most of that to polygons because viewing is just too slow otherwise, especially if we’re passing things on to clients and their ancient laptops. There are bigger industries than the games industry that will be interested in this, and after reading up, I’ll let them know!
10/03/2010 at 06:39 The Sombrero Kid says:
The reason people are skeptical is because is because they have no information in their video. There is no doubt that this is a voxel engine though, it likely uses the traditional voxel renderer. The other reason to be skeptical is that they show complete ignorance of the actual issues at play, monolithic rendering, the probelms with moving lighting or shading a set of voxels, the difference or lack thereof between a voxel engine and sub pixel polygon engine, if they’d addressed these issues it’d show an understanding of the concerns of computer scientists in the field as it is they either don’t know about this stuff or they’re trying to hide it.
The whole first half of the video is designed to turn off computer scientists as quickly as possible, why are they trying to sell this tech to people who don’t know what a polygon is? They don’t pick their renderer a programmer does.
I appologise for the quality of my writing I’m on my phone on the bus.
10/03/2010 at 07:50 Hattered says:
@The Sombrero Kid:
From the videos, I’d say they’re just trying to attract investors so they can polish their product and sell out to Big Poly. The whole thing came off as, “They didn’t buy us, but they have to buy us, so they will buy us.” (From the sound of it, putting together that SDK is the last thing in the world they want to do.)
10/03/2010 at 07:58 dantokk says:
Yes, advances in computer graphics tech are usually accompanied by papers in journals, presentations at conferences, live demos. Instead we get a bitchy “Creative Assembly BARRED US FROM PRESENTING OUR TECH TO THEIR BOARD OF DIRECTORS” commentary reel that sounds like it’s pitching for investors. Okaaaaaay then…
10/03/2010 at 07:11 Dave says:
OK: see Publications of Paul Rosenthal, particularly “Image-space Point Cloud Rendering.”
This technology is real, but very immature and not very useful yet.
I expect animation to be a problem.
Remember how, in the old days of 3D, animation was often done with collections of rigid meshes? So you bend your arm, and it hinges from the shoulder and detaches? That was before skinning, where a each vertex in the mesh has some number of weighted attachments to multiple bones (usually 4). This adds say 24 bytes to every vertex, but GPUs can handle skinning a few thousand vertices in their sleep.
To animate with acceptable quality instead of tearing and folding in weird ways, every point in a point cloud will also need to have this sort of skinning. Take that 327,000 point hand from Rosenthal’s paper, and give each point 24 more bytes of bone weight data, and you’ve just added 7.6 megabytes. For a hand. This is data that has to be authored somehow (conversion from a traditionally rigged model, maybe?), and processed every frame.
Animation aside, notice in that paper how the Happy Buddha model ran at 18fps at 1024×1024. Just to draw one single statue, not to animate anything, or run physics or gameplay or audio or background content downloading. This is what those who write graphics papers euphemistically call “real time performance.”
10/03/2010 at 08:22 Gap Gen says:
Yeah, point cloud data can be really big, although it’s possible you’d have lots of compression in there as well. It’s an interesting idea, though I guess I should have read the article before I sat through 4 minutes of someone very slowly and very carefully explaining what a colour is.
10/03/2010 at 07:13 gribbit says:
These people are beating on the wrong drum. If they were screaming about “FULLY DESTRUCTIBLE ENVIRONMENTS!!!” they’d get better buzz. But then, they’re not quite that far along. and. If these guys could show their oh-so-fancy tree getting shot with a railgun, splintering at the point of impact, then tipping over in a heap of broken but still-stiff limbs and free-falling leaves, I’d be reaching for a checkbook and my phone right now.
OK, so this isn’t supposed to be a voxel demo. I know that the point of their technology and these demos is the ray-tracin’ gizmahoochey they’re using for rendering, but the best application of that that kind of tech that I can see is in realistic object manipulation. Games look pretty nice right now, and while I lose a bit of immersion when I look at hexagonal tree trunks and flat sprays of grass, I lose a lot more when my +4
e-peengreatsword or rocket launcher don’t interact realistically with my environment. Even today, most “destructible” things show damage like a Final Fantasy avatar — they’re either perfect, weakened, or dead, plus or minus a couple decals. We had that crap back in Duke Nukem 3d, which wasn’t even running a complete 3d engine (try shooting underneath a flying alien). I’m more-or-less done being impressed by that (and most of it isn’t even as fun as kicking open a fire hydrant to get a drink of water).I want to be able to drill a functional murder hole into a wall in a DM, and I also want to be able to kill a sniper hiding behind an inch of sheet rock with a high-velocity bullet. Heck with custom sprays, I want to carve my name into the stone wall of the enemy base when I’m winning against them. Right now, we’re about two steps shy of being able to make this happen for real. For now, this kind of interactivity only seems to be happening in sandboxy games like Minecraft and Dwarf Fortress, games that games exchange graphics (and even realtime rendering!) for raw performance that gets applied in a variety of ways. If ray-tracing can free up resources that can be used to juggle a larger interactive point cloud in real time, then I’m for ray-tracing.
In short, if they aren’t at least pondering ways of moving, modifying, and deleting their creations in real-time, they’re missing the point IMO. I would take a pretty serious hit in the graphics department for an increase in my control over the environment, regardless of the tech that brings it to my screen.
10/03/2010 at 07:15 cpy says:
I can’t quite put it in my head right now but, this seemed a very early tech video really lacking stuff you’d like to see in games… motion :)
10/03/2010 at 07:47 dantokk says:
If the presentation style didn’t give it away already, this is a complete snowjob. The revolutionary “search algorithm” sounds like handwavy speak for raytracing visibility determination, and that’s about all he reveals. The absence of animation and transparency is telling. There’s nothing new here.
10/03/2010 at 07:59 Grunt says:
I’m enthused by this. Just the existence of an alternative to the monolithic polygon makes me smile and dream happy fluffy dreams. So much potential, delivered by so English an accent.
OBVIOUSLY we need to see more to assess its true potential (and I’d caution those commenters who believe they understand the tech to wait for more as well) but considering that not so long ago we were all praising Outcast’s voxels I think a game based on this tech might be very warmly received. Voxels aren’t the only software trick we’ve apparently abandoned in games as a result of the polygon fetish – perhaps we’ll see a resurgence of those too.
They have a fight on their hands, though. The big GPU manufacturers won’t want their party spoiled by some uppity newcomer looking to take chunks out of their revenue. But I, for one, am bored of the antics of our polygon overlords and look forward to seeing more of this system.
10/03/2010 at 12:39 Tejlgaard says:
*sigh*
Some of us _do_ understand tech, and the claims they make – to be able to do point map simulations on par with the billion and trillion point super computer experiments? to have billions of points? unlimited detail?
They can’t even do 10 billion unique points in less than 5 gigabytes because _noone can_; do the math yourself if you don’t want to take my prior post in this thread seriously. The idea that this would run on a nintendo wii or a DS? ludicrous. Rediculous. Inane.
10/03/2010 at 08:02 medwards says:
http://en.wikipedia.org/wiki/Steorn
That is all.
10/03/2010 at 08:20 Grunt says:
lol, good point but at least UD have made an attempt to demonstrate their technology. The first of many, one would hope.
10/03/2010 at 08:20 Tomo says:
“UNLIMITED DETAIL!”
“UNLIMITED DETAIL!”
“UNLIMITED DETAIL!”
It’s like the Cillit Bang adverts all over again.
“UNLIMITED DETAIL! AND THE POLYGONS ARE GONE!”
10/03/2010 at 08:31 Pessimal says:
For UNLIMITED DETAIL their points would have to be infinitely small.
10/03/2010 at 10:24 Mark O'Brien says:
Their points probably are infinitely small, or at least as small as floating point arithmetic will allow.
Their algorithm probably grabs the closest point to the ideal spot intersected by a particular pixel, so if there are fewer points then those points are effectively “bigger” and if the points are densely packed they are “smaller”.
What they mean is that the amount of processing required does not increase with the amount of detail in the scene. Detail is in practice limited by artist man-hours and by memory, not by processing power.
Still not unlimited, granted. You could make a case though that the technology would allow a developer to include exactly as much detail as they like, and there is something “unlimited” about that.
10/03/2010 at 16:07 solipsistnation says:
Their points are pretty large, actually. Take a look at the first video, when a plant gets close to the camera at about 3:90.
10/03/2010 at 08:31 faelnor says:
I love their picture gallery, all the images there look like the covers of early books about 3D when it was all the rage in 1995. You know, those ugly povray-rendered teapots and columns and skulls and colored palm trees. The future is here!!
10/03/2010 at 08:37 Mark says:
To those complaining about how nothing’s moving: Outcast did voxels with the terrain. I do not mind seeing a return to voxel-based technology even if it’s in a limited role. You CAN have voxels and polygon models on the same screen, y’know.
10/03/2010 at 08:41 Srejv says:
1:45 looks like animation to me. But that’s just me.
10/03/2010 at 08:41 Lobotomist says:
HAHAHA!
GFX cards PWNED!!!!!
10/03/2010 at 08:49 Bobsy says:
Good to hear Tony Blair’s keeping busy.
10/03/2010 at 08:50 Sp4rkR4t says:
Ok, it’s certainly an interesting idea for an engine but it will offload a massive amount of problems to other fields, like I’d like to know just how big was the texture & map data of that city they were flying around in the demo, bet you you couldn’t fit it onto a SSD.
10/03/2010 at 08:58 Dzamir says:
THIS IS RAYTRACINGGGGGGGG!!!!!!!!!
A 30 years old technology is now called REVOLUTIONARY!!!!
10/03/2010 at 09:08 Gap Gen says:
Not really. At least, the website claims it’s distinct from ray tracing.
10/03/2010 at 09:50 Noc says:
I think that’s the point we’re contesting here, Gap Gen.
First, all of the benefits they claim are things they have in common with raytracing. Hell, look at the video above, at 7:40: all of the things they’ve been yammering about through the previous seven and a half minutes are on that list – double hell, it’s even got the word “unlimited” all over it!
And yet, they don’t do anything to explain how their “search algorithm” is not raytracing. Their pitch is basically “Look, see, raytracing is cool, but it’s slow. But you know how searching stuff on, like, Google is really fast? We’re doing that instead.”
This boils down to “Just like raytracing, but faster.” Rendering it down further** gets us “faster raytracing.” Steven Wittens has what sounds like a good guess at how they’re doing it back on the first page. They don’t explain it on the site: instead they go into the “Google is fast, right, guys?” spiel, and then throw out buzzwords (MASS CONNECTED PROCESSING!) and then have the gall to call their system “perfect [and] bug free.”
‘Cause everyone hates bugs, amirite? Well this system is so good it ain’t got none of them either! It’s perfect! Honestly, I was putting all this down to overenthusiasm at first? But the more I look at this whole thing, the funnier it starts to smell.
**I APOLOGIZE FOR NOTHING!
10/03/2010 at 09:56 Insectecutor says:
@Gap Gen: yeah, raycasting is different to raytracing. It’s also not at all new. Remember Comanche?
These guys certainly have an engine and they don’t make any outrageous claims (besides the abuse of the term “unlimited” – I think they’re trying to say that execution speed is bound by screen resolution rather than the size of the data set) but their technology simply isn’t new: it’s been done by loads of people before.
Which leads me to the conclusion that these bastards are trying to make a mint by pulling the wool over the eyes of some clueless investors. The presentation is awful – the tone is condescending, their company logo looks like the cover of a menu from a chinese takeaway restaurant, and their website is a joke.
Their registered business address is a caravan hire business in Caboolture, Australia. The website is the amazing, interactive http://www.dellcaravanhire.com.au. Anyone with a whois tool can check that out.
10/03/2010 at 10:04 Noc says:
I think that’s the point we’re contesting here, Gap Gen.
First, all of the benefits they claim are things they have in common with raytracing. Hell, look at the video above, at 7:40: all of the things they’ve been yammering about through the previous seven and a half minutes are on that list – double hell, it’s even got the word “unlimited” all over it!
And yet, they don’t do anything to explain how their “search algorithm” is not raytracing. Their pitch is basically “Look, see, raytracing is cool, but it’s slow. But you know how searching stuff on, like, Google is really fast? We’re doing that instead.” Apparently the way it actually works is complicated.
(Curiously, Steven Wittens has what sounds like a good stab at how they’re doing it back on the first page, and it’s not even something that’s that hard to explain! It just sounds a lot less mysterious and impressive once you do.)
Anyways, all this boils down to “Just like raytracing, but faster.” Rendering it down further gets us “faster raytracing” which is a very different thing than “not raytracing.”
10/03/2010 at 10:37 Gap Gen says:
Ha, OK. I agree that the video is really slow and annoying, though. I guess if they wanted to advertise to techies, they’d make a video that explained more than what a polygon is.
10/03/2010 at 09:07 RogB says:
all im seeing is detail NOISE. Everything is overbumped and detailed and its just a mess. clever tech for rendering the current fad of over-detailed zbrush muscleymen/demons but the realworld DOES have a lot of flat and angular surfaces. i’d like to see examples of how a point cloud copes with this.
10/03/2010 at 09:20 Helm says:
This looks like a slightly next-gen Ecstatica (and Ecstatica II) for DOS.
I remember things.
10/03/2010 at 16:00 SheffieldSteel says:
If modern graphics cards supported the ellipse as a primitive, in addition to the triangle, we would be a lot closer to efficient realism. In my opinion :-)
10/03/2010 at 09:25 NukeLord says:
They have a graphics engine which can produce UNLIMITED detail? Not even limited by how good my computer is? They’re modelling detail beyond the level of quarks?
Where do I sign?
10/03/2010 at 09:39 Schmung says:
Think everyone else has covered the numerous reasons that this is guff. They’ve only solved one teeny tiny part of a very large puzzle here and shouting about the death of the polygon is not going to help their cause one bit.
10/03/2010 at 09:43 Rand Althor says:
Outcast used Voxels and had reflections.
10/03/2010 at 09:48 neolith says:
Outcast uses a mix of polygons and and voxels. The normals of the polys are used there to calculate the reflections.
10/03/2010 at 09:47 neolith says:
I hate to sound negative, but I don’t see that system replacing polygons any time soon.
While it seems they did manage to create a very, very advanced and highly efficient voxel algorythm, this system still creates a lot of problems that have been solved ages ago with polygons.
1. content creation
Creating polygonal assets and their accompaning files like textures and animations is a highly optimized and rather fast process by now. 3DS max, Maya, XSI and the like have been optimized for over a decade and a half to do just one thing to perfection – let artists create stuff based upon polys with troubling them as little as possible. Setting aside all other possible problems creating stuff based upon point clouds requires a radically different approach in creation. You’d have to make a whole industry start from zero again in terms of learning and working. While that is not impossible it is a pretty big problem.
2. animation
While the video states that animation is not a problem with point cloud data I beg to disagree. Creating believable animation with high poly models (and there albedo and normals on it) can become pretty hard to do properly. If the model is to deform in a believable way, that is. There are certain tricks to use when for example creating an arm that has to bend, so that the polygons intersect each other without screwing the shape of the model or the factor that the maps are stretched. A highly increased amount of data here also highly increases the work for the rigger and the modeler and multiplies their problems.
3. advanced effetcs
The video shows (as far as I can see given the rather bad quality of the video compression) static geometry and a mirroring plane beneath it. The models have basic color and a static sharp shadow assigned as it seems. While I can see that working pretty well I’ll have to ask myself what happens if I actually want to move things around. Since their tech makes it most likely impossible to use blob shadows or shadow maps they’d have to rely on traced shadows. While I can see them making use of their point-for-pixel lookup mechanism for that the very same way they look up the points show on screen, it’ll effectively cut their framerate in half as it is twice the work to do for the engine to look up lit points. Also this reduces shadows to hard shadows.
Transparencey is not possible with their tech as it stands now due to the one point for one pixel approach. So no windows for example.
Shaders based upon normal vectors are not possible as cloud point models have no normals – you need polys for that. This does include any kind of reflection that is not based upon a simple plane. It also includes any kind of advanced lighting as well.
While FSAA can be done by effectively doubling the resolution and scaling the image down to the actual pixels this approach quadruples the amount of time the lookup has to take plus the time for the rescale.
DOF is only possible as a post effect. This approach eats quit a lot processing power.
What about billboard graphics, for example for particle systems? IMO not possible for this kind of engine, too.
What about animated textures (panning stuff for example)? They are hard to do with voxel engines.
What about physics? You need polys to even calculate basic intersections.
I am sure, I’ll stumble on more stuff the more time I am giving thinking about this tech.
Again, I really do admire what they have achieved so far, but IMO is trying to replace polygonal engines with it the completely wrong way. Rather than replacing the polygons I see this tech being integrated into ordinary engines to take care of stuff that causes them slowdowns. Creating clouds, mist, rendering grass on a plane etc.
They also might have a really bright future in fields that rely on point data and its visualization. Medicine or geodata for example. But replacing polygons? No way IMO, especially not in the next fewe years.
10/03/2010 at 10:10 the wiseass says:
How does this technology have a future?
Raytracing can do all this and better and is already supported by the industry with Intel octocores running real-time tracing applications at efficient speeds and nvidia supporting raytracing on their GPUs with their OptiX engine.
But yeah, I’d like to see these guys succeed as it would put an end to the every growing hardware race in games.
10/03/2010 at 10:41 Rich says:
Can’t help looking at that and thinking it’s what Outcast should’ve looked like.
10/03/2010 at 10:41 wat says:
Look, it’s voxels. What a blast from the past.
Also, it still uses floating point operations, so it’ll still need 3D cards – Only that the slow change from dedicated 3D cards to GPGPUs will open up the market for different rendering methods.
10/03/2010 at 10:43 Watch the Second Video says:
Taken verbatim from the second video, addressing the oft-repeated concern about how objects would be created in their software. I believe, if what he says is accurate, that an industry-wide revamp of content-creation software would not be necessary, as neolith states above:
—————————————————————————————
“…so how would we use unlimited detail? Well, there’s two ways to import graphics: you can either laser-scan them in. We haven’t actually done that yet, but we know that laser-scanners produce point-cloud data and we run unlimited point-cloud data. The other way is to build your polygon objects at the highest-settings, as though you are building them for movies, and then you can just do a “convert” to point-cloud x-y-zed color property and you can import unlimited polygons directly into Unlimited Detail. We haven’t done that yet either, we’ve been working with direct voxel-editors…”
10/03/2010 at 11:41 neolith says:
Sure, you could convert your polygonal data to be voxels. But why do that in the first place? It doesn’t increase detail at all, it just increases the work you have to put into it.
10/03/2010 at 10:48 Stitched says:
1) Don’t use cheesy midi Mozart tunes in the background of your tech-demo. It’s grating, distracting, and unnecessary. The tech should speak for itself, usually.
“(Before the ‘but that looks rubbish’ comments arrive – the reason Unlimited Detail give for the stuff they’re showing looking a little rustic is that the artwork is created by programmers, not artists.)”
2) And that is exactly the problem. Who is this demo for? Other programmers or artists?
When creating tech that affects how art content is created, hire ARTISTS to build the demo with the tools you have. These are the people responsible for creating the content using YOUR engine technology. Programmers, while the involved in implemention of the technology, are not. (The colour palette you chose is blah, the content you created is blah, the presentation – also blah.)
Someone mentioned, already, animation. I agree, there are some very REAL questions concerning character creation:
Theoretically, you could point cloud capture a character like Alex Vance, but how do you get the textures?
How does a skeleton work to bind/deform/transform this information in space?
How does a modeller create models using this “method”?
While it may processor-light, is content creation process-light? (meaning creating content, with your technology is FASTER than current methodologies). While it may display and be more efficient in your engine, if getting there is a HUGE pain in the ass, this is not something to gloss over and has real production costs; in terms of manpower and time (another way of saying money).
If the point-cloud data technology is fairly old (voxels are something from the 90′s), how come no one has ever done this before until now; almost 20 years later ? I remain skeptical in that we are not getting the full picture.
I think that given this over the DX11 adaptive tesselation technology, I think that we are more likely to head toward adaptive tesselation.
10/03/2010 at 11:12 Insectecutor says:
Done some research on this Bruce Dell chappie. His linkedin profile says he’s been CEO of Unlimited Detail since 1995, meaning he founded the business at the ripe age of twelve years old judging by his school record. His website’s technical contact is his dad’s caravan rental company, Dell T & L.
I wonder why RPS took this seriously. I back down on my previous assertion that he’s trying to be sneaky or sell snake oil, it looks to me like he’s simply arrogant and ignorant enough to believe he’s the first guy to have achieved this. Perhaps he secretly knows others have done it, but thinks approaching it in a different direction makes his method somehow better. Either way it’s safe to ignore it. Atomontage are much more convincing.
10/03/2010 at 11:37 stahlwerk says:
I’m a little hesistant to call it a voxel-based process. Attention
Voxels, like pixels in 2d, have an implicit position, meaning you have a data structure with exactly x times y times z entries (e.g. in Medical Imaging this value is the density of the tissue at that position). Traversing and rendering this volume data set via raycasting, especially with sensible shading and even self-shadowing is still somewhat of a moving target in research. Most imaging software uses the gradient (difference of value between neighbouring voxels) to recreate iso-surfaces, for example with the “moving cubes”-algorithm, which brings the problem back to polygonal surfaces, which can then be blended by standard graphics card hardware.
This tech however seems to be based on a point data-structure. Each Entry has a coordinate, a normal direction (for shading), a size and a color. This is actually a very common data structure in 3d scanning, the main problem being identifying and matching points from differrent scans to determine the parameters.
To render a point based data structure is totally trivial, especially on graphics hardware (glBegin(GL_POINTS)… go nuts!). To do so fast is totally non-trivial, because to render something fast you have to determine what NOT to render, and do that faster than rendering would take..
So, to speed up that determination stage, space partitioning algorithms (KD-Trees, Octrees etc.) are typically used, which drastically reduce searching time. With that gain comes increased preprocessing time, which damns you to a more or less static scene (a point may move inside its partition, but not cross over into another one), lest you can rebuild your tree on every frame. This process is used for “conventional” ray-tracing methods (speeding up the expensive ray vs. polygon hit detection).
In a point-based data structure (cheap ray vs. sphere hit detection), you can get a little fancier than that. My bet is “Unlimited Detail” is a hybrid approach. they use a graph based search algorithm (of which there are numerous, the ANN-library for example) or similar to determine the nearest points with normals towards the camera, and then they use a space partitioning algorithm (on the fly, perhaps) to determine the nearest pixel-ray vs. point hits.
You actually can’t do this computation on the GPU effectively, because each step would potentially need to access the whole Data structure information. Also, every byte of cache on the CPU is a god-send for algorithms like this. Fermi may change all that, however.
10/03/2010 at 11:41 terry says:
Switched off when the voiceover said “INFINITE DETAIL” in the same tone that that one guy said “MASSIVE DAMAGE” when attacking next-gen crabs at E3.
10/03/2010 at 11:50 gentk says:
Looks like they are just hunting for funds, with no real feasible tech yet…
Also most of the stuff there is instanced objects?
In 3d rendering,specifically raytracing, rendering instanced objects, say 1000x 1millionPoly objects, is much much much faster (practically just minutes longer than rendering that one object) than rendering the same polycount/detail for different non instanced objects.
I smell BS on this. the fact that all of their scenes were just filled with instances of a few objects shows that it wouldn’t be able to do anything remotely useful with a production scene.
10/03/2010 at 12:21 The Sombrero Kid says:
after reading steven wittens description, i agree that’s probably what’s going on, i think we will eventually move to technology which has some things in common with this implementation, specifically fast ray tracing and sparse octtrees that compliment conventionally modelled data. terrain is and has always been a good candidate for voxels and graphical effects are a good candidate for a sparse octree shader implementation.
10/03/2010 at 12:35 eot says:
Doesn’t look too different from something like this:
http://www.youtube.com/watch?v=Zl9CiGJiZuc&feature=related
10/03/2010 at 12:49 AngryAnt says:
Say the tech is real, try for a moment to imagine data sizes on models made for this system.
For each “unlimited” point, you’d need to store xyz,colour,property (according to the video). You’ll likely be able to get around storing xyz for all points with some clever algorithmic work, but still.
10/03/2010 at 13:31 Tejlgaard says:
I already described an algorithm for that, but your analysis is correct. Though colour can just as easily be stored in a map, and as I said earlier, you could probably get down to a lower bound of 4 bits pr. point if you’re really stingy.
But even at half a byte pr. point, which is _extremely_ lenient, the space for anything that can reasonably be called “unlimited” detail is too much. Hard drives need to have all the properties of a pci express mounted super ssd, and many, many gigabytes worth of space to talk of unlimited detail in even a single crysis map.
10/03/2010 at 13:18 The Sombrero Kid says:
http://www.youtube.com/watch?v=VpEpAFGplnI&NR=1&feature=fvwp
this is worth taking seriously and is likely the future of this kind of tech.
10/03/2010 at 13:28 Insectecutor says:
The seductive cooings of the girl in the music combined with that horrifically disfigured brown spiky bondage troll makes this video unsettling.
10/03/2010 at 13:59 neolith says:
There is already Software out there using siumilar approaches. 3D Coat for example uses voxels for freeform and detail modeling with a quality compareable to Mudbox or ZBrush.
I must say though that I don’t see this being used as a part of some realtime engine for games. I reckon it is the next step for modeling applications though.
10/03/2010 at 15:52 The Sombrero Kid says:
this is going to be in games, this is id tech 6, it’s the concepts of megatexturing applied to geometry.
10/03/2010 at 18:46 neolith says:
How are voxels linked to the megatexture tech?
10/03/2010 at 21:42 TheSombreroKid says:
megatexturing is about virtualising textures so that a device can load the texture to whatever resolution it can handle at varying distances, continuous, seemless lod, this is sparse octtree voxel engine that will make up id tech 6 is designed so that they can have that continuos lod on the geometry as well as the textures.
11/03/2010 at 18:06 u335 says:
This paper is explaining the tech (I think) that Sombrero Kid posted. Hell if I can understand it, though. Can anyone give a non-programmer like myself a description of this any how it is different from what Dell was explaining in his horrible vid?
http://s08.idav.ucdavis.edu/olick-current-and-next-generation-parallelism-in-games.pdf
10/03/2010 at 14:06 Spd from Russia says:
Wrong on so many levels. You dont need unlimited geometry, you need realistic lighting and surface shaders much more that another mill of polys.
10/03/2010 at 15:19 Mario Figueiredo says:
Bingo!
10/03/2010 at 16:24 Urthman says:
Yes, exactly. My computer can process polygons in effectively unlimited detail, as far as my eye can tell, as long as it doesn’t have to do realistic lighting. It’s the lighting that sucks up all the computer power these days. Most of the difference between the high and low settings on Crysis is the lighting.
10/03/2010 at 14:46 meeper says:
What’s the content generation pipeline looking like? 16 months may be just a tad optimistic if the pipeline is radically different from current methods.
10/03/2010 at 15:27 Bobo says:
More Engines similar to this one are under construction, I know this one – seems to be quite final these days:
http://atomontage.com
10/03/2010 at 15:37 SheffieldSteel says:
I’ve been saying (for a depressing number of years now) that we need to be drawing something better than triangles, and as video cards have got more and more advanced it is getting harder and harder to break away from that model.
So I’d really like to believe that this is groundbreaking, and showing us the way to the Next Big Thing.
But.
If this is really a revolutionary search algorithm that brings the previously unattainable within reach, then show me the patent. Really, if it is new technology then it must be patented as soon as possible… which will make the algorithm available for other engineers (/me waves) to look at.
More likely, what they’ve done is put a lot of work into optimising both their search algorithm and their data structures. And that, I think, is where the problem lies. A data structure that’s optimised for fast searches is generally not optimised for quick and easy addition/removal of data, nor for sorting – the key operations that games programmers need if the engine is to display a dynamic world, as opposed to the static world shown here.
Others have already commented on the other basic game technologies (lighting, transparency, animation) that this demonstration fails to demonstrate, so I’ll leave it there.
10/03/2010 at 16:01 stahlwerk says:
I feel much in the same way, although frankly I’d rather like to see a conference paper than a patent. What I came to accept though is that the triangle-based graphics pipelines are “here” and “fast and good enough”, and therefore will be universally used for games until something more efficient will come along. In a few years we will be able to simulate, rig and fake polygon based, interactive cgi into photorealistic territory. Especially the developments in Global Illumination and screen space Ambient Occlusion are extremely promising (e.g. see the crytek siggraph entries).
Also, as has been noted already, online tesselation may lead to infinite detail as well. If one goes to the trouble of reinventing the wheel as a set of points, why not describe it as a set of general mathematical primitives and combine them with boolean operations? Find a way to tesselate that efficiently et voila: unlimited detail for the insanely fast current GPUs.
If he, instead of being smug and vague, had at least hinted at the interactive properties of his (their?) engine in the video, I may have been more optimistic about it. As it stands I’m not yet willing to wear the “ATI & NV are after my bodyfluids” tinfoil hat.
10/03/2010 at 16:15 Taillefer says:
The games application of it doesn’t interest me that much at the moment. But smooth navigation of unlimited points is certainly something my company could use.
I wander if we’ll ever have procedurally generated clouds. Hmm.
10/03/2010 at 17:50 ddd says:
Actually you can do something similar, less complex and more standard with DX11′s tessellation.
Voxels are a non-sense.
12/03/2010 at 22:40 namuol says:
Define “less complex”.
I don’t believe you appreciate the complexity involved when a GPU compiles a shader on the fly and begins to execute it… this runs in software, and solves dozens of problems that would each have to be implemented in separate shaders (or more likely, one nightmarishly-large shader) that would both perform and *behave* differently across GPUs, despite being written in something “standard” like DX11.
10/03/2010 at 18:24 Mike Arthur says:
The Reddit comment thread about this has some decent explanation by people that actually know what they are talking about with this technology:
http://www.reddit.com/r/gaming/comments/bbg9c/
This post explains a bit more about it:
http://anteru.net/2008/07/25/242/
Here’s a non-vapourware version with a paper so you can read about how a similar result was achieved:
http://artis.imag.fr/Publications/2009/CNLE09/
10/03/2010 at 18:32 Mike Arthur says:
My CG researcher friend pointed me to this:
http://www.youtube.com/watch?v=Bz7AukqqaDQ
This is far more impressive, I’d said, and uses voxels. Pretty amazing.
12/03/2010 at 22:56 namuol says:
@Mike Arthur:
Lightstage 5 (or any version, for that matter) is very impressive indeed, but it’s not really related to the rendering techniques presented by “Unlimited Detail”… the fact that they use voxels is kinda unrelated to the quality you see in that video.
That being said… if you want your mind blown, watch some of the videos on Paul Debevec’s (Lighstage researcher) website: http://www.debevec.org/
This is LightStage version 1.0: http://www.debevec.org/Research/LS/
Watch the video, it explains how it works pretty well. Also, play with the (windows only) demo!
10/03/2010 at 18:50 jon_hill987 says:
Most. condescending. video. ever.
10/03/2010 at 19:08 Ed says:
I’d like to reiterate previous comments, specifically “Steorn” and “Time Cube”.
Might also want to add OnLive to that list. It’s a scam, or at the very kindest, useless in practical terms.
10/03/2010 at 22:58 PHeMoX says:
It’s about freaking time we’d abandon poly-goons.
I wanted the return of the voxel engines, but this sounds a whole lot better.
Search algorithms also take time though, so I think it’s still bound to how complicated a certain scene really is.
However, literally showing it on screen will cost less power.
It does sound very revolutionary to me.
10/03/2010 at 23:02 PHeMoX says:
If I understand the Google algorithm properly, there’s a whole lot of pre-indexed search results to speed up things. I can imagine they will use a similar approach to deal with the bigger issues, like out of range points in comparison to points on the opposite side of a level that can never be seen in the same view.
Yeah, this got me genuinely excited.
10/03/2010 at 23:33 Mathieu says:
Seems that this video was made a couple of years ago.
This thread link to an article posted in 2008.
http://forum.beyond3d.com/showthread.php?t=47405
Note that they’re 3 posts by Bruce Dell on this thread.
The domain name unlimiteddetailtechnology.com was created 6 months ago, this may point out that they’re still on business…
11/03/2010 at 00:46 u335 says:
Oh wow. The guy alleging to be Dell in that thread is asking what a memory cache is….
11/03/2010 at 15:53 PHeMoX says:
Doubt that guy is Dell… quite unbelievable.
11/03/2010 at 01:42 Tim says:
Why is he trying to pitch this in laymen terms instead of directly to graphics programmers?
If it’s so good, they should publish a paper on it and get it peer reviewed.
I find it hard to believe that nvidia or ati, would tell them to go away unless they were selling pseudo science. They’d jump at the chance for a edge over the competition.
And man.. what an annoying lecture.
11/03/2010 at 01:50 KillahMate says:
Yeah, this is a scam. Here’s another link for you, note that Dell himself posts a few comments in the thread, saying how they’re just about to go sell their tech. Then note the dates. April of 2008.
Yup. Scam. Old one, actually.
11/03/2010 at 16:11 PHeMoX says:
That’s actually not quite true, there’s been talk before April 2008 about this.
Whether scam or not, I think you might be onto something there as it does sound technically revolutionary.
Search algorithms also take time and also depend on resources, so I’m quite skeptical.
The whole idea does sound a lot like some kind of LOD, where polygons are split into 3D atoms. Doesn’t this mean there are now millions more individual ‘polygons’ on screen that need to be calculated anyway?
Somehow the idea sounds odd, even though I do understand the voxel rendering concept.
11/03/2010 at 07:52 pbutt77 says:
Well we should hope this is halfway true atleast. If we could integrate it with the current way graphics card do things…it could take a huge workload off gpu and cpu possibly. I agree animation, lighting an ect seem questionable. But what if we use this only for the stationary scenery and objects and let gpu/cpu handle the rest. The synergy between all of this technology could be exactly what we need to free us from visual limitations and push us pass the borders of our creativity. Developer cost would drop, everybody would still have their jobs, deadlines would be less of an issue hopefully and that means more free time to focus on quality and quanitity as the only bi-product! zzzz….oh sorry, just woke up!…thats was one hell of a dream!
11/03/2010 at 11:02 adam says:
It’s point cloud DATA, not point cloud DARTAR.
Accents are funny.
11/03/2010 at 12:35 Derek Smart says:
I remember when 3D graphics were first announced for video games, some of the comments here are worse than those – but thats only because people progressively grow up to be complete idiots.
As someone who has worked with 3D graphics for decades and have written many a graphics engine, I can flat tell you that the concept of image space point cloud rendering has been around for quite sometime and like voxels, has its own limitations. In fact, voxels are FAR more practical even with their own limitations.
While the tech is not far fetched, we’re just not there yet because the computing power that will make it practical for games will arrive long after most of us are dead and gone. I’m 47 and plan to live to be a 100 if I have anything to do with it.
Even so, point cloud rendering is not going to replace 3D cards because all the computing power needed can still be off-loaded to an add-in card and thus leaving the cpu un-touched. In fact, there is nothing preventing the card manufacturers from putting another PCR dedicated chip on the PCB specifically for use with PCR data.
In the short term, I can see PCR being used in specialist areas (genetics, DNA modeling, atmospheric modeling etc) on systems with specialist computing HW. As long as they don’t go the destined-to-fail route at PhysX-on-a-chip route, it should be OK.
This presentation just strikes me as being a bit off. When something as ground breaking as this appears, it is usually through professional graphics channels, peer review, White papers etc. This presentation is geared at folks who play with Crayons, not us developers who actually have an inkling as to wtf they’re actually talking about.
Quite clearly they’re looking for funding. I remember how the PhysX guys started out. Guess how that ended.
12/03/2010 at 01:46 The Snee says:
If I remember correctly, the original Delta Force used voxel based technology for its terrain, and polys for all the other objects.
12/03/2010 at 03:08 Rugged Malone says:
A coworker linked that video to me today and I assumed it was a joke.
As a developer I call snake oil / bullshit. Nothing the narrator mentions is at all novel, and nothing of any substance is demonstrated. It sounds like someone trying to hook clueless investors to be honest.
Not to mention, if you’re trying to convince people that you have come up with something faster and prettier, you aren’t helping your cause any by showing a video full of ugliness and choppiness.
12/03/2010 at 03:39 remover says:
”
Not to mention, if you’re trying to convince people that you have come up with something faster and prettier, you aren’t helping your cause any by showing a video full of ugliness and choppiness.”
I forgot that flash-player youtube captures are an accurate reference point for visual technique!
12/03/2010 at 07:52 KillahMate says:
But that’s exactly the point. I think most folks here agree that the tech they’re demonstrating is feasible, it’s simply the way they’re presenting it that whiffs of scam. They imply that they’ve resolved some or most of the problems/limitations of PCR, but show nothing of the sort, we only see things we’ve already seen before.
As you say, PCR has its uses, but they present it as some grand panacea, in a presentation very sketchy with details no less. My favourite part is in their FAQ, they have a section titled simply “How does it work?”. That got my hopes up. But the answer then goes “Imagine I send you to find me a book in a library. The library is very large…” and etc, in a short “Indexing for Dummies” parable. At no point does it mention or compare with any known algorithm, or anything any graphics enthusiast (not even necessarily graphics programmer), or in fact search engine programmer would know about. They give us nothing except grand promises and vague explanations. If they had presented themselves more straightforwardly they might have inspired more trust.
12/03/2010 at 07:53 KillahMate says:
That was a reply to Derek Smart, by the way. The commenting system is utterly borked.
13/03/2010 at 01:16 namuol says:
Precisely what I was thinking, KillahMate. This sort of tech has been demonstrated before… if they’ve been trying to sell this since 2008, it’s no surprise they haven’t gotten anywhere; most people who sleep on a mound of moneybags have a consultant or two.
16/03/2010 at 21:15 Zecc says:
It should be at least a year old now. See this forum post:
http://www.somedude.net/gamemonkey/forum/viewtopic.php?f=12&t=419&sid=17111f9b43feb101fd9e7ca59ec1ad6a
16/03/2010 at 22:12 Kyle Klouzal says:
If you had an algorythm that computed an unlimited amount of points, then the algorythm would run for an unlimited amount of time(lol) Then if you had another algorythm to search through those unlimited amount of points you would be searching forever because the points are an unlimited number! THUS they would have to set a finite limit on the amount of points therefor not unlimited detail. :O And a cellphone to compute such a feat? hah! yeah right.
18/03/2010 at 06:41 Flying dutchman says:
This sounds nice, but…
It’s no problem for a 3D engine to show round objects in great detail. The flopped game Republic had a novel graphics engine that allowed you to zoom in on anything without losing detail. Well, up to an impressive point. The trees did have individual leaves for instance and were not bumpmaps or low poly models. A vase didn’t look like a hexagon. The videos immediately reminded me of Republik.
There must be a reason why manufacturers did not adopt technologies like this. I bet it has to do with gaming speed, interaction and the speed of building worlds.
As for the claimed 20% increase in polygon counts, that’s not the whole story. Memory becomes better, processing power becomes better, DirectX/OpenGL becomes better. GPU’s follow Moore’s Law and double in power every 16-19 months. Proof of concept demos already show very realistic graphics.
19/03/2010 at 14:31 Doggy says:
I did a little background research, because as many people have noticed there is something off about the whole thing.
This is what I found:
1) Bruce Dell didn’t know what a CPU cache was.
2) The website is registered to an address that sells caravans in Australia.
3) Lack of any sort of specific information or realtime demonstrations
(I left the links at home but I can find them again if necessary).
My thoughts on how it could work:
1) There’s a huge grid of points containing all graphical details (no, it’s not unlimited it’s just big)
2) Datastructures are built from the ‘point cloud’ that allow it to be rendered from arbitrary angles and distances more efficiently then raytracing through a huge cube of data.
My problems with this are memory consumption and CPU usage.
The screenshots with the thousands of blue animals were said to be in a single pointcloud.
The resolution of this would have to be more than tens of thousands.
10000x10000x10000 x (size of a single point) would be the uncompressed amount of data to store this, which is not feasible on modern computers. Add to this the datastructure that would optimise drawing speed and it’s taking up ridiculous amounts of memory.
29/03/2010 at 15:06 Plusfours says:
Gulag (mar 10)
Virtual dirt can be modelled effectively in finite element simulation packages. Either by a deformable network of balls connected by springs (implicit modelling), or by a pile of objects that have some affinity for each other (smooth particle hydrodynamics) The first type is used effectively for things that bend but don’t smash, the second for things that smash or slide or flow.
http://en.wikipedia.org/wiki/Finite_element_method
http://en.wikipedia.org/wiki/Smoothed-particle_hydrodynamics
13/04/2010 at 09:47 Johnny says:
If it had any plausibility, Intel would be all over this like a rash. Ipso facto I call BS.
13/04/2010 at 18:24 VoxelKing says:
The underlying technology is related to something called “sparse voxel octrees”, which aren’t anything incredibly amazing. What the video doesn’t tell you is that these are not at all suited for things that need to be animated, so they’re of limited use for anything that uses procedural animation (e.g., all ragdoll physics, etc.). So they’re very inflexible. You can get great detail, but you get it in a completely static world.
A rough summary of where things stand with this technology in mainstream games is here:
http://mainroach.blogspot.com/2009/01/sparse-voxel-octrees.html.
You will also want to check out Samuli Laine’s work; he’s a Finnish researcher who is focusing a great deal of his attention on this subject and is unlocking some of the secrets to implementing it well.
http://www.tml.tkk.fi/~samuli/
13/04/2010 at 18:45 VoxelKing says:
unlimited does not mean “unfinite” thats a wrong interpretation. They just mean the engine dont put limits on the grahic-designer / worldbuilder, like polygon games where you need to rebuild the same gameobject in different polycounts depending on viewing distance.
They also claim to have been working on this for over 15 years and to have been started this as an hobby – so its not just out of the blue, but still it needs a demo to be prooven right.
Interview on Facebook:
http://www.facebook.com/topic.php?uid=105528666147262&topic=15&_fb_noscript=1
24/04/2010 at 18:58 Mike Talyor says:
I highly doubt this would eliminate the need for graphics cards. The process they are describing would perform best with a massively parallel processor. Ideally one “core” to search for and process the data for each pixel. Fortunately we have massively parallel processors – they are called GPUs or graphics cards. Just instead of processing lots of polygons, they would be used for lots of pixels. While this process may be possible to run in software like they are claiming in their tech demo, once you add proper shadows, reflects, etc. to make the game look half way decent you are going to still need a powerful multiprocessor GPU to pull it off well.
10/06/2010 at 19:29 JustaName says:
@ Seol,
I don’t think it’s rubbish. When it comes to efficiency, a properly distributed database is ridiculously fast. I mean, hell- forget databases. Think filesystems for a second. ZFS, ResierFS, Ext3, NTFS, etc. Btrees.
The way that efficiency has evolved with those (outside of obvious things such as journalling) are the pointers and methodology of inodes and similar technologies. If you are compare ext2 to ext4 there is a huge leap in performance.
This is no different. DX11 is heavy on resources to begin with, even though it provides a lot of great ‘functionality’ and the like. If meta data can be accumulated through a sparse distributed database and be directly relevant to 3d information that is thrown about in application, then unlimited detail is indeed viable.
As per the grid comment, it also looks like a test to prove instancing is possible. I haven’t seen the video in some time mind you, so I can’t recall what the author (or voice at least) was trying to point out.