Procedural Closures

Previously I've been working on proving the synthesis and editing process of a single 'object' within a fixed geometry/calculation memory budget (the synthesis buffer).

Since this doesn't scale and won't let me achieve the ambition of large procedural worlds, we need something more.  This is where Phase II comes in; a system to hierarchically synthesise multiple objects of successively reducing scale and increasing detail when and where it's needed.  This is based around a kind-of 3D subdivision of the world with more subdivision and detail near the observer and less further away.  There are a number of parts to this investigation:

• The synthesis system needs to support the concept of closures; snapshots of a procedure and its input values that can independently drive further synthesis.
• Graphical bodies need to support sub-bodies, each capable of containing procedure closures to drive successive synthesis steps.
• Procedures need to be able to generate higher detail closures from sub-sections of a procedural model to be used to populate these sub-bodies.
• The renderer needs to be able to switch between low density bodies and equivalent high density sub-bodies according to distance from camera (and when they are available to draw).

This is the bare minimum needed to effectively prove the principals of phase II and enable generation of scenes much much larger than a single synthesis step can generate.
Wish me luck, I'm going in...

Approaching Phase 2

Oh my, yet another year.  Not big on progress news are we.  Well, I have not been idle (except where blogging is concerned), and a lot has happened.  Let's start with a screenshot:

This is the current state of my experimental procedural modelling system, called 'Apparance'.  Here you can see a number of significant improvements over my initial prototype.  I have visual editing of the procedures, fairly advanced property editing panel, and a bigger list of operators to build with.  This represents the final stage of what I have come to call 'Phase 1'.  This is where I prove the first key element of my project; that of visual editing to drive procedural modelling.  I also wanted to take it to the point that it could stand up as a 'minimal viable product' that someone could play with without any need for tricks, manual hackery and workarounds.  I am considering releasing the binaries for people to play with to get some feedback and test the water a bit.  I've collected a few more pictures from its development history over the last year in an Apparance development gallery.
No promises when, but next time I'll talk about Phase 2...

Another project takes flight

Goodness, a whole year has passed without a word. Until recently this was also the case with any form of code. I am now however spending most evenings working on something not entirely unrelated to the project. The progress I am making with it is very rewarding and I am programming with passion again. Let me talk about it for a moment...

For a long time I've been thinking about the virtual circuits project, as I hope this blog illustrates, but I have come to find it too hard to work on due to its size. I'm sure I would progress gradually, but it seems to have petered (yet) out again. Along-side this, a second great interest has occupied me with almost equal power, a secondary project idea I have invested a massive amount of thought cycles to over the years; that of procedurally generated worlds. Now without going into it too much at this stage I decided to start prototyping it up and found myself making some significant progress, even re-using some of the virtual circuits codebase I had already laid down. I wouldn't describe this second project as a new direction; it is more a parallel track as there are overlaps and similarities. In fact, I have come to realise that working of this new technology is going to stand me in good stead for tackling the bigger project that now lies underneath on the pile. The following strikes me:

• As I am re-using some of the tech, any work on developing that will benefit both projects.
• The dataflow paradigm is something they both share, all-be-it with some subtle differences, such that development of the model, views and tools is largely transferrable.
• The procedural worlds would be a great test case for the virtual circuits as I envision them being the most powerful way to 'run' the world functionally.

Based on this assumption, I am going to roll the new project into the remit of this blog. It seems like a good idea to keep focussed on a single blog for both rather than start a separate one. In fact, the overlaps between them would just be a pain across two blogs.

So, what have I been busy on? So far I have set up a very basic native DirectX based render system supporting multiple viewports, cameras, scenes, layers, and bodies, with proper resize, device reset, and threading support. This serves as the raw engine into which procedural graphics synthesizers feed meshes, and eventually textures, materials, and more. I have an initial implementation of the synthesis system with multiple synthesizers running on separate threads, the start of an operator library, and data driven procedure definitions. All this is hosted within a managed WPF test app to provide simple viewport/camera/catalogue and textual (XML) procedure editing. Using a system called a Network Bonded Hierarchy I was developing for the VICE project to communicate between the engine and editor the managed-native interop has be reduced to three pinvoke functions. All that’s probably a lot to take in at once; and I hope to expand on this in future posts. For now, though I’ll leave you with a screen shot using just a cube operator and few other basic logic and maths operators to create an interesting recursive shape.

A realisation on progress

I've inadvertantly managed to make some progess, not physical progress, but psychological progress. A couple of nights ago I woke at 3am and spent the rest of the night mulling over some of the problems I face with this project. I decided to apply some very focussed thought to a single particular problem; that of synchronising data flowing between concurrent circuits (between threads of the same process, between processes on the same machine, and between machines via the network). It wasn't the progress I made on mapping out or solving the problem, it was the realisation that after writing it up yesterday that this was actually useful progress. It now seems an obvious thing to say, but this approach which seems to be along the 'divide and conquer' line may actually be the way forward.

I've tried this approach before, but I don't think I had the right framework in which to accomodate the results such that they would remain useful. Part of the problem has been how best to record my thoughts and expanding design; separate files, big word document, web pages, wiki, spreadsheets, one-note, visio diagrams, database, bespoke tools, etc. Having just tackled a very specific task I was looking for the best place to document it and realised it was really just the fleshing out of a small sub-section of the technical design overview. Not wanting to clutter the overview I rearranged the documents slightly so that this tech design doc acted as the to-do list and fill out another document with the details. This will form a technical implementation guide, some design, some solution, some thinking, and act as an execution plan for all the individual parts.

So, I didn't realise it, but my overview gives me a detailed enough skelton that can be fleshed out bit by bit and more-or-less at random. This means several things:
1. If I get stuck on (or bored) of part of the design I can switch to another.
2. I build up an implimentation guide to follow for when I actually write the code.
3. I am able to design a very large and complex system having broken it down into small parts.
4. I get to see really how large and complex a project this is (eek!).
5. It also breaks the deadlock with the hierarchy navigation UI problem I've been stuck on.

I guess none of this is new wisdom, but coming to the realisation myself is more potent than being taught it. Here's to progress!

An Open Book

I'm not sure this is the right thing to do. I don't know what is. Here are my journal and technical design notes:

• VICE Design Journal - my original design ideas, thoughts, notes and journal.


• VICE Technical Design - the latest structural overview of the main concepts.

At least it should help save some blog time. It's quite a lot to absorb, but dig in, let me know what you think, ask questions.

Details and Features

I've expanded a bit on the higher-level goals, now I'll describe how I see it working and some of the features it must have.
The core of it will be a system of virtual circuit elements, or virtual components, connected together via their virtual I/O pins. There will be fundamental component types (that get implemented in code) and composite components built up from these fundamentals (and indeed other composite components). (Aside: The word virtual which applies to most of these concepts, since they mimic real-world electronic circuits, will get a bit tiresome quickly so it will be assumed henceforth.) Input and output to/from the computer running the system will just be implemented as a set of components and wired up as signal sources and sinks. These circuits will run on one or more connected computers, with interconnections abstracted away as much as possible, allowing seamless wiring across machines. It will be edited via the network connection from an editor running on another computer. This editor will employ sophisticated visualisation techniques to make navigation around complex circuits and systems easy, providing rapid editing, tweaking, and viewing of the circuits as they are running.

The hosting service must be able to run on a variety of hardware from old salvaged 386's up to modern high end multiprocessor machines. This is important as I want to be able to utilise the cheapest and simplest hardware to solve a given problem, or conversely just use whatever is to hand to solve the simplest problem.

The overall systems you would be able to create with this tool could be as large as spanning many dedicated machines across a network or the Internet to just a single background task on a single machine. Being able to distribute work and scale systems as easily as dragging a circuit from one box to another and have it all just work is vital for supporting high bandwidth compute bound processing systems (e.g. computer vision) as well as physically distributed systems (e.g. large plant control or multi site monitoring).

Some of the other features I envisage are as follows:
* Libraries of common components.
* Multicore wires (simplifies connection diagrams).
* Wiring conduits (control inter-process/network communications priorities).
* Buses (higher level distribution and aggregation points).
* Diagnostics components (editor only control and monitoring).
* Arrayed connections (for lists and collections of signals).
* Arrayed components (for iteration on a collection of signals).
* Control wiring (signals, think: pass by value).
* Process wiring (objects, think: pass by reference).
* ...

I will go into more detail on these at random in future posts.

What's it all about?

Ok, so, enough preamble, what is this all about you ask?

For a long time I've dreamed of having a way to make the creation of electro-mechanical, electronic, electrical and purely software devices easier by replacing all the custom control electronics with a computer. This is a fairly obvious approach, nothing new there you say, but I am after something more powerful, I want to be able to construct the controlling software with the same methods and techniques used when creating the physical parts. Designing, inventing, and creating a physical system or machine is a process of experimentation, testing, iterating, and trial-and-error. It involves wiring up motors, switches, lights, sensors, modules, relays, solenoids, valves, and more to IO ports of a computer or microcontroller, fiddling with wiring, tweaking controls, watching the effects, plugging them together in a way you have never before to create something new. I want the same process for the software that runs them. I want to be able to drag virtual components and circuits around the screen, plugging them together this way and that, tweaking values and watching the results, a fully interactive control system working with the hardware, all in real-time. I have so many projects that could work like this, so many things I want to experiment with, so many ideas, so much that could be done with a system like this, that it has become a project to preceed all other projects. Every time I think of a new idea it rapidly degenerates into 'how much easier this would be if my control system idea existed', and then to 'there's no point investing any time in hard wiring/coding my idea when I could be working on this general solution that will benefit all projects so much...'.

And so, we have my project, a technology I am calling Virtual Information Circuitry Engineering, or V.I.C.E. for short. I'll expand on what it entails next.