Issue 4414: CAD FTF issue regarding UML which looks kind of like CORBA profile
Issue 4415: IDL extracts in document are inconsistent about showing module declarations
Issue 4433: Need to add a "ColorStruct color;" to the PresentationStruct
Issue 4485: Surface.nurbs_approximation should be renamed nurbs_representation
Issue 4486: Surface.nurbs_approximation should 'tolerance' argument declared as inout
Issue 4487: Edge.nurbs_representation should h. 'tolerance' argument declared as inout
Issue 4488: CAD Services needs to clarify 'exact' for nurbs_representation functions
Issue 4489: Binding for Face.nurbs_representation needs major design overhaul/removal
Issue 4490: CAD Services IDL issue
Issue 4491: CAD Services IDL issue (02)
Issue 4492: CadBrep Edge.nearest_points function incorrect
Issue 4493: CadBrep Edge.nearest_points function needs clarification
Issue 4528: Should there be a get_parameter_set function at the Model interface level?
Issue 4537: TessellationStruct normals field should be VectorStructSeq
Issue 4538: What are units for 'angle' field in TessParametersStruct
Issue 4541: Model level parameters for geometry creation issue
Issue 4542: BodyTessellationStruct issue
Issue 4543: Body.property_info, several values are calculated. What is the return accur
Issue 4544: Support for STEP input / output?
Issue 4547: Sections 1.8, 2.8, 3.1, 3.2, Editorial
Issue 4548: Section 3.4, Editorial
Issue 4551: adding an attribute to the entity group
Issue 4558: we have to generalize is_manifold() methods in all BRep entities
Issue 4559: method of CadMain::EdgeLoop has to be renamed
Issue 4560: how to add new topological entities to existing model with sharing of exist
Issue 4561: Method names in topological entities are not everywhere unified
Issue 4562: Replace #include "CadFeature.idl with #include "CadFoundation.idl"
Issue 4563: I haven't found any way to create ModelInstance
Issue 4564: CadSystem Properties issue
Issue 4566: Surface.intersect_ray argument error
Issue 4570: CadFoundation::Entity interface
Issue 4571: There is no way to delete any CadFoundation::Entity interface child.
Issue 4572: Entity.Position() returns PointStructure instead of TransformationStructure
Issue 4573: Deletion of CadFourndation::Entity descendants
Issue 4595: interface for STEP open shel
Issue 4627: Entity Factory issue (Function)
Issue 4628: Entity Factory issue (Function 2)
Issue 4629: Entity Factory issue (Function 3)
Issue 4630: Entity Factory issue (Function 4)
Issue 4631: Entity Factory issue (Function 5)
Issue 4632: problems in the EntityCreation interface.
Issue 4653: Several properties in the CadBrep::PropertyStruct need clarification.
Issue 4985: Incompletely specified operations - issue
Issue 5729: Add some operations to CadFoundation module's interfaces
Issue 5747: Model Instances vs. Top-Level Entities
Issue 5748: EntityFactory and ModelInstanceFactory
Issue 5749: Euclidean Dimension
Issue 5750: Tessellation Types
Issue 5751: Curve Parameters
Issue 5752: "Entity-Types"
Issue 5753: "Cadsystem" interface issue
Issue 5774: interface Model : CadFoundation:: Attributable replaced
Issue 5775: remove CadGeometryExtens interface
Issue 5776: Set color on Layer interface
Issue 5777: Operation to identify opened Models
Issue 5841: Add operations to CadMain::Model
Issue 5842: bounding_box" behavior
Issue 5844: altering the use of EntitySeqs to LongSeqs
Issue 5845: Suggest altering the input parameter CadFeature::ParameterSeq model_params
Issue 5846: CadGeometry::Curve::tessellate()
Issue 5848: CadFoundation.idl: In the CadFoundation::EntityPropsStruct
Issue 5849: struct PolyLineStruct is defined but not used anywhere
Issue 5935: interface Parameter
Issue 6693: CadMain::ModelInstance::component()' collides
Issue 7140: CadConnection, CadSystem: Avaliable_models() enhancement
Issue 4414: CAD FTF issue regarding UML which looks kind of like CORBA profile (cad-ftf)
Click here for this issue's archive.
Source: DSTC (Mr. Keith Duddy, dud(at)dstc.edu.au)
Nature: Uncategorized Issue
Severity:
Summary:
UML looks like Corba profile, but is not quite. In particular the
<<Interface>> stereotype should be <<CORBAInterface>>. There may also
be some "in" tags in the wrong place.
* IDL extracts in the document are inconsistent about showing module
declarations.
I was building a Java3d display for CadServices data and I realized that > we do not return the object color in the PresentationStruct. We return > the color of the highlight (specular_color), and various parameter about > reflectance - but we do not include the base color of the object. > > I think we need to add a "ColorStruct color;" to the PresentationStruct.
This was an oversight. A data member was added to PresentationStruct and appropriate documentation changes were made
Surface.nurbs_approximation should be renamed nurbs_representation to be consistent w/ Curve.nurbs_representation.
Surface.nurbs_approximation should have 'tolerance' argument declared as 'inout' instead of 'in'. CAD Services specification indicates that 'If nurbs representation is exact, tolerance will be returned as a negative'. By the way, the 'NURBS' acronym should be capitalized in the spec and IDL when used in this context.
This correction resulted in a minor modification of the IDL and supporting documentation
Edge.nurbs_representation should h. 'tolerance' argument declared as 'inout' instead of 'in'. CAD Services specification indicates that 'If the representation is exact - tolerance will be returned as a negative value.
CAD Services specification needs to clarify 'exact' for nurbs_representation functions. nurbs_representation indicates that if the NURBS is exact, then tolerance is returned as negative value. Is that exact geometrically or exact geometrically AND parametrically?
Agreed. To clarify the representation, the document was changed to require that the negative tolerance value indicate: geometrically exact = -1 or parametrically exact = -2.
Binding for Face.nurbs_representation needs major design overhaul or removal. IDL indicates the function returns a CadUtility.NurbsSurfaceStruct. A simple NURBS surface structure cannot represent arbitrary faces w/ irregular boundaries, both outer and inner.
A NURBS representation of a Face might require a complex NURBS data structure. To resolve the issue, it was agreed to remove this operation, thereby, requiring an access of the Surface interface that can be used to return a NURBS representation.
CadBrep Oriented Edge IDL defines an 'end_vertex()' function, but not a 'start_vertex()' function.
CadBrep Edge IDL defines a 'start_vertex()' function, but not an 'end_vertex()' function.
CadBrep Edge.nearest_points function incorrectly defines the 'nearest_points' argument as 'in'. CAD Services spec documents Edge.nearest as 'Determines the minimum distance, and corresponding closest points, between this Edge and the input Edge. The returned value is the minimum distance'. The 'nearest_points' argument should be declared as 'out'.
CadBrep Edge.nearest_points function needs clarification for 'nearest_points' argument. How are the nearest_points defined? It is declared as a PointStructSeq, but no further details are provided. Will there always be 2? Is the first point of the sequence a point on the given edge and the second point a point on the edge corresponding to the input argument? What is the expected behavior if there are multiple locations that the 2 edges have an identical minimum distance?
No use case was identified for this functionality. The agreed consensus was to remove the operation. This eliminated the ambiguity.
Should there be a get_parameter_set function at the Model interface level?
This is a useful extension of the Model interface. An appropriate operation was added to the interface.
The type of the 'normals' field in TessellationStruct should be VectorStructSeq instead of PointStructSeq.
adGeometry IDL comment documents the 'angle' field in CadGeometry.TessParametersStruct as "deviation between normals of facets". Neither the IDL nor the CAD Services spec. indicate what angular units should be used.
Model level parameters for geometry creation. Should the model creation operation support new parameters?
Should Shell.tessellation return a similar structure to Body.tessellation? Currently shell tessellation returns a FaceTessellationStructSeq while body tessellation returns a BodyTessellationStruct. Shell tessellation results are the only tessellation results that do not have an object reference to underlying topology. Rename BodyTessellationStruct to something like ConnectedFaceTessellationStruct?
Agreed. BodyTessellationStruct was renamed to ConnectedFaceTessellationStruct, so as to make an extremely long name even longer
Body.property_info, several values are calculated. What is the return accuracy? Should a separate accuracy for each separate property be returned? Should accuracy be returned at all?
This issue was extensively reviewed by the Manufacturing Domain Task Force. The difficulty is that some CAD Systems allow input accuracy requests and return "indicators" of actual achieved accuracy. These approaches vary widely and the current specification requires vendors to clearly identify their implementation for this request. The consensus resolution was to make the interpretation of the accuracy parameter implementation defined. This will allow "accuracy" requests to be implemented in a manner best suited for each CAD System.
Support for STEP input / output?
This requirement was deferred to the Manufacturing Domain Task Force Roadmap for possible inclusion in the next RFP.
Sections 1.8, 2.8, 3.1, 3.2, Editorial: Compliance points / levels and optional interfaces are spread around the document in a way that would hamper formal claims of conformance.
It was agreed to reorganize the Compliance points as follows: Identifier Description Base All interfaces in all modules except CadGeometryExtens. GeometryExtensions Base, plus all interfaces in CadGeometryExtens. PersistentIdentifiers Base, plus support for persistent identifiers as described in Section 2.2.2.2, Model Operations, and Section 2.3.2.2, Entity Operations. UserInterface Base, plus support for a user interface as described in Section 2.1.3.1, CadSystem Operations. Parametrics Base, plus support for parametric regeneration of CAD entities as described in Section 2.6.2, DesignFeature Interface. If the UserInterface compliance point is not supported, the CadUserInterface interface becomes inaccessible (PdmSystem::get_gui throws GuiUnsupported) and its implementation becomes moot. Similarly, if the Parametrics compliance point is not supported, the Parameter interface becomes inaccessible (DesignFeature::get_parameter_set returns an empty sequence). Otherwise, all interfaces called out by Base are mandatory. Support for persistent identifiers, a user interface, or parametric regeneration of CAD entities are indicated by declaring support for the respective compliance points. Additionally, implementations may vary in their support for accuracy, presentation properties, and session-level identification of CAD entities. However, these variations are exposed through specified behaviors of the mandatory interfaces.
Section 3.4, Editorial: Although the description of interaction with PDM Enablers is fairly clear, a sequence diagram (or several, for the several cases) would increase the likelihood of interoperability.
Our entity groups in Cad Services don't have any form of an identifier or name that can be retrieved through the interface. The only returned data is either a list of entities in the group or the count. It makes it difficult to present this information to a user. We might consider adding an attribute to the entity group, however that means it gets inherited to the layer. readonly attribute string native_label;
1. Perhaps we have to generalize is_manifold() methods in all BRep entities. I propose to have is_manifold() only in BrepEntity interface, but not in each interface. The only restriction is vertex, which can return anytime TRUE.
It was agreed to move the is_manfold() operation up one level of the object hierarchy to the BrepEntity interface
OrientedEdgeLoopSeq edge_loop() raises (CadUtility::CadError); method of CadMain::EdgeLoop has to be renamed to
OrientedEdgeLoopSeq oriented_edge_loop() raises (CadUtility::CadError);
for unification.3. It is not clearly described in the specification document, how to add new topological entities to existing model with sharing of existing entities. Let's say we have 2 vertexes already created and we would like to add an edge. While implementing EntityFactory interface, a developer have to care about this sharing. Otherwise vertexes won't be shared. And from my point of view we have to speak about that in the document.
Vendors may implement the CadMain::EntityFactory to allow Unique IDs (available from the CadFoundation::Entity interface) to be input in place of the index values returned from the creation operations in the CadMain::EntityFactory interface.
5. Method names in topological entities are not everywhere unified. To return a single entity we use normally prefix get_entity. To return a sequence we use no prefix normally: for example Shell get_shell () raises (CadUtility::CadError); OrientedFaceSeq oriented_faces () raises (CadUtility::CadError); Not all method names in CadBrep module satisfy this rule.
6. #include list of CadGeometry module contain: #include "CadFeature.idl" that has to be replaced by #include "CadFoundation.idl". CAD Geometry never use features explicitly.
7. Creation of ModelInstances. I haven't found any way to create ModelInstance. And it's not explained in the specification.
A ModelInstanceFactory interface was added to the CadMain module. This interface enables the creation of ModelInstances:
interface ModelInstanceFactory
{
CadMain::ModelInstance new_model_instance (
in CadUtility::TransformationStruct global_location)
raises (CadUtility::CadError);
// Creates a new ModelInstance with initial transformation
// according the global coordinate system
};
An operation was added to the Model interface to support access to this interface:
ModelInstanceFactory new_model_instance_factory ()
raises (CadUtility::CadError);
//Creates the ModelInstanceFactory, which is used to
// add ModelInstances
In the CadServer interface we have the ability to inquire launch properties for the CadSystem, and then pass in a set of properties when we call connect() or connect_with_password(). Once the CadSystem is running we do not have a way to query or change the properties. As an example - UG has a property for the search path for files. You can set this property when you initially start up the CadSystem. If it needs to be changed during a session the only choice is to shut down the CadSystem with disconnect() then call connect() again. Also, if you connect to an already running CadSystem you cannot determine what properties were used during the original connect(). I think I would propose adding something like "get_properties" and "set_properties" for the CadSystem interface. These calls would basically allow a query and update of the properties provided to the CadServer via the connect() calls. CosPropertyService::Properties get_properties(); void set_properties( in CosPropertyService::Properties props );
The 'intersection_parameters' argument in Surface.intersect_ray() must be type 'CadUtility::UvStructSeq' instead of 'CadUtility::DoubleSeq'.
There is no "3D Location" function in Entity interface. There is only Entity.Position(), which returns PointStructure, but it is not enough to describe a 3D transformation. It's necessary to return TransofmrationStruct from such a function. It's necessary also to mention, that Entity interface has a method for transformation. However, if Position() has another goal, than 3D location of Entity, it shall be described in the document.
The position functionality was not clearly defined in the IDL or the document. It was agreed to relabel the position operation to reference_position and provide an additional operation global_location that provides a TransformationStruct with global coordinate information
There is no way to delete any CadFoundation::Entity interface child. We shall add the possibility to delete: Model ModelInstance BrepEntity Curve Surface
Two operations were added to the CadMain::Model interface that enable deletion using either a unique entity identifier or the object reference to a valid CadFoundation::Entity. Deletion of a high-level entity deletes all dependant, lower-level entities.
The IDL is modified to include the following operations in the Model interface:
void delete_uid_entity(in long uid) raises (EntityOutOfModel,
CadFoundation::UidUnsupported, CadUtility::CadError);
// Removes ModelInstance, BrepEntity, or Curve from the model
void delete_entity(in CadFoundation::Entity entity)
raises (EntityOutOfModel, CadUtility::CadError);
// Removes ModelInstance, BrepEntity, or Curve from the model
Replace
CadUtility::PointStruct position () raises (CadUtility::CadError);
// Returns a struct of the coordinates of a single, reference location on
// the entity that should be unique relative to neighboring entities.
method by
CadUtility::TransformationStruct location () raises (CadUtility::CadError);
// Returns a struct of the applied transformation, which represents
// the location (position, turn, scale) of the entity according the global coordinates
In that case, we will be able to refer the entity according any other entities.
This method doesn't return the "last applied transformation", but "the superposition
of all applied transformations". In that case, location of the entity in 3D space will be returned.Possible resolution:
Add methods:
interface CadSystem
{
void delete_model(in string modelname)
raises (InvalidModel, PermissionDenied, CadUtility::CadError);
// Removes model from CadSystem
void delete_model(in CadMain::Model model)
raises (InvalidModel, PermissionDenied, CadUtility::CadError);
// Removes model from CadSystem
}
interface Model
{
exception EntityOutOfModel;
void delete_entity(in long uid)
raises (EntityOutOfModel, NotIndependent, UidUnsupported, PermissionDenied, CadUtility::CadError);
// Removes ModelInstance, BrepEntity, Curve or Surface from the model
void delete_entity(in CadFoundation::Entity entity)
raises (EntityOutOfModel, NotIndependent, PermissionDenied, CadUtility::CadError);
// Removes ModelInstance, BrepEntity, Curve or Surface from the model
}
Suggest interface for STEP open shell, ie a collection of faces that do not enclose a volume.
Function
CadUtility::LongSeq index_faces(in CadUtility::LongSeq oriented_eloops,
in CadUtility::LongSeq eloops, in CadUtility::LongSeq edges,
in CadUtility::LongSeq vertex_loops, in CadUtility::LongSeq surfaces)
Could you describe, please, the reason of presence of "eloops" and "edges" in the parameters?2. Function
CadUtility::LongSeq index_edge_loops(in CadUtility::LongSeq oriented_edges)
Edge loop is described by list of edges, because of this, the "in" parameter oriented_edges should be CadUtility::LongSeqSeq.3. Function
CadUtility::LongSeq index_shells (in CadUtility::LongSeq oriented_faces)
raises (IncorrectIndex, CadUtility::CadError);
The same situation. "In" parameter orieneted_faces should be CadUtility::LongSeqSeq, because shell is a set of faces.4. Function
CadUtility::LongSeq index_oriented_xxxxxxxx
For functions which create oriented entities, boolean flags "sense" should be present in parameters, i.e. like BooleanSeq senses.
5. Function
CadUtility::LongSeq index_oriented_faces(in CadUtility::LongSeq faces,
in CadUtility::LongSeq vertices,
in CadUtility::LongSeq vloops)
Maybe instead of this, the description should be something like this:
index_oriented_faces(in CadUtility::LongSeq faces,
in CadUtility::BooleanSeq senses)?
For what reason should you put the vertices and vloops in parameters?Here is a quick itemization of necessary changes (most from Sergey and
a few additional). Following the list is a modified section of the IDL
that can be used to replace the corresponding lines in the existing
CadMain.idl file. *** NOTE: Also need to add 'typedef sequence<LongSeq> LongSeqSeq;'
to CadUtility.idl.
index_faces:
Needs 'SeqSeq' of oriented_eloops instead of 'Seq'
For consistency, arg should probably be 'oriented_edge_loops' instead of 'oriented_eloops'
Does not need eloops, edges.
index_edge_loops:
Needs 'SeqSeq' oriented_edges instead of 'Seq'
index_shells:
Needs 'SeqSeq' oriented_faces instead of 'Seq'
index_bodies:
Needs 'SeqSeq' oriented_shells instead of 'Seq'
index_vertex_loops:
Ok (just included in IDL below for easier replacement of old IDL section)
index_oriented_edges
Need 'BooleanSeq senses'
index_oriented_faces
Need 'BooleanSeq senses'
No vertices or vLoops needed
index_oriented_edge_loops
For consistency, should probably be 'index_oriented_edge_loops' not 'index_oriented_edgeloops'
Need 'Seq edge_loops' not 'Seq edges'
Need 'BooleanSeq senses'
index_oriented_shells:
Need 'Seq shells' not 'Seq ofaces'
Need 'BooleanSeq senses'
No vloops needed
CadUtility::LongSeq index_faces(in CadUtility::LongSeqSeq oriented_edge_loops,
in CadUtility::LongSeq vertex_loops, in CadUtility::LongSeq surfaces)
raises (IncorrectIndex, CadUtility::CadError);
CadUtility::LongSeq index_edge_loops(in CadUtility::LongSeqSeq oriented_edges)
raises (IncorrectIndex, CadUtility::CadError);
CadUtility::LongSeq index_shells (in CadUtility::LongSeqSeq oriented_faces)
raises (IncorrectIndex, CadUtility::CadError);
CadUtility::LongSeq index_bodies (in CadUtility::LongSeqSeq oriented_shells)
raises (IncorrectIndex, CadUtility::CadError);
CadUtility::LongSeq index_vertex_loops (in CadUtility::LongSeq vertices)
raises (IncorrectIndex, CadUtility::CadError);
CadUtility::LongSeq index_oriented_edges(in CadUtility::LongSeq edges,
in CadUtility::BooleanSeq senses)
raises (IncorrectIndex, CadUtility::CadError);
CadUtility::LongSeq index_oriented_faces(in CadUtility::LongSeq faces,
in CadUtility::BooleanSeq senses)
raises (IncorrectIndex, CadUtility::CadError);
CadUtility::LongSeq index_oriented_edge_loops(in CadUtility::LongSeq edge_loops,
in CadUtility::BooleanSeq senses)
raises (IncorrectIndex, CadUtility::CadError);
CadUtility::LongSeq index_oriented_shells(in CadUtility::LongSeq shells,
in CadUtility::BooleanSeq senses)
raises (IncorrectIndex, CadUtility::CadError);
Input parameters replaced or renamed as suggested with the exception of: 1. Parameter oriented_eloops on index_faces has not been renamed 2. Parameter BooleanSeq senses has been added to index_oriented_edges() and index_oriented_faces() as sense. 3. Param 1 to index_oriented_shells has not been renamed 'shells'. It remains as ofaces. 4. '_' has not been added to the name or param 1 of index_oriented_edgeloops
double inertial_moment_spherical; double gyration_radius_spherical; CadUtility::VectorStruct first_moments_centroidal; CadUtility::VectorStruct inertial_moments_centroidal; CadUtility::VectorStruct inertial_products_centroidal; CadUtility::VectorStruct principle_moments_centroidal; CadUtility::VectorStruct gyration_radii_centroidal; are unclear. Jim Stevens identified the following: The "centroidal" moments are the various mass properties with respect to the center of mass for the body. This is the more "typical" case for mass properties. They correspond to similar mass property calculations in the structure that are with respect to a specific coordinate system. Principle moments are moments inertia along the principle axes through the center of gravity of an object. When defining a moment of inertia around an arbitrary axis thru the center of mass you end up with product terms. There is one axis definition for which the product terms are zero, which is called the principle axis and the moments of inertia when using that axis definition are the principle moments. Radius of gyration is related to the moments of inertia and the mass along each axis. I am not sure about the meaning of first moments. I am pretty sure that inertial_moment_spherical and gyration_radius_spherical have to do with representing the model with a single sphere that would have the same overall inertial characteristics as the analyzed body. Jim Stephens Based on Jim's comments I am not certain that we need the first moments or the spherical inertial moment and gyration radius.
The identified data members need additional documentation and some rarely-used items were removed
Mikhail Kazakov mentioned that some of the Cad Services interfaces may be under-specified. Here is a list of operations needing additional documentation: 1. CadMain:: open_model( …) - the question involves whether this operation loads the specified model into memory or are all the available models in memory and the open_model() operation merely returns an object reference to the model. Recommendation: the documentation should include the following: The open_model() operation loads the specified model into memory and can be unloaded by invoking close_model() on the Model object reference. 2. CadMain:: top_level_entities (in CadUtility::TypeCodeSeq entity_types) - what happens when an empty TypeCodeSeq is passed? One could respond with all top level entities or none. Recommendation: Documentation shall state that an empty TypeCodesSeq will result in a system exception (BAD_PARAM). 3. unsigned long unique_entities_count (in CadUtility::TypeCodeSeq entity_types) raises (NotValidCadType, CadUtility::CadError); - what happens when an empty TypeCodeSeq is passed? One could respond with all entites or none. Recommendation: Documentation shall state that an empty TypeCodesSeq will result in a system exception (BAD_PARAM). 4. CadFoundation::EntitySeq unique_entities (in CadUtility::TypeCodeSeq entity_types) raises (NotValidCadType, CadUtility::CadError); -- what happens when an empty TypeCodeSeq is passed? One could respond with all entites or none. Recommendation: Documentation shall state that an empty TypeCodesSeq will result in a system exception (BAD_PARAM).
It's necessary to add some operations to CadFoundation module's interfaces: CadFoundation::Entity::SetColor(CadUtility::ColorStruct color) raises (CadUtility::CadError); CadFoundation::Layer::SetColor(CadUtility::ColorStruct color) raises (CadUtility::CadError);
The distinction between model instances and top-level entities was unclear to me, especially so given my task of trying to write a general purpose tool to "import" arbitrary CAD models into CFD-GEOM via the CAD Services interface. A Model can contain zero or more ModelInstances, and this provides support for assemblies. At the same time, certain entities in a Model are designated as top-level entities, which also brings to mind the concept of a composition or assembly.
I was already familiar with the Factory design pattern and so the purpose of the EntityFactory and ModelInstanceFactory interfaces was immediately obvious to me. I'm not sure how familiar other users of the CAD Services will be with this pattern, depending on their software development background.
The Entity::euclidean_dimension() operation is described as returning the "Euclidean dimension of the entity" (with type long). What is this referring to? My guess is that it returns 2 for two-dimensional entities or 3 for three-dimensional entities, but this is unclear
For example, consider the requirements for calling Body::tessellate():
ConnectedFaceTessellationStruct
tessellate(in TessType t_type,
inout TessParametersStruct params,
out boolean flag);
The first argument (the tessellation type) can be one of two enumerated values, WIREFRAME or VISUALIZATION. Nowhere in the specification is any hint given as to the difference between these two settings. One might guess that the VISUALIZATION tessellation type produces a larger number of triangles, but to what degree? Is it implementation-dependent?
Resolution: The documentation needs to be more explicit on the differences between the two tessellation types.
The Edge::start_parameter() and Edge::end_parameter() operations return the "curve parameter corresponding to the start (end) vertex". I suppose this is referring to the parametric distance along the underlying curve, but it's unclear because of the sort-of generic use of the word "parameter".
Resolution: Both questions refer to the projection of a curve into parameter space from the standard Cartesian representation. The documentation needs additional text to describe these representations.
In some methods (mainly Model-Interface) "Entity-Types" are demanded as an
selection mechanism to select appropriate entities. Example:
CadFoundation::EntitySeq top_level_entities (
in CadUtility::TypeCodeSeq entity_types)
But the CAD-Services provide no opportunity to implement a method that
allows to ask for these entity types that are supported by the respective
CAD-System. But in our mind it is up to the CAD-System and thus to the
CAD-Services to provide such informationOne of the design goals for CAD Services is to present a uniform model of the geometric entities without regard to the underlying native CAD System. The entities that are used in CAD Services are clearly documented in the IDL or UML diagrams. It is expected that some native CAD systems may require geometric entities that are specifically created by the CAD Services implementation to conform to this model. These entities would be created from the underlying native representations.
The interface "Cadsystem" provides access on a "CadUserInterface" by the method boolean is_interactive(out CadUserInterface gui); Normally loading a model in the CAD engine and showing it with the editor are two different tasks. "create_model" and "open_model" obvioulsy are related to CAD-Engine activity. GUI activities like showing, hiding etc. are not mandatory implicated. If methods like "create_model" and "open_model" are intended not to include GUI operation then functionality to control the "CadUserInterface" is missing. Therefore the following function would be very helpful (They assume that a model is already loaded by the CAD engine): createWindow(model) // Creates a window and put it in the foreground hideWindow(model) // hides an existing window but doesn't delete it foregroundWindow(model) // put an existing (even if hided) window in the foreground deleteWindow(model) // delete the window and the corresponding window data structure but NOT the model within the CAD engine Every model should throw a "ModelNotLoadedException" if the model is not loaded. Summing up this should allow for a separated control of activities within the CAD-engine and the editor.
Resolution: Adding functionality to the optional GUI interface seems a reasonable request. The ModelNotLoaded exception is not needed since a presumably valid Model reference is required by the operation. Other exceptions can be resolved using the CadUtility::CadError exception
interface Model : CadFoundation:: Attributable was replaced by interface Model : CadFoundation:: Entity This is an issue I've posted many times ago. This really simplify the life with implementation and classification of entities.
I propose to remove CadGeometryExtens interface:
module CadGeometryExtens{
interface Point : CadFoundation :: Entity{
CadUtility::PointStruct coords() raises (CadUtility::CadError);
};
struct PointOnSurfaceStruct{
CadGeometry::Surface basis_surface;
CadUtility::UvStruct the_point;
};
interface PointOnSurface : Point{
PointOnSurfaceStruct pos_info() raises (CadUtility::CadError);
};
struct PointOnCurveStruct{
CadGeometry::Curve basis;
double crv_param;
};
interface PointOnCurve : Point {
PointOnCurveStruct poc_info() raises (CadUtility::CadError);
};
It seems to be quite unuseful
Resolution: These point interfaces somewhat duplication the vertices and point structs (CadUtility module) available in the standard.
The Layer interface needs a set_color() operation
Resolution:
The following operation is added to the Layer interface:
void set_color( in CadUtility::ColorStruct new_color);
// change the color of all entities in this layer
The existing interfaces on the CadSystem interface do not indicate CadMain::Model references that may be opened and available for immediate use
Resolution: As a convenience to the implementers, an opened_models() operation is added to the CadSystem interface. The UML diagram in Section 2.1.1 is updated to indicate the new operation. In addition, Section 2.1.3.1 is modified to include documentation of the operation: opened_models Returns a sequence of Models (CadMain::ModelSeq) that are active and are ready for client use. This is distinctly different from the available_models operation, where a string must be used to open the Model or load it into memory.
void add_child(in Model child_model) raises (CadUtility::CadError); void remove_child(in Model child_model) raises (CadUtility::CadError); It is suggested that Model be changed to ModelInstance to allow for assemblies
Agreed. The in Model parameters should be changed to ModelInstances
An empty TypeCodeSeq in Model::bounding_box() and Model::top_level_entities() will be handled differently according to the comments in the IDL-files. In bounding_box it means all entities and in top_level_entities it should generate a BadParam exception. Would it not be better, to give it in both methods a similar meaning? Recommend "bounding_box" behavior.
Agreed. The documentation should be changed for the Model::top_level_entites() operation.
I suggest altering the use of EntitySeqs to LongSeqs - essentially to use Unique IDs as identifiers. [In places like: Model::delete_entity(), EntityGroup::add_entities(), EntityGroup::remove_entities()] I see there 2 main problems: 1. I don't see that it is really neccesssary to use the (in this case Entity objects) CORBA objects to identify an object. unique_id's could always be used. -> Less traffic and a lot easier to map. Besides: how much sense does the UidUnsupported exception make? unique ids can always be created. 2. The required mapping especially on the server side is somewhat tricky and not the fastest. You would have to map the CORBA objects to the implementation objects. Nasty thing to do.
Suggest altering the input parameter CadFeature::ParameterSeq model_params on CadConnection::CadSystem to a CosPropertyService::Properties
Agreed. The documentation and idl should be changed to use CosPropertyService::Properties.
is there any reason, why the double parameter (tolerance) of CadGeometry::Curve::tessellate() is declared as an in parameter and not inout? In other places like CadGeometry::Surface::nurbs_representation() the tolerance parameter is declared inout.
CadFoundation.idl: In the CadFoundation::EntityPropsStruct the variable global_position is never mentioned in the pdf file. Besides: The corresponding method to global_position in CadFoundation::Entity is named global_location. Shouldn't that be either both position or both location?
struct PolyLineStruct is defined but not used anywhere. Either the according interface PolyLine is missing or the struct is obsolete
The interface Parameter provides four functions · string get_expression() raises (CadUtility::CadError); · void set_expression(in string e_value) raises (CadUtility::CadError); // operations to allow an expression that may drive geometry · CadUtility::EntityAttrib get_value() raises (CadUtility::CadError); · void set_value (in CadUtility::EntityAttrib value) raises (CadUtility::CadError); // operations providing access to parameter value Actually “Parameter” is an easy interface. But since we have seen different implementation approaches and since it was not clear for us in every case too what should be handed over to the set-methods and what could be retrieved by the get-methods I write down our assumptions and hope that it will be corrected if that was not the approach you have had in mind: A parameter covers expressions like “a=6” or “a=b+c”, where “a” is the “name” of the expression. getValue() therefore will return the recursive computed value in the case of “b+c” or an error when there is a problem with the computation. In case of “6” getValue() will just return the value “6”. setValue() allows to set a value if the value of “is_read_only” has the value “false”. The type of the handed over value must match the type of CadUtility::EntityAttrib stored by parameter. In the case of “a=6” “is_independent” keeps the value true. In the case “a=b+c” “is_independent” turns to the value “false”. It is a question whether handing over a value like “8” should be allowed at all when the parameter carries an non numeric expression. getExpression() is similar to getValue() with the difference that the return type is a string. setExpression() allows to set expressions like “d+e” or “8”. The values of “is_independent” and “is_read_only” have to be set accordingly. Expression like “a=d+e” and “a=8” should be possible but internally the expression is parsed and “a=” is ignored. Expression like “b=d+k” should be forbidden because they provide a back door to define completely new parameter when name is set to “b”. If this also has been intended this should be made clear. But I guess this would require extra methods that allow to define parameter. Summing up it is actually no problem to omit the value-methods The “expression”-methods can take over the task to handle values because these also can be represented by expressions like “8”.
'CadMain::ModelInstance::component()' collides with the new 'component' keyword for IDL from CCM. I suggest ro rename it to 'CadMain::ModelInstance::component_model()'.
Disposition: ?
OMG Issue No: ?
Title: CadConnection, CadSystem: Avaliable_models() enhancement
Source:
Markus Helmke, Produktionstechnisches Zentrum (PTZ)
Technische Universität Berlin
Email: markus.helmke@ipk.fhg.de
Summary:
The method "available_models()" provides access to models available to the active CAD System and returns all available models in a list. Up to now the method does not take into account how the models are structured on the server side. When a user selects a model it would be helpful to navigate through the tree structure of the servers file system. A similar problem is the specification of a users file name in that moment when he wants to use "save_model_as()" or "create_model()".
The proposed methods, data structures and definitions aim to improve navigation capabilities for both systems and users when accessing models. For various reasons a native CAD-system normally is able to access different directories which are presented also to the user. This is to let him structure his work but also in order to offer templates that ease the design process, because in most cases designer aren't starting from scratch, but they are provided with templates that cover predefined parameters or a special design philosophy.
Assuming a user wants to store, create, or open a model on the (maybe remote) machine running the Cad-Services he expects something like a "FileChooser"-dialog. The method "available_models()" was not designed to support such functionality and therefore needs to be extended.
The proposed methods allow for implementing the intended functionality because they represent an essential subset of methods needed to do the following:
- Navigation (get_root_directories(), get_models_and_folders(), get_parent_directory())
- Create new subfolder (create_new_folder())
- Providing information to choose a file or folder on the client side (get_models_and_folders())
The concept provides the possibility not to expose the whole file system to the user by using "root_directories". Every directory can serve as root directory and thus only its subdirectories are exposed to the user. The user starts navigation in the one of the roots.
The methods were taken from JAVA's abstract class "javax.swing.filechooser.FileSystemView" which serves as "JFileChooser's gateway to the file system" and as such promise to be sufficient. Additionally IWF has implemented against the proposed CAD-Services enhancement with success.
Resolution:
?
Revised Text:
The following typedefs, struct and operations are added to the CadConnection module respectively to the CadSystem interface:
module CadConnection
{
struct Path
{
boolean is_dir; // Indicates whether Path represents a file or a directory
string path; // Canonical, absolute, and unique path representing a file or
// a directory
};
typedef sequence<string> RootsList;
typedef sequence<Path> PathList;
interface CadSystem
{
// Creates a new folder in a given directory.
// param parent_dir: The (canonical, absolute, and unique) path of the
// directory, in which the folder will be created. This must be either
// one of the root directories (see get_root_directories()) or a
// directory that exists in one of the root directory's subdirectories
// param folder_name: The name of the folder to be created. It must be a
// valid and a not already existing name.
// raises CadUtility::CadError: If there was an error in creating the
// folder.
void create_new_folder(in string parent_dir, in string folder_name)
raises (CadUtility::CadError);
// Returns a list of (canonical, absolute, and unique) pathnames repre-
// senting the root directories. In a root directory or in any other
// subdirectory, model files can be found.
// return: List of pathnames representing root directories.
RootsList get_root_directories();
// Returns a list of subdirectories and model files of a given directory.
// param directory: (canonical, absolute, and unique) path of the
// directory from which to get the list of subdirectories and model
// files. This must be either one of the root directories or a subdirectory.
// return: A list representing subdirectories and/or model files
// of the given directory.
// raises CadUtility::CadError If there was an error retrieving the list.
PathList get_models_and_folders(in string directory)
raises (CadUtility::CadError);
// Returns the parent directory of a given directory.
// param directory: (canonical, absolute, and unique) path of the
// directory from which to get its parent directory. The given directory
// should be a subdirectory of one of the root directories.
// return: The path of the parent directory.
// raises CadUtility::CadError If there was an error retrieving the
// parent directory.
string get_parent_directory(in string directory)
raises (CadUtility::CadError);
};
};
Disposition: ?
Disposition Parameter: ?