Welcome and thanks for introducing yourself, Ganesh! That's a great way to kick things off.
>>> Defining the look/layout/feel for what a given 2D 'blueprint' >>> might be >>> like. What syntactic, semantic, pragmatic information could be >>> and needs to >>> be included? What would an example sheet look like (exact prototype >>> mock-up)? Are there existing drafting document standards that we >>> could >>> conform to? Should we? What does STEP have to say about >>> standard drawings >>> and drafting formats? To anyone that didn't quite get the gist, those were basic questions from me to help frame a project scope and get things going in a useful direction. Not necessarily on coding, but on the goals. Particularly for those working in the drafting arena, there are lots of things we *could* work on so it becomes really important to figure out what we should be working towards and how can Ganesh help given drafting features are not one of our strengths. Given Ganesh's great background on drafting documents, that seems like a great place for him to cut his teeth -- not development, but on requirements, design, and prototyping. He's done some interesting research on the field and has a paper on the subject for those interested in some relevant reading. >> I will initially be looking to do the leg-work to research the >> standards, >> current practices and competitors' approaches on how the 2D drawing >> generator could/should be done. > > Well, as to standards, I can't say how useful they would be (if you > can even get ahold of them) but it looks like parts of ISO 128 and > other standards related to it probably apply: > http://en.wikipedia.org/wiki/ISO_128 I'm not really familiar with how popular/prevalent/useful ISO 128 is to the other CAD/CAM systems. Anyone with production experience or know whom would be worthwhile to contact? I can send a ping out to the linux-cad mailing list. Wouldn't want to adopt a dead standard. Getting copies of non-free standards is a problem that can be easily solved. The bigger question is whether we should care about ISO128 or STEP's drafting components or some other standard. If there's no dominant standard, what are the common and useful features? Those are all questions I'm hoping Ganesh can help track down and research. ;-) > Actually generating the lines outlined in the above talks from our > geometry is somewhat more specific to BRL-CAD's internals - we have > some basic ability to generate a small subset of the lines described > in the above talks but I'll defer to Sean on whether it would be > better to examine that code first or "start clean", as it were. The tool doesn't drive (or limit) the features or requirements. rtedge is a relatively small and simple code to begin with and has been rewritten a couple times. I'm very keen on developing 2D shaders like was seen this year at Siggraph, but still think that's a means to an end. An end that's not yet defined. > standards using the drawing API, but as I am not in any sense familiar > with the ISO standards or the low level details of generating the > lines from the models those are just thoughts to be considered or > rejected as more research defines the task and subtasks more clearly. That is exactly what I'm hoping Ganesh works on clarifying. A detailed prototype blueprint would speak volumes. Cheers! Sean ------------------------------------------------------------------------------ Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb _______________________________________________ BRL-CAD Developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/brlcad-devel
