Not sure. It's much simpler to figure it out than it is to program it in some usable form. You'd probably start like that 2.5yo claydoo engine he had.
Major questions I have are:
1. If the atoms are really quads/tris how does he draws them when they're big enough to be more than a single pixel?
2. Still part of question 1; If he draws a quad on screen when really up close, which can save some engine time, how does he decide when to draw another quad that may be on front of that one. Is there some sort of z-buffer too?
3. How does his instancing works? That's one of the major points there, because that scene in the demo only works because he has thousands of instances of the same thing.
Alright, but, I'm still confused as to how the data in the object is arranged?
I don't know either, but I think it is probably organized in:
points -> tris -> quads -> atom
Atoms probably have only the following data:
position, radius, color, quad pointer
So, at a certain distance, you know the radius will only fill up a pixel at most, so you -don't- have to look at the polygons to render that pixel. Only really close up images or low resolution objects would require you to look at the polygon. Which is the complete inverse of how our 3d graphics work right now.
Which brings me to another question, how does he anti-aliases it when several atoms could fit in a single pixel? Does he interpolate the color or just pick the most relevant atom? The way he speaks about it makes it sound like it only picks a single atom to fill the pixel, but I think that would create noise and possibly too sharp images.