I have a couple of thoughts on these posts.....
As for the file formats there is no reason to change or add to what
is already present and working flawlessly. All of the types defined in
DNA are saved automatically, this is the whole reason behind the DNA/RNA
concept. When a new type is added to DNA it must be aligned and the size
accounted for. There are a couple of reasons for this concept, the main
one is backward/foreword compatibility, all (or most) of Blender
releases can read files from newer or older versions. The second reason
behind DNA is to make reading/saving files easier, there is minimal work
needed to define a new type. See this page on DNA if you have any
A database is not needed to save our CAD files, it is true that there
is a hierarchy but using a database is overkill and will severely bloat
both the file sizes and the executable. Blender is a small download
right now and we really should keep it as small as we can, the
openCascade is a large library by itself (100MB+). This is another
reason to only use the "Modules" that we need from it like the Modeling,
Curves and others. There are already hierarchies in blender, all we need
to do is follow that same principle using a child/parent relationship
between the nodes just like in a tree view control. Searching the
hierarchy is very simple, we just start at the top node and enumerate
our way down until we find what we are looking for. I put together a
small diagram showing this concept, you can find it at
I would not spend allot of time trying to get a call tree made, as I
have mentioned before there is allot of stuff still in the code that is
not used anymore or is only used on specific features, the openAL
feature is a good example. Also we are not going to use most of the
code in blender, there are only about 5 or so "Modules' that we are
going to need, these include DNA, RNA, Editors, Graphics and
blendkernel. Aaron and I are working very hard to document these areas.
I don't think that documenting the entire program will gain us anything.
2.5 is a primarily a redo of the code and features, there will be
several changes and additions before the Beta release and it will be a
waste of time documenting these areas now let alone having to update
them when they do change.
I am working on the BlenderCAD code structure and design which also
consists of the Blender C wrapper. This contains diagrams of any areas
of blender that we will be using. Aaron is helping me with the
documentation and has also had a failure trying to use Doxygen to create
a call tree. If anyone needs to "Trace" the code and usages QT Creator
provides this, granted it is not in a neat HTML format but will give you
the information you need. I have already put a simple overall data
diagram on SourceForge and will post more as I get them done. If anyone
wants to help with this endeavor or start on other areas of the design
like the UI please let me know and I can give you some direction.
During the several conversations that I have had it sounds to me like
we want stay with SourceForge, it has all the tools that we need and
most are already setup. If I am mistaken about this please let me know.
SourceForge has a Project Management program and is partially setup. We
need to add more tasks and milestones, everyone has access to this by
going to Hosted Apps-->dotProject. This is a very valuable tool, not
only does it give us a schedule to try and keep but also shows tasks,
who should be working on them and what tasks are dependent on others.
This really gives everyone a very good perspective of the project. We
really need to be aware of what we are working on and stay in constant
communication with each other to avoid duplicating work or working on a
project that is no longer needed.
Registered Linux User: 506696
Registered Ubuntu User: 30563
On 04/11/2010 07:58 PM, James Ravan wrote:
> I was thinking today about file formats for our files. I've begun to
> read the book I bought to learn about SolidWorks, "Commands Guide
> Tutorial for SolidWorks 2010". I've only started (the book must be
> 800-1000 pages), but it's already apparent that the format for a
> SolidWorks file must be hairy indeed. We need a way to describe a
> hierarchy of descriptions:
> features -> parts -> assemblies -> libraries
> This is no mean feat, i.e., it will be hard work, and if the blender
> folks are resistant to us changing their code, they'll certainly be
> resistant to making _major_ changes and additions to the .blend file
> format. So, I was thinking that we should have some discussion about
> what our file format ideas are.
> I'll tell you my approach. This is not a file format problem, it is a
> database problem. There is more than one type of structure to define
> and sets of structures are related to other sets of structures. That's
> not simple, and to me, it screams "use a database, not a flat file".
> I worked in databases for about 15 years, so this kind of thing
> doesn't scare me at all. In fact, it seems like coming back to old
> friends. We could use something like SQLite for the time being, and we
> might decide it scales well enough to support a BlenderCAD single
> user. And if we would like to support network accessible data, it's a
> pretty straightforward application to develop using RPC or RPC-like
> tools (I would look at YAML as a transport format given some previous
> experience with XML - I'm not an XML format fan). And we could easily
> support larger systems, perhaps using PostgreSQL on most platforms and
> SQL Server on Windows, to allow multiuser library access.
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> BlenderCAD-devs mailing list