May 18 2008

Animating Brushes

Published by at 10:41 pm under Code

I have been spending time making a realtime brushing engine. It uses CG shaders to do the rendering and can be driven by scripts or a joystick.

The interesting thing when running in real time is that the brushes fade out and move around. It means that often, it is much harder to understand what the underlying picture is (not that the fish or crabs in the previous videos were easy to understand).

The entire engine is a multithreaded render which builds a command buffer in the simulation thread, while drawing the previous frame’s command buffer in the render thread. The synchronization is always tricky, but I have a number of debugging rendering modes which make it easier to figure out what is going on. At compile time, I can select:

  • Multithreaded double-buffer
  • Single threaded double-buffer
  • Single threaded single-buffer
  • Single threaded immediate

When I am adding a new feature, I start at the “easiest” level (single threaded immediate) and work my way up from there. Usually, if the single threaded double-buffer is working fine, then the multithreaded one is okay as well.

I am using Direct3D for all of the rendering. Along with the command buffer, I have a vertex buffer. Since it is created with a FVF (vertex description), I can use it with the offset command to just fill it with vertices. Since I am used to the PS2 and PS3 ways of rendering, this feels very natural. I don’t have many fixed vertex buffers with the brushes…everything is dynamic and generated per frame.

Currently, I have flower pictures as the background. I create a cube with a flower per panel. The panel which is facing the user is the drawing panel, although I have a number of buttons which cause other things to happen to the image (spawn a 1,000 brushes, collapse all brushes to the center, etc). I sort the panels based on the middle of the panel and get some rendering back to front. It is not perfect, but it does the trick for most angles.

The next step is to add the scripting back into the engine. With my previous Peduncle work, it was all non-realtime and I just rendered out a movie. I need to get some level of control over the input to the system…relying on my joystick movements in realtime won’t cut it.

The other thing is to add some more job/task management code. While I have the simulation and rendering in different threads, there is a lot which can be spawned off to other threads. For example, all of the panels are distinct at the moment…they don’t depend on other panels. I am planning to spawn a number of threads at the start of the app. Then they can be woken up by tasks which need to run and then go back to sleep when the task finishes. The goal is to not spawn/kill threads every frame, which is very expensive to do, but rather reuse the threads.

No responses yet

Trackback URI | Comments RSS

Leave a Reply

You must be logged in to post a comment.