Translucency/Refraction in the "bulb" software

[Tabasco Raremaster]

The typical distance estimating functions we all use work fairly well on the inside. They are a bit slow "pulling away" from the surface. No worse than doing reflections. Just flip the "distanceMultiplier" to its negative whenever a surface is hit.
I tested this by doing some fractal xrays. Search fractal xrays on youtube if interested.

@ eiffie
Awesome examples you`ve got there. Can you please show some images made inside those objects too?

[eiffie]

Here is a refraction and translucency example using simple fractals:
The same technique will work on boxes and bulbs you just need more patience than I have.
Something for your CPU cores to ponder.
<a href="http://www.youtube.com/v/pzkofBNsZV0&rel=1&fs=1&hd=1" target="_blank">http://www.youtube.com/v/pzkofBNsZV0&rel=1&fs=1&hd=1</a>

[eiffie]

I haven't seen any examples of transparency yet besides my own. Not sure what is holding people up. Maybe I haven't given good enough examples of explained the few hangups/workarounds. Maybe I just haven't been watching all that close. Surely this can be implemented in fragmentarium. When I write a complete material script with reflection, refraction and occlusion I will try to port it to fragmentarium unless Syntopia beats me too it.
<a href="http://www.youtube.com/v/5sytDncBpU4&rel=1&fs=1&hd=1" target="_blank">http://www.youtube.com/v/5sytDncBpU4&rel=1&fs=1&hd=1</a>

[marius]

I haven't seen any examples of transparency yet besides my own. Not sure what is holding people up. Maybe I haven't given good enough examples of explained the few hangups/workarounds. Maybe I just haven't been watching all that close. Surely this can be implemented in fragmentarium. When I write a complete material script with reflection, refraction and occlusion I will try to port it to fragmentarium unless Syntopia beats me too it.

I tinkered with translucency a bit a while ago but never committed anything.

Currently looking into double precision shaders.
Appear mostly useful to slow the rendering down, not so much reveal more interesting structure..

[eiffie]

You are right there is a speed hit but not more than multiple reflections if the DE is properly constructed. Detail is also lost but the gain is artistic. So I think the problem IS a lack of good examples and us coders not being the best artists

[marius]

You are right there is a speed hit but not more than multiple reflections if the DE is properly constructed. Detail is also lost but the gain is artistic. So I think the problem IS a lack of good examples and us coders not being the best artists

Ah, I meant the double precision shaders that I'm playing with take a performance hit.
Yes, the reflecting / refracting not too much, delta limiting # of rays.

True that, not being much of an artist vs. coder. You're miles ahead of me though ;-)

All the GPU renderers appear more coder / tinkerer friendly than artist friendly.
I figure the software renderers need to pick up refracting, like they did w/ reflection.

[xenodreambuie]

Reflection and refraction only look good when much of the object is sufficiently smooth; or if composed of small blobs or facets, they're not too small. Otherwise it tends to look too noisy. So it works best if iterations are limited, or the detail is limited or smoothed in obj export, or perhaps using different materials for areas of fine fractal detail.

More generally, for aesthetics, all colouring and lighting should be chosen to work with any fractal structure rather than against it.

I know this is secondary to implementing the possibilities in the first place.

[ker2x]

that's one of the reason i wanted to code a pathtracer(marcher?) that work with distance estimation (all free/commercial available pathtracer are tracing against polygon (eg : luxrender, indigorenderer, ...).

But it's much harder to do (for me) than i hoped
And yes, one of the first rendering (the first?) of mandelbulb was using pathracing (hello lycium   )

[Syntopia]

that's one of the reason i wanted to code a pathtracer(marcher?) that work with distance estimation (all free/commercial available pathtracer are tracing against polygon (eg : luxrender, indigorenderer, ...).

In the GitHub version of Fragmentarium, there is now support for accumulated/progressive rendering to a float (HDR) buffer (with a second pass by another custom pixel shader for tonemapping/gamma correction and post processing), so making a path tracer is not that complicated. I'm working on a new "soft"-raytracer using this, and I get  good results - using multiple rays per pixel, you get high quality anti-alias, better ambient occlusion, soft shadows without using DE hacks, and depth-of-field. And since it is progressively rendered, it is still possible to navigate interactively. I've attached a test render.

Currently looking into double precision shaders.
Appear mostly useful to slow the rendering down, not so much reveal more interesting structure..

I've also tried double precision, but was discouraged when I realized several math functions (e.g. sin, exp) were not available in double precision even in the latest GLSL specification. And on the examples where I got it working, the quality didn't visibly improve - so there must have been other issues. Besides, on consumer Nvidia hardware, doubles are very slow (1/8 speed of singles).

[ker2x]

yay !

Code:

git pull --rebase

what raytracer should i include ? The Soft-Raytracer.frag ?

[Syntopia]

yay !

Code:

git pull --rebase

what raytracer should i include ? The Soft-Raytracer.frag ?

Yes - it should be compatible with the other raytracer. The Knot.frag example uses it per default, I think.
You must set the render mode to 'Continous' to render accumulated frames - otherwise only one ray is rendered per pixel.

Be aware, that it is still very experimental :-)
 

[ker2x]

You must set the render mode to 'Continous' to render accumulated frames - otherwise only one ray is rendered per pixel.

Haaaaa now i understand what was the problem. thank you

--
Keru