pouët.net

nystep: which 4k are you btw talking about?

Cool, that's quite a speedup :) Guess it'll depend heavily on the scene, but it's one more weapon in the battle for speed.

It's going to add code to the VS though. I'm guessing that as the code can be near identical to the FS code, the compressor will nearly eliminate that? If not I guess it'd be easy to write the duplicate code out twice when setting up the shaders.

psonice: If it only was "finding new uses for old tricks"; it's "reinventing the exect same ways of using old tricks". Which doesn't mean it's an useless method, but I think you have to accept that it's not novel any more ;)

who cares? :)

kusma: doing a low-res pre-pass is obviously not novel, doing it for raytracing definitely isn't, doing it in the vertex shader possibly is (though I'd be surprised), but yeah, who cares? it's something a lot of us discussing it here weren't doing before, and it seems it was worth suggesting it :)

(and tomorrow, if i get time and manage to get the lighting bugs fixed first, I'll add this to my raytracer to optimise out the ground and sky, just pass texture coords + normal through. Maybe I can hit 60fps on my olden radeon 2600 box :)

las, well i didn't want to spoil the thread for self-promo either.. :p i just meant something like that. At least it can give you an idea of the performance increase that is possible.. x2 is not so bad. :)

As for shadow rays, it's also possible to store a nearer z where to start the shadow ray from the light source to the point to shade. so we can get "shadow maps" in raymarching? for spot lights it requires one texture and for point lights a cube map.. no big surprise. For reflections there's no magic solution, except that you can of course (and HAVE to) start the reflected ray with the epsilon obtained at your intersection. It's not only faster, it's also that your cone is getting bigger and bigger as you reflect the ray, which is quite interresting to acheive other effects (atmospheric and mie scattering in particular?).

Anyway, you can use the epsilon at the primary ray intersection as a "lod factor" when looking up textures and evaluating the material...

Nothing special then again, all of this is already possible with rasterisation, and yes, there is heavy conjecture content in this post. :) i guess it's all possible, but i haven't tried yet.

Hmm.. some interesting ideas there! Use the epsilon to determine the noise octaves for example, so noise gets cheaper with distance. And shadow maps for fixed geometry/lights (or would it work as a separate pass at low res for lighting?)

Speaking of lighting, how about doing the shadows in the vertex shader pass? It'd be low res lighting, but cheap. With some tweaking, it might produce at least a passable glow? Not sure, but could be worth trying.

Back to fixing my raytrace lighting, nearly there :)

1. Using bounding geometry is a good idea.
2. Using exit early and dynamic branching is a good idea.
3. Avoiding expensive texture lookups is also a pretty good idea.
4. And using one rough (without lookups for noise) and one high quality (with lookups) marching step is a pretty damn good idea.

To apply that all you have to know your scene pretty well.
But this crap now runs with 80fps at 1024x768. And that's way faster than 15 fps.

\o/

Of course you also want:
5. Raytrace anything you can once, before rendering, and remove those objects form the distance function.

Ohh... And it's 1280x1024... reaching 93 fps.

Over 100 \o/
4 Steps in the refinement pass are enough - wtf.

You know you're finished optimising when it's still doing 60+ and you can't turn the res up any higher :)

screenshot or it didn't happen! (so that we can see the type of scene also, else numbers don't mean anything) :)

True, such speeds are easily achieved with an empty scene ;) Somehow I think las is a bit past that stage though :D

true, i expect something nice from him. :)

It pretty much looks like http://pouet.net/prod.php?which=56922 - better.
No screenshots before evoke - sorry :)

And I use some kind of proper 3d noise texture - painfully expensive. You just can not march that thing brute force.

I like that answer better than the screenshot ;)

A little 'off-focus' but at least not offtopic: I've ported my Revision PC 4k sphere tracing/raymarching entry to JOGL (as las would say "better readable for java-pussy-coders") and published the original+commented code on Github. Maybe someone could learn stg from it :) enjoy ...

Original 1:1 port (minified shader)
Commented port (development shader)

Thank you, though i had your commented source already because i noticed it was just a cut&paste minified version of what is done on http://www.fractal.io. ;D

ScenePassivist: very nice work - as I mentioned earlier this should have been in the top3. :)

Fractals - are fractals, - are fractals. That's kinda getting boring.

a13X_B:
That one http://vimeo.com/23018524 impressed me - how fast is it?
Did you improve it any further? Better material? Want to see code :)

People still use java? I thought everyone was already using .net / mono.

well, that's true las. fractals get boring, i'd better switch to something new.

I m still impressed by fractals