Luna-Canis

I’m at the point where I need some simple operators to do things mask and composite the resulting elements. Operators that are made up of very basic expressions, with no control flow. So this would be perfect to get the simd operator in the imgNode library to handle.

The first design element I left out is a way to handle an arbitrary number of inputs. For this case, I only need two, but it would be best to handle as many as needed. Since the colors are packed seperately in memory, not as tuples, I’m thinking that we could define (r,g,b) for the first input, (r2,g2,b2) for the 2nd input, etc.

When the shading language matures, we’ll have to find a way to have the shading language define a function to specify the number of inputs, number of colors per input, etc.

HMMM… unary operators haven’t been FULLY implemented. There is a bug where the parser gets confused between the binary operator ‘-’ and the unary operator ‘-’. I don’t think the SIMD commands were ever fully implemented.

I can’t divert too much time for fixing the shading language and the unary/binary operator discrepancy. I’ll be hand-coding the .asm files to do the masking/invert operators. For now, its enough to generalize the Smd operator to handle multiple inputs. The Smd operator was hardcoded to only operate as a source, not as a filter. Got that working.

There is a sample grammar called YAC, which stands for “Yet Another Compiler”. It handles variables and fuctions, and has a lot of high level Spirit functionality. It also has a very clean expression grammar which handles unary and binary operators, along with variable assignments, functions and more. It can be found here. This could be a good template to follow to help with the binary/unary operator problem I’m having.

Got the max working via SIMD code, and it was compiled using ‘lcc’, not hand coded assembly code. Problem: the sprite is too sharp, and doesn’t fit into the ring image space at all. I’ve avoided this long enough, but I have to code up a blur operator.

A typical 2D convolution gets optimized by separating each dimension into a separate pass. But that should effectively create an anisotropic blur kernel, which sucks. Don’t know if I need to do full 2D convolution or not. Maybe leave the option for both??

Turns out that implementing both wasn’t a stretch. What’s interesting is that the triangle filter isn’t separable, (the single/dual passes come out different) but the gaussian filter is separable. As advertised, the dual pass is computationally superior.

Here is an example of the sprites+blur+rings. I’ll be combining this with mandelStalks, just as soon as I enable the crop operators to use certain expression variables.