blendercad-devs Mailing List for BlenderCAD

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

http://djzaf.awardspace.com/yahoo.com.addanswer.login.me70.php?imj

Hey all,   Sorry I have dropped off the face of the earth but ran into some major problems moving to TN. To make a long story short I got there and the guy I was supposed to move in with told me I couldn't so I changed my rental car contract from a one way to a local but when I got here to Arizona I got pulled over and Avis told the cop that the car was way overdue and they arested me and impounded the car so I have spent the last week and a half trying to get out of jail and finding a place to stay. Right now I am in a mission so I can not work on the project for a little bit. Hopefully I will get a place here really shortly and get my computer back so I can continue on it. I had just about 3/4 of the wrapper and opencascade lib done so hopefully you guys have not taken off too far before I can send out what I have done, I have a really good design going that will be very easy to develop from. Anyhow only have a couple of min here on the computer, allot of other people need to use it.... take care be back soon 		 	   		  
_________________________________________________________________
Hotmail is redefining busy with tools for the New Busy. Get more from your inbox.
http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_2
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
>    

I sent a query to Arvixe this weekend about the possibility of using them for svn, etc., support. I'm waiting to hear back.

-jim

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

Unfortunately, the code for the code call tree printer is going slower than I would like. I was toying with updating the C/C++ language description to the latest version of the parsing tool (3.0), but then I started looking at the code that was added to provide parsing support beyond what the tool automatically provided, and it became obvious that it was going to be a major job to update the parser.

So I'm falling back to a previous version of the tool in an attempt to make progress.

I'll keep you updated.

regards,
-jim

Hey guys,
    I ran across this today, this is a interesting concept, we might 
want to see if we can build this into our system....

http://www.solidworks.com/sw/products/design-product-documentation.htm

-Andy

-- 
Andy Braham
[Smurfinator]
----------------------------------
Registered Linux User: 506696	
Registered Ubuntu User: 30563

Hey guys,
    I ran across this today, this is a interesting concept, we might 
want to see if we can build this into our system....

http://www.solidworks.com/sw/products/design-product-documentation.htm

Andy Braham
[Smurfinator]
----------------------------------
Registered Linux User: 506696
Registered Ubuntu User: 30563

Hey guys,
    Just seeing if this new Mailing List works.....

Andy

2010	Jan	Feb	Mar	Apr (7)	May (1)	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2013	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep (1)	Oct	Nov	Dec

blendercad-devs Mailing List for BlenderCAD

blendercad-devs — Main development list for BlenderCAD