I've dabbled in trying to do procedural generation in the past (in particular to make good looking trees), and I feel like the missing component (to me) was easy ways to connect geometry. It's easy to make two cylinders, but then trying to join them together is very hard.
In theory CSG can fill this niche, but it can be a bit difficult to think about the problem in that way (for me, at least) since you can no longer view it as just for looping to add vertices, but you instead need to model everything as a 3d shape.
I tried building some routines to take two loops of vertices and connect them through heuristics by adding faces, but I had a hard time getting it to work well (choosing which vertices should connect was much harder than I expected, it was easy to get really bad looking connections).
What I really want to do someday is make a game where there is a system for different modular procedural generation systems to work together in a way that allows for spontaneity. So e.g., systems could "claim" slices of the world, delegate parts of it to other systems (e.g., put some plant here) and connect with other adjacent things.
I would advise to keep at it and not overcomplicate things.
There was a recent video on creating generative trees [0] and the hack was to just let the cylinders intersect, so even hacky tricks can work and produce good results. As you say, CSG can work but might be overly complicated. Another trick is to create a tree skeleton and then do lofting, maybe even combined with CSG, to create the trunk and bark.
For me, a good library is enabling and finding a good 3d geometry library, maybe to do boolean operations, like joining cylinders or subtracting geometry out, helps enable a lot of new ideas. I've played with a few geometry libraries and the only one I even vaguely like is JSCAD [1].
Look up signed distance fields. They are the most elegant CSG solution by far for procedural geometry. It's kind of like a functional way to describe and morph 3D shapes.
Highly recommend searching for Mercury Delight on YouTube for an idea of what people have done in the demoscene with it. Also lots of examples on shadertoy. It's amazing stuff.
Upon further reflection, what's really happening in that example is that I'm using non-CSG primitives provided by OpenSCAD, so I retract my comment (at least partially).
Good terrain generation is not trivial, either at world scale or down at eye level. The straightforward approach yields what you see in the article, a craggy heightmap which looks like almost nothing in reality and isn't particularly interesting to explore.
Dwarf Fortress for example starts with basic midpoint displacement but then does a lot of custom massaging.
This is the entire problem with the game industry.
Nothing shown in this article is even vaguely trivial. The author is very obviously a 100x'er by comparison to almost every human on Earth (with GPU shader rendering specifically). The "straightforward approach"? "Straight forward..."?
Out of 8,000,000,000 humans, what percent of them can implement even the "hello world" steps necessary to start this article? Hey y'all, how many even know what a shader is? There's such a huge amount of OpenGL jobs... ("what's OpenGL, we only use Unity")
How about online gamers? What percent of the 1,021,282 players current online for Counter Strike 2 (7/28/2024, 1:22 PM EST) [1] can even implement the first steps of the shaders necessary for the game they're playing?
What percent even know how to compile a simple command line c++ program or write an even more simplistic Javascript script in a browser? Note, this is vaguely a trick question, as most humans can barely operate email.
Why are we comparing a technical skill to all 8 billion humans on earth. Like you said, if you can make a hello world program, you're probably better than 99% of humans by default at programming. But that's not a very useful metric.
Also, I'm not quite sure how this turned back around to your "thesis". How does this make a problem with the games industry, exactly?
> How about online gamers? What percent of the 1,021,282 players current online for Counter Strike 2 (7/28/2024, 1:22 PM EST) [1] can even implement the first steps of the shaders necessary for the game they're playing?
It's like asking what percent of the drivers can build a diesel engine. And call it "the entire problem with automobile industry".
Sorry, but this is just nonsense. Of course few users can build the thing they use.
I believe his point was this is labeled "straightforward" while being a highly technical subfield of programming, itself a rare profession, that few people could create.
The point, as I see it, is that the combination of skills demonstrated in the article is pretty rare. Most users of the (game) technology take certain things for granted, but they are not trivial, and the number of people who can do these things well is not a few million but possibly a few hundred. And most of these few don't make indie games. Hence the complaints about things not being ideal are, well, not very useful.at best.
Big companies that can afford it overcome this via specialization. An artist who does concept art and general animation may have zero skills writing shaders, etc, thus the rare one-man-show combination of skills is not required.
> and the number of people who can do these things well is not a few million but possibly a few hundred.
I briefly walked through the article and I can confidently say these techniques are well-known among graphics programmers. These days even artists who can't write code know what triplaner mapping and PBR are, even though they can't implement them from scratch.
Doing something "well" is subjective, but there is no chance there are only less than 1000 people who know these.
I'm still thankful to the author for writing these down, of course.
What is the "problem" you speak of in the first sentence? I don't see it explained in the rest of your post.
Are you just pointing out that this is a very specialized field that requires having studied/learned a lot of complex inter-related topics and that most of us have not done so?
I have had mixed experiences with using depth pre-pass. When I tried it a few times, I didn’t see any significant performance improvements on midrange to high end desktop GPUs. I'm not entirely sure why, but I suspect it was due to early Z rejection saving pixel shader invocations. Typically, I render my opaque meshes in front-to-back order.
To be fair, my experimentation was within the context of a CAD/CAM application rather than a game. The scenes were quite different from typical game environments, with minimal textures and very high-poly geometry.
All of these techniques are super situational and depend not only on the overall game and engine but on the specific artwork and scene composition etc.
Depth pre-pass is also often the first step of occlusion culling, but again that’s situational. Much more likely to be useful for a complex cityscape than a CAD model.
Yeah, a depth prepass won't help you if you're vertex bound. It's most useful when you have high depth complexity and expensive fragment shaders (which to be fair is most games). It's also not usually required for a deferred renderer, but for forward+ it's normally a decent win.
In theory CSG can fill this niche, but it can be a bit difficult to think about the problem in that way (for me, at least) since you can no longer view it as just for looping to add vertices, but you instead need to model everything as a 3d shape.
I tried building some routines to take two loops of vertices and connect them through heuristics by adding faces, but I had a hard time getting it to work well (choosing which vertices should connect was much harder than I expected, it was easy to get really bad looking connections).
What I really want to do someday is make a game where there is a system for different modular procedural generation systems to work together in a way that allows for spontaneity. So e.g., systems could "claim" slices of the world, delegate parts of it to other systems (e.g., put some plant here) and connect with other adjacent things.