The file sexp_export.py lives with your blender scripts.
As of writing it only supports Blender 2.49 (mostly because
the Python API of 2.5 is still fluid).
OpenGL and threaded operation of slime/swank do not play nicely unless
your slime / swank communication-style is NIL, not :spawn. I have not
(OpenGL contexts require code to be executed in the same thread, and
the repl is executed in a seperate thread from swank, making
interactive execution impossible.)
At present photons is mainly tested and developed on Windows with
SBCL 1.0.45 and CCL 1.6.
Photons has a layered design.
Assets are at the bottom layer (actually things like textures and
glarrays/vbos are below this, but these are considered internal).
They live in ~/photons, along with any support files such as textures
and fonts. They are created by the blender exporter, sexp_export, which
exports geometry, cameras and lights as .lisp files
Assets are discoverable via the (list-assets) function. Assets can be used
to create components, which are the next layer.
Components are your atomic, updaatable, renderable object. When invoked
with (test-components) in photons-test, the photons main loop automatically
renders and updates all components in the scene. A component may be created
directly from an asset with the (make-component "assetname") function call.
Copies may be created with the (clone-component "component-name") call.
Components are discoverable with (list-components). At present camera, mesh,
and light components are implemented.
Entities are yet to be implemented. They will consist of collections
of components, and be able to pass messages to each other. They will
be initially primarily implemented to create renderable objects.
Photons offeres a number of restarts while rendering. One is to drop
entirely out of the rendering loop and exit glfw. This is the
preferred mode of terminating photons as it enables the GLFW cleanup
code to run.
Another is to simply skip interactive evaluation of the form you just
entered, if it is badly formed.
If a condition is signaled in the rendering or update phase of photons,
a restart will enable you to skip this phase (after you fix the problem
that gave rise to the condition).
This has been found to maximise interactive working, and I believe
photons is a very stable way of livecoding OpenGL code in Common Lisp.
Phtons has a main loop divided into five phases: creation,
intiialisation, rendering, update and destruction. These are associated
with function tables, which are essentially a list of function hooks
to run at that time (see tables.lisp)
Creation: Lisp side and foreign data that represents assets, etc are
created. The functions in the intialisation function table are run.
Initialisation: The rendering surface and opengl context have been
created. A good time to create OpenGL server-side data and do any
Rendering: Stuff draws. For very precise rendering, an interpolation
fraction is given whih is the value to interpolate to preicesely
render the frame as it would appear between this timestep and the
Update: Stuff changes: Physics update happens, if there is one. State
changes. Time and deltat time are the parameters to these update
functions. DetaT is the time between the last timestep and this.
Timestep is controlled by the *timestep* special.
Destroy: The window has been closed, or failed to open. Time to tidy
up OpenGL state and free any foreign memory.
A run with Photons
The usual preliminaries:
;; in the emacs minibuffer
;; in *inferior-lisp*
(setf swank::*communication-style* nil)
;; in the emacs minibuffer
;; in the slime repl
(asdf:oos 'asdf:load-op 'photons)
[ on CCL there will be a restart warning about redefining
DELETE-DIRECTORY; this is safe to ignore
[ the above should open a window and get the photons
rendering loop running ]
[ You may see a warning about communication-style
not being NIL: this means that the repl is running
in a seperate thread from photons. You must ensure
swank / slime are using the NIL :communication-style
in order to interactively evaluate OpenGL code at
the REPL ]