This project has moved. For the latest updates, please go here.

Regarding conversion of Coordinate systems

May 16, 2013 at 12:25 PM
Hi Daniel,

I had a small confusion. With the help of dxf reference book, I listed all those entities whose points are in OCS. Below is the list of entities:

a. ARC,
k. TEXT,
m. VERTEX (2D)

And based on your code, I found that

ARC, CIRCLE, INSERT and TEXT entities are performing OCS to WCS conversion, and IMAGE, DIMENSION, ELLIPSE and ELLIPTIC edge data of HATCH performs WCS to OCS conversion.

Q. 1. Being is OCS, why the second half list (mentioned above) are being converted from WCS to OCS?

Q. 2. Why ATTDEF, ATTRIB, LWPOLYLINE, POLYLINE, TRACE, POLYLINE (2D) and VERTEX (2D) are not being converted?

Thanks & Regards
Rakesh Patil
May 16, 2013 at 12:26 PM
I guess TRACE entity is not implemented I guess. Ignore it from the above list :-)
May 17, 2013 at 7:19 PM
As a rule of thumb, the public interface of the entity classes always use WCS, internally the DxfReader and DxfWriter will make the conversion, where necessary, from WCS to OCS and vice versa.

Let's take for example the Circle and Ellipse entities. The basic information that the class for the Circle requires is the center in WCS and the radius, while the Ellipse requires the center in WCS, the major axis and the minor axis; but internally the dxf requires for the Circle the center in OCS and the radius, while the Ellipse requires the center in WCS and the endpoint of the major axis in WCS. Totally different data for very similar entities, you can see a circle as an ellipse which major and minor axis are equal to the diameter. Since I am always trying to use WCS some conversions and calculation must to be done to pass to the dxf the proper information. The center of the circle must be converted from WCS to OCS, and in the case of the ellipse its center doesn't need to be transformed but I need to calculate the endpoint of the major axis. Since it is easier to obtain that point in OCS, the angle must be taken into account, I do that even though later I have to convert it to WCS.

Something similar happens with the Image entity the u, v vectors are calculated, for simplicity, in OCS and then converted to WCS as the dxf requires. And there are even entities that some data of the dxf is required in WCS while other is in OCS to add a little more confusion to the transformations. The internally structure of the dxf is a mess result of many years of AutoCad development and the documentation is even worse.

The polyline 2d was superseded by the LightWeightPolyline long ago. Now there are two kinds of polylines, the Polyline entity is a 3d polyline while the LightWeightPolyline is a polyline 2d. The LightWeightPolyline needs its vertexes in OCS to force it to 2d, since all its vertexes must be on the same plane. The old polyline 2d code is there in case a program is exporting them with the old dxf format.

The case of the block attributes its a little more complex. There is a method in the Insert class called TransformAttributes to make the data local to the insert to which they belong. It is the default behavior, I like that the attributes data local to the insert, so they are moved and rotated with it.

The DxfReader and the DxfWriter are internal classes for a reason, they are not to be used outside the DxfDocument, and trying to explain all internal transformations will take pages. Center yourself on the public interface of the classes and if you find something odd or something that it is not working as expected I will try to do my best to explain it. Perhaps I just made a mistake.

May 18, 2013 at 10:46 AM
I understand that the DxfReader and the DxfWriter are internal classes. I get the proper results too. But I was confused with the documentation. So I asked why all the points in OCS are not converted to WCS. Like the points in LWPolyline entity, the code is not containing the transformation, though the dxf reference says the points are in OCS.

I also observed that, there is a transformation code for circle entity and ellipse entity. And in case of hatching done for elliptical arc edge, transformation exists but not in case of Circular arc edge. Why is this so? I am not pointing out any error. Rather, want to know the real story. DXF reference is speaking one thing. Your code is doing things differently, still I am getting proper results. This means the dxf reference is not correct. Is it?
May 19, 2013 at 7:21 PM
The Hatch entity might need a longer explanation. In this case all data of the HatchBoundaryPath needs to be in local coordinates of the hatch and they need to be on the same plane (a hatch is a pure 2d entity as is the light weight polyline). So, if the entities are in the same plane as the hatch, the local normal vector for them has to be (0, 0, 1), in this case the OCS are equal to the WCS. The transformation of the axisPoint you can find for the ellipse edge is not really needed, but it will make no harm if the data is correct (normal vector (0, 0, 1)), but I will erase it for the next update.

Remember, when the dxf documentation says that the data for the boundary paths of the hatch is in OCS, it means that the information is in local coordinates of the hatch not the object coordinates of the edge path entity. It similar as the behavior of an insert, all entities that makes the block are in local coordinates of the coordinate system defined by the insert, thus for them the world coordinate system is the insert coordinate system and not the global world, if that makes any sense.

Most of the time, at least in my case, AutoCad is used to draw plans, when I am working in 3d or I just use solids (I cannot implement those entities since they depend on proprietary data and I have no information of how to do it) or I use another program. In a 2d drawing all entities have as normal the UnitZ vector, therefore the same entities that you pass to the hatch boundary path can be used to draw its edge. If the hatch normal vector is not UnitZ and you want to draw its edge you will need to create a new edge converted by the transformation matrix of the hatch.