Scripting
In a nice wow moment, I added Javascript support to the ray tracer sample in a matter of minutes. It “just worked” using the existing architecture with very little code added to the sample itself.
(Ok, admittedly, I did do a somewhat lengthy refactoring and clean-up submission to the LxEngine internal Javascript support – but just to make it more modular now the vision of the LxEngine architecture is a bit more mature than it was back when I first started integrating V8 into the project.)
The Result
Here’s a simple scene created via an XML document with a Javascript for loop to create the various spheres and their materials.
LxEngine Ray Tracer Scripting
Here’s a link to the XML scene file that created it.
The Code
The script support is added completely independently of the ray tracing code. This is the way it should be and, it turns out, that’s exactly the way it is too.
(1) The LxEngine Javascript subsystem (one of the standard ones) is plugged in, via 1 lines of code:
DocumentPtr spDocument = spEngine->loadDocument(options.filename);
spDocument->attachComponent("javascript", lx0::createIJavascript() );
(2) A new Document::Component is registered to look for <Script> Elements, which it passes the contents to the Javascript subsystem to do the interpreting. The scripts themselves use the LxQuery API (a JQuery-like, pure Javascript library for manipulating the LxEngine DOM) – which manipulates Elements within the Document without needing any app-specific knowledge (i.e. it doesn’t care that this is a ray tracer, only that attributes and values on Elements in the Document are being changed).
spDocument->attachComponent("ray", create_raytracer() );
spDocument->attachComponent("scripting", create_scripting() );
The object created by create_scripting() is quite simple and mostly just C++ boilerplate to create a class and respond to Document changes.
The LxEngine Javascript subsystem itself was added mostly back in November for other projects, but due to the architecture, it was fully reusable without any changes.
(3) There is no three. The ray tracing code itself has no knowledge of whether the Element was created via a script or was part of the initial XML. In MVC terms, the ray tracing code just works since it is properly abstracted from the Model changes.
It was really cool to have the LxEngine architecture surprise me (i.e. the guy designing this and constantly setting unrealistically lofty goals of how I want this all to work) with how seriously easy it was to add a useful feature like scripting.
[...] it just worked (again). The Javascript implementation was essentially fully reusable from the ray tracing sample. It [...]
Rasterizer Progress
31 May 11 at 17:50