Created attachment 625 [details] Replacement Illustration of GPS orientation I find the explanation of the GPS orientation vectors (rot1 and rot2) very confusing. Current: For more general applications, the user may supply two vectors (x’ and a vector in the plane x’-y’) to rotate the co-ordinate axes of the shape with respect to the overall co-ordinate system (Fig. 3). Proposed replacement text: For more general applications, the user may define a rotated coordinate system for the source shape by supplying two vectors defining the x'-y' plane of a new coordinate system. These may have any length, and are not required to be perpendicular to each other, provided they are not collinear. The new z'-axis direction is uniquely defined as perpendicular to this plane and oriented according to the right hand rule (Fig. 3). The current illustration in Fig 3 is difficult to interpret and visually ambiguous. I am attaching a proposed graphic to replace it.
*** Problem 2252 has been marked as a duplicate of this problem. ***
My other suggestion is concerning the description of Assemblies. It is natural for a novice reading the documentation to see the section on assemblies as the right way to combine components together. But in reality a LogicalVolume already implements the features necessary to combine multiple components together and is the recommended approach. It would be good to make this point explicitly for people who might be reading the documentation out of order -- especially in its online form. The primary use case for Assemblies is also not explained clearly. The example pictures show parts that interlock with each other in a complex way, with the implication that this is the use case for which Assemblies are the solution. But actually, the challenge of interlocking parts is defining their solids to ensure they don't overlap each other when placed in their desired positions and orientations. The Assembly construct does not help with this problem at all. The only benefit of the Assembly is that you do not have to define a solid for the mother volume that encloses all the components inside. Actually, Fig. 9 does partially illustrate the use case, but is not explained correctly. The caption says "Examples of assembly of volumes." But the examples only make sense if the weird shapes in the picture are *each* an Assembly of other parts. That way the problem of defining the outer shape is avoided. But since the shapes are shown as looking like perfectly reasonable solids made of blocks, the right way to construct these would be to use Boolean Unions to combine the solids together. This would be a real example of a use case for Assemblies if each of the weird shapes is actually composed of many smaller parts that only partially fill the spaces described by the outlines. The advantage of the Assembly is that you can avoid artificially constructing the weird-shaped solid solely for the purpose of enclosing the components. I could take a crack at illustrating this. --Brian
Created attachment 626 [details] Possible example of Assembly Possible improved example of assembly
(In reply to Brian Yanoff from comment #3) > Created attachment 626 [details] > Possible example of Assembly > > Possible improved example of assembly Caption could say "Three assemblies surrounding two simple blocks"
