So, what do distance field equations look like? And how do we solve them?
category: code [glöplog]
The exe is quite a mess because it's loads a bunch of shaders from several locations. Working on my last 64K intro for a few years now ;)
I can prepare something tomorrow ok? Now I am going to read and sleep :)
I can prepare something tomorrow ok? Now I am going to read and sleep :)
Heh ok :)
Welldone on getting the algorithm to work (and yes, the .005 thing actually yields a HUGE speed increase in most cases; especially with most of your screen not hitting anything at all and with such a fast card).
Goodnight!
Welldone on getting the algorithm to work (and yes, the .005 thing actually yields a HUGE speed increase in most cases; especially with most of your screen not hitting anything at all and with such a fast card).
Goodnight!
CrossProduct, it's not 0 it's 0.001 for us, still shouldn't make that much of a difference.
If you want an exe: please e-mail me at rob _ aardbei at hotmail dot com, so that I can reply you and send an exe tomorrow.
Goodnight!
Goodnight!
Ah i see, so it really WAS the card that was making it so fast :) (~20FPS on a gf8500GT with no lighting or expensive primitives and mostly blank space)
It was a good and simple implementation - no branching, no BS, just clean code straight from this thread :)
Glad it worked so well for you! Keep it up.
It was a good and simple implementation - no branching, no BS, just clean code straight from this thread :)
Glad it worked so well for you! Keep it up.
oh man, I need a better card
~20 FPS? Oh my :)
It's good to hear I'm not completely crazy though :D Thanks for testing!
It's good to hear I'm not completely crazy though :D Thanks for testing!
phew, this just saved me from committing suicide. I mean if that code was running at some 50 FPS on GeForce 8500 GT I would have so done that.
Good thing I claimed from the beginning it was the card and not my special coding abilities ;)
and this shows that those new ATI cards are numerical monsters. Time to change the green for the red again!
Too bad shader compilation time is slow as fuck with ATI it seems :(
When I included some perlin noise stuff it took the compiler 2 minutes and 1200 MB of RAM to tell me about an error in the shader.
When I included some perlin noise stuff it took the compiler 2 minutes and 1200 MB of RAM to tell me about an error in the shader.
From 300FPS to 20FPS? Wow!
Now I get it where I should run Muon Baryon in realtime :) (I was running it in GF8600 and it was still extremely slow and wondered if maybe I needed a GF twelve or something?)
Now I get it where I should run Muon Baryon in realtime :) (I was running it in GF8600 and it was still extremely slow and wondered if maybe I needed a GF twelve or something?)
No lol, I read the ATI was slower in this 4k. And it says something about 8800 with P.S.4. So where the shaders emulated in software for the 8600?
CrossProduct: Think about not bloating your code size due to function inlining or loop unrolling (ie sometimes you have to trick the compiler not to unroll etc). You're probably generating a huge shader program - the gpu shader analyzer can show you. Too big programs will also slow the gpu down. Muon Baryon is the horror example of this.
Btw I guess that most of the shader compile time in HLSL comes from the microsoft compuiler.
Btw I guess that most of the shader compile time in HLSL comes from the microsoft compuiler.
Just a question. Those 3d plasma alike (like in Dollop and many other old intros) are they represented as a abstract equation of sines additions where this algorithm works? Or are the plasma written in a voxel field and then the algorithm is applied in the voxel field? Because in the second case, I thought it would look blocky, but those 3d alike plasma things morph and change shapes so smoothly and the look soooo curvy, that I initially thought it can't be raymarching on voxel field but something different.
Optimus: My best guess for Dollop is that kurli does dome fixed ray-testing at a coarse resolution, and some interpolation in the end to find the exact hit. You can see sometimes that it misses, but it's all hidden pretty well. In other words, I don't think it uses distance functions at all. But I might be wrong, of course.
I had my plasma formula for simple raymarching (without distancefields).. and it somehow resembled to a very smooth looking surface because of some artifact in the compare function which looked for a hit..
Btw, a scene like the screenshot with same cube size etc runs around 125 fps here on 4670 in 1600x1200. So numbers seems reasonable.
The raymarching in dollop is some mixture between distance functions and regular step size. I'd say that the evaulation function evaluates density, but this value is to some extent used to control the step size.
Code:
return max(length(max(abs(p)-vec3(.4),.0)),.5-length(p))The raymarching in dollop is some mixture between distance functions and regular step size. I'd say that the evaulation function evaluates density, but this value is to some extent used to control the step size.
hey CrossProduct, could you give these exes a try and tell me how fast they are in your ATI card? It's Slisesix rewritten for the GPU (straight port from the C to GLSL). http://www.iquilezles.org/trastero/rgba_slisesix_glsl.zip. Let's see how far it is from realtime. Thanx!
(I post here because these prod was a distance field raymarching thing of course - just to clarify)
Just an idea I have had after reading this post, but I have no time to try to develop it:
- Instead of using perspective, you can do distance field rendering for parallel proyection. This is easy.
- With parallel proyected it looks that you can trace by groups of rays instead of ray by ray - I suppose this would be difficult for GPU, easier for software rendering. If you do it by groups of rays - let say, 5x5 rays, and you trace the central one, then you can check the other rays with just the spheres given by the central ray, and not will all the scene. When the rays are not inside the spheres given by the central ray, then the raytracing continues for those rays the common way.
- This *might* speed up a bit the process... maybe.
- Finally, you can deform the whole scene to look like perspective proyected... maybe.
What do you think?
- Instead of using perspective, you can do distance field rendering for parallel proyection. This is easy.
- With parallel proyected it looks that you can trace by groups of rays instead of ray by ray - I suppose this would be difficult for GPU, easier for software rendering. If you do it by groups of rays - let say, 5x5 rays, and you trace the central one, then you can check the other rays with just the spheres given by the central ray, and not will all the scene. When the rays are not inside the spheres given by the central ray, then the raytracing continues for those rays the common way.
- This *might* speed up a bit the process... maybe.
- Finally, you can deform the whole scene to look like perspective proyected... maybe.
What do you think?
Sounds like a borked adaptive subsampling RTRT algorithm from the late 90's :)
Ferris, not borked... the spheres calculated by this ensure that there is empty space there... I suppose there should be a way to use it to speed up rendering
well, maybe the way I wrote it is borked, but there should be a good way to use that to speed up rendering...
Heh I didn't mean borked in a bad way :)
The boxing thing would be really impractical on the gpu since you'd have to draw a bunch of quads over the screen, instead of the one normally used.
Though this method would be interesting to try in software.
The boxing thing would be really impractical on the gpu since you'd have to draw a bunch of quads over the screen, instead of the one normally used.
Though this method would be interesting to try in software.