Actually, when playing a game for example, your GPU has to potentially touch millions of polygons as well: It is transforming them from world space to screen space (aka perspective projection). And it can cope with that load easily because it doesn't alter the initial mesh - it computes temporary screen positions. I do the same: Every voxel is transformed and *drawn* at the correct screen position. The original voxel model isn't altered.
It's even easier than that. All you need to do is to transform the ray with the inverse transform of your voxel model. This will give you rigid transformations and non-rigid transformations that preserve distance-relations (like scaling). However, this approach wouldn't work for skinning since it breaks the parent-child node relationship.
Could you rotate voxel objects by represent them with bounding boxes on the map so that rays cast by the renderer or physical interactions hit the box they enter a separate, off map static octree at the same angle they hit the bounding box? You could do a robot with several bounding boxes but animals would be allot harder. Maybe deflect a based on its proximity to skeleton points or distorted boxes?
This is awesome. Thank you so much for explaining how sparse voxel octrees work in and understandable way. I couldn't find anything helpful on Google. So this was great, not to mention incredible!
@buzinaocara In theory it would. But I restore the octree property (all child nodes lie completely inside their parent node) by stretching the voxels/enlarging their bounding boxes. Though this doesn't break the algorithms you mentioned, it makes them more costly (for example a bigger BB means more ray hits => less optimization potential). This issue is also covered in part 3/3.
One thing to remember is that you could store a depth value on the rendered result and draw anything you like over (or between) that like 2d sprites, better if it's all the same but to be fair polygon games use raster graphics etc still. Might be a bit more difficult with a compressed style of tree though.
With a non rigid transformation, like skinning or maybe a cubic space deformer, you would basically have a curve instead of a straight ray, right? But since you still would be stepping along a curved ray in an axis aligned octree, this maybe would only add a constant costs to the raytracing. Could this work? You know any papers about raytracing and deformers? Also, Voxels might allow "mpeg 3D video" like animations. Anyway just thinking out loud, thanks for the great videos!
For skinning, I think the problem is the derivation of the curve. Even with primary rays, you first have to determine what voxels are visible to the eye to determine their bone influence and arrive at a matrix transform for the visible voxels (could be more than one per pixel if the voxels are transparent) in order to trace a spline through them. So you would have already done the prerequisite work to draw the skinned voxels in order to find the curve to march through them, and that's also view dependent. I think the idea of tracing curves instead of rays is an interesting one for interesting camera effects, although you might have problems with the curves missing important features in the scene leading to gaps and more noise in the resulting pixels unless you trace something like a curved cone through the segments you march or use many jittered sample curves per pixel (similar to raytraced DOF).
This is good work... you have essentially a point-based renderer using octree as bounding volume hierarchy. A sphere tree might have been used instead to circumvent the rotation problem (not to take anything away from your solution, which is very nice). See also "ManyLoDs: Parallel Many-View Level-of-Detail Selection for Real-Time Global Illumination" which discusses a sphere-tree-based point renderer.
You actually can rotate entire models (by model, I mean a tree) in world space. Rotating individual parts like limbs within a single model (in local space) get a bit tricky, however.
Interesting stuff. I think this can be made even more efficient by rendering the animated SVO using discrete raytracing by transforming the camera rather than the voxels themselves...
You determine the center point of every voxel. Does it mean, that it is rather a pointcloud then? Becouse you need the position of the voxels individually? Thanks!
1) Voxels are not memory efficiant. When you say something stupid like 1 bit per voxel, that does not contain color, or normal, or texture information. Once you add that, BAM your out of memory. 2) i dont know about that 3) LOD such as octree can be applied to triangles, so this is not a advantage of voxels 4) streaming has nothing to do with voxels vs triangles, so this is not a advantage of voxels 5) voxels only have color, no texture, so texturing is a disadvantage of voxels.
Less noticeably so the higher the resolution from a practical POV. Displacing low-res pixel art in Photoshop is definitely going to mess it up very visibly, but not ultra-high res (say 100,000x100,000 pixel image) even with nearest neighbor sampling unless we zoom in way close.
How can you animate multiple rigged models containing potentially millions of voxels using this technique? That would mean you have to apply a rotation matrix to every single one of those millions of voxels. Unless you can offload that to the GPU (and even then it would struggle) I don't see how this is really effective.
Since it's done at render time per-pixel or per-ray while traversing the octree, you don't have to drill down to the leaf voxels of every single character in the scene, only the ones that are visible and with LOD which allows you to stop traversal prematurely without going all the way to the leaves (unless we're really zoomed in to a particular voxel). So the cost is more relative to how many pixels to render, or how many rays being cast, not how many characters or voxels there are in the scene. As an example, suppose you have a 2D 100,000x100,000px image (10 billion pixels) represented using a sprase pixel quadtree, and you want to apply a brightness filter to the pixels on the fly. You don't have to apply it to all 10 billion pixels or even close at any given frame, since if you're zoomed in close to the image, you only have to apply it to the pixels which are visible inside the viewport (say the viewport is 1024x1024, in which case you only have to apply it to a million pixels and not all 10 billion). If you are zoomed way out, you still only have to apply it to a small number of pixels, since you only have to draw from the lowest-resolution mips of your sparse quadtree. So the cost here is not so proportional to the full resolution of your 10 billion pixel image, but the resolution of the viewport looking at a section of it.
So this method offloads the work of transforming each voxel to the GPU? But if a regular game has millions of polygons, then a voxel engine replicating the same game world could contain billions of voxels. I think voxel engines are great but much more processing power is required to make them suitable for high resolution, large scale game worlds.
This is so stupid. Scaling the voxels to fill the gaps is a horrible soloution. This will break rendering optomizations that expect voxels to have a constant size, and orientation. You re-invented the wheel, and now its jagged, and blocky. Your wasting your life playing with cubes, when the rest of the world is rendering triangles at rates you will never, ever achieve with voxels.
This is awesome. Thank you so much for explaining how sparse voxel octrees work in and understandable way. I couldn't find anything helpful on Google. So this was great, not to mention incredible!
![Noob To Max With DRAGON REWORK In Blox Fruits [FULL MOVIE]](http://i.ytimg.com/vi/LnBMOinoOvA/mqdefault.jpg)
Actually, when playing a game for example, your GPU has to potentially touch millions of polygons as well: It is transforming them from world space to screen space (aka perspective projection). And it can cope with that load easily because it doesn't alter the initial mesh - it computes temporary screen positions. I do the same: Every voxel is transformed and *drawn* at the correct screen position. The original voxel model isn't altered.
It's even easier than that. All you need to do is to transform the ray with the inverse transform of your voxel model. This will give you rigid transformations and non-rigid transformations that preserve distance-relations (like scaling). However, this approach wouldn't work for skinning since it breaks the parent-child node relationship.
@Rubuler it's in the vid info above the link is to a page which links to a pdf.
@Rubuler there's a link to my homepage in the video description -> Animated SVOs -> asvo.pdf
Could you rotate voxel objects by represent them with bounding boxes on the map so that rays cast by the renderer or physical interactions hit the box they enter a separate, off map static octree at the same angle they hit the bounding box? You could do a robot with several bounding boxes but animals would be allot harder. Maybe deflect a based on its proximity to skeleton points or distorted boxes?
This is awesome. Thank you so much for explaining how sparse voxel octrees work in and understandable way. I couldn't find anything helpful on Google. So this was great, not to mention incredible!
@buzinaocara In theory it would. But I restore the octree property (all child nodes lie completely inside their parent node) by stretching the voxels/enlarging their bounding boxes. Though this doesn't break the algorithms you mentioned, it makes them more costly (for example a bigger BB means more ray hits => less optimization potential). This issue is also covered in part 3/3.
One thing to remember is that you could store a depth value on the rendered result and draw anything you like over (or between) that like 2d sprites, better if it's all the same but to be fair polygon games use raster graphics etc still. Might be a bit more difficult with a compressed style of tree though.
@Rubuler He had a link in part 1. you can find it there.
@theb1rd Thank you for your input, your observations are right. I'll check out the paper you mentioned.
With a non rigid transformation, like skinning or maybe a cubic space deformer, you would basically have a curve instead of a straight ray, right?
But since you still would be stepping along a curved ray in an axis aligned octree, this maybe would only add a constant costs to the raytracing. Could this work? You know any papers about raytracing and deformers?
Also, Voxels might allow "mpeg 3D video" like animations.
Anyway just thinking out loud, thanks for the great videos!
For skinning, I think the problem is the derivation of the curve. Even with primary rays, you first have to determine what voxels are visible to the eye to determine their bone influence and arrive at a matrix transform for the visible voxels (could be more than one per pixel if the voxels are transparent) in order to trace a spline through them. So you would have already done the prerequisite work to draw the skinned voxels in order to find the curve to march through them, and that's also view dependent.
I think the idea of tracing curves instead of rays is an interesting one for interesting camera effects, although you might have problems with the curves missing important features in the scene leading to gaps and more noise in the resulting pixels unless you trace something like a curved cone through the segments you march or use many jittered sample curves per pixel (similar to raytraced DOF).
This is good work... you have essentially a point-based renderer using octree as bounding volume hierarchy. A sphere tree might have been used instead to circumvent the rotation problem (not to take anything away from your solution, which is very nice).
See also "ManyLoDs: Parallel Many-View Level-of-Detail Selection for Real-Time Global Illumination" which discusses a sphere-tree-based point renderer.
You actually can rotate entire models (by model, I mean a tree) in world space. Rotating individual parts like limbs within a single model (in local space) get a bit tricky, however.
Unfortunately that doesn't work, as transforming the camera only allows you to implement rigid transformations.
@radulphi Ah. Didn't realize Animated SVOs was a link, thanks!
Instead of scaling the voxels could you get the graphics card to fill in the gaps in what are supposed to be solid objects in post.
Interesting stuff. I think this can be made even more efficient by rendering the animated SVO using discrete raytracing by transforming the camera rather than the voxels themselves...
have dynamic accelerated and created from source triangles to octree proxy representation, can be animated
you try to represent data storage in the octree, its not optimal
it should only be used as intermediate, temporary, dynamic
but it can be updated when needed, on demand
its like a 3d frame buffer
a palette of animated voxels is better, i mean pre-calculated animations, infusing models into the world
You determine the center point of every voxel. Does it mean, that it is rather a pointcloud then? Becouse you need the position of the voxels individually?
Thanks!
I don't have the skills but this is very interesting for the future of computer graphics... I hope one day we'll have real usable Voxel 3D engines !
Couldn't you just use multiple octrees and rotate them by raymarching on a distance field?
Where can I read your thesis? Can't find it.
1) Voxels are not memory efficiant. When you say something stupid like 1 bit per voxel, that does not contain color, or normal, or texture information. Once you add that, BAM your out of memory.
2) i dont know about that
3) LOD such as octree can be applied to triangles, so this is not a advantage of voxels
4) streaming has nothing to do with voxels vs triangles, so this is not a advantage of voxels
5) voxels only have color, no texture, so texturing is a disadvantage of voxels.
Wouldn't that generate horrible aliasing?
Less noticeably so the higher the resolution from a practical POV. Displacing low-res pixel art in Photoshop is definitely going to mess it up very visibly, but not ultra-high res (say 100,000x100,000 pixel image) even with nearest neighbor sampling unless we zoom in way close.
How can you animate multiple rigged models containing potentially millions of voxels using this technique? That would mean you have to apply a rotation matrix to every single one of those millions of voxels. Unless you can offload that to the GPU (and even then it would struggle) I don't see how this is really effective.
Since it's done at render time per-pixel or per-ray while traversing the octree, you don't have to drill down to the leaf voxels of every single character in the scene, only the ones that are visible and with LOD which allows you to stop traversal prematurely without going all the way to the leaves (unless we're really zoomed in to a particular voxel). So the cost is more relative to how many pixels to render, or how many rays being cast, not how many characters or voxels there are in the scene.
As an example, suppose you have a 2D 100,000x100,000px image (10 billion pixels) represented using a sprase pixel quadtree, and you want to apply a brightness filter to the pixels on the fly. You don't have to apply it to all 10 billion pixels or even close at any given frame, since if you're zoomed in close to the image, you only have to apply it to the pixels which are visible inside the viewport (say the viewport is 1024x1024, in which case you only have to apply it to a million pixels and not all 10 billion). If you are zoomed way out, you still only have to apply it to a small number of pixels, since you only have to draw from the lowest-resolution mips of your sparse quadtree. So the cost here is not so proportional to the full resolution of your 10 billion pixel image, but the resolution of the viewport looking at a section of it.
So this method offloads the work of transforming each voxel to the GPU? But if a regular game has millions of polygons, then a voxel engine replicating the same game world could contain billions of voxels. I think voxel engines are great but much more processing power is required to make them suitable for high resolution, large scale game worlds.
This is so stupid. Scaling the voxels to fill the gaps is a horrible soloution. This will break rendering optomizations that expect voxels to have a constant size, and orientation. You re-invented the wheel, and now its jagged, and blocky. Your wasting your life playing with cubes, when the rest of the world is rendering triangles at rates you will never, ever achieve with voxels.
This is awesome. Thank you so much for explaining how sparse voxel octrees work in and understandable way. I couldn't find anything helpful on Google. So this was great, not to mention incredible!