GPU-accellerated renderer
For the past few months, I've been working in my basement to make a new renderer based on a radically different algorithm to generate flame fractals. My initial hopes is that the algorithm would be fast enough to render sheep in real time, and although it's slower than I had hoped, I'm still getting a performance improvement of about 3 orders of magnitude over Apophysis (that's 1000x faster!). This is fast enough to bring rendering at 1024x1024 to 15 fps or so on a GeForce 8800GTX!
Anyway, before I bore you with any details, here's a first screenshot.
http://i4.photobucket.com/albums/y136/Keldor314/GPUFlamesFirstLight.gif
(hopefully the link will work - this forum seems to be a bit peculiar in terms of formating tags)
[EDIT] Nope, the link didn't work :-P Well, there's the URL anyway. [/EDIT]
As you can see, there's still a lot of work to be done. For one thing, color would be nice (the standard palette-based algorithm is incompatible with my rendering algorithm, so I still need to figure out a way to at least get something fairly close). Also, due to me misinterpreting the flame algorithm, the image is strictly incorrect for the input parameters. Fortunately, correcting the misinterpretation will actually make the program 2-4x faster depending on the average number of Xforms used in each transformation (I was treating each xform as a separate transformation, rather than adding them together to get the result of the single transformation containing all of them). Finally, only the 15(?) original xforms are presently implemented. However, most of the newer xforms will be easy to add (if tedious), with the exception of the noise based xforms, which will take a new algorithm to force them to work.
Progress Report
After a liberal application of procrastination on my part, I've finally pieced together a corrected version of the transformation function. I also added in the rest of the xforms (from the new paper) with the exceptions of the noise based ones (Noise, JuliaN, JuliaScope, Blur, Gaussian, RadialBlur, Pie, Arch, Square, Rays, Blade, and Twintrian I believe) and will be holding off on the ones involving the trunc or mod functions for now (Rings, Rings2, Fan, Fan2, and Rectangles are the only ones that come to mind) until I get some questions about the performance of the Geometry Shader answered. Namely, adding them in has the potential to cause a big performance hit, whether or not they are actually used in a given frame. This is because the value needed for [maxvertexcount] basically DOUBLES for each POTENTIAL truncation or modulus cut in any given cell, which will get out of hand FAST, since not only do all the docs recommend trying to use a low [maxvertexcount] to increase performance (probably because of the way memory allocation has to be handled - allocating large numbers of variable sized lists where the size is not completely determined until AFTER the shader is run is a real problem...), but there's also a hard limit to deal with. Still, since the probability of a bunch of cuts happening to cut through the same place at the same time is quite low, there may be some way to work around the problem.
Anyway, next thing to do is rethink the calculation of the dilation factor of the transformations. Previously, I was doing this analytically, but for some of the later variations, the math could be quite hairy, and easily cut into performance. The alternatives are also problematic, since either I have to compute the dilation factor in the geometry shader per triangle (leading to potential artifacts similar to flat shading artifacts) or somehow extract neighboring transformed vertices after the geometry shader has sliced the geometry to handle discontinuities in the xform mappings to do per vertex shading.
Made a lot of progress
Made a lot of progress today. Rendered flames are now correct. I'll see if I can get some screenshots up later. I've benchmarked the renderer at 10-30 fps depending on the number of transformations in the given flame. Of course, since I haven't actually coded in any animation stuff, it's just a still picture with a frame counter. Speaking of which, how is a given sheep animated? I've read something about 'rotating the transformations in 3d', but that's pretty vague:p
Here's a new
Here's a new screenshot.
My image host resized it, but the origional image was just a touch under 2048x1536 (The app window was that dimension, but the client area is a bit smaller). The rendering itself was done at 2048x2048. Best of all, the rendering time was about 1/4 of a second:-D
Let's see if the link works this time e.e
Anyway, I got some basic animation working, I *think* it works the same way as electric sheep loops, but since I couldn't find any specific explanation about how sheep loops are animated, I pretty much had to guess. The framerate's a bit choppier than I would like for most sheep, and more importantly, there seems to be very large variations in brightness, even between frames in the same sheep, though this may just be an artifact, since currently any orbit that exits screen space is cropped.
The cropping I just mentioned is one of the next problems for me to tackle, though I'm concerned about how my potential solutions may influence framerate. After that, I need to figure out a good coloring algorithm. As I said earlier, the standard algorithm won't work with my implementation (actually, I could force it to, but it would probably make the algorithm an order of magnitude slower - same with noise-based xforms and motion blur, but with any one of those three, you would essentially get the other two for free)
In any case, I'm actually getting somewhat close to being able to put together a basic release! Of course, the system requirements will be steep (Windows Vista, directx 10 graphics card).
Hey Keldor, any update on
Hey Keldor, any update on your renderer? Thanks for spending time on this; the idea of being able to use Apophysis as a VJ tool is very cool. Though I don't have too much experience, I'd be willing to learn about it and help if you are still working on it.
Keldor is announcing his
Keldor is announcing his releases on the Apophysis email list.
looks good, the rotation is
looks good, the rotation is done like bergey says.
you should just be able to use the flam3_rotate() function in flam3.h and spin() in flam3-genome.c
I was thinking of taking a
I was thinking of taking a crack at this problem, in OpenGL rather than DirectX. I'd love to see your code.
As for how the loops are implemented, [Draves 05] says: Electric Sheep rotates over time the 2x2 matrix part of each of the transforms...Sheep are 128 frames long.
I assume that means repeated multiplication of the affine matrix by [cos(2pi/128), -sin(2pi/128, 0, sin(2pi/128), cos(2pi/128), 0] (or similarly if you want to go clockwise). I haven't actually looked at that piece of code yet.
How are you constructing the loop?
I don't know much about
I don't know much about matrix math, but if you look at the flame in Apo you see xforms represented by triangles. The first 2 coefs reference the x point in relation to the vertex (o), the second 2 the y point in relation to o, and the last 2 reference o in relation to the origin.
When you use flam3-genome, it'll rotate the x and y points around o over nframes. Remember that time=0 and time=nframes should be the same, so you have to store the original frame as time=0 and then loop over nframes.
Recent comments
1 day 4 hours ago
1 day 4 hours ago
1 day 13 hours ago
1 day 13 hours ago
1 day 16 hours ago
1 day 16 hours ago
1 day 16 hours ago
1 day 16 hours ago
1 day 17 hours ago
1 day 17 hours ago