Thanks for the help with sphere tracing...
category: code [glöplog]
nice. very shroomy ;D
Nice!
Music fits the trippy landscape perfectly. :)
Music fits the trippy landscape perfectly. :)
<3
minecraft on acid? :D
Looks great, but isn't that a bit heavy for a game?
Is that some kind of fake SSS material? :)
nice
This is bloody cool.... is it a game or something ?
this!
for everybody wondering wtf this is I advise to check out the Duangle Blog
This looks great. Awesome colors.
Great!
Very cool looking. What are the game mechanics?
Thanks for all the feedback :)
Gargaj: kinda. ;)
xernobyl: yeah, it kinda is *guilty look*. But we're going to take another one or two years until release and by then I think most people should be on a GTX 460 level from which the game becomes playable. We also offer detail settings for different rigs, so... it would really be a shame to waste that opportunity for a new tech just to be nice to low end PC's - high end users want some toys, too.
las: No, but nice idea. I've been thinking about refractive materials, but they are expensive... at the moment, I'm doing all shading in a second pass, and that wouldn't be possible anymore. I think. Or not?
gloom: check the game site for some more details... duangle.com/nowhere - some planned features are mentioned there.
Gargaj: kinda. ;)
xernobyl: yeah, it kinda is *guilty look*. But we're going to take another one or two years until release and by then I think most people should be on a GTX 460 level from which the game becomes playable. We also offer detail settings for different rigs, so... it would really be a shame to waste that opportunity for a new tech just to be nice to low end PC's - high end users want some toys, too.
las: No, but nice idea. I've been thinking about refractive materials, but they are expensive... at the moment, I'm doing all shading in a second pass, and that wouldn't be possible anymore. I think. Or not?
gloom: check the game site for some more details... duangle.com/nowhere - some planned features are mentioned there.
paniq: very nice. :)
1-2 years? i want my "high end toy" now :) this looks and sounds so awesome. i would be afraid to loose orientation in impossispace too fast though. at least at the beginning :)
Did you consider adaptive rendering? Something like Heaven 7 did, but in a more GPU-friendly way.
You could basically start with 2x or 4x smaller rendertarget and render corner pixel of 2x2 or 4x4 grid. Then during upsampling you can decide whether to interpolate or not. Probably best done using Z-buffer (output interpolated value or discard pixels then run extra rays in second pass on pixels not written), and high-resolution rays could start from distance found in first pass (e.g. minimum of neighboring results) to save some initial steps.
Looks like there is a lot of space for optimization.
You could basically start with 2x or 4x smaller rendertarget and render corner pixel of 2x2 or 4x4 grid. Then during upsampling you can decide whether to interpolate or not. Probably best done using Z-buffer (output interpolated value or discard pixels then run extra rays in second pass on pixels not written), and high-resolution rays could start from distance found in first pass (e.g. minimum of neighboring results) to save some initial steps.
Looks like there is a lot of space for optimization.
nice! though KK, before going to packet tracing, I would first go with cone step raymarching to avoid unnecessary steps generated by the regular "sphere tracing" technique.
Also an octree based marching cubes like tesselation could be worth looking at if you've got time. And there's that GPU gems article that everyone as read 2 or 3 times... http://http.developer.nvidia.com/GPUGems3/gpugems3_ch01.html
skomp: yeh - master pieces take at least three years. i restored planetary gravity again yesterday. i had to do it, i got sea sick. and it's better this way, you can now plunge yourself into the depths and climb up again. :)
KK: did you tweet this to me earlier? because the topic came up... i'll definitely give it a whirl. i tried a similar idea before but the thinking was flawed; the heaven seven approach could work tho - esp. since the color buffer only contains xyz positions at the moment.
xoofx: that's what i did - one pre-step with huge 32^2 pixels and fat cones to do the first steps, and a per-pixel step to walk the rest of the distance. it produced horrible artifacts in corner cases, even with bilinear lerp, and didn't actually speed up things much - the first steps are the cheapest; it's tracing the edges that is the costliest step, and a pure "pyramid histogram"-like technique could already do wonders here...
...or not, since we're only optimizing away stuff that's not very expensive anyway, and are still left with the hard stuff. I guess I'll find out soon.
xernobyl: marching cubes tesselation and the GPU gems article is exactly what i wasted my time with for three weeks. when you are trying to avoid geometry shaders, then it's clunky, it's wasting memory, you lose a lot of exciting "surface morph" possibilities, and it's especially not infinite. you can't just scan a huge perpetually changing landscape volume into marching cubes in under 60 seconds. it's a shitload a code for something that is effectively very static and also ugly at close distance. MC meshes look horrible. let's not go there anymore, i don't want to read any more papers. they're all insane.
KK: did you tweet this to me earlier? because the topic came up... i'll definitely give it a whirl. i tried a similar idea before but the thinking was flawed; the heaven seven approach could work tho - esp. since the color buffer only contains xyz positions at the moment.
xoofx: that's what i did - one pre-step with huge 32^2 pixels and fat cones to do the first steps, and a per-pixel step to walk the rest of the distance. it produced horrible artifacts in corner cases, even with bilinear lerp, and didn't actually speed up things much - the first steps are the cheapest; it's tracing the edges that is the costliest step, and a pure "pyramid histogram"-like technique could already do wonders here...
...or not, since we're only optimizing away stuff that's not very expensive anyway, and are still left with the hard stuff. I guess I'll find out soon.
xernobyl: marching cubes tesselation and the GPU gems article is exactly what i wasted my time with for three weeks. when you are trying to avoid geometry shaders, then it's clunky, it's wasting memory, you lose a lot of exciting "surface morph" possibilities, and it's especially not infinite. you can't just scan a huge perpetually changing landscape volume into marching cubes in under 60 seconds. it's a shitload a code for something that is effectively very static and also ugly at close distance. MC meshes look horrible. let's not go there anymore, i don't want to read any more papers. they're all insane.
in under 60 seconds -> in under 1/60 seconds. of course you can scan anything in a minute.
paniq: I tried something like what kk suggested before and got a good speed increase, but it would depend heavily on your scene.
What I did was basically shade a grid instead of a single quad, and raymarch in the vertex shader. It's easy to change the step size this way by just changing the grid size, and you can easily pass multiple values to the fragment shader as varyings.
In my case I used it to pass the depth and the object ID to the shader. The object IDs were all integer values but passed as a float - this way you can check in the fragment shader, and if it's an integer value you know the current pixel includes just one object, and that's all you have to march. If it's a fractional value you render the full scene. This could obviously be a lot better, but it worked :)
Stuff that didn't work so well: anything smaller than a grid square can be inside the square, not detected, and never rendered. Using the depth value was dodgy too - with a signed field it's not so bad, but still small details can be cut and holes can appear. It's good to step back from the interpolated surface some way before marching ;)
What I did was basically shade a grid instead of a single quad, and raymarch in the vertex shader. It's easy to change the step size this way by just changing the grid size, and you can easily pass multiple values to the fragment shader as varyings.
In my case I used it to pass the depth and the object ID to the shader. The object IDs were all integer values but passed as a float - this way you can check in the fragment shader, and if it's an integer value you know the current pixel includes just one object, and that's all you have to march. If it's a fractional value you render the full scene. This could obviously be a lot better, but it worked :)
Stuff that didn't work so well: anything smaller than a grid square can be inside the square, not detected, and never rendered. Using the depth value was dodgy too - with a signed field it's not so bad, but still small details can be cut and holes can appear. It's good to step back from the interpolated surface some way before marching ;)
paniq: That wasn't my tweet.
Another solution would be to split work into full screen passes. Let's say first pass does half steps, and second one the rest. The first pass could then emit Z values that will kill already stable pixels on early Z in second pass. The point is, to stop as much work on early Z as possible. Early exit and/or discard within PS is too late, because as soon as pixel gets into usually 64-pixel wide dispatch, it will stay there untill any of the 64 pixels does some computation (and you can bet one of them will hit some stubborn edge).
Sadly, this approach doesn't scale that well to more than 2 passes, because emitting Z from PS will usually disable early Z (unless you use conservative Z functionality).
Another solution would be to split work into full screen passes. Let's say first pass does half steps, and second one the rest. The first pass could then emit Z values that will kill already stable pixels on early Z in second pass. The point is, to stop as much work on early Z as possible. Early exit and/or discard within PS is too late, because as soon as pixel gets into usually 64-pixel wide dispatch, it will stay there untill any of the 64 pixels does some computation (and you can bet one of them will hit some stubborn edge).
Sadly, this approach doesn't scale that well to more than 2 passes, because emitting Z from PS will usually disable early Z (unless you use conservative Z functionality).
MC meshes look horribletry surface nets