programmatic approach to shape grammars
Brought to you by:
mikaelc
Menu
▾
▴
It seems like implementing a shape grammar is going to take time for all sorts of reasons.
As you are using QTScript (which is an ecma script similar to Javascript), how about adding some methods to the existing system and allowing evaluation in the tree...
This would not prevent the addition of a suitable grammar later but allow us to do all sorts of similar things and possibly motivate a specific grammar.
Here is an example of what I mean:
Store (or have accessible) the history of operations applied to the existing cell at eval time. Here I use cell to represent the transform that is incoming to a Rule, or the state of a node in the Tree.
This would allow us to do things like:
Rule R1 {
if self.depth > 3 then R3 else R4
... }
This can be simulated by using maxdepth and > in the existing syntax but a lot of duplication has to be done in the definitions of R3 and R4
Also this case is much harder to do:
if mod(self.depth, 2) == 0 then R3 else R4
If a user defined a new value then this could be available to lower branches in the Tree.
E.g.
Rule R1 {
self.myval = 22 }
then this would be available to cells lower in that branch by referencing self.myval e.g. setting a window style at a certain depth can be propogated to all children of only that branch
Also the parent can be reached to, perhaps, see if it is small enough to apply a new rule.
Rule R1 {
if self.parent.bbox.maxdim < 1.0 then R3 else R4
These would be functions to be evaluated at runtime to save on storage.
A starting set might be:
self.parent - to refer to the level above
self.depth - an integer based on depth in tree
self.bbox - the unit box given by the transform of this node in the tree
with extra methods for position .x, .y, .z, for length in each dimension (.X, .Y, .Z), diagonal length L,
.maxdim - the largest of .X, .Y, .Z
orientation .rx, .ry, .rz (in degrees), and scale .sx, .sy, .sz
with methods to calc dot and cross products and an aim-at method.
self.color, self.hue, self.sat, self.b, self.a
returning null or None if value does not exist and equating that to 0 for purposes of calculation (to avoid lots of exception testing in the code)
We could then make objects that, for example:
- all pointed towards a certain spot regardless of depth or other rules in the tree
- could scale and position themselves to fit evenly on the sides of the parents (like windows)
- etc
all without building an explicit syntax to support this like CGAs etc.
at the same time not excluding their addition in the future
Hi,
The reason I'm adding QtScript is for programmatically setting up workflows, such as changing a EisenScript variable, run the script and spawn an external process to ray trace individual frames for creating movies.
I am not very fond of extending EisenScript itself with program logic and variables - as I said in the post about a second random number generator, I want to keep EisenScript clean instead of something which resembles an ordinary procedural programming language. For creating highly controlled structures something like Processing would probably be a better choice!
Regards, Mikael.
Yes - I see.
Cheers...