OCS extrusion direction for LWPOLYLINE

[kpetrow]

Looks like extrusion direction was only implemented for ATTDEF. Extrusion can be part of LWPOLYLINE along with a bunch of other entities. The biggest issue with current code is that parseLWPolylineVertices runs through the rest of the entity but code 210, 220, 230 are at the end of the entity and apply to the entity not the vertices. To solve this I ended up passing the entity into the parseVertex function so we can grab the extrusion directions and append them to the entity:

line 1106:
entity.vertices = parseLWPolylineVertices(numberOfVertices, entity);

and then add the code to the parseLWPolylineVertices function:

var parseLWPolylineVertices = function(n, entity) {
		if(!n || n <= 0) throw Error('n must be greater than 0 verticies');
		var vertices = [], i;
		var vertexIsStarted = false;
		var vertexIsFinished = false;

		for(i = 0; i < n; i++) {
			var vertex = {};
			while(curr !== 'EOF') {
				if(curr.code === 0 || vertexIsFinished) break;

				switch(curr.code) {
					case 10: // X
						if(vertexIsStarted) {
							vertexIsFinished = true;
							continue;
						}
						vertex.x = curr.value;
						vertexIsStarted = true;
						break;
					case 20: // Y
						vertex.y = curr.value;
						break;
					case 30: // Z
						vertex.z = curr.value;
						break;
					case 40: // start width
						vertex.startWidth = curr.value;
						break;
					case 41: // end width
						vertex.endWidth = curr.value;
						break;
					case 42: // bulge
						if(curr.value != 0) vertex.bulge = curr.value;
						break;
					case 210: // OCS extruding x
						entity.extrusionDirectionX = curr.value;
						break;
					case 220: // OCS extruding x
						entity.extrusionDirectionY = curr.value;
						break;
					case 230: // OCS extruding x
						entity.extrusionDirectionZ = curr.value;
						break;
					default:
						//todo: mark unhandled somehow?
						curr = scanner.next();
						continue;
				}
				curr = scanner.next();
			}
			// See https://groups.google.com/forum/#!topic/comp.cad.autocad/9gn8s5O_w6E
			vertices.push(vertex);
			vertexIsStarted = false;
			vertexIsFinished = false;
		}
		return vertices;
	};

This probably needs to be implemented for all vertex functions,

I guess now that we pass in the entity we could directly add the vertices, but this is least amount of changes. Now the fun of converting Object coordinates to world..... Anybody got that code?

[bzuillsmith]

Oh, you're right, this function will run to the end of the entity. I never needed to implement anything 3D so I didn't test or think about that.

Yeah, those could really be moved out to the entity. We just need to identify all the codes that are possible on the vertices section (if there are more than what's there already). Then the default case in this switch you posted could stop parsing the vertices and return without advancing the scanner.

Do you want to give that a try and submit a PR?

As for the OCS to world stuff, I wrote three-dxf which uses three.js under the hood. Not sure, but maybe Three.js will take care of that for you (assuming you are able to use it in your project).

[kpetrow]

Maybe just return on default case?

I also use three js. Three would handle it if you put the lines in parent object then rotate the parent, but I need a 2d drawing and don't want to have to rely on three js libs for canvas drawing. I found some c code that I could port over... I'll look through the 3dxf code. I have some tricks iplemented for large dxf files, and would love to pick up any optimizations you have.

I'll do a PR tomorrow. Thanks