pouët.net

Go to bottom

Raymarching Beginners' Thread

category: code [glöplog]
I agree, but i probably badly express myself, so you didn't get my point. sorry for that. the point was, in some cases raytracing (with acceleration sctructures of course) leads to a lower rendering time. in particular when you've got over 10-100 million triangles.. with rasterisation, you'll still have to transform every triangle if it is likelly to be visible. with raytracing and a hierarchy, you won't even touch the triangles which are far from rays, and rays stop at the first intersection.. raytracing is always better in that way that it doesn't lead to any overdraw.
added on the 2011-08-18 11:12:10 by nystep nystep
I find it relativelly amusing as a sidenote that in rasterisation, that defered shading got trendy because the shading cost gets so high that overdraw becomes a bottleneck. :)
added on the 2011-08-18 11:15:20 by nystep nystep
This effect we are talking about is not the best thing one can come up with - but given how I would implement this with sphere tracing this is 1. much simpler and 2. faster under certain circumstances if you do it with sphere tracing.

Basically what you do is domain rep on cubes and then you figure out the center
for each cell of the domain rep by using ceil or floor and use this position in order to look up the radius of your cube from a second "distance field". If you now increase the number of cubes horribly by making the domain rep grid size smaller this WONT affect the performance (but you have to take some care...). So we are talking about "constant time" versus O(n^3) where n*n*n is the number of cubes on your grid.
I didn't try it - so I might be wrong - but I don't think so.
added on the 2011-08-18 13:23:33 by las las
las: surely with domain repetition, the repetition size determines the maximum size of a step. So smaller cubes = smaller step size = more steps = slower...

Plus a scene like this could have many "worst case" areas, where you have many small cubes with space between and the ray travels a long distance through close geometry - causing more steps per ray again.
added on the 2011-08-18 14:01:53 by psonice psonice
Okay, that's an ugly scenario - use bounding spheres on the "second" field first to get a good initial ray position and you gain a lot again, anyways whatever happens depends on how you do it.
added on the 2011-08-18 14:30:36 by las las
nystep: Actually, I got your point the first time. But you are wrong; you don't have to transform every triangle with, only the ones that ends up in a batch that pass occlusion culling. And when it comes to overdraw, sort your batches in font-to-back order, and early-z culling will prevent it. So in other words, we are pretty much back to the same thing: Both a perfect raytracer and a perfect polygon renderer only touch roughly the primitives that are actually rendered (a raytracer usually needs to perform some over-testing in the leave-node, and a polygon renderer does some polygon clustering). But a perfect raytracer with a tree-structure is O(log n) traversal time per pixel, whereas a perfect polygon-renderer O(1).

This is the standard problem with the way people promote raytracers: They assume a perfectly optimized raytracer, but a dumb polygon-engine.

Raytracers DO tend to have a big advantage for out-of-core rendering... when implemented on the CPU, at least. But that's a very atypical use case, and certainly off-topic here.
added on the 2011-08-18 15:14:52 by kusma kusma
kusma, i've got your point too, but you're wrong too. :) but very much out of topic indeed.
added on the 2011-08-18 15:34:19 by nystep nystep
nystep: I'd like to hear why you think I'm wrong. Just responding "you're wrong too" doesn't convince me. General renderer scalability isn't that off topic, but out-of-core rendering certainly is.
added on the 2011-08-18 15:58:14 by kusma kusma
kusma, let's stop this relativelly useless (out of topic) picking about rasterisation vs raytracing. I thought that the bottleneck was for long on the shading rather than the primitive rendering anyway.

But yes, even with all your optimisations, you'll have to transform vertex after sorting batches, so it only saves fragment processing power. sorting batches is O(n). and it also depends on how many materials you have to switch between batches. If you've got one material per batch your bottleneck might be switching shaders actually.

The traversal is O(log(n)) but in practice that logarithm base is very low. It might not cost much in terms of rendering time to switch from 1 million triangles to 1 billion in a raytracer. With rasterisation it does.

But triangles are the past anyway. So let's let the guys back to their topic. :)
added on the 2011-08-18 16:17:52 by nystep nystep
nystep: No you missed my point completely. You do occlusion culling BEFORE transforming, thus not having to perform vertex transformation for invisible batches.
added on the 2011-08-18 16:23:52 by kusma kusma
wahou, you can guess how much of an object is visible through a semi transparent tree leaf? you're so good. sorry that i'm so bad.
added on the 2011-08-18 16:25:41 by nystep nystep
GO MAKE A DEMO ABOUT IT!
FIGHT.
added on the 2011-08-18 16:34:24 by las las
nystep: Uh, it's not like raytracers can cull things behind transparent objects either?
added on the 2011-08-18 16:37:38 by kusma kusma
http://hyperfun.org/FHF_Log/Bastos_GPU_ADF_SMI08.pdf
Just found this - looks awesome. Let's give it a try.
added on the 2011-08-18 17:26:51 by las las
Thanks for the feedback. Same stuff in all directions here with no shading but good enough for a sketch.
BB Image
And I don't really know if it worth finalizing(shading, texturing, refracting B-) ).
And since it's totally possible to use triangles resterisation and raymarching(-tracing, -wobbling, -bending) I'd really like to see software rasteriser on GPU that benefits from all the possible techniques. For now I'll just stick with what I can easily implement, because you know reasons ;)

p.S. Did anyone else noticed that even mentioning "unlimited anything" tend to cause flames?
added on the 2011-08-18 17:46:42 by a13X_B a13X_B
kusma: ye you're right. i must have been high when i mentioned marching-squares. but, in theory it can be done, but it a waste of space if the grids are as small as that on the picture. it's only usefull if you don't want to evaulate each point.

i actually did the 3d version in this sucky demo from 2002: http://www.pouet.net/prod.php?which=5563
added on the 2011-08-19 00:18:47 by rudi rudi
bah. wait. i might be wrong, again. buuuh. it might be a plasma function instead, i can't really remember :( and i dont wanna watch that ugly demo again. and i think i lost the code.
added on the 2011-08-19 00:20:31 by rudi rudi
anyway, those who are talking about marching cubes and think that it has something to do with rasterization, is totally wrong.
added on the 2011-08-19 00:26:09 by rudi rudi
Any idea to do generate a sphereflake for fast raymarching? :)
added on the 2011-08-19 01:47:58 by las las
Something like this one would be awesome BB Image
From here http://www.ugcs.caltech.edu/~andrei/papers/is98/is98.html
added on the 2011-08-19 01:52:41 by las las
I also want to join the cube-sphere club!

BB Image

Not quite sure I understand every line of code I found here or in the rm toolbox thread, but it's going forward.. I have do write p = mod(p+0.5, 1) - 0.5 instead of just mod(p) to avoid horrible distorted chaos. Is this normal?

My second OpenGL project so don't judge it too hard. also made a 2d plasma in glsl earlier this week
added on the 2011-08-19 21:33:24 by sprkng sprkng
sprkng: welcome to the club! Nice shape + lighting (is it lighting + iteration count?)

You can probably just do mod(p+0.5, 1) btw. The cube will move on screen, but repeat will still work normally. Or maybe even just mod(p), and set your cube to have it's centre at 0.5.
added on the 2011-08-19 21:48:21 by psonice psonice
Thanks! It's phong shading + iteration count for hue. Going to try adding AA and real lighting next
added on the 2011-08-19 22:08:07 by sprkng sprkng
BB Image
added on the 2011-08-20 11:35:07 by las las
I really don't want to pouetize this thread, but I can't resist... It's stronger than me.

BB Image
added on the 2011-08-20 11:39:23 by torus torus

login

Go to top