... I might experiment with them a bit more for this side project - they are a real Swiss Army Knife of sorts
Swiss Army Knife for a reason.
Raycasting is essentially a bute-force method which is pretty easy to
implement and virtually solves all problems (Swiss Army Knife), if just the
complexity wouldn't rise in orders of magnitude rather quickly. However,
there is nothing easier than probing (point-sampling) an environment and
take action on it. The main optimization is always cutting down on the
amount of rays fired. Second, to limit the extend of the rays. Third, to
simplify the geometry of the objects the rays interact with. Fourth, to
build spatial data structures (BVH etc.) to limit unnecessary ray-object
intersections.
The problem with all the more advanced optimizations is that with each one
the flexibility of the whole thing decreases, being the worst if you need to
make your geometry static to gain more optimization. Static scenes allow for
the best optimization no matter what.
So it's important to think about how flexible the engine/game should be/stay
when major parts are being based on raycasting to solve problems. However, it
basically boils down to this; great flexibility requires you to limit the size
of your world resp. the amount of objects in that world. Hence, there is a
sweep-spot somewhere. If the flexibility of the game should be great, than the
game/gamplay needs to be realizable within a more limited world resp. with
fewer objects. On the other hand, if there should be plenty of things to
watch like lots of eye candy objects in a huge world, than this will
restrict the flexibility of the game considering having to raycast them all.
The above basically describes a method for creating games for indie
developers running on a low budget. For one, you can't really create huge
assets right from the get-go (not even speaking about optimizing them it for
different platforms). However, if your gameplay just needs a few objects,
then you can basically raycast through the environment like crazy solving a
lot of problems making the interaction very flexible. For example, you can
keep the geometry of the objects very dynamic. No problem if intersecting
them is more difficult because there are only a few of them. And with
objects being dynamic in shape, one can already build create gameplay from.
Another interesting aspect considering raycasting is; as less you use any
sophisticated optimization, as better it can be parallelized on multiple
cores. This basically rests on the fact that brute-force algorithms are
usually trivial to parallelize (many independent sub-problems). Hence,
instead of doing any heavy optimization (which will ultimately restrict the
flexibility to some degree) you make up for it by distributing the rays over
multiple cores utilizing the many cores in a lot of machines theses days.
(wasn't this the reason Pixar went away from REYES over to a full ray-based
rendered?). This becomes even more feasible today than years ago due to
unified memory. Hence, you don't have to partition geometry loading parts of
it into memory of a given core. In principle, you basically just partition
said rays with the only difficulty to balance the load on said cores. But if
you have too much cores computing the hell out of it, then the bottleneck may
become memory contention. But looking at the high bandwidths these days and
of the future, there should be enough room for making some good computation.
With the ever increase in performance, such a solution becomes more and more
feasible even at larger scales. I think this is a reason for many graphics
engine now incorporating a lot more raycast/tracing techniques for realizing
otherwise difficult effects. Wouldn't be surprise if future consumer graphics
accelerators will feature ray-triangle intersection in hardware.
Anyhow, cool topic, lots of possibilities.
