Luna-Canis

Done more than enough compiling obscure shaders. I’ve started reading in the .ufr files, which are state files for an Ultrafractal render. These are a LOT easier to parse, its more just token/value pairs as opposed to crazy expressions. Once I’m done with this, then I have to figure out an implementation for the execution. I’ve been kicking around a few ideas for the node implementation. The best one so far is having something .otl-like, except it has different functions defined. One for the globals, one for the formula, one for the inside coloring, one for the outside coloring. The parser will assemble the ultrafractal source into a single operator with those function put into a single file. Another operator can then read in this expression tree, parse the parameters, defaults, and compile the code internally to SIMD for execution.

otl’s should have this. They should have vex functions that get called when the frame changes, or when the name changes, or when a parameter changes. The main engine shouldn’t be responsible for doing setup and cleanup. That’s always an awkward implementation for hdk vex operators.

So I’m able to read in an entire Ultrafractal statefile. All the layers, all the formulas, all the parameters, etc. So now I have to create operators to execute them. For this, I have to extend the expression language to be able to create operators. Kinda like .otls, but these will be able to do more. Before I start on this, I just want to write out a (minimal) feature list that I’ll need to have implemented to get this working.

• I’m defining a new file type, these are pretty generalized. Depending on what variables I’m binding to it, they’ll be able to operate on images, geometry, pretty much anything. So the filetype shouldn’t be associated with just images. For now, I guess I’ll just give them a .shd suffix and think of some pneumonic later.
• The file is going to be a list of functions. Each function gets called at different times.
• classCtor() gets called the first time the operator is created. This defines the operator name and label, also defines any parameters to be binded, hidden, varying, or user parameters with a gui associated.
• ctor() gets called when the instance is created. This will set up globals.
• frameChange() gets called when the frame changes. If this is a time dependent operator, this can be used to update time dependent globals.
• execute() this main execution loop
• dtor() cleanup globals for this instance.
• The file will be parsed, and the functions listed will be the main entry points. Other local functions can be defined, and called.
• The only function that need to be executed via SIMD is ‘execute()’. A finished product would check for the code in this section to be fully able xlate itself to .asm code. But there is no reason you can’t have multiple simd sections, embedded in the shading language. This wont be necessary for emulating .uf files, but its an interesting feature to have.
• The shading language currently looks for only one function, plus some globals. Need to extend the shading language to just be a collection of functions. Hopefully this wont break too many things. But its definitely a step foreward, and makes the shading language more flexible. I was going to write an entirely new grammar to start fresh, but I think that might be a waste of time and code. I’m going to try converting the ShaderGrammar to just be a single function, then have another grammar be a list of functions. Hopefully I can work this out and not get stuck with the code in some unuseable form.

The first example would be a prototype file that defines an operator, plus some parameters that I can instance with the gui. I really like Houdini’s VopSop, it creates a one-off operator, I wont be able to do that since this is text only.

I found a sane path to upgrade the ShaderGrammar to be a function. Also, I’m adding a new Cmd subclass for holding a function. Everything falls into place.

Some interesting developments: I’ve upgraded the ShaderGrammar to parse functions instead of just one function. This generalizes for the existing shader grammer I already defined. What I didn’t think of is how to make the functions and the shader language re-entrant. So the grammar will execute expressions, and the expressions can call a grammar function.

I’m going to update all the existing .shd files, make certain they still execute, etc. Right now, I should decouple the function parsing from the shader parsing. That’ll be necessary since I need to have a shader grammar, and an operator grammar, both using functions.