 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"PM 2Ring" wrote:
> Here's my latest Mandelbulb, rendered using the isosurface / df3 method.
> but no radiosity: it was just too slow. This render took over 7 days on my
> 480MHz machine. I was hoping for a more impressive looking result, after all
> that render time. Oh well.
I like your color scheme, and also find the surface can have a nice, porcelain
look with the right finish.
Did you leave Jitter on? Jitter on is the default, but I've found using -J
helps reduce "smearing" and "fuzzing" in the final image.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
waggy wrote:
> CShake wrote:
> [...]
>> phin=atan2(y,z)*n;
> [...]
>> phin=atan2(y,z)*n;
> [...]
>
> Hmm. Perhaps these have a small error? I think maybe they should be like this.
>
> phin=atan2(y,x)*n;
>
> http://www.skytopia.com/project/fractal/2mandelbulb.html#formula
>
> Also, I used the same starting point, then grabbed one of the wikipedia
> references and read some more. (I also think I found a small improvement and
> plan to write it up over the break.)
>
Right you are, once again one character causes all the problem... Thanks!
That fixed code takes a bit longer to run, but all told this image took
less than an hour, 800^3, n=8.0, radiosity, and the media halo uses the
same df3 (you can see how the smooth scaling works). This isosurface was
created by using function{0.06 - df3_func(x,y,z)}, the 0.06 part can
then be tuned to make the surface 'grow'.
Now I wonder if it's worth doubling the integer size in the df3 to
remove some of the grain.
Post a reply to this message
Attachments:
Download 'mandelbulb_df3.jpg' (79 KB)
Preview of image 'mandelbulb_df3.jpg'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
PM 2Ring wrote:
> but no radiosity: it was just too slow. This render took over 7 days on my
> 480MHz machine. I was hoping for a more impressive looking result, after all
> that render time. Oh well.
I haven't used any raytracing software for years, but am wondering how
much do the modern machines change the rendering times with something
like this? for instance, i am currently using a quad-core 2.00 ghz
machine with lots of ram. obviously, the quad-core would be faster, but
by how much?
zutroi
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
zutroi wrote:
> PM 2Ring wrote:
>> but no radiosity: it was just too slow. This render took over 7 days
>> on my
>> 480MHz machine. I was hoping for a more impressive looking result,
>> after all
>> that render time. Oh well.
>
> I haven't used any raytracing software for years, but am wondering how
> much do the modern machines change the rendering times with something
> like this? for instance, i am currently using a quad-core 2.00 ghz
> machine with lots of ram. obviously, the quad-core would be faster, but
> by how much?
>
> zutroi
Not only are current CPUs running faster clock speeds than old ones, but
they tend to do more per clock cycle too.
My quad-core Q6600 (overclocked from 2.4GHz to 3.2GHz) really shovels
through renders. It is easily four times as fast as my old dual core
D820. I thought that was fast when I got it!
What CPU do you have? Look it up on Tom's Hardware for an idea how fast
it is compared with others
(http://www.tomshardware.co.uk/charts/processors,6.html)
Remember that POVRay 3.6 only uses a single core.. to use multi-core
CPUs you need to move up to the 3.7 beta.
Rarius
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>PM 2Ring on date 13/12/2009 06:44 wrote:
> Here's my latest Mandelbulb, rendered using the isosurface / df3 method.
> but no radiosity: it was just too slow. This render took over 7 days on my
> 480MHz machine. I was hoping for a more impressive looking result, after all
> that render time. Oh well.
>
>
I find it somehow impressive.
;-)
Paolo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> PM 2Ring wrote:
>> but no radiosity: it was just too slow. This render took over 7 days
>> on my
>> 480MHz machine. I was hoping for a more impressive looking result,
>> after all
>> that render time. Oh well.
>
> I haven't used any raytracing software for years, but am wondering how
> much do the modern machines change the rendering times with something
> like this? for instance, i am currently using a quad-core 2.00 ghz
> machine with lots of ram. obviously, the quad-core would be faster, but
> by how much?
>
> zutroi
Taking the overhead needed when multithreading, 4 cores and 4.166 times
the CPU speed, around 14 to 16 times faster would seems like a realist
estimate. Can even be a LOT faster if the slower machine had to use the
swap and you don't need to on the new one.
Alain
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"PM 2Ring" <nomail@nomail> wrote:
> Simple "Mandelbulb" C source code.
> Compile with
> gcc -o Mandelbulb Mandelbulb.c -lm -O3
Greetings all,
Here's my humble contribution. The attached archive contains a C++ program that
computes the density file for the Mandelbulb, but using the GPU through an
OpenGL shader. The OpenGL context is provided by SDL 1.3 (currently still in
beta, but already working well).
Compile with:
g++ -Wall -O3 -msse2 -o mandelbulb_gpu -lGL $($SDL13_DIR/bin/sdl-config --cflags
--libs) mandelbulb_gpu.cpp
....where $SDL13_DIR is where you installed SDL 1.3.
On my system (AMD Athlon 64 X2, nVidia 8500 GT), it computes a density file of
1000x1000x1000 in about 12 seconds (using non-trigonometric expansion provided
elsewhere).
Hope this helps.
Best regards,
Post a reply to this message
Attachments:
Download 'mandelbulb.tar.gz' (3 KB)
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Kafka wrote:
> "PM 2Ring" <nomail@nomail> wrote:
>> Simple "Mandelbulb" C source code.
>> Compile with
>> gcc -o Mandelbulb Mandelbulb.c -lm -O3
>
> Greetings all,
>
> Here's my humble contribution. The attached archive contains a C++ program that
> computes the density file for the Mandelbulb, but using the GPU through an
> OpenGL shader. The OpenGL context is provided by SDL 1.3 (currently still in
> beta, but already working well).
> Compile with:
> g++ -Wall -O3 -msse2 -o mandelbulb_gpu -lGL $($SDL13_DIR/bin/sdl-config --cflags
> --libs) mandelbulb_gpu.cpp
> ....where $SDL13_DIR is where you installed SDL 1.3.
> On my system (AMD Athlon 64 X2, nVidia 8500 GT), it computes a density file of
> 1000x1000x1000 in about 12 seconds (using non-trigonometric expansion provided
> elsewhere).
>
> Hope this helps.
>
> Best regards,
>
Nice. I wanted to play with GPGPU code, but just now finished final
exams for the semester and didn't find the time.
Without looking at the code, I have to ask a few questions:
Can you specify where to zoom in?
Is there any noticeable difference due to using single precision, or are
you using the double registers on the GPU directly (and using 1/10th the
power of the card)?
While I spent a bunch of time on my mbulb df3 generator, I'm probably
going to move on to the native function patch for the ability to
arbitrarily transform the surface (and not need to 'render' twice for
each image)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
CShake <cshake+pov### [at] gmail com> wrote:
> Kafka wrote:
> > "PM 2Ring" <nomail@nomail> wrote:
> >> Simple "Mandelbulb" C source code.
> > Here's my humble contribution. The attached archive contains a C++ program that
> > computes the density file for the Mandelbulb, but using the GPU through an
> > OpenGL shader. The OpenGL context is provided by SDL 1.3 (currently still in
> > beta, but already working well).
> >
> Nice. I wanted to play with GPGPU code, but just now finished final
> exams for the semester and didn't find the time.
> Without looking at the code, I have to ask a few questions:
> Can you specify where to zoom in?
No, values (boundaries, max_iters, etc.) are hard-coded in a bunch of constants
at the beginning of the source file. But feel free to change them, or I can
modify the code so that they're given as command-line parameters.
> Is there any noticeable difference due to using single precision, or are
> you using the double registers on the GPU directly (and using 1/10th the
> power of the card)?
I can't use double with OpenCL nor GLSL, as the driver and chipset I have don't
provide that extension. From what I read here and there, using double would
reduce performances by a factor of 5 to 10. That said, most of the time is
acutally spend into writing the file: see the attached code, it displays the
mandelbulb in less than a second (not generating the .df3 file, just displaying
using the shader).
> While I spent a bunch of time on my mbulb df3 generator, I'm probably
> going to move on to the native function patch for the ability to
> arbitrarily transform the surface (and not need to 'render' twice for
> each image)
Regards,
Post a reply to this message
Attachments:
Download 'mandelbulb.tar.gz' (3 KB)
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12/13/2009 9:40 PM, CShake wrote:
> ...
Interesting image... the grayish protrusions remind me a bit of
ferrofluid under the influence of a strong magnet. Cool!
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
