|
cKleinhuis
|
 |
« on: September 29, 2007, 06:32:24 PM » |
|
sorry to post it a second time  Hi All, i have just managed to get a first image out of my "Animation as Slices " Rendering method out of mutatorkammer, here are the results: these are visualisation of a 3 dimensional valuefield of size 128x128x128 using smoothed vertex normals as colors  you can watch the corresponding 2d animation here
<![CDATA[<a href="http://www.youtube.com/v/JEjvixdIEpY&rel=1&fs=1&hd=1" target="_blank">http://www.youtube.com/v/JEjvixdIEpY&rel=1&fs=1&hd=1</a>]]>read more on fractalmovies.com: http://fractalmovies.com/index.php?option=com_content&task=view&id=59&Itemid=283d Mandelbrot Twist Above  3d Mandelbrot Twist  3d Mandelbrot Twist Above 2  and another set of different views from a different animation, 256x256x256 resolution, no smoothing 3 3d Mandelbrot Twisting    |
|
|
|
« Last Edit: August 16, 2014, 05:05:34 PM by cKleinhuis »
|
Logged
|
---
divide and conquer - iterate and rule - chaos is No random!
|
|
|
|
cKleinhuis
|
|
« Reply #1 on: September 29, 2007, 08:34:46 PM » |
|
if any one ( i know plenty here ) has fun to corporate with me in rendering these 3d formulas using a high quality volume field renderer please please please contact me,
i think this could be a very pretty way of defining quaternions ....
|
|
|
|
|
Logged
|
---
divide and conquer - iterate and rule - chaos is No random!
|
|
|
|
lycium
|
|
« Reply #2 on: September 30, 2007, 08:34:21 AM » |
|
i think this could be a very pretty way of defining quaternions ....
defining quaternions? quaternions have been defined for a long time now: http://en.wikipedia.org/wiki/Quaternion#Definitiondo you mean defining some kind of 3+1d volume? |
|
|
|
|
Logged
|
|
|
|
|
lycium
|
|
« Reply #3 on: September 30, 2007, 08:35:55 AM » |
|
btw as you probably know, don has been working on such a volume rendering program for quite some time, and its octree storage scheme could help a lot with your large empty regions.
however, he's switched to sunflow now... maybe you can talk with him about using that rendering engine?
|
|
|
|
|
Logged
|
|
|
|
|
cKleinhuis
|
|
« Reply #4 on: October 03, 2007, 05:04:47 PM » |
|
i see, rendering iso surfaces will never lead to high quality renderings, i have to implement a raytracer ... ;(
|
|
|
|
|
Logged
|
---
divide and conquer - iterate and rule - chaos is No random!
|
|
|
|
lycium
|
|
« Reply #5 on: October 03, 2007, 05:11:45 PM » |
|
ray tracing fractals is extremely difficult, especially without a really solid understanding of numerical methods (precision-related issues in solving equations and other numerical processes). moreover, you can write a ray tracer in < 100 lines of code (actually i just minutes ago described to a german fellow how to do exactly that) but that doesn't necessarily mean it will be useful. to get past the "chrome spheres on checkerboard floor" stage takes a lot of effort, and to make a good renderer is more of a fine art than a science ... many books have been written about this, and that's why i was saying to don that it's really not a matter of months! to keep track of the fast-moving world of efficient, realistic rendering is almost a fulltime job (every year reading all the siggraph and eurographics papers, all the little forums ...) even if you ignore the time it takes to reach the 1997 state of the art: http://graphics.stanford.edu/papers/metro/ |
|
|
|
|
Logged
|
|
|
|
|
cKleinhuis
|
|
« Reply #6 on: October 03, 2007, 05:29:07 PM » |
|
what would you suggest ? i have a plain 3d formula wich returns inside/outside values ( either boolean or by a scalar )
using the isosurface/marching cubes method, i can generate a mesh to be imported in a rendering program, but would loose most
of the detail
so i was thinking about writing a renderer similar to those wich render quaternion fractals, by tracing a ray from the eye into the scene, the problem here is the collision detection, i would send my ray into the scene given a step length, and when this ray would pass into a solid,m the entry point has to be determined, and here the problems start again, a surface normal has to be approximated ... and in a first step i would only allow direct point light, without shadows, rendering with shadows would lead to an enormous
amount of tracing through my scalar field ...
perhaps i could use the isosurfaces as a hint for the raytracer to determine inside outside regions faster, so that only the borders should be refined ...
|
|
|
|
« Last Edit: October 03, 2007, 05:30:47 PM by Trifox »
|
Logged
|
---
divide and conquer - iterate and rule - chaos is No random!
|
|
|
|
lycium
|
|
« Reply #7 on: October 03, 2007, 05:46:01 PM » |
|
in the specific case of quaternion julia fractals, there is fortunately an "unbounding volume" algorithm for rapidly intersecting the surface. this is presented in john hart's classic paper, "Ray tracing deterministic 3-D fractals", in which he also gives a normal estimation algorithm too. (you can download that paper here: http://graphics.cs.uiuc.edu/~jch/papers/rtqjs.pdf) now of course you can go ahead and implement that, i suppose most fractal coders do at one stage, but these days i wonder how worthwhile it is to do so since modern gpus can render this in realtime. keenan crane, now at nvidia, wrote a nice tutorial some years ago on doing exactly that: http://www.devmaster.net/forums/showthread.php?t=4448one of the ugliest things about doing crisp 3d fractal rendering is in the normal computation. and the reason is obvious too, it will never make sense to get a "normal" to something that isn't even a surface to begin with! efficiently rendering 3d fractals requires lots of special-purpose analysis, as is seen here with the special case of quaternion julia sets. i wrote a bit more about these matters in this thread: http://www.fractalforums.com/index.php?topic=738 |
|
|
|
« Last Edit: October 03, 2007, 06:05:19 PM by lycium »
|
Logged
|
|
|
|
|
cKleinhuis
|
|
« Reply #8 on: October 03, 2007, 05:51:47 PM » |
|
too bad, i think i cannot use the distance estimator method described here, because of the large variety of fractal formulas i present, inside/outside is not a matter of iteration depth, it is more a decision of the mapping of a complex result to a inside outside map
my inside regions are dfined by complex value ranges, not by iteration depths ... ;(
|
|
|
|
|
Logged
|
---
divide and conquer - iterate and rule - chaos is No random!
|
|
|
|
lycium
|
|
« Reply #9 on: October 03, 2007, 05:55:37 PM » |
|
yup, that's a problem basically all 3d fractalists face.
|
|
|
|
|
Logged
|
|
|
|
|
cKleinhuis
|
|
« Reply #10 on: October 03, 2007, 06:05:34 PM » |
|
it would lead to an enormous slow renderer  |
|
|
|
|
Logged
|
---
divide and conquer - iterate and rule - chaos is No random!
|
|
|
|
David Makin
|
|
« Reply #11 on: October 03, 2007, 06:12:56 PM » |
|
The method my current formulas use is to simply get the normals from adjacent found solid points only (with a threshold to decide when the points aren't adjacent to avoid black edges on overlapping areas) - this requires either a partial or full 2-pass method. In Ultrafractal I implimented this but actually fire 5 rays per pixel due to the way UF works in order to avoid having to have a screen array.
As to ray-tracing things based on non-standard "solid" conditions for efficient ray-tracing you have to devise a method of distance estimation to suit whatever solid condition you use and/or use an element of brute-force, my formulas for UF allow "solid on orbit trap value" and base the stepping distance on a function of the current orbit trap value giving the user control over various parameters for doing so.
|
|
|
|
« Last Edit: October 03, 2007, 06:14:39 PM by David Makin »
|
Logged
|
|
|
|
|
lycium
|
|
« Reply #12 on: October 03, 2007, 06:21:25 PM » |
|
it would lead to an enormous slow renderer indeed it would, and that's without even considering secondary rays for shadowing / reflection / global illumination. for example if you look at my latest 3d fractal ( http://lyc.deviantart.com/art/rise-64751071), you'll see how the light reaches inside the object, bounced off the floor. so each pixel has thousands of rays (in that image about 2000 per pixel) for antialiasing, each of which can bounce a potentially infinite number of times, on average about 5 or 6 times. if i had to take tiny tiny steps (fractal surfaces are infinitely fine!) along these rays, each time checking against a seriously complex fractal iteration, that would be completely intractable. especially when you consider the statistical noise introduced by monte carlo integration. fortunately, for many fractals you can find a nice way to bound the computation by unbounding the volumes it intersects along the way, similar to how hart does it in his papers. once you understand the basic gist of how this is done, the only remaining task is to derive normal estimation methods, and this is where the real hell lies: incredibly much tuning of precision parameters to get a nice balance of over-smoothness and artifacts, keeping the two different (forward and inverse) models consistent with each other, ... really, it's no coincidence that you don't see many well-rendered 3d fractals on the net! each one has its own story of tricks required to make it practical, and most fractalists are too concerned with the intricacies of palette adjustment to bother with all this cutting edge nonsense (see e.g. http://www.fractalforums.com/index.php?topic=739) |
|
|
|
|
Logged
|
|
|
|
|
cKleinhuis
|
|
« Reply #13 on: October 03, 2007, 08:27:17 PM » |
|
|
|
|
|
« Last Edit: August 16, 2014, 05:23:56 PM by cKleinhuis »
|
Logged
|
---
divide and conquer - iterate and rule - chaos is No random!
|
|
|
|
cKleinhuis
|
|
« Reply #14 on: August 16, 2014, 05:07:15 PM » |
|
stumbled over this, this was nice and provides a decent method to actually "design" 3d fractals, like the julibrot fractals
|
|
|
|
|
Logged
|
---
divide and conquer - iterate and rule - chaos is No random!
|
|
|
|
December 20, 2011, 02:58:26 PM
Dilber MC Theme by HarzeM