Game Development Reference
In-Depth Information
6.8 Complicated Assets
In many cases, sending a field-changed message is all that is needed to change an
asset. However, in some cases, that protocol would be too slow. Two classic exam-
ples of this are texture and model changes. In most cases, assets are represented as
large, untyped arrays of data. Adding the overhead required to properly describe all
of this information and referring to the values as strings would be wasteful and quite
dicult. One option is to implement a real-time model-editing API like Verse.
2
It
has some restrictions on the formatting of the data, but passes model information
in real time.
Another option is to chunk changes and have a special case for these asset
types. For our pipeline, when a texture or model changed, we would recondition
the asset and notify the engine to reload the file. This notification followed the
same communication pipeline as other real-time changes but utilized special case
code to reload the asset at runtime. While not as powerful as real-time editing,
avoiding that problem entirely is significantly easier than implementing it inside
the relatively simple communication system. This has the added benefit that any
image editor can be used. Instead of writing a plugin for each image editor, we
wrote a file system level
3
tool that would wait for textures to change and alert the
runtime when that happened.
Because we wanted to see real-time editing in our tool, we took a hybrid ap-
proach for models. We knew we could not afford the generic reflection-based system,
but we also wanted a faster turnaround for large models. Here, we added a binary
diff system. Instead of sending the entire changed asset (which for a suciently
complex model was quite large), we would only send what had changed. This relied
on the processing power of our computers, but in this case, the optimization al-
lowed us to have nearly real-time changes for model data. Writing a fast, powerful
binary diff system was beyond the scope of the project, so we were able to rely on
a known layout of our vertex structure. In general, most of our changes happened
in small contiguous memory blocks. The diff would walk the data for the first and
last change in the block and only send over those bytes. On the runtime side, it
would also take advantage of this diff information to know what part of the GPU
representation of the vertices needed to be locked and updated.
6.9 Conclusion
Real-time editing capabilities are incredibly useful for speeding up content-creation
time. Once a content creator has experienced this functionality, it is very di-
cult to return to the normal work-build-test model. It frees them up to do what
2
Formoreinformation,see
http://www.quelsolaar.com/verse/index.html.
3
Writing a file system watcher can be implemented with a small number of OS calls. Care
must be taken to test on a variety of different image editing suites since many suites have odd
I/O behaviors which may leave files in an indeterminate during writing.
