Animated Sparse Voxel Octrees: In-depth pt 3/3
HTML-код
- Опубликовано: 21 июл 2011
- Part 3/3 of the in-detph series on animated sparse voxel octrees. Contents:
- Limitations of my animation technique
- Possible use cases for my animation technique
More info at: bautembach.de/#asvo
The video contains short clips of "Rage", "Crysis" and "Mirror's Edge". 
Наука
![Sparse voxel octree modification and benchmarking [Voxel Devlog #3]](http://i.ytimg.com/vi/yjOLx4O634I/mqdefault.jpg)
Thank you for this set of videos its a very interesting subject and great to see someone tackling the tricky problem of voxel animation. You have explained the subject very well.
These three videos are an excellent tutorial to voxels. You are an excellent teacher.
Thanks for these In-Depth-Videos, very informative.
Control Voxels in a point cloud. Much like rendering hair, guide hairs inform the rendered hairs what to do so, at least in real time, the computer does not have to calculate movement and physics for every hair. This would allow freer movement of the control Voxels while rendered Voxels can be informed where to be and what to do. This would be technically similar to NURBS and/or Sub-D surfaces, using relatively few Controls Voxels to inform the location and movement of the rendered voxels.
Thank you very much for sharing your knowledge with us :)
Thank you all for your interest, feedback and kind words.
@MakAttak101 Both shadow mapping and stenciled shadow volumes compute shadows in a pass separate from the final rendering pass. Therefore, you can choose a different (appropriate) level of detail for the voxel model during the shadow computation phase.
@MakAttak101 Sry for the late reply (youtube didn't tell me that I've got messages). Answer to your question: Not necessarily. After being resized/stretched and before being drawn, the size of the voxel is evaluated. If the renderer considers it too big for the screen it will traverse the voxel's child nodes (if it has any) to achieve the desired level of detail.
great work here!
What about allowing them to move to align up back inside there box? If they can't you increase the level of detail and try again. This might allow for realistic skin stretching.
@jamal925 Thanks for the comment. By the way, there is no 'u' in 'another'
For rigid animations that works fine ;) but what if you would like smooth transitions around joints of a rigged character?
you dont have to have boxy borders and surfaces, you can have a function determine if and how the surface is being hit, if you use functions as the surface representations, and the ocree as the ray-intersection resolving structure
@tulp35000 Voxel means volumetric pixel, a pixel with 3 dimensions.
There are also point clouds, which are similar, but well, round.
@Ringwaul there is Qubicle Constructor and Slab6
@radulphi Hey, I'm a 3D modelling student looking to get into voxel modelling, but I can't seem to find any free voxel modelling programs. Can you suggest any?
Yes that is true I was just thinking of that one case. In a world of machines it would work well. Though the other cases obviously need to be covered.
what about using point cloud instead, then skin the point in realtime?
Then maybe there need to be algorithm to remove part of the point at certain distance.
What if the voxels were drawn as the circumspheres of the scaled cubes instead of the actual cubes? Would that ensure there would be no gaps? Would there be any issues created by this different approach?
@Geoxile there is Qubicle Constructor and Slab6
Good looking stuff
Thank you :)
probably we don't know how to character rig via voxels...but does foliage won't crash/kill system to make real time rendering?
Doesn't the voxel know which voxels it touches? can't they stretch and rotate with this information? Or this still leaves the negative positives?
Why don't you do it the other way around, starting from the place where result should be and finding out where each voxel was on the model? Should fix the gaps issue and transforms limitations. Moreover, doing it on demand, computing high LODs when they are needed. Could that work?
I always thought of for doing rigid animation you would just use a transformation matrix to change the axis of the voxels animated. Though you would need another oct-tree for each animated part.... maybe you could store them in an oct-tree. hmm. I dunno.
Very interesting informative videos! Thanks a lot!
And as I could nag that you mispronounce some words in a funny way I found myself actually understanding everything! Compared to a lot of other tech videos. :]
Thanks!
Please correct me if I'm wrong, but intuitively I'm thinking you might already have a solution for fairly extreme deformations (like a character doing contortionist poses) and even without the need to be very conservative with the stretch factor or even avoiding it entirely without visible hole artifacts (along with avoiding stretching artifacts which are too noticeable) provided that your voxel models are high-resolution and filled in. The holes only seem to be an issue with a hollow surface, since a ray that misses a rotated voxel on the surface should still end up hitting one inside, and that doesn't seem to me like it'd create such noticeable artifacts unless the voxels are really large.
That is to say, instead of only rasterizing the triangles making up the surface of the character to your voxel hierarchy, perform an additional precomputation step constructing your SVO which fills in the voxels making up the inside of the character's body (perhaps interpolating the material values of neighboring voxels and repeating until the entire character's body is filled in), turning it into a filled solid.
For example, it is very challenging to deform the pixels making up a high-resolution outline of a triangle if we're going to do on the fly at render time per-pixel using a quadtree in a way analogous to raytracing without yielding gaps in the deformed outline or very visible stretching of it, but it doesn't seem so much so if the triangle is filled in and not just an outline. Maybe we'll notice a few aliasing artifacts around the triangle's edges if we zoom in close around the filled triangle's edges, but gaps should be eliminated since a ray that misses a rotated pixel will still hit one of its neighbors.
Of course that results in way more voxels to store in the SVO, but that seems like the type of content that would lend itself reasonably well to SVDAG compression with lots of redundant octants.
Or define a mathematically sound, hole-free, ray-SVO intersection test that takes bone transforms and weights into account. That would give you the same guarantees. And while it would work for arbitrary deformations (within the skinned mesh domain that is), the stronger your deformation the less potential for pruning ray-voxel intersections.
@@dennisrkb A difficulty I am finding just thinking about it is avoiding the requirement to store a great deal more data per voxel (in my case, even 4 bytes would be a great deal more data) even if I was afforded a great deal of time in precomputation and could anticipate all possible deformations in advance.
But also my dream would be to generalize this beyond bone deformations, since a lot of game and VFX engines often also do things like tweens/morphs applied on top with displacement maps to displace vertices arbitrarily for things like facial expressions, making muscles flex, morphing a skinny character into a chubby one (procedural character creation as in the case of games like Mass Effect allowing users to generate their own characters using morph sliders) with results more akin to smooth translation than rotation, etc. It seems very difficult to anticipate every possible case and even if we could, to avoid creating far more false positives with AABBs that encompass the full range of possible relative motion for each voxel in the hierarchy.
It seems to me like a filled-in voxel model would be a lot more forgiving in that regard unless I'm overlooking something. I might need to just try it and see.
@@dennisrkb Amazing work BTW! I really love voxels and would love to find not only engines utilizing them more but artists to utilize them more directly in the content creation process.
@@darkengine5931 How should inner voxels be animated? Why wouldn't they suffer from the same dilemma you're describing?
@@dennisrkb Same way as the outer voxels with the way I'm conceiving it (which could very possibly be overlooking edge cases). For skinning in the engine we're using even though it's based on polygons, we actually generate a voxel grid and use a heat diffusion type of technique to compute the vertex bone weights given a polygon mesh and bone hierarchy, so we already get the data for how to transform the inner voxels through that process.
For something like morphs/tweens and lattice deformations, I'm thinking we can do a similar thing based on the proximity to the vertex that would normally be displaced with a similar kind of diffusion technique. There with weighted translation, avoiding gaps even from outer to inner neighboring voxels seems trickier than rotation, but something I'm thinking we can mitigate by tampering with weight distribution but possibly combining it with your stretch factor.
Mostly I'm counting on optimizing and optimizing the SVDAG to achieve higher and higher resolutions and relying on the filled property and possibly some artist parameters to help mitigate any possibility of noticeable gaps since I find that a bit easier in our case, albeit a bit inelegant.
@jamal925 Not to mention you forgot to end the sentence with a period; or do you Canadians call that a 'full stop' ? On a more serious note, I don't see why my comment was uncalled for. I thanked him for the information because it was quite insightful and then I gave him pointers on how to correctly pronounce two English words. I didn't put him down for the mispronunciations, I didn't verbally attack him in any way. Which part did you feel was offensive?
Holy sh**t, it works.
Um... Dennis, what's your opinion on using cage deformations for skeletal animations of voxel models? I.e., splitting the model into connected cubical or tetrahedral volumes of appropriate size (each with its own octree), and animating the vertices of the resulting "cage" using any of the traditional techniques?
Terribly sorry if you've already seen this comment. I'm just not sure if my first attempt to post it was actually successful "^_^
I was eager to read your comment but couldn't. It only showed up in my feed but disappeared when I clicked on it.
So I'm going straight from voxels to pixels in my work. What you describe would require converting voxels to meshes first (at least temporarily and potentially on the fly)--which sounds very doable especially with "new" technologies such as geometry shaders. But if you already got a mesh, why limit yourself to cage deformations? All the metadata necessary to create a proper mesh (including skeletal data) could be stored in the octree..
In fact this warrants a modern investigation: Could we use voxels only for modelling+intermediary storage and convert them to polygons on the fly at the exact LOD we need? Up for it?^^
@@dennisrkb I'm certainly not up for it, unfortunately xD
But I think that converting voxels to meshes isn't necessarily required for cage deformations.
I made a conceptual illustration ( imgur.com/D6BTcPt ) for a 2D case, but the same principles should apply to 3D too. In the illustration, at first we have the original model, and a (relatively) low-poly cage around it (A). The cage consists of connected volumes (or polygons, in the 2D case), which correspond to a particular slice of the model (B). When converting the model to voxels, we don't convert the whole model to a single octree, but rather transform each slice of the model into the un-deformed coordinate space of the corresponding volume, and create an octree in that space (C). As a result, we get a collection of separate octrees which, when deformed in the right way, match (up to octree resolution) the geometry of the original model (D).
That way, we don't need to convert anything to meshes during the rendering, we only need to render a bunch of linearly (or trilinearly) deformed octrees. In this scheme, only the cage vertices have actual bone weights, whereas the voxels' positions are determined by their integer coordinates in the octree and the positions of the corresponding volume's vertices.
@@dairin0d Now I get you. That's definitely possible. My voxels have bone weights and are driven by skeletal animation. There is nothing in the way of storing 'cage weights' (or inferring them) instead and using cage transforms in their place. I don't see the need for separate octrees though. You can just apply the cage transform on the fly, as you're traversing your (global) octree. Am I missing something?
@@dennisrkb As far as I understand, applying the cage transform on the fly (during the traversal) would be very troublesome for the octree nodes that don't fall neatly into a single cage cell. I made another illustration ( imgur.com/7B4xjLq ) that, hopefully, demonstrates the problem.
Let's assume that, at some finer level of detail, each voxel belongs to one particular cage cell. However, their parent would have to "belong" to every cage cell of its children, which significantly complicates the calculation of its position and bounding box.
In principle, a similar problem exists for direct bone transformations as well. The method in your thesis just seems to sidestep it (at least, that's the impression I got) by skipping these calculations for all intermediate LOD levels and relying on moderate animations ;-)
@@dairin0d I see the problem now. Yeah originally I wanted to compute an accurate "stretch" factor but couldn't figure it out at that time.. Another idea that could avoid requiring multiple octrees would be to use a non-axis aligned tree, whose hierarchical structure closely follows the model (the skeleton of the character in your example), a kind of "content-aware" subdivision. Although you'd loose quite a few benefits of octrees this way.. so when can we expect ASVO 2.0 from you?^^
Not at all. I actually considered this approach first but decided against it because it would require me to project all eight corners of a voxel, rather than just the centre (and I wanted to avoid the additional arithmetic operations)
I'm relatively new to voxels. One thing I noticed is that people in the comment sections say it is difficult to create the models. Is that true? Let's assume I want to create a landscape with a forest on top of it. How would I go about creating it? Is there a blender-like tool out there?
The problem is that there is no standardized format for voxel models. So you'd have to write your own polygon mesh->voxel model conversion tool, after deciding on and specifying your own proprietary voxel format.
@@dennisrkb
That would mean I create the landscape in blender, create plants in blender, put those plants wherever they belong and convert the finished product into voxel. Whenever I change something I need to change it in blender first and convert everything into voxels again. Is that order correct?
Let's assume I have the skyrim map, how long would that take? A minute, an hour, a day? Obviously it depends on the converter, but I would love to hear a very rough guess.
One idea which comes to mind is that if we have a forest with trees which can actually grow, it could switch the polygon treemodel when outside of the render distance and it could convert it in real-time from polygon to voxel when it renders the new chunk. Is that a realistic idea?
Also if I create a voxel terrain which is changeable, there needs to be a converter from voxel to polygon again. But this one can take more time. Because it only needs to convert the changed chunks and it basically has all the time it needs.
Are the ideas I stated here realistically implementable or are there other ways which you can get the same effect in a way more simple manner?
@@philippbrogli779 Or you could write a voxel-based game-engine (+ modelling tools) that can manipulate/render voxels directly without the need for conversions ;)
@@dennisrkb If I want to stand on a mountain and see the cows walking in the valley, with the trees rendering all the way to the horizon, which is better suited? Voxel or polygon?
Would it make sense to make a polygon renderer for creatures and a voxel renderer for Plants and landscape? Or would it be better to focus all the energy in only one type of rendering?
@@philippbrogli779 You hit on a really great idea! Make a hybrid engine that uses voxels for static (not moving, but destructible) objects such as terrain which they are perfectly suited for, and use polygon meshes for foliage and other animated characters. Blend the two via the z-buffer. Also, before you jump into coding, have a look at "Mega Meshes" to see what's possible with on-the-fly mesh generation: ruclips.net/video/M04SMNkTx9E/видео.html
@SiegeX1 thx^^.
All eight? It's a cube, the radius of the circumsphere is the distance between the center of the cube and anyone of its corners :P
So how the data structure looks like? It is not a 3D texture anymore? (Great work BTW!!)
It's a sparse octree stored in BFS order github.com/denniskb/asvo
@@dennisrkb I download your code, but VS says projects are incompatible, what do I miss? (I used VS only for .NET and Unity projects yet
@@YYYValentine It's best if you open an issue on GitHub ;)
@Ringwaul I'm sorry, I don't know of any that are free =( - you're probably already aware of 3D Coat. Should you decide to buy it, the youtube channels PILGWAY3DCoat and philnolan3d offer great resources for learning.
Is it true that you can't rotate a Voxel? Can't you have several independent Octrees attached to the vertices of polygons?
It is sweetable. :)
Sweetable
Why are voxels square.. they should be round, more flexibility.. but hey i know nothing about this stuff.
@jamal925 Dude, cool down, he was just being polite.
Thanks for the explanations. Btw, 'rigid' is pronounced 'ridge-id' and 'suitable' is pronounced 'su-ta-ble'
@jwk2001 hahaha xD