Видео

imgui does not have any (point cloud) rendering capabilities of its own. It is strictly a UI (windows, menus, buttons, ...) that easily integrates with 3D graphics APIs such as OpenGL, DirectX, ... You could export your point cloud and view it offline in MeshLab or another 3D viewer/editor. Alternatively, you could render the point cloud to a texture and then display said texture. The rendering could be done on the CPU or GPU. Such a program would take ~10 LOC in OpenGL for the render code plus boilerplate/scaffolding. I recommend learnopengl[dot]com We are talking about visualizing points as single pixels or tiny discs here. Anything more fancy/complicated quickly gets into research territory. See Grossmann & Dally 1998; Magnus Strengert, Martin Kraus, and Thomas Ertl 2006; ...

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.

Those wobbles were due to my giant windscreen which was directly attached to the handlebars. The wind turbulence induced the wobbling. I've since removed the screen and raised the forks by 5mm (the bike was too neutral, the front too light/wishy-washy from the factory). Never had speed wobbles again thereafter. I recommend raising the forks regardless of wobbles or not. It greatly improves the balance of the bike and its cornering ability^^. Ride on!

He's what we call a "Klarino" (show-off) in Greece^^. Reminds me of this guy: ruclips.net/video/L5KfYofxZZQ/видео.html Having said that, he improved a lot since then. Thx for watching^^.

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?^^

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

also source pixel cube map path tracing, and n^2 sphere cube map path tracing

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 then jump into the actual source data, through pointers

no problem when going really close

no need to throw detail out

you dont have to calculate the octree all the way down, you just need the intersection point with the geometry

its kinda cheating what planes and triangles to check in the ray tracing algorithm

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 ;)

lol can't wait myself! :)

Hey mate I'm afraid I got barely any videos showing off my MT :( try this: ruclips.net/video/Usaha7sqObg/видео.html are you riding one yourself?

Yeah. I just finished a scrambler-like project on a 2019 bike(much like this ruclips.net/video/G2v_8FteFw8/видео.html with a few more weight saving mods. Plus a full system Termi and ECU flash. It’s now just an engine and a seat :) but I love the idea of removing the air box, just don’t know if I’ve got the testicular fortitude to go that far! Do you think you sucked much grit into the pistons with them that exposed? I love your blog on your MT. It’s like the Dead Sea scrolls! :). You’re leader in mods on this bike for sure!!!

those are chinese knock-offs from ebay, note that we painted the white/black parts ourselves!

Thx for reading my blog!!! I've since installed a 520 chain conversion kit with aluminum sprockets. Missed the opportunity to weigh them though :(, but should've saved another 2kg easily, if not more ;)

@@dennisrkb Not just that but it's rotational and unsprung weight. Did you notice a big performance difference and how often have you needed to adjust the chain since swapping to a smaller one? My chain and sprockets are due for a change so I was going to swap to a steel/aluminium sprocket to save some weight without losing any lifetime.

@@6Twisted due to the low weight, high seating position, and geometry of the bike (very front neutral, had to actually raise the forks by 5mm to make it turn in), it was already incredibly agile to begin with, so I would be lying if I say I noticed something. Perhaps you could've measures a split second faster acceleration 0-100 but nothing perceivable with your human senses. I installed a DID ZVM-X and didn't need to adjust it once in 5000km, so I guess I'm gonna opt for the "standard" VX version next time, save some weight and money.

I doubt that :P

I think it was used for the environment and not the actual models though

You're approximating arbitrary shapes by sub-dividing the bounding cube around it evenly in 8 sub-cubes and you repeat this process recursively. After enough steps the voxels become sufficiently small to accurately approximate smooth surfaces even though they are cubical (the same way you can't make out individual polygons in a sufficiently high-resolution mesh - it appears smooth). For rendering, you start at the root node, and, as long as its too large to be displayed, you recurse into the children and so forth. Once the projected size of a voxel becomes ~1px you can stop traversing the tree and draw the voxel. Check out ruclips.net/video/fGMu5kDNKU8/видео.html

Hey as12 this is a simplified version of my thesis work tailored to non-technical people.

Okay, but I would still argue that spreading simplifications that lead to pervasive and hard-to-get-rid-of misconceptions is not a good thing. At the very least, instead of claiming "nothing more, nothing less" you could have said something along the lines of "actually it's more complicated than that, but this notion will do for our purposes". Just saying...

@@dennisrkb I think to that you should correct this video.

?

For animation? You can, but if you want a fully destructible game, including destructible people, then the solution he mentions is better.

Depends on the topography of your object. Flat surfaces can be represented more efficiently with polygons. 3D, non-parametric fractals can be represented more efficiently (memory-wise) with voxels.

Okay, that's right... but in most non fractal cases the voxels should use more memory. You talked about foliage in the last video, but you show a polygon scene. So do you know any voxel foliage? I can't imagine that, because a grass blade or leaf must be very detailed for that.

Zudomon Jon Olick does euclideon better.

have fun deforming and animating models made of voxels...

A custom rasterizer in CUDA with similarities to QSplat

+MrBratkenSolov It's not bullshit.

Jealous much?

***** No!

***** I'll have one for christmas, you're just jealous

Anton Zuykov you want to hear a cooler story? Make a paper / presudocode for it and I will make a render to blow your socks off. >:p