Old polylines work, but new LWPoly's doesn't ??
You can also just use the CONVERTPOLY command to change the LWPolylines into "Heavy" 2D Polylines [no need for a routine to make them 3D Polylines -- CONVERTPOLY is a standard AutoCAD command], and then run your routine.
I may take a look at editing your code to work directly with LWPolylines, so you don't need to convert them either way, but it won't be right away -- I'd need some time to figure out exactly what it's doing, since I don't know the language.
Kent Cooper, AIA 
@marko_ribar wrote:
... if OP is to use it on LWPOLYLINE entities then it's probably intended exactly to perform operations with arced ones as I don't see why such request is asked...
The example drawing doesn't contain any arc segments, so that may not be an issue. It may be that they made the request simply because they drew some Polylines in the default type of Polyline, not realizing the routine wouldn't work on them when that type is LightWeight. If that's the issue, they can just [for future use] change the PLINETYPE System Variable to 0, and then when they draw Polylines, they won't be LightWeight, and the routine should work with them.
But looking at the example drawing does raise other questions in my mind. If the routine is stepping along vertex locations to find corners for 3DFaces it's going to draw, shouldn't the Polylines have the same number of vertices, to get the 3DFaces to fill up all the way along both edges of a space between Polylines? The ones in the example drawing have different numbers of vertices. What happens at the trailing end? [I couldn't really try it and see what happens, not knowing what the prompts were asking for.] And if it's supposed to do what I would imagine, I wonder what happens along the "sides" of that big bulge to the right -- do some 3DFaces cut across each other, or something?
Kent Cooper, AIA
@Anonymous wrote:
... this is not perfect yet, because it cannot follow the polylines edges
accurately and seems to end premature without reaching the endpoints ;>(
....
The original doesn't reach all endpoints either [in the sample drawing attached to Post 7, as well as in my own trial]. I haven't dug really deeply into the operation of that or @marko_ribar's LWPolyline variant, but I'm guessing it has to do with too great a difference in the numbers of segments in different Polylines.
Obviously, if the number of subdivisions you ask for is greater than the number of segments in the Polylines, both routines are adding 3DFace corners inside some Polyline segments. That seems to be the cause of 3DFaces that overlap each other, at least when the number of Polyline segments differs, within limits. What should happen if you ask for fewer subdivisions than the number of segments in one or both Polylines? It seems the 3DFaces are supposed to meet all Polyline vertices, but what if I ask for 10 divisions but a Polyline has 15 segments? Would that ever be the case? If so, should some of the 3DFace edges span across open space and not lie along such a Polyline in some places?
I suspect this could be done much more concisely using (vla-curve...) functions, which I may take a shot at -- for one thing, it should be doable in a way that wouldn't care whether the Polylines are lightweight or heavy, or in the case of heavy ones, 2D or 3D.
Kent Cooper, AIA
You may be interested in my DivPLVerts.lsp routine with its DPV command, available here. It takes a Polyline and forces it to have the specified number of vertices, adding some to the longer segments as necessary. It obviously requires the specified number to be more than what it already has, but it looks like that's your typical situation, anyway. When that's the situation, you could apply DPV to your Polylines, and then run 3DFaces using every vertex of the DPV'd Polylines directly, without the overlapping situations.
Kent Cooper, AIA