Dev:2.4/Source/Development/Projects/DbBlender/OldPage

DbBlender

What is DbBlender?

This project tries to investigate, design and implement SQL support in Blender to enable remote repository capabilities.

There are a few goals I've set for this project:

• user: $ ease of use: through providing known mechanism enable user to interact with remote repository $ collaboration: enable web-based collaboration through remote repository $ item database: the librarian
• technical: $ keep SDNA intact: to maintain as much compatibility with existing and future .blends. There's no reason to break it open, since it works fine and provides already builtin back- and forward compatibility guarantees. $ reuse existing code: reuse current load and save functionality as much as possible. $ non-intrusive: deducting from the first two goals, it is my intention to keep Blender intact as it is and add code more or less around Blender. It should be possible for others to easily disable this functionality (or enable ;) )

DbBlender for the User

Apart from its technical side I have to think also of how this should fit the user, how it is to be used, and how it is to be presented.

When you think of Blender and SQL functionality you might wonder what good it is for. The remote repository can be used for several goals, like teamwork through the net, or having a central library for models, available for all users who are allowed to connect to the database.

Think of it as synchronisation with a SQL server. Blender data (like mesh data, etc.) can be flagged to either push itself to the database, or pull data from a database. To get new data (mesh, material, etc.) from a database the user can 'browse' the availabe data, and add it to his .blend, pretty much like the current "Append" method for libraries.

The user can manually synchronise with the SQL, thus taking away the need to have always a connection open. Also, if the .blend is saved synchronisation can be done always at a later stage. The user is still able to work with the data, even though there is not a permanent connection with the database.

Visualisation of the datablocks can be done in OOPS view, and some of the settings could be visible through OOPS, too. More info: DbBlenderUI.

DbBlenderRoadmap

I'm not going to draw up a decisive roadmap, but some small list is available.

Screenshots and Videos

movie 5 movie 9

Documentation

Database structure

I use FabForce's DBDesigner|database|setup. I've attached a preliminary draft, which contains not much useful information at the moment.

The database will mainly hold binary data, ie. the dna of blender data. Direct data of structs will generally be put into table members, for linking data a linking table will be created, so that when specific has been saved to the database, it can be linked multiple times and with other data.

These linking tables actually can be thought of as the pointers that link data to each other. (this thought need to be worked out more carefully).

Especially with the database it is imperative that the binary blender format is retained as much as possible.

• save binary data
• save sdna with the data for back/forward compatibility
• represent partially filesystem (for full emulation - client side logic).

Communication

• SQL queries needed to retrieve data
  • 'filesystem'
  • blender data
  • authentication

Technologies

• MySQL library

Needed hacks

I started the development on my win box, using scons to do the build process, but there seemed to be problems with WinSock.h. I deleted each and every occurance of the FAR define, since it is always defined as empty for my compiler. Somehow when building with scons, that gave problems.

Through the subversion repository you can get also the windows library and .dll for mysql.

-- NathanLetwory - 21 May 2004

just made some spelling corrections -- JW