Luna-Canis

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.

Going to have to think of the next logical step for the shading language. That would have to be for loops, so that we could perform iteration for the escape time rendering. That’s definitely it. In the process of doing this simple example, I had implemented statement functions and variable assignments, which I hadn’t considered before. It was time well spent.

I’ve got the printing working, and got to implement a utility that does all escape character substitution like /n and stuff like that.

But I’m seeing a shortcoming in my symbol definition. The symbol can only point to the start of the location of symbol data, it can’t differentiate between a vector[3] and vector[3][0]. This wasn’t a problem with all the different cases of operators and functions. But for something that’s highly overloaded like the ‘print’ commands, we need to be able to make this distinction. This will most likely break a lot of things, but luckily I came across this bug early on. Hopefully the fix will be relatively painless….

Ok, just looked at the assembly file definition, which can be found here. There are two ways that the symbol definition is used. They are declared in the SYMBOL section of the assembly file. This should stay the same. What needs to be changed is the way they’re referred to by expressions, and how they get written out in the assembly code stage.

Got the assembly file symbols to differentiate between referring to an entire symbol and a sub-component. This allowed for the print command to have properly overloaded arguments. Works fine!!

Now onto FOR LOOPS. But to get that, I should look into doing things like pre/post fix operators like ++/– and other operators such as +=/-=.

More thoughts…. pre/post fix operators such as ++ and — are for the shading language grammar, NOT the expression grammar. These operators have side effects and are not part of a pure expression language. On the other hand, what IS missing from the expression language are unary operators such as ‘!’ and ‘-’. These are important.

I FINALLY got around to printing up a piece and my friend was nice enough to have it displayed in his bedroom. Cecil and Helen from soccermom have this over their bed. Click on it to see a higher rez version.

Also have some .avi animations in 2k and ntsc resolutions. Requires divx to view. I should convert them to quicktimes or something with a more common codec. Windows users can use windows media, but mac users may have to download and use the divx viewer.

This project was an experiment with Pickover’s epsilon cross method. Basically, we count how many iterations it takes to arrive within a small distance to the real or imaginary axes. We can rotate the axes, offset the rotation with respect to the iteration number, do some spatial and temporal antialiasing, etc. This leaves us with the final result you see here. I coded this up in Vex COPS using Houdini. The goal will be to able to do this using shading language in spa.

I’m reading ‘2012 The Return of Quetzalcoatl’ by Daniel Pinchbeck. You can get it here. It brings together many disparate things in my mind and wraps them up nicely. I’ll only include a quote here and let you check it out on your own…

Soon I found myself rematerializing in the musty Haight-Ashbury attic from which I had launched. Coming out of my trance, I looked down at my arm. Standing on my sleeve was an intricate metropolis, a science-fiction city of glittering spires and emerald skyscrapers in which I could almost see the movements of an infinitesimal transport grid. I looked around at my friends sitting in a circle around me, and all of them appeared radically transformed. They were themselves, but patina’d with complex multicolored tattoos, sporting celestial headdresses, prismatic auras, and elaborate comic-book-superhero armatures. The thought occurred to me that we were actually space aliens or cosmic deities who had projected ourselves backward into this time, prearranging this crude but amusing encounter in “meat-space” from our holographic homeland. “Everyone is God,” I muttered as the vision faded away.

I got an idea to combine mandelbrot stalks, a basic Mandala, some space invaders characters, and possibly one of the mooninites. The intension was to use the shading language for everything, but it’ll be a long time before its ready to do anything that useful. So I’m just creating c++ operators to do it. I hope it comes out nearly as cool as I’m visualizing it in my head….

Ok, maybe no mooninites, but definitely the space invader sprites.

So I guess its good to fix things along the way. I realized that I needed two different ways to detect the need for supersampling. One is by taking a regular contrast measure between neighboring pixels, but for fractals that have ultrathin filaments, more analytical methods are needed. Specifically, I need for the supersampling to be triggered by either pixel contrast or an image map. In implementing that, I found a bunch of inefficient code, so I started cleaning it all up, and now its FUCKED. In the end, I’ll have something more flexible and appropriate for fractals.

Ha ha

Ok works now. To do the supersampling mask, I need to know the projected pixel size in the complex plane, and how it changes as I iterate. So I added an automatically calculated parameter to the camera operator so I can refer to it from the escape time operator.