Logo by S Nelson - Contribute your own Logo!


it was a great time but no longer maintainable by c.Kleinhuis contact him for any data retrieval,
thanks and see you perhaps in 10 years again

this forum will stay online for reference
News: Follow us on Twitter
Welcome, Guest. Please login or register. September 21, 2018, 06:40:46 PM

Login with username, password and session length

The All New FractalForums is now in Public Beta Testing! Visit FractalForums.org and check it out!

Pages: [1]   Go Down
Share this topic on DiggShare this topic on FacebookShare this topic on GoogleShare this topic on RedditShare this topic on StumbleUponShare this topic on Twitter
Author Topic: An Idea for Faster(?) Calculation of 3D Fractal Surfaces  (Read 215 times)
0 Members and 1 Guest are viewing this topic.
Forums Newbie
Posts: 1

« on: July 30, 2016, 04:51:13 AM »

I use Mandelbulb, so that is where this idea arose.

I am not sure if one or both of these systems has or have already been proposed, but here goes:

Could one take the average number of raysteps for the pixels surrounding a certain pixel and use that average as a preliminary value for the proximity of the fractal surface? If an average of the nearby numbers of raysteps was used, with the calculation jumping up a raystep from the average, then down a raystep from the average, then up two raysteps from the average, then down two raysteps from the average, and so on for infinity could be used until either a surface is reached or the calculation ends. This would, hypothetically, make rendering regions of the fractal that are relatively similar in distance to the viewer render more quickly, right?

This next idea is a bit different. If the average number of raysteps is very high and standard deviation of the number of raysteps for nearby pixels is 0 (as would be the case whenever there is a large area of negative space), the program could just assume that that value will also be negative space. This would require a checkerboard approach to calculation, in which some pixels are calculated first using the method outlined in the previous paragraph and the ones inbetween those pixels are assumed to be negative space  as well if the average number of raysteps is high and standard deviation is 0. This method of "assuming" values could lead to a small loss of quality, I would think, so it may be less desirable than the method outlined in the previous paragraph. This checkerboard approach could also be used for the previous paragraph as well.

Does anyone know if these ideas have any capacity to expedite rendering?
Fractal Bachius
Posts: 563

« Reply #1 on: July 30, 2016, 05:33:01 AM »

The issue I can see is that with sphere tracing using distance estimates each ray step is a different size, depending on how close the surface is.  So number of steps isn't an indication of position.
Pages: [1]   Go Down
Jump to:  

Related Topics
Subject Started by Replies Views Last post
Faster Alternative to TIA coloring? Programming dbyrne 7 1803 Last post June 26, 2010, 05:53:02 PM
by Duncan C
BOINC Project idea : fractal@home Let's collaborate on something! ker2x 8 1443 Last post September 02, 2014, 05:57:34 PM
by erstwhile
I need a faster round() in C++ (G++ on OS X 10.6) Programming aluminumstudios 11 4324 Last post June 22, 2010, 07:15:33 PM
by twinbee
Let's program a way to use this fractal idea in Chaospro Let's collaborate on something! Thunderwave 0 821 Last post September 21, 2010, 12:13:48 AM
by Thunderwave
How do common programs render fractal surfaces? 3D Fractal Generation Sandreal 5 537 Last post August 14, 2017, 12:35:41 AM
by 3dickulus

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines

Valid XHTML 1.0! Valid CSS! Dilber MC Theme by HarzeM
Page created in 0.198 seconds with 27 queries. (Pretty URLs adds 0.009s, 2q)