Видео

I like the new video format!

you have a great sense of humor!

Instead of standard ray/plane intersection marching, maybe you can use SDF ray marching when you aren't using DDA. SDFs are very GPU friendly and the SDF of a cube does not use division. Plus you can round/bevel your cubes using SDFs for added artistic desicions.

Voxel de_nuke looks awesome

So you’ve switched to grouping 64 voxels together and using 64 bits to represent the presence - or absence - of a voxel in that group…but can I ask: what physical size you’ve designed an individual voxel to be? From the video it looks as if each voxel is supposed to be a few centimetres in size, but it’s hard to tell. I’m particularly curious because of the permanent storage requirements of “tiny” voxels (at least…tiny compared to the Minecraft 1m cubed voxels…). I’m working on my own system (as per my comment on another of your videos) and trying to balance the requirements of higher detail (smaller voxels) against permanent storage requirements (smaller voxels = higher voxel density = more voxels = more storage requirements). Are your voxels ~5cm cubed or bigger or smaller?

Very Small FPS in your last demo. I have 15 fps on 3050 RTX and Ryzen 5

Could you improve the performance of the voxel game veloren

I'm just wondering - how do you find the normal vector of a voxel when the ray (from eye to fragment) hits it? When I raymarch from eye to fragment, i keep track of which axis the closest plane is on, and use that to decide the normal. The problem is that when the ray hits the surfaces at certain angles, the roundoff errors cause the wrong normal to be used, and so for example if you are really close to a wall, you see a "grid" around the voxels: this is because around the edges of voxels, the normal reported is the one for the internal (invisible) side. Since I'm not seeing you are any other raymarching youtubers struggle with this problem, I presume there must be some better way to figure out the normal of the voxel I hit. Do you have suggestions? Thank you in advance if you choose to answer.

I am a bit confused your video description says using raytracing but you talk about raymarching?

Very nice, lets see paul allens voxel rendering pipeline

Basically saying "I've achieved the holy grail of computer graphics" feels *a little* conceited, but that aside, I really like your engine. A lot of these small-voxel engines seem to always try to copy John Lin's work, and concern themselves with outdoor sunlit scenes primarily (which are easier to light), but I appreciate how well yours handles indoor scenes with more varied lighting. Really good work!

This is really amazing !!

Hi Douglas! I’ve been following your work and I have a question: obviously your voxels are quite a bit smaller than those in other systems (like Minecraft’s). But how far down (under the “ground”) do your voxel worlds go?

For the beam optimisation: Have you considered that some single-voxel particles could be entirely missed?

And using this make ultimate minecraft :D How big world with LOD can be displayed? could be this large enough to have similar scope to MC?

Hello, I've actually stumbled across this exact problem of DDA being fixed, and I needed to traverse the octree in a more efficient manner. And actually I found the solution, it's pretty dirty, but it works. IDK if you can contact me on RUclips, but you can try.

Amazing stuff!

Not sure I understood half of the things you talked about, but love the look of the game!.

I've been watching this come along for years. Your work has been very inspiring. Thank you!

Just subbed. Amazing stuff!

i wonder if you'd be able to easily extend the algorithm to do bounce lighting with a second ray from the bounce. with all the techniques you cooked up, i think it would be smooth and look great. you could even have a setting to determine n bounces for computers with very high specs.

1:20 "Meet Gorgeous Latina Women" xD

You could draw the material at blank locations as if rasterizing, and then blend it, and draw at the final bounce as if rasterizing.

In case you haven't watched it yet, you might be interested in the 2021 SIGGRAPH presentation called "Global Illumination based on Surfels"

I've watched most of your videos, you're doing a really good job! I myself am working on a voxel game for about 2.5 years; funny that we started around the same time. Though in my case I'm not necessarily focused on the graphics engine. I went from using polygons to raymarching a few months ago but there's still a lot of work to do on various details of it. My pipeline is quite different from yours. I render the scene by raymarching from each pixel in the direction of the sun; if I hit an object, I consider the pixel to be in shadow, else I calculate the intensity of light based on the normal and the direction of the sun. During this pass I create an image with the unlit colors, the intensity of sunlight, the normals and the positions. Then, I render a sphere around each light source, and within this sphere, I read the position and normal from the previously-generated images and cast another ray - towards the light source - and add the intensity to the light image. I finally combine the light image with the unlit color image. It performs surpringly well even with thousands of light sources, but it does lag on older GPUs when lights are present. Your videos did give me some ideas during the process. Your technique might inspire some more improvements to my lighting system. Keep up the good work and congratulations on everything you've done!

Very impressive work! I'm wondering how well this translates to directional effects like specular reflection or temporally inconsistent effects like moving objects. When I was working on my SSAO shader for OpenMW, I found I could get pretty beautiful SSAO for static scenes with just reprojection and temporal AA, but moving objects caused a lot of problems.

Congrats on 10k❤

Hi, you have to take a look at this : Beyond White Noise for Real-Time Rendering from the channel SEED - Electronic Arts Blue noise work like magic for low sample count and realtime!

Keep it up man! You are reaching something truly awesome!

Would love to see some BRDF magic next. Iirc you've got unique per-voxel normals, I'm curious to see how that would look with even some basic fresnel-driven gloss. Also HDR colors + basic tone mapping would make emissive voxels/skyboxes look insane

Wonder how Rust would perform in comparison. 😊

Удивляюсь с каждого твоего видео, отличная работа, альтернатив просто не существует! Желаю тебе успехов, в этом нелёгком деле, и очень надеюсь, что когда-нибудь на твоём движке люди начнут создавать игры!

Well done, this is really good stuff.

I always wondered if rendering each voxel as a 2D point in 3D space might look or perform any better than rendering cubes. For example something where distant points that would otherwise occupy one pixel are averaged together into a larger, lower density grid, and where points that are close enough to the camera to where you might see between them get expanded to fill the space, maybe with some additional noise or filler texture applied to fake even smaller detail. No idea how well it would work in practice, but it would be interesting to see something like it tested.

This is amazing. It's turning into exactly what I picture when I think "voxel engine"! The fact that this is all running on a 1660ti is just mind boggling, too. One minor nitpick, as a french speaker: "À-trous" is french for "at/toward holes" and sounds a little more like "ah true", not "a truce". Not a big deal though, especially compared to the insane amount of code work you've put in 😂

So cool! I always look forward to ur videos

This is awesome! Your work is always inspiring. I had a similar idea for spatial ray reuse that I wanted to leverage for my own voxel engine, though it was texel based since my engine is designed to be more Minecraft like. The fact you got this working is very cool and I can't wait to see where you go with it! You are truly innovating :)

mad respect, u program in light mode

I was wondering if it would be possible to make lower resolution scales have sharp edges. You should already know where the edges of all visible voxels are so instead of simply rendering the pixelized output you could take each pixels corresponding to individual faces of a voxel upscale it as its own image (only blending pixels from the same face) and then sort of apply a "mask" following its edges so there is a clear cutoff instead of a blurry one. Also for some reason, if I set the resolution scale below 1x, the frame time stays constant at 6ms no matter if i use 2x or 5x scale.

This really has come so far! Keep up the great work!

Tbh i dont really understand what you explain in your videos but I still watch them and I kinda just sit here in pure amazement, it's so cool. I honestly can't wait to see the finished product

Wow, really impressive work! Interestingly, a few weeks ago I started work on implementing a per-voxel hashmap into my own engine for lighting. My whole pipeline was basically identical to yours, great minds think alike haha. I have since changed my technique slightly though and have thus far only used it for soft shadows. Excited to see what you do next!

Amazing work! Great solutions for denoising, the shot of the tree at night really sells the value of the emissive voxels!

This looks amazing! What is the performance like?

you are doing gods work here.

You really should have nearest neighbour upscaled this video to 4k and uploaded it at 4k. RUclips compression completely butchered parts of this video.

Congrats on 10k subs !

Sound like temporal reStir

Have you got a road map? Quo vadis Douglas? At what point does the engine become a finish product? I've been following you for a while and, yes the progress is impressive and kudos to you for not giving up

Tried running it in browser and yea... it's a bit laggy (like 2 - 5 fps I'd guess?) but personally I wouldn't be able to do this under 1 fps, so great job, considering how great it's looking.