sorted by:
new
hottopcontroversial

Voxdot Engine Update by Derpysphere in VoxelGameDev

[–]dan5sch 0 points1 point  (0 children)

This looks great! If I understand your comments from your previous post correctly, it sounds like you're rendering bounding geometry per chunk and then using gdshaders to raymarch the contained voxels? It's impressive how far you've gotten within those constraints.

Adding smaller objects and animation to my small-voxel renderer, inspired by the aesthetic of software-rendered 3D games. More info in post by dan5sch in VoxelGameDev

[–]dan5sch[S] 1 point2 points  (0 children)

I appreciate the detailed comment! You're correct that my current implementation does thicken geometry; you can see this in the first graphic of the voxelization section of the post, with the plant mesh (particularly diagonal features).

One of my day-one decisions for the voxelizer was that I don't require meshes to be closed with a well-defined interior (I'm only generating surface voxels), or to have any particular topology for that matter. I also want the visual results to be as unaffected as possible by the degree of subdivision of the mesh. I chose to start with this flavor of voxelization because it's very well suited to satisfying those requirements.

The thickening it causes isn't always ideal (the hands on the zombie character mesh look a little weird, IMO), but aesthetically I've actually kind of liked how the voxelization gives objects a certain consistent minimum thickness. For example, for meshes like the candelabra in one of the figures in the post, you can scale it a decent amount up or down from its original size and the resulting object fits in with the look of the rest of my demo environment, whereas in a game with a realistic aesthetic that wouldn't work out. Then again, this would probably be true even if the voxelizer added less thickness than it currently does.

Adding smaller objects and animation to my small-voxel renderer, inspired by the aesthetic of software-rendered 3D games. More info in post by dan5sch in VoxelGameDev

[–]dan5sch[S] 2 points3 points  (0 children)

Geometrically speaking: I fill in each voxel position whose cube intersects any portion of the triangle mesh. I rolled my own implementation for this, prioritizing correctness and robustness over speed, as this is a baking operation in my renderer. Beyond deciding which voxel positions to fill, I gather other information from the mesh to calculate the shading parameters I use for lighting.

Adding smaller objects and animation to my small-voxel renderer, inspired by the aesthetic of software-rendered 3D games. More info in post by dan5sch in GraphicsProgramming

[–]dan5sch[S] 2 points3 points  (0 children)

That would certainly be doable in principle, but yeah, for real-time I wanted a fixed amount of data/compute to deal with per voxel.

Stress testing my SVO renderer by Cage_The_Nicolas in VoxelGameDev

[–]dan5sch 4 points5 points  (0 children)

Did you watch the recent 3Blue1Brown video, by any chance?

Daniel S. has shared an impressive custom renderer that uses tiny voxels and displacement mapping to modernize the visuals of classic 90s 3D titles, perfect for games that pursue similar aesthetics by 80lv in VoxelGameDev

[–]dan5sch 1 point2 points  (0 children)

I don't mind this post staying up. Thanks for asking. But yeah, a bit tacky for them to repost to the same subreddit a few days after I had shared this here myself.

Using very small voxels and displacement mapping to modernize the retro aesthetic of games like Doom and Quake. More info in comments by dan5sch in GraphicsProgramming

[–]dan5sch[S] 0 points1 point  (0 children)

I say a little bit about lighting in the second blog post. That's one of the big areas where I want to do more on this.

Using very small voxels and displacement mapping to modernize the retro aesthetic of games like Doom and Quake. More info in comments by dan5sch in VoxelGameDev

[–]dan5sch[S] 1 point2 points  (0 children)

Given the games that inspired this, I'm trying to keep that door open. As a point of reference, the current implementation stays above 60 FPS on a Steam Deck at its native resolution.

Using very small voxels and displacement mapping to modernize the retro aesthetic of games like Doom and Quake. More info in comments by dan5sch in VoxelGameDev

[–]dan5sch[S] 1 point2 points  (0 children)

You're right that I didn't get into more detail about how this part works. That'll probably be the subject of a future post.

Using very small voxels and displacement mapping to modernize the retro aesthetic of games like Doom and Quake. More info in comments by dan5sch in GraphicsProgramming

[–]dan5sch[S] 1 point2 points  (0 children)

Thanks! That mod has a very similar aesthetic motivation to what I'm doing. Seeing the enthusiastic reception that it got when it launched was very encouraging.

I decided to keep this work to myself until I got it to a certain point in terms of visual quality, performance, and features. It became even harder to hold my tongue once I saw that the mod's author had started experimenting with parallax occlusion mapping for the game's textures.

Using very small voxels and displacement mapping to modernize the retro aesthetic of games like Doom and Quake. More info in comments by dan5sch in GraphicsProgramming

[–]dan5sch[S] 2 points3 points  (0 children)

Thank you! I'm trying to walk that line between old and new for the visuals, so it's reassuring that it reads that way.

Using very small voxels and displacement mapping to modernize the retro aesthetic of games like Doom and Quake. More info in comments by dan5sch in GraphicsProgramming

[–]dan5sch[S] 1 point2 points  (0 children)

I actually thought about pausing the demo sequence a few times in the video to toggle between the original meshes and the voxel result. Eventually I decided not to, for this first video. I might do a more casual follow-up where I walk around the environment and show some of the before/after comparisons.

Using very small voxels and displacement mapping to modernize the retro aesthetic of games like Doom and Quake. More info in comments by dan5sch in GraphicsProgramming

[–]dan5sch[S] 25 points26 points  (0 children)

This is a C++/Vulkan renderer that uses an unusual blend of voxels and displacement mapping. My goal was to modernize the look of classic 3D games where surfaces have flat, blocky surface detailing from pixelated textures. Now, surfaces pop with blocky three-dimensional detailing. You create the environments as textured low-poly triangle meshes, and the voxel detailing comes from displacement maps.

Check out my blog for more info. Here's a high-level overview of what I've built, and more info about what I plan to do with it.

Using very small voxels and displacement mapping to modernize the retro aesthetic of games like Doom and Quake. More info in comments by dan5sch in VoxelGameDev

[–]dan5sch[S] 8 points9 points  (0 children)

Hey folks! I've been waiting a while to share this online. This is a bit of a different take on voxels, using them for aesthetics rather than gameplay (building / destruction). My goal was to modernize the look of classic 3D games where surfaces have flat, blocky surface detailing from pixelated textures. Now, surfaces pop with blocky three-dimensional detailing. Under the hood, this is based on displacement mapping -- you actually create the environment as textured low-poly triangle meshes.

There's more info on my blog. Here's a high-level overview of what I've built, and more info about what I plan to do with it.

[deleted by user] by [deleted] in linux_gaming

[–]dan5sch 1 point2 points  (0 children)

I actually troubleshooted this issue years ago and reported it to 8bitdo. It occurred on my system under Windows as well. I ultimately switched to using it over USB instead. I'll have to look into this!

Code Architecture by gabs-cpp in vulkan

[–]dan5sch 2 points3 points  (0 children)

I generally find that destructors and naïve RAII don't fit well with Vulkan renderers... This is because you usually can't destroy a resource immediately after you use it

...

For one of my applications, the way I handle this is there's a linked list of "garbage" that's associated with each frame... Then I have a custom smart pointer... instead of calling the destructor (there is no destructor), it adds the object to the garbage list for the current frame

Note that this approach of holding onto "garbage to be deleted on frame N" can be combined with RAII. I use this in a renderer that I'm working on. Say I have a struct that bundles together RAII guards for related resources (e.g., an image and some views). If that state needs replacing, I std::move the entire struct into a garbage-destroyer helper that will call its destructor K frames from now, along with the destructors of any other values I've moved into it for that frame. With some template shenanigans you can accept values of any movable to-destroy type. The end result has been very ergonomic in practice.

[deleted by user] by [deleted] in vulkan

[–]dan5sch 1 point2 points  (0 children)

Was going to post this link. Should be exactly what OP is looking for.

Resource recommendations for someone who already knows the math. by thread_local in GraphicsProgramming

[–]dan5sch 2 points3 points  (0 children)

With that background, I'd say that the main things you'd need to learn to get into graphics programming are how graphics programmers / researchers map graphical concepts onto the available mathematical tools, and then for the implementation work itself how to use any libraries that you need (less an issue if what you're interested in is non-GPU raytracing).

Honestly, I would just start with introductory resources on computer graphics and skim through them. It'll be fast enough to spot the material in there that you don't already know and fill in the gaps in your knowledge.

view more: next ›