pouët.net

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.

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. :)

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.

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.

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.

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.

kusma, i've got your point too, but you're wrong too. :) but very much out of topic indeed.

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.

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. :)

nystep: No you missed my point completely. You do occlusion culling BEFORE transforming, thus not having to perform vertex transformation for invisible batches.

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.

GO MAKE A DEMO ABOUT IT!
FIGHT.

nystep: Uh, it's not like raytracers can cull things behind transparent objects either?

http://hyperfun.org/FHF_Log/Bastos_GPU_ADF_SMI08.pdf
Just found this - looks awesome. Let's give it a try.

Thanks for the feedback. Same stuff in all directions here with no shading but good enough for a sketch.

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?

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

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.

anyway, those who are talking about marching cubes and think that it has something to do with rasterization, is totally wrong.

Any idea to do generate a sphereflake for fast raymarching? :)

Something like this one would be awesome
From here http://www.ugcs.caltech.edu/~andrei/papers/is98/is98.html

I also want to join the cube-sphere club!



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

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.

Thanks! It's phong shading + iteration count for hue. Going to try adding AA and real lighting next

I really don't want to pouetize this thread, but I can't resist... It's stronger than me.