[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.
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
various 3d techniques
av
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:
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
videocodecs
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
fluxus/scheme
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))
