Standard for the Exchange of Product model data (STEP) is an ISO standard for the computer-interpretable representation and exchange of product manufacturing information which can be used to represent 3D objects in Computer-aided design (CAD) and related information. BRL-CAD makes use of the STEPcode project to implement its step-g importer, which is currently adapted to a specific STEP application protocol (AP).Some examples of commonly encountered application protocol includes AP203(Configuration Controlled Design) which defines the geometry, topology, and configuration management data of solid models for mechanical parts and assemblies, AP214(Automotive Design) which had everything an AP203 file includes, but adds colors, layers, geometric dimensioning and tolerance, and design intent, and AP242(Managed Model-based 3D Engineering) which has everything an AP203 and AP214 file includes, but adds updated kinematics support.The goal of the project is to make it possible for STEPcode to generate a parser, which supports multiple application protocols simultaneously.

STEPcode has the ability to generate c++ classes for the various STEP application protocols which are used for parsing STEP files. Developing a step-g parser that would have the ability to parse various STEP files could be achieved by determining the file schema using the FILE_SCHEMA instance within the file header and then switching to appropriate parser but this would not be efficient as there would be so much repeated code generated and it would also lead to an increase in compile and build time of BRL-CAD thus the need for a unified parser.
The ability to support many protocols within one framework is one of the key strengths of STEP. All the protocols are all built on the same set of Integrated Resources, so they all use the same definitions for the same information. For example, AP203 and AP214 use the same definitions for three dimensional geometry, assembly data and basic product information. Therefore making it possible to enable STEPcode generate a parser, which supports multiple application protocols simultaneously.

The first step in developing an application that works with several application protocols is to construct a merged express schema that covers all of the different entity types that we must work with. This would require a good understanding of the Express data modeling language and the various STEP application protocol schemas to be merged as the merged express schema would be a union of all of the application protocol definitions .

In generating reliable C++ classes which supports multiple APs simultaneously, we would require some familiarization with how STEPcode presently supports a single AP.
STEPcode begins by generating C++ classes for each AP from their respective EXPESS definitions using exp2cxx. When an application is linked to this classes a STEPfile object is created

The STEPfile constructor instantiates a Registry and InstMgr reference which is used to initialize entity registry. Thus generating a dictionary with all entity definition, for validating entities passed to the program by comparing against those found in the dictionary and thus returns a valid instance if its definition is found in the dictionary.
As we move to multiple APs, we must become more aware of this matching process, and may place some of it under application control. These issues could be avoided by using the combined schemas so that classes are only matched once.

If we intend to create fully conforming datasets for several APs, we need more than a common subset of definitions. The conformance classes for each AP will probably mandate a number of AP-specific relationship objects like the cc_design_* entities of AP203 or the applied_* entities of AP214.

For this project we would need AP-specific classes for each AP that we must support. The physical schema (EXPRESS) of our application would be a union of all of the AP definitions. There are two ways to produce the classes.

We could manually merge the AP long form or short form schemas into one, resolve any conflicts, and then generate classes from the merged schema.

An expedient alternative is to generate C++ classes from each individual schema into the same directory. If there are duplicate entity definitions, the latter source files will simply overwrite earlier ones. We must use caution with this technique. The APs should not have many structure conflicts, since the APs are all based on the same integrated resources, but there may be a few.

As seen above we would be using the first options for generating C++ classes for our various application protocols.

Select types in particular, are prone to variability between APs. When an AP is converted from short form to long form, selects are trimmed to eliminate types outside the AP scope. In extreme cases, the select contains just one type. Consequently, if you compare several long form schemas, the same select type definition may vary widely between them. For example, consider some definitions from AP203 and AP214.

An application will have problems if C++ classes are generated from a definition that does not have all of the required types. To avoid this, we would have to generate the classes for these selects from the most inclusive EXPRESS schema available,like the merged schema.

The next part of this project would be to ensure that step-g converter can
reliably make use of the merged classes in carrying out conversion, giving the ability to support multiple APs using a single parser.

This phase of the project would have to do with mainly testing the functionality of the step-g converter against the newly developed parser. Testing would actually have to be carried out after every modification through out the development process in order to catch and fix bugs introduced early. It would also incorporate bug fixing within some existing part of the code, proper code commenting and an update of the STEP manual.

I have no commitment within the Google summer of code period except for my end of semester exams which would run for about two weeks around 24 June– 11 July , but I would make up for the time by putting in more hour before this period guarantying at-least 40 hours a week.

My change in department was because of my passion for coding and mathematics and also due to my low interest/motivation for electronics which was a large part of the engineering curriculum. This has given me the time to focus on the thing I am very passionate about and since this is the first year computer science is being offered as a major for the undergraduate level at my university, participating in the Google summer of code would be an encouragement to others who intend to enroll into this department.
I am primarily a c/c++ programmer with special interest in computer graphics, computer networking, multi-threading and artificial intelligence.

I have always had the interest of contributing to open-source and have made some contributions to BRL-CAD like development of a vrml-g converter. Working on the vrml-g converter has given me some experience on what geometry conversion is all about, thus higher chances of success in completing this project. I would also have the opportunity to gain more experience and learn lots of new things.

I choose STEPcode because having some experience contributing to BRL-CAD on geometry conversion and given that this project encourages cross collaboration between both STEPcode and BRL-CAD it would give me the opportunity to work with a wider range of experienced developers and also improve my knowledge of computer graphics.