pouët.net

Just started cleaning up the code and had an idea, and I see what the problem is now. This might apply to raymarching too, in some cases, depending on the 'distance to sphere' implementation and the scene.

What happens is roughly this:

- You have a reflective object in the centre of the scene (like my shiny ball above)

- You have an inverted sphere enclosing it (radius is negative, or you're doing min(obj, -sphere) or similar). This is the 'sky' in my pic above.

- With an inverted sphere, you only see the "far side" of the sphere, so the front is open. You can't see the 'front' of it.

- The reflection means you can see the back AND the front in the camera view. Worse, in a sphere reflection, the viewing angle is extremely wide - more than 180 degrees, so you see the front and back together.

- The front is invisible, so in some cases you'll only see the reflection of a hemisphere. In my case, I see both sides, but there is a glitch at the seem (not sure why this is, but I remember having trouble with this before so I guess my fix is slightly fucked).

That should be pretty simple to fix - maybe you screwed up the sphere intersection test?

Yeah, I think i understand where I went wrong now. The 'glitch' is caused by the different perspective between the front and rear halves of the sphere. Just taking the negative of the distance is not enough here, I'll have to rewrite it.

you must have a bug, cause the sky is reflected wrong too: red left, green right, but the sphere shows the opposite. a sign bug, or the wrong order of params in the reflect() function, or something like that?

by the way, No Chrome Spheres Over Checkboards Permitted In This Thread, please! :D http://www.pouet.net/prod.php?which=32735

you must have a bug, cause the sky is reflected wrong too: red left, green right, but the sphere shows the opposite. a sign bug, or the wrong order of params in the reflect() function, or something like that?

by the way, No Chrome Spheres Over Checkboards Permitted In This Thread, please! :D http://www.pouet.net/prod.php?which=32735

huh? how did i do that?

Ninja skills, that's how. Or coders stutter.

Actually I started with a nice (as in stolen) floor texture. But you know what? Checkerboard is the best for debugging reflections, and so is a sphere :) I noticed the reversed reflections too, my hack for inverted spheres is to blame again :( Well, it needed optimising anyway, with 2 nasty bugs I'll just rewrite it properly.

I've looked at that reflections problem a bit more, and realised that using an inverted sphere for the 'sky' is utterly wrong. Or, at least, it's incredibly inefficient.

If you take the 'sky' as a sphere that's infinitely far away (which is actually ideal in most cases), the distance from any point in the scene to the sky is always infinity. Swap infinity for a large number, and your distance function is simply 'distance = largeNumber'. Can't get more optimised than that :)

Also, the normal (which is handy for texture coords and the like) is trivial. The centre of the sphere is always the current point, so it's simply 'normal = -rayDirection'.

I'm currently writing down a list of names for the greetings & thanks slide for my vienna talk (almost random order):

Some are actually not really raymarchers but came up with some helpful hints :) (or listened hours to some ideas which I didn't mention here yet for certain reasons ;))

Did I forget YOU?! Mention it - NOW.

Game of the day : someone in this list don't understand shit about code : find him :)

iq, Decipher, Ferris, psonice, chock, unc, XT95, manx, smash, kusma, nystep, nytrik, a13X_B, PauloFalcao, Lord Graga, Tigrou, auld, Sdw, flure, Psycho, Mewler, toxie, knighty, gopher, Sleo, Pirx, msqrt, vibrator, cupe, rarefluid, Xetick, mudlord

Quite glad of ending in this list without having provided any signficant help :D

nytrik, does that matter at all? ;)
I crawled through the whole thread and created that list, damn I forgot to mention texel, and already added some other guys too.

Some of those names will be bold - those who are know why ;)

I will give it a try +ne day and follow rez exemple.

Hello,

I'm trying to get into raymarching in webgl using iq's ShaderToy, but currently most of examples there aren't working at all... I've read those two remarkably helpful and inspiring threads here but I still can't get the work done.

I would really appreciate if someone could provide me with simpliest raymarcher with cube or whatever working in ShaderToy.

boased, try this.
http://pastebin.com/qwV7XQZg

I've not been posting much, but heres a little snippet of an upcoming demo to make up for it :) 3D Perlin Noise <3

Make it move, dammit :D

Mewler: awesome! can't wait for your demo :)

I wanted to post about GLSL shader disassembly otherwise.
It's actually possible to get assembly out of these.

On AMD/ATI there is: ASHLI - Advanced Shading Language Interface

And on nVidia, one has to use cg's compiler command line:



hope it helps.

nystep: "opengl assembly" isn't really any more useful or closer to the metal than the glsl itself.
For AMD you can use the GPU Shader Analyzer to get actual gpu assembly, which is very useful, at least to check for proper vliw utilization.

Mewler: NICE. I demand a torrent!
Is there any way to get in contact with you?
IRC? ICQ? Jabber?

Yesterday, I manually unrolled a loop. Didn't change the contents at all, just unrolled it. It was much faster. Wtf! This is on ipad/iOS/SGX543, not desktop though (and it wasn't raymarching too).

I'm guessing that was just a strange compiler fail, but it did make me think. Anyone tried an unrolled raymarcher for speed? I guess it shouldn't be hard to code an unroller. And of course it *should* be no faster, but on the ipad I got >30fps compared to 18fps, and that's the kind of speedup we don't want to miss :)

usually you profile every code you write. if youre not, feel to unroll and debug time every line you write.

wait...why do you think "it *should* be no faster"?

psonice: im not sure i understand what you mean - did you assume it wouldnt be faster because the compiler would have unrolled for you already, or did you assume it wouldnt be faster because you didnt understand the implications of using flow control in shaders?

I thought the compiler unrolled loops in simple cases? (This was an extremely simple loop, fixed iteration count (just 5 iterations too), no early bailout/conditionals etc.).

I do have a (very basic) understanding of the implications of flow control - I've just re-written this shader to remove conditionals + early bailout (it's a tweaked bilateral filter). This one for() loop was the only remaining flow control in any of the shaders for this app :)

More knowledge would be very good though - any suggestions for reading material? This is the beginners thread remember :D