[20060807-11] During the season of Bureaucracy, Anno Mung 3172. some workshop notes from one of the Xmedk Workshop series. with dave griffiths, pix, tim boykett, tom schouten, kate rich, nik gaffney, maja & goran kuzmanovic.

• fluxus [see: Fluxus Notes & Sheep Scheme
• packet forth [see: Packet Forth ]
• ogre [see: Ogre Engine ]
• etc+

• “buzzword archaeologist”
• “carbonated cheese”
• “being a generalist only really works when you are around people who don't know anything (much about what you are a generalist about)”
• “localised expertism” - I think this was meant to be the idea that expertism is a quantum phenomena. Either you are an expert and no one understands you or you aren't so you're an idiot.

pix was wondering how appropriate the techniques required for using ogre in the 'loop of artistic processes' are. primarily, having to build a specific framework each time, along with the problems involved in having to think too far ahead while doing things the 'ogre way'.

scripting languages provide a way of reducing the initial effort, but often at the expense of having less flexibility later in the process, particularly with regards to optimisation and machine effieicny.

the scriptable → ogreOSC experiments were a preliminary attmept to reconcile the script/static divide

scheme benchmarking → fluxus/ scheme integration. .

textures and dirt → how to make computer graphics look dirty, and the continued relevance of materials. computer graphics can be seen as 1/2 geometry, 1/2 maelable modeling/texturing/artwork. in some ways analogous to incorporaitng samples & synthesis. discrete sampling vs. continuous.

discussions about different types of efficiency. on one hand, the ease of expression, how effiecient is describing/desinging/testing. on the other, performance/machine efficiency can have definate implications. being able to see this tradeoff is often a result of having spent [or lost] alot of time on either side of the 'divide'. the trade offs across this divide can be seen in pd as compared to gcc, and dave having to keep scheme out of the main graphics loop in fluxus.

development faces the tradoff between using libraries, or previously made wheels, rather than reinventing. yet time is often lost in working out the complexity of glue layers/mess and OPAs (other people's abstrations)

there are many different ways of working with graphics material. so the tools for various tasks should/could be based on how this works.

how to work out a continuum from high level/general to specific was a recurring theme. tom's motivation for using forth, to help mesh lower lvl with more the general. dave's motivation for embedding scheme into fluxus, etc.

diifernce between events & stream. how to use continous data… ,

debunk [fullerism: diˈbə ng k] → where did this come from → [bunk: nonsense] → nänˈsensikəl

genetic programming to generate shaders

• how to evaluate the fitness of a shader
• glsl shader generator, ref. fluxus list
  • optimised tree traversal,
• instruction limit, types of instructions limit

various 3d techniques

• modeling space is much more complex than 1d segments, always surfaces rather than interiors
• how is space. sampled 3space → particular abstractions.
• bringing life to things using textures. .
• extend list of 3d graphics techniques, (eg. geometries, tris vs. nurbs, particle systems]
• 'non-standard' procedural techniques.. .

av

• incorporating sound can remove clunkiness in the visuals
• the sound somehow bridges the gap.

anyway, on the issue of dirt and non photoreal rendering, there are a lot of games following this route, mainly japanese ones that are going for the calligraphy/ink look, I think okami achieves this very successfully: http://www.cloverstudio.co.jp/title/okami/okami_pic01.html

also viva pinata has a really nice look I think:

• http://www.generationmp3.com/bigfiles/Neko/vivapinata_screen3.jpg
• http://www.vivapinata.com

problems related to modeling 'things' as meshes, or otherwise wanting to do the things that are less appropriate for modern gfx cards. the unexpected difficulty of getting graphics hw to do something it wasnt designed for

scenegraph → collada [also ps3 format] now in ogre.

trade-offs between sketching & performance. often a misnomer as to how resource hungry 'scripting' is, in relation to heavy duty rendering. this becomes more apparent during NRT rendering, but is still relevant to RT processes. if in doubt → profile.

hardware interfaces

• bodydata → virutal tim
• pf/cat → pic
  • tom's bootloader w/forth env.
  • permeability of hardware/software interfaces using forth.
  • using darcs for binary rollback

videocodecs

• problems with non-framebased formats
• gstreamer as reasonable interface, pix.
• various 2nd hand murmurs of dissent,
• no particularly concrete objections
• tom suggests raw packets/frames as types
• problems behind videojack-like things
• superset vs. minimal subset of features
• little consensus of how this should be done
• is it really possible to do 'well'?
• defacto standards → what 'works'

free software dev. models

symmetry

equivalence

scraggles → hair rendering → corporate research → lighting models

something I found when researching fast hair rendering, but is just generally interesting is a breakdown of the techniques behind shadow of the collusus: here with a translation here. the pictures of how they did the hair and smoke with multiple shells and layered textures - also stencil buffer blurring etc are quite good to see.

http://www.watch.impress.co.jp/game/docs/20051207/3dwa.htm

http://www.beyond3d.com/forum/showpost.php?p=660151&postcount=18

mr. phong and mr. blinn

unicycle

why packets/forth

• packets of data as general, for instance video frames, textures, datasets, whatever → packet forth
• all vocabulary, hardly any syntax.
• hardware forth, packet forth and CAT (a forth-scheme connection) as a trinity

fluxus/scheme

• scheme-ness allows recursive ctreation of objects easily

and on the programming tack, and just to throw confusion into the already confused scripting/compiling debate is starlogo: http://education.mit.edu/starlogo-tng/ which has a very nice (although I feel it may be a little cumbersome) graphical programming interface. given enough time I'd like to write a clone of that for scheme/fluxus

livecoding codewars. something like Tierra, using a cool visualisation. potntially unrelated to spastic dancing robot with muscle actuation step sequencer in which the delays with the physics engine make it quite cool - would be interesting to see it physically.

getting PF working with the latest Xcode environment for OSX [v2.4]. the interface is lovely simple text command line stuff, the documentation is terse but there. the general memory space and the way to do things like taking over the main loop make it highly felxible - it seems that making something is PF that reacts directly to OSC as its “command line” is quite simple…

diascussion about the problems of speed. how much speed is actually lost through the “easiness” of a scripting and/or graphical interface? Dave talked about the script reading parts of the high definition renderers that they were using, this was only 3 minutes from the 3 hour rendering time. So even reducing this to zero is probably not useful.

This question then remains: how much do we lose with scripting? Associated question, which was how I understood Pix' comment about frustration with PD, is about expressivity. certain things are hard to express in PD or some other language. This seems to tie in with an earlier discussion about the idea behind unix of lots of small interconnectable specialist tools. So as Tom was saying, data streams (pipes) are just streams, they should be connectable. So a box that is an ImageMagick? unit or a pdp unit should be exactly as much a part of PD as another message type, and building units that enclose scripts (as PF enables in PD as does the python extensions (I think)) should be easy.

The fluidity of expression is problematic. Making things in some environments is easy, and working interactively with a collaborator in real time is easier with environments like PD where everything can always happen and does, slightly less easy in fluxus where instantaneous compiles are possible, hard in C or C++ with the whole edit-compile-run cycle. PF is also somewhere in the middle, the command line interface blocking procedures. Somehow a multithreaded PF is wanted here, but that probably breaks the stack model. Tom talked about a multiprocessor parallel Forth machine.

trying to get a system that does OSC reception of data for visualisation of data flows. fluxus allows a tristrip to be used, to lay out a seris of data values as waves

fluxus usage notes from dave.

the screens all refer to the same data space. as long as (every-frame) has not been re-called, the same procedures keep getting called. so re-defining commands called from the every-frame routine will just replace the current definition. Then nik has made a replacement every-frame routine that reads in certain OSC messages and will load fluxus files that are referred to. this means that he can edit files in emacs (comfortable for him) and have them run under fluxus when he needs them. dave also then talked about using the #!/path/to/fluxus -X first line to make fluxus files executable.

trying to generalise the tree example from nik I made it into a scene graph structure, then allow traversing the graph and setting various parameters such as scaling (hard) and colour (works well) and rotations (fine).

documentation madness at the end looking at the various sketched things under muscle control. silly and fun. everybody else has gone to bed.

discussion about ease of use. how much does a user need to know about OpenGL, about stacks and trees and parallel processes? Tom and Dave seem to think that the stack is a necessary part of the model that a user needs. Pix says that in Ogre he doesn't have to think about these things, he just has a scene graph and links to certain parts of the scene graph that he wishes to manipulate directly. And a game engine is even more general, in terms of not needing any particular comprehension from the user.

_(sheep (don't ^lisp))