Luna-Canis

Welcome to WordPress. This is your first post. Edit or delete it, then start blogging!

This is an implementation of Clifford Pickover’s ‘Epsilon Cross’ method. Each time your point iterates, if it falls within a cross shape, it either gets colored white or black. I added a bunch of effects on top such as supersampling in space and time, finding ways to autodetect how large the projected pixel was. A 1k version can be found here.

The *first* fractal animation done with Spa. All the operators are tile based. It was fun to get working, but the next obvious step will be to get the SIMD engine working. This is for two reasons:

1. SIMD scales better with complexity
2. Need the ability to do different things like flow control, if/else statements, and ‘other’. What I learned from using VOPs in Houdini, is that control structures don’t translate well into connected graphs. Or maybe it does, but even with VOPs, you still need a working shading language to have the scene graph translated into. For doing complex things like orbit traps, and other arbitrary escape time functions, the shading language is the way to go.

The idea for the first example came to me after I realized that the mandel/julia split of the escape time iteration is really just a 2D slice of a 4D equation. By arbitrarily rotating a 2D slice through 4D space of the mandel plane, or the julia plane, you could get a continuous rotation between a mandelbrot set, and a julia set. The results are a lot less spectacular than the explanation, but it did lead me to some interesting research into arbitrary 4D rotations, the SO(4) group. This link shows the formulation for arbitrary rotations in R4, very similar to quaternion rotations in R3.I just set a few keyframes and got the resulting animation. Like I said the idea was much greater than the final result.

This example was more fun. I keyed a camera zoom to start, but then got a chance to test the per-pixel expressions, some periodic coordinate warping, and some noise.

The coloring algorithms are very simple, but this was more of an exercise in getting some basic animation and expression features working. It was a huge personal success, and it lead me directly into implementing the SIMD virtual machine.

Going to FINALLY start coding again. Just finished spiderman 3, ordered NEW GEAR, all new mac stuff to finally replace this poor Dell computer that I think I bought sometime in 2000 or so. 7 years old, I’m glad it made it this far. The Mac stuff should arrive within a week, so that should hopefully be enough time to put it together.

I just looked at the old ‘todo.txt’ in spa/app/spaExe, and I’m hoping that this blog will do a much better job of keeping track of shit than a single text file.

So the last thing I was working on was the grammer for the shading language. Lets see if I can get something decent compiled. I was working on lcc. I’m trying to get a simple example working that will produce the same output as the simd assembly that I hand coded. The problem (now that my memory is coming back to me) is that I was trying to find a way to generalize the compiler to handle geometry, images, everything possible. It would be kinda wasteful to try and figure out all generalizations now, I should just work on getting this example working for images. I just have to define some default variables (like size and position) and it should work.

Ah… also the default scalar flag I was thinking about. I realized that depending on context, we want scalar values to default to either doubles or float. I’m putting that in now… Done.. that was simple.

Now faced with the way to defined I/O variables. We *could* compile them into the compiler, but that’s definitely not the way to go. We want to have header files to define these variables. But then that brings up the problem of generalizing ‘include’ paths and using the c pre-processor. We’re not going to do that… I’ll hand code the global variables for now, we’ll try using the c-preprocessor later.

Added a globals keyword, so we can declare global variables. This will turn out to be more flexible than renderman or mantra. We will be able to declare user defined globals at compile time. The user will have to know what the expected I/O variable names are, but they can also keep some globals handy for computational/signalling purposes.

One aspect that I have to start dealing with is the whole varying/non varying temp variable initialization. With a little overhead, I can have user defined temp variables default as non-varying, and have them mutate to varying as needed. Keeps the overhead at a minimum as well. I was going to handle this on the fly, but on second hand, I think it might be easier to do as an operation in a 2nd pass. There are too many things to add and take care of.

GOT IT WORKING. 

The parser can suck in the full shader file that duplicates the assembly file test. Next is spitting out assembly code. Maybe by tomorrow??? YES

Today, we try getting the source to dump assembly code, which will be a monumental step for the shading language. We may begin rendering by the end of the week.

Trying to think about a strategy for doing temp variables for evaluating expressions. There should be a recursive virtual function, (re-implemented by VarValue) to take a tmp variable template, a tmp variable count, and an array of variable names and types to fill.

Also another interesting point, the root node of any expression doesn’t need a temp variable because it can write its results directly into the assigned variable. We need to initialize the root node of every exprssion to write its assignments directly into the assigned variable.

Got so much working today. The proof of concept for the recursive expressions calculating their own temp variables and creating assembly code WORKS. Unbelieveable.

I glossed over the extremely simple case: straight variable assignments, no expressions. Lets enumerate the different variable assignments to get things straight…

• vector = vector
• scalar = scalar
• vector[i] = scalar
• scalar = vector[i]

Actually, the first two cases are the same, we just make certain that both are the same type. So there will be a total of 3 new assembly commands, templated to handle the different data types and vector sizes.

Its pathetic when Apple can make hardware to run windows XP better than any PC manufacturer. The hardware hooks up perfectly, wireless runs, putting it together was great. Looking foreward to splitting up the SIMD virtual machine execution to the seperate Intel cores. 4 Threads!! We’ll see.

For now, I spent the last two days putting all the old windows stuff onto the new machine. Installed msvc7.1 no problem. Got the old Ultrafractal stuff back. MAN, thats so fast its scary. Better yet, we’ll see how long it takes to port to the mac side. That would a GUI port to fltk, but that would be the end goal anyway.

Got the entire test script (test6.shd) to compile and produce good object code. Of course, it doesn’t work, so I’m finding I need to also be implementing debugging commands as well. Starting with our old friend printf. But this also points out something I forgot in the grammar definition. I hadn’t allowed for expressions that produce side effects, expressions that are just function calls. So I’ve inserted it into the grammar, and I’ll be producing some printf commands as well.

Implementing was a bit tricky. I required some grammar debugging, and some research into how Spirit grammars work. I forgot that actions tied to rules get executed as soon as they’re matched, so I was chasing some ghost bugs for a while. I also forgot about the role of errors and having an initialized stack for expression parsing. Once I got these out of the way, I correctly had expression statements implements. Even got a print command started for debugging.

Unfortunately, there is still something fundamentally wrong with the variable linking stage. The base example is missing values, and anything more complicated coredumps. So I’ll have to have that working before getting any print commands implemented.

Stuck on a coredump. Its causing me to re-inspect the grid/shader/shader instance loading/linking procedure. Its not immediately clear how the grid planes and the shader symbol table sync together.

In the simd operator, I made an assumption about the number of planes that existed, which is ridiculous. I just made the number of planes match the initial .asm example. Upon resizing or setting the .asm file dirty, we need to have the planes and symbol table match. Also make one wonder how previous examples haven’t crashed sooner, since no attempt was made to make the test .asm files match the simd.cpp file.

ARGH… so close… I’ve cleaned up a LOT of assumptions and bad code I made to speed up the RunContext development process. In the course of debugging, I’ve been generalizing a LOT of the binding/variable code. Which is good news. I’m SO close to fixing this bug. Its now down to a bad index inside smd::Funct for my tmp variables. I should get it by tomorrow.

But what’s strange is that the bug doesn’t exist in Release mode. Uninitialized variable. Darn… compiler works again…

GOT the shading language to compile and execute identically to the assembly test. Mon May 7 21:48:34 PDT 2007. Hoo RAY. There were some bugs in the simd instructions, but thanks to the world of templates, I only had to edit a two functions to handle up to 100 permutations of Float/Int/Double, vectors and scalars.