www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - very simple pure CPU raymarching demo

reply ketmar <ketmar ketmar.no-ip.org> writes:
the following[1] is the demo of pure CPU implementation of the 
famous "raymarching" algorithm[2]. of course, doing that in GLSL 
shader will be many times faster (10x? 20x? dunno), but i'm too 
lazy to port the necessary gl headers (and don't want to use 
derelict for some random reason ;-), so i did it on CPU.

it's basically the fragment shader code, executing on CPU instead 
of GPU.

of course, one can use more threads to render image parts, but 
i'm too lazy to implement that (let's say that i left this as an 
excercise for a reader; i know you all love such "excercises").

you will need Adam's simpledisplay.d and color.d from here[3].

no OpenGL required.


[1] http://ketmar.no-ip.org/dmd/zrm3_adam_trd.d
[2] 
http://iquilezles.org/www/articles/raymarchingdf/raymarchingdf.htm
[3] https://github.com/adamdruppe/arsd
Jan 24
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
ok, just4fun, mulththreaded renderer[1]. set ThreadCount to 
number of your CPU cores to get some speedup.

note: this is not how `std.concurrency` should be used! please, 
don't do wroker queues as i did!

[1] http://ketmar.no-ip.org/dmd/zrm3_adam_trd_x4.d
Jan 24
parent reply karabuta <karabutaworld gmail.com> writes:
On Sunday, 24 January 2016 at 14:18:23 UTC, ketmar wrote:
 ok, just4fun, mulththreaded renderer[1]. set ThreadCount to 
 number of your CPU cores to get some speedup.

 note: this is not how `std.concurrency` should be used! please, 
 don't do wroker queues as i did!

 [1] http://ketmar.no-ip.org/dmd/zrm3_adam_trd_x4.d
This is the kind of maths I hoped I could try to understand. The spirit is not there :)
Jan 24
parent ketmar <ketmar ketmar.no-ip.org> writes:
 This is the kind of maths I hoped I could try to understand. 
 The spirit is not there :)
it's very easy, actually. the basic idea is this: our "primitive" functions returns distance from a given point to the primitive. i.e. auto point(1, 2, 3); float dist = BoxPrimitive(point); now `dist` is a distance from `point` to our box. it's by definition a shortest possible distance, of course. now, to trace a ray, we are doing basically this: try all primitives and find the minimal distance to ray origin. then we know that we can safely move ray forward by that distance, 'cause it won't hit anything by the way. so move it, and repeat the process. stop when we made some number of steps or minimal distance is less then some threshold. whoa, we succesfully found our hitpoint! (and with some trick we also know wich primitive we hit) basically, that's all. now just fire rays for all screen pixels, and color the pixels according to primitive color, adding some lighting to make image sexy. the math is our ordinary vector algebra and light calculation, nothing arcane. to calculate lights, we can use the same "find minimal distance" function to get light intencity for the given point. this is a win, 'cause we don't have to really trace a ray here. of course, this is the simpliest case: light without shadow casting. to cast shadows, we have to trace a ray for real. using "distance field" will allow us to do some more tricks too: easy soft shadows, ambient occlusion and others. they are, of course, possible with traditional raytracing too, but more expensive. of course, the more objects our scene has, the slower it renders, as we don't try to do any space partitioning. something like that. the code is really simple, just try to work out some simple primitive formula, and you'll get it.
Jan 24