Re: [Blendercad-devs] Thoughts about file formats

[Andy B. <and...@ho...>]

Hey all,
    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 
questions 
http://wiki.blender.org/index.php/Dev:Doc/Blender_Source/DNAStructs.
   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 
http://downloads.sourceforge.net/project/blendercad/Documentation/Application%20Design/BlenderCAD-DataStructure.odg?use_mirror=master. 
<http://downloads.sourceforge.net/project/blendercad/Documentation/Application%20Design/BlenderCAD-DataStructure.odg?use_mirror=master>
   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.

Andy Braham
[Smurfinator]
----------------------------------
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.
> thoughts?
> -jim
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; 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.
> http://p.sf.net/sfu/intel-sw-dev
>
>
> _______________________________________________
> BlenderCAD-devs mailing list
> Ble...@li...
> https://lists.sourceforge.net/lists/listinfo/blendercad-devs
>