Show HN: WebGL Voxel Engine

Thanks for the work!

I had started an earlier version in Unity but I really dislike fighting what feels like a giant extraneous system. I was blown away by your demo; in particular the environmental damage. You 'sold' me on writing something similar. I'm probably yak shaving now but it feels so much more right to be programming instead of fighting Unity.

> just remember its a marathon not a sprint so pace yourself and keep at it!

Thanks! This really is the best sentiment for personal passion projects. Tho an occasional sprint can be fun too!

This 'isn't my first rodeo'. I've been partially implementing ambitious software projects for years!

When I was still going to computer graphics classes the ThreeJS source code helped me learn a bunch - the code is pretty straightforward when it comes to the basic to at least get a scene and an OBJ loader working with some shaders.

To learn about shaders, I've found that some reading up on the graphics pipeline. Along with https://thebookofshaders.com/ was been very helpful on giving me a foundation for shader programming. I was also like you, solid bg in CS/Linear Algebra but intimidated by the seemingly steep learning curve of graphics. I dabbled with Unity and now I've started to play more with shader programming and understanding GPU's.

The way I learned was by figuring it out myself through hacking. I decided to start with a program that could set the color of a single pixel, then tried to figure out how to draw a line from that, and from that to a triangle. After that, try to use the Z value of your points to draw a box from lines with some kind of perspective. With a good background in math, most of these algorithms should be relatively simple for you to figure out. After that, you’re not too many lines of code from rendering full 3D models. Doing it this way, I learned how shaders work by having to figure out manually why they are actually needed. Here is my project, which can now render textured objects in real time with multiple light sources: https://github.com/accatyyc/c-3do

I still have no idea how to do “correct” perspectives. This is just something I hacked together until it looked good.

I can very much recommend doing a project like this. You will naturally figure out how 3D graphics work, and it’s simpler than it appears.

I've found this is a great learning resource: https://webglfundamentals.org/

Relevant shaders link here: https://webglfundamentals.org/webgl/lessons/webgl-shaders-an...

Part of why it's difficult is that there are a tons of concepts belonging to 'real-time rendering' which three.js is built on top of. These are things like how a 3D scene is projected from a particular viewpoint using a 'camera', how lighting works, the split in vector/raster techniques for representing 3D shapes vs their surfaces, the role of shaders in modern GPU architectures etc. I'd recommend the book 'Real-time Rendering': https://www.amazon.com/Real-Time-Rendering-Third-Tomas-Akeni...

Edit: I'd also add: I wouldn't bother learning much OpenGL/WebGL to begin with (except shader programming in GLSL, since there's no good alternative abstraction for that). If you end up liking working with 3D graphics, go back and learn some about it since it'll help you understand performance concerns better—but meanwhile, knowing it is just an optimization you don't need yet. It's true three.js is built on top of it, but the significant principles you need to use three.js effectively fall under real-time rendering, not OpenGL.

At just a basic level: 15-ish years ago, 3D rendering APIs used what is called the "fixed function pipeline". Texture mapping, 3d-to-2d projection, and so on were limited to the specific functions implemented in the hardware of the video card and exposed by the 3D API you were using.

The programmable pipeline requires you to define some programs called "shaders" that run on the graphics card and replace the previous fixed pipeline functions.

Example: Say you feed a bunch of geometry information into the API (a list of vertices, faces that use those vertices, coordinates for textures, etc). The "vertex shader" receives 3D vertex coordinates (and possibly other values) and needs to output 2D screen coordinates. The hardware calculates which screen pixels will actually show which part of which face, and passes some coordinate information to a "pixel/fragment shader". The basic job of that shader is to read texture, color, and lighting information and decide what color should be output to the screen for a specific pixel (replacing the functionality of the lighting and texturing functions that were used in the fixed-function pipeline).

I think that three.js adds another level of abstraction on top of the actual graphics APIs.

Coming from a CS background, with a few years "in industry", I started by reading about the history of computer graphics, read some fixed-function 3D graphics tutorials, built a few toy programs, then moved to the shader pipeline, and built a few more toy programs with the things that I learned. Read theory, experiment to see how it maps to practice, refine your understanding, and then go back to reading, if necessary.

If I'm remembering correctly, I mostly ended up using http://www.opengl-tutorial.org/, liberally supplemented with Wikipedia articles and random mathematics articles, as necessary. (obviously, this isn't focused on WebGL and Three.js, but the core concepts apply. It might make more sense to go for tutorials in the ecosystem you'd like to learn, rather than learning one system, then having the time and cognitive overhead of learning to map the concepts to a new system).

Engines hide all the fun stuff. It's nice when you just want to get a game made, but if you want to get into 3d you can start by making your own soft 3d engine, eg. no 3d api, only cpu. Hand code the 3d to 2d (screen) transformation. Write your own code that decide what color the triangles should be in. Then when you understand the domain, you can look into the low level 3d hardware api layer eg. WebGL for the web.

You might be interested in https://github.com/ssloy/tinyrenderer/wiki

I do :) I've written a tool that bakes out clifford algebra functions into glsl (using sympy/sage to generate the clifford algebra). I want to use it to play with volumetric data... in the web browser! Obviously that's very lofty... foolish even.

If it's even possible, it'd be hard. I don't have the chops at the moment, and neither does chrome!

"But I think it will be quite some time before these capabilities are exposed in a web language and also with sufficiently high resource limits to do anything non-trivial."

Realistically, that's probably more what I'm actually waiting for.

And GVDB could be perfect, except for its super awkward licensing and platform lock. Ugh! I think there are some other realtime VDB projects out there, so I might check into those some time.

In the meanwhile, when I get around to it, I'll probably end up doing low poly ("low-simplex") stuff. A more realistic goal for the browser of today (and for my skillset) is something that can intersect lower dimensional manifolds with simplices embedded in higher dimensions. Dealing with normals will be mind bending. But I believe it can be done!

My project is to play with 4D (and higher) Moebius transformations of animated polygon scenes.

First, the animated polygons need to be converted into 4d polytopes. Using the intersection tool described above, the 4d scene can be "scrubbed" in a time-like way by transforming the intersecting manifold. Except that now it's possible to apply conformal transformations to the 4d polytopes before scrubbing through!

This is an old demo of 3d Moebius transformations applied to key-framed polygons: http://hyperspectives.wondering.xyz/moebius/hyperhorse.html

Except that now I'm wondering about what 4d Moebius transformations look like.

How do they deform animation? I'm pretty sure that under a 4d moebius transformation, all four of the horse's legs could be running at different rates without ever interfering with one another. Of course they'd all be different sizes too. Also, spatial dimensions of the horse geometry would melt into the time dimension, depending on what kind of manifold was doing the time-slicing. What would it look like??! I want to see!

I might actually be able to get away with using stereographic projection/rejection for time-slicing instead of intersections, but I need to think that through very, very hard. I think it'd probably result in some gnarly polygons.

By the way, another thing I'm really looking into is this: https://link.springer.com/chapter/10.1007/978-3-642-54382-1_...

I've managed to implement these clifford-bezier surface patches in Sage, haven't gotten around to OpenGL.

EDIT:

By the way, in case you're curious, the idea that the horse's legs could move at different frequencies without intersecting one another is very much related to "spacetime dilation" in the theory relativity. The principle that would keep the hyper-horse from self intersecting is conformal invariance, which is closely related to Lorentz invariance.

Probably a WebGL-Issue and not much you can do about it ...

I have 2017 MBP with touch bar. The sound kept playing, but mouse and keyboard didn't respond to anything. The game canvas was black. Couldn't quit browser or switch window from keyboard so only option was to force boot.