[See post to watch QuickTime movie]

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.

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.

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

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.

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.

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.

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.

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.