ray marching a cloud fly-through

[bergi]

hello world,
i'd like to share this patch with you.
it's a ray marching, or ray casting shader used to do this lovely sky below.

ray-marched clouds

clouds2.jpg (23.57 KiB) Viewed 423 times

for any one new to the term 'ray marching', it's a technique to sample media (density) along a ray. as opposed to real ray-casting, which normally is used to find intersections between lines and other geometry, the ray-marching algorithm samples a scene in a discrete step size. you can only do little optimization on that. it is more like the brute force approach. anyways, gpus have become unbelievably fast, that we can almost forget what's behind the algorithm when watching the patch below

raymarchA.toe

ray-marching a cloud fly-through

(7.46 KiB) Downloaded 78 times

description and comments are included

[keithlostracco]

Totally awsome Bergi. Thanks for the example.

I've been thinking about learning to write a ray marching shader to render thousands of cubes. I've found when instancing/drawing geometry there are unavoidable limitations to the number of instances/points and was thinking that if I can write a shader that uses ray marching and render the scene only within the pixel shader, I would then be able to have a relatively unlimited number cubes.

Do you think it would be possible? If so would you have any tips on how to get started?

nice work
cheers
Keith

[bergi]

thanks keith.
well, quite good explanations and much more impressive examples can be found on IQ's website http://iquilezles.org in the 'strawberry' pages.

the thing you probably want to look at is 'distance field ray-marching'.
see, as noted above, pure ray-marching is very expensive. it won't help you rendering a lot of instances much faster. in this cloud example it does a nice job and one does not need a very high resolution for the fluffy graphics. if you want to render geometry instead, that means you must find surfaces of objects that are defined in some way. well, let's dive into some detail.

in typical ray-tracing, you test the current ray (a line starting at the camera and going endlessly in the direction of view) for intersections with the shape of every object in the scene. this can be optimized a lot by building axis aligned bounding boxes around more complicated objects and whole parts of the scene. finally you build some tree-structure that enables you with a few intersection tests to figure out which objects wont be touched by the ray and which might need further investigation.

anyways, that's raytracing. if we forget about reflections, transparency and anti-aliasing then we have to do exactly one ray/scene-intersection test for each pixel-on-screen. for the moment, assume ray-marching geometry would be the same procedure, except that the ray/scene-intersection test has to be done a LOT more times for each pixel, since your actual 'ray' is only a small sub-section of the infinite ray, and it's moved this small bit after each ray/scene-test. that's not what you want to do however, just wanted to clearify the concept a bit.

ray-casting or -marching has a lot of advantages over z-buffer polygon rendering, but certainly it's not the execution speed. in particular you can render much more exact and/or complex/organic geometry. f.e. a sphere in opengl is actually a bunch of triangles. to get it exactly 'round' at a reasonable resolution you have to do a serious amount of subdivision. in raytracing you can simply state: sphere at xyz with radius r and use a geometrical sphere/line intersection test to find the surface which renders a perfect sphere in the end. besides, doing transparency, reflections, shadow and anti-aliasing can be done with the same algorithm, once it's working, with only minor additions. but i get lost here... i only wanted to say that, if speed is a concern for you when rendering a lot of geometry, you will not exactly find help in ray-casting. but it certainly can make things look nicer.

the 'distance field' technique is one major optimization to the brute-force ray-marcher. it works best for rendering surfaces and not so much for the cloud-thing above. the interesting part is that once you got a reasonable implementation running, you can indeed render an unlimited amount of instances at nearly the same speed. more precisely, copies of your scene or parts of it, or simply instances. but there are some constraints as you will learn. simply said, if you want a cube, a sphere, an iso-surface, what-ever - no problem. if you want the same object at, say, EVERY integer x,y,z position, as far as the eye can see - no problem - then some slight sine-waves that bend the universe - no problem. what about reflections, smooth shadows and volumetric lighting? - certainly. if you want a thousand objects at completely arbitrary and user-defined positions - that's a problem.

i won't repeat all the good tutorials about it here. rather i point you to this presentation:
http://iquilezles.org/www/material/nvsc ... ne2008.htm
and hope you make the best out of it and the other stuff on this amazing site.

one thing though. writing such an algorithm in an opengl shader is nice and easy but does not scale to well. it's good for tiny scenes with not really much going on. for complex scenes, one would have to pack the scene data into textures or something like that. it's probably more appropriate to do it in CUDA or openCL because of the ability to send arbitrary data to the gpu. also, say you find that your scene has grown up and just looks so astonishing that you don't really care that it's not realtime anymore. but running an opengl shader that takes a second or so to return will lock your whole operating system.

that should not sound pessimistic in any way. i'm just sharing some experience with that kind of stuff. there are great applications for ray-marching. get used to it and let the artist in you decide.

[keithlostracco]

Thanks for the explanation and the links. I wasn't sure exactly what I would need to do but I knew it was something along those lines. I've been playing around with some of the new 3d fractal programs that use some of those methods (Mandlebulber and Fragmentarium). I did manage to port a Menger Sphonge and a Mandlebulb into Touch although I still don't fully understand their shaders fully.

My plan for the cubes might be a little huge to start with and might be quite difficult to do based on what you had said about using defined points. My idea is to have a 3 dimensional grid of cubes lets say 1000x100x1000. Each cube has it's own 2d texture for each face as well a 3d texture (so each cube can have a different image while all playing the same movie).

Then the cube's main (solid color) and opacity are determined by individual pixels of multiple color maps using uv coordinates that extend to the boundaries of the cube. The first method would be to use 3 texture being projected orthographical onto the 3 different plans. The second would be to use two or more maps projected along y axis onto the zx plane the are then blended from the bottom row of cubes to the top row. There is a third method that is only really practical for a few layers which uses 1 map for each layer (I have a geometry version using 4 layers), and then the 4 method would be to use a 3d texture.

All this to have a final animation of a 3d image made of (bevelled) cubes that's overall shape at any give moment is based on textures. Although I'll be happy to start with just a bunch grey blocks with positions totally based on math in the shader.

Checking out the Quilez sight I found he had bunch of functions for drawing primitives and the tutorial for the menger sphonge. I think that would be the best place to start.

thanks for tips
cheers
Keith