pouët.net

Go to bottom

trick for 1k raymarchers :: lighting

category: code [glöplog]
@psonice:

Well, suppose at p we have a plane instead of a curve surface (since the 0.1 or epsilon is little, we can suppose that).
p
____________________________
\
\
\ ray

So, the f() of the p+0.1*l will be maximum -- 0.1 -- when the ray is normal to that plane, and it will be less and less as the ray have less angle with the plane. The minimum distance to the plane to a point -- given by f() -- is always in a line normal to the plane and crossing the point.
added on the 2010-08-02 00:22:28 by texel texel
... Should I do an image of that?
added on the 2010-08-02 00:23:48 by texel texel
BB Image
added on the 2010-08-02 00:48:53 by texel texel
I think I'm slowly starting to get it.. maths isn't my strong point, but I'll keep thinking it through until it makes sense. Thanks for the description + diagram, it's helping a lot (I've progressed from not getting how it can work at all without calculating the normal to nearly getting it completely.. just needs a final little gear to click into place!)
added on the 2010-08-02 09:31:18 by psonice psonice
And you can improve the accuracy with:

Code:float d=f(p+0.1*l/c)*c;


Converges on the exact result of the dot product method as c -> infinity.
added on the 2010-08-02 10:55:36 by doomdoom doomdoom
Kinda sad that in reality this will "converge" to pure IEEE rounding artifact noise as c->infinity :D
added on the 2010-08-02 11:13:59 by kb_ kb_
Quote:
On my decent, 24 bit monitor the 2nd image looks better, very little visible banding.

Oh we're talking about the second image? Sorry, I have absolutely no banding on that one (MacBook Pro). I was comparing the banding in the first render to the non-banding in the second one. :)
added on the 2010-08-02 11:22:20 by decipher decipher
The macbook pros use TN panels I think (or at least did), so you're possibly looking at a dithered 16bit image :)

The quality of the dithering seems to vary by a massive amount actually. On my cheap home screen it dithers by flickering the pixels between two shades, which looks really nasty in certain cases but works ok in others.

On my work box, I have a reasonable 20" imac screen which is TN/16bit, but I can't see any banding, flicker or dithering at all. It looks 24bit. I also have a reasonable quality HP screen, also TN, no banding or flicker here at least but if I look close I can see dithering. Both are massively better than my cheap screen at home :( (but probably cost a lot more!)

Btw, you can easily tell if you have a TN screen: set it to show a full screen of solid colour (grey works well). See if the top of the screen is the same colour as the bottom - TN screens look like you have a gradient. If you move your head up + down, the gradient moves. This makes them bad for graphics work ;)
added on the 2010-08-02 11:31:13 by psonice psonice
kb: I was writing something along the lines of "up to the precision allowed by floats and f()", but then I figured you'd all be clever enough to see it was implied. ;)
added on the 2010-08-02 11:57:44 by doomdoom doomdoom
Quote:
If you move your head up + down, the gradient moves. This makes them bad for graphics work ;)


It makes them bad for everything. ;)
added on the 2010-08-02 11:59:47 by doomdoom doomdoom
just use more coder color gradients, the eye can easily be tricked and won't see the monitor restrictions anymore.. ;)
added on the 2010-08-02 14:43:24 by toxie toxie
I thought this topic was about a lighting trick, not color banding on shit lcd displays :)
added on the 2010-08-02 17:29:20 by ferris ferris
Tell that to the guy who blamed his lcd display for the fact that one image had more banding than the other (on the FUCKING SAME SCREEN), I'd say :)

But yeah, the trick is neat. Most fun part is that I tried to find ways to make it fail and had to realize that the "original" implementation would fail in all of those cases, too. Unless of course if you uncomment the normalize() ;)

That's maybe the one drawback - you need to magically know the magnitude of the gradient of the distance function. Might suck for complex ones but then again this is about 1k programming.
added on the 2010-08-02 18:05:51 by kb_ kb_
I magically know the magnitude of the gradient of all distance functions! ;)
added on the 2010-08-02 19:11:45 by doomdoom doomdoom
The world may now!

Thanks for the trick :)
added on the 2010-08-02 19:16:33 by las las
if it's a distance function, you know the magnitude for sure :) If it's just some sort of potential function kb is right, you pretty much have to find the magic constant by trial and error. But who cares, it's 1k coding indeed.
added on the 2010-08-02 19:33:49 by iq iq
thanks for sharing iq, indeed, nice trick, not only for size optimization but also for speed ;)
added on the 2010-08-02 22:38:26 by xoofx xoofx
speed:
kusma: just imagine some effect that needs like 1-6 march-steps only for the most of geometry...having like 4-6 more calls can be very frustrating in these cases !
also iq at some point proved that most sphere-marchers (atleast) have an average of like 20 steps...so 1 additional call instead of 4-6 is a speedup that cant be ignored...the higher the resolution the more it helps in speed-issues !
atleast should have applied to "sphere-marchers", didnt survive in pointing that out correctly...
dryhumping this dead thread to get some attention, can someone test the final of my 1k on an ATI card?

http://www.pouet.net/prod.php?which=55469
Worked on my ATI 4850 here.
added on the 2010-08-11 18:37:52 by Intrinsic Intrinsic
Still not movement here, ati 3870 - just a nice still picture in yellowish colors :)
added on the 2010-08-11 18:38:59 by maytz maytz
*facepalm*
I updated my gfx drivers from 10.2 to 10.7 and it runs smoothly now - in blue colors :) ...dindn't know my drivers where THAT outdated - my bad :)
added on the 2010-08-11 18:53:57 by maytz maytz
still picture still :(
added on the 2010-08-11 18:54:38 by Gargaj Gargaj

login

Go to top