- [[Help]] - How to edit pages in PukiWiki. - [[FormatRule]] - Text formatting rules. - ''Site [[Map>http://fenn.dyndns.org/cadwiki/?plugin=map]]'' new project: ''[[qcad_clone]]'' ***So what's this all about? It's a list of ideas about a future [[CAD>http://en.wikipedia.org/wiki/CAD]] project - i need to come up with some snazzy jazzy name for teh googles I dont expect to try to do a top-down design like [[gnu-cad-cam>http://sourceforge.net/projects/gnu-cad-cam/]] and never get anywhere - that's been done too many times already ;) Instead we'll be doing "bottom up programming" using lisp - oh boy! This should be fun. If i can implement half of this i'll be amazed. ***Data structure tags and relational database -hierarchical file systems are a pain to use: you have to decide which category something goes in. rather than force the user to make this decision, there should be multiple possible trees to sort objects by((brl-cad has multiple database trees)) - in other words, multiple tags that can be applied to each object -- tags may or may not be inherited by children in a particular tree (need example cases of when this is or isnt appropriate) --tags may be automatically assigned based on a given constraint or arbitrary expression --- for example "heavy stuff", "expensive stuff", cost/benefit ratio, non-standard stuff (subject to lots of back-propagation) lots-of-little-files idea: see http://www.bruno.postle.net/neatstuff/draft/ - files can be saved directly to disk with each change. rant about "save considered harmful": http://caseyporn.com/blog/archives/000909.html -what about log-structured filesystems for infinite undo? --how long does a commit to a local darcs or svn repo take? ---provide a built-in repository? and when i undo then edit something it starts a new branch in the repository, preserving what i did before undo-ing. when i rename an object or assembly it renames the file and notifies the rcs system - greatly simplifies working with imported files - dont need to import them - complements a "[[procedural]]" or "feature-based" modeling philosophy parallel ideas wrt RCS: revision control system "virtual filesystem" - appears as a normal directory to outside applications, like how the proc/ filesystem works - files are stored as a series of diffs. ideally the application would take advantage of this, and store the actual input of the user - there would be an extra "cache" file format for extra speed. it is the latest reconstruction of the branch, e.g. a bitmap for a painting application, whereas the actual diffs that are stored would be brushstroke data revision control "delete merge" -delete or insert steps into the flow from A to B -difference between undo and "step backwards" is that undo branches off the current tree but step backwards simply inserts your changes into the tree -"commutativity" http://en.wikibooks.org/wiki/Understanding_darcs/Patch_theory -- this needs to be handled intelligently by the application: i.e. if B depends on A, for a parametric dimension for instance, resolve the dependency when you delete A by asking the user what B should now depend on (dont simply delete B! there will be normal "delete hierarchy" commands as well) --even with commutativity, dumb shit can happen. say user A creates file C and D. file C references file D. now at the same time user B creates files C and D, but _his_ file _D_ references his C. now A and B commit their creations. the RCS happily merges the two files, which now contain a circular dependency. yay! ***User Interface/Visualization part manipulation -be able to modify a component in a sub-assembly, for example move that capacitor out of the way of the exhaust pipe (or whatever) --it should take some extra user effort to invoke this "edit-in-assembly-view" mode --one possibly cleaner way to do it would be to visualize locations of related components (related by the user's custom tags) while still in edit mode. this relieves us from having to implement multiple different edit modes (standalone edit and assembly edit) ---cant simply show the locations of all nearby objects because we might be using many many instances of this object ---or can we? it would get ugly quick but it would show all of the relevant constraints on a part's geometry, enabling top-down design (sketch outline first, squeeze sub-assemblies in later) process-based features -bind a geometry feature to a process, for example a cylindrical hole could be bound to a drilling feature, or an up-and-over tab for stencils -the binding should be user configurable and capable of complex and parametric processes, for instance rapid-prototyping techniques - since it may not be possible to go from geometry to process specification without some sort of feature-recognition algorithm (unlikely in a user-generated process specification) we'll have to have process specification tools that "render" to 3d geometry, for instance a thread-turning process will render to a helix with all the thread geometry specifics --but it will also be necessary to go the other direction, as in rapid-prototyping --might even have to go both ways as in the case of a rapid-prototyped part with threads on it for example rendering considerations -ability to draw to various vector formats (dxf, svg) and edge render as hidden line for technical drawings --automatic export of "shop drawings" including process symbols (i.e. drill here, grind here) -i like the way blender's pink outline shows what objects are selected -i like how iges geometry is rendered with the minimal number of lines to give you an idea of the shape --these could be used as control surfaces in some of the more complex objects like nurbs patches visualization -since we have a full 3d toolkit at our disposal, display multi-dimensional surfaces (such as solution-spaces) and parametric constraints (as opposed to run of the mill solid-modeling) with the appropriate number of dimensions and properly labeled with the functions they represent --should we be able to modify parametric constraints by poking at their isosurfaces? --some constraint surfaces can get very complex and abstract with off-the-shelf part databases and cost/benefit ratios, possibly beyond the ability of a mere mortal to understand what ve is looking at somewhere between interface and goal-oriented flow - need to get some ideas on how to design a goal-oriented interface -- how to specify "fuzzy" constraints -- how to weight optimizations with some amount of utility e.g. cost, performance, efficiency, mass, reliability - automatic routing of pipes and wiring harnesses ***Goal-oriented flow "taking the engineer out of engineering" ((actually it makes you more of an engineer - see yudkowsky's "perceptual transcend")) mass and cost profiling -by various user specified categories --structural members, power transmission, electronics, etc --broken down into tree view -running totals available on a "head up display" -by cost of off-the-shelf parts and assemblies --will require excruciating database integration skillz -by material costs of bounding {box, rod, tube, sheet, volume, user-defined} --bounding shape chosen automatically by default --bounding shape chosen from a database of raw stock on hand --how do you decide whether to solve for the raw stock shape individually or to "nest" parts together where appropriate? need to know machining and fabrication capabilities ---the computer can compare the cost of using materials and parts on-hand versus buying new -costs calculated from tables specified in arbitrary monetary units, for example 1970's USSR rubles per ton of steel. costs are then translated into "absolute monetary units" - of course newer statistics will be more accurate than older ones, but we might just take what is easiest to use, since its just an estimate. -- this could be done by building an extension on to the "[[units>http://www.gnu.org/software/units/]]" unit conversion database -by machining time, painting time, electricity consumed, number of assembly steps (total movement necessary to assemble the product) --these might actually be fairly simple to calculate, if not necessarily accurate --would require access to the machining/welding/assembling algorithms - but there's only so much you can know ahead of time --more accurate for in-house production because the user can tweak values to match experimental data automatic, on-the-fly optimization - it's automatic, you dont have to tell the computer to do it --this is in the spirit of [[mechanoid's post on cnczone>http://www.cnczone.com/forums/opensource-software/10901-software.html#post85690]] -- this could be a feature of the lisp interpreter, or it might require careful marshalling of processes so as not to bog down the system (think renice and preventing new forks from spawning) - an optimization procedure can be used as a function in a spreadsheet type environment, for example for picking the best choice from a list of materials that results in the lightest part. an FEA stiffness calculation would be used as the "lambda expression" in this case, and then fed into an iterative solver that chops off bits that are unnecessary - evolution in action! -- for that matter, may want to look into available genetic algorithm libraries - highly parallelizable --can run optimizations on separate nodes --_should_ be paralleled so as not to constantly hog the main CPU with possibly unimportant calculations - back-propagation/feedback of optimization side effects can result in wild oscillations that quickly get out of control -- will have to pay close attention to default min/max values for many unspecified parameters (most of which require intensive calculations - thermal, stress, acoustic properties, fatigue, thermal expansion, galvanic corrosion, etc etc etc) ---will have to decide which calculations are worth doing. this may end up being assisted heavily by a linear solver package. "worth doing" is based on the user-specified or default utility functions of a given parameter