I'm rather lost why a building a line segment is of value from vsg::Builder. It's really heavy way to implement the drawing of single line segment, and really not what I'd want any VSG user to be doing as it's just so inefficient.

What is the purpose here?

I have reflected on the need for generating lines and I think the right approach is to passing in a complete vsg::vec3Array or possibly a list of vsg::vec3Array to generate lines for. Creating primitives mesh might also be something you'd want to do in this way. Perhaps it could all be just done together.

I am going to close this PR as I just don't feel it's useful for real world applications. If we want an API to make it lines and mesh geometries more easily then vsg::Builder might be a starting place, but to brain storm what this might be I think a Discussion thread would be the right place to do this.

I have reflected on the need for generating lines and I think the right approach is to passing in a complete vsg::vec3Array or possibly a list of vsg::vec3Array to generate lines for.

This means that when drawing lines it is necessary that

1. geometryInfo gets an additional member for setting vertices, which contains the points for the lines
2. since there is currently no explicit way in the StateInfo class to set the topology of the GraphicPipeline, it is necessary to enable the wireframe in the vsg::StateInfo instance to display lines.
3. Rename to createLines() as it could create more than one line

Or is there more to do ?

Or is there more to do ?

What about normals and texture coordinates? When you create a line, they are calculated in createLine(), but if you use more than one line, I assume they have to be specified as well. Or can they be calculated completely in createLines() too ?

All good questions, that I don't yet have quick answers to, I will need to sit down and ponder on the issue.

vsg::Bulder was written specifically for primitives shapes like cubes, sphere etc, rather than free form meshes/points/lights so the StateInfo/GeometryInfo start creaking at the seams when we start trying to generalize them to this more general purpose.

It may be that we need to have two builder classes - one for shapes, and one for free forms geometry setup. I need time to think about the topic though.

It may be that we need to have two builder classes - one for shapes, and one for free forms geometry setup. I need time to think about the topic though.

Vulkan specifies several primitive types. Perhaps an additional PrimitiveBuilder or BuilderPrimitive class would fit.

Vulkan specifies several primitive types. Perhaps an additional PrimitiveBuilder class would fit.

geometryInfo gets an additional member for setting vertices, which contains the points for the lines

May be PrimitiveGeometryInfo or GeometryInfoPrimitive ?

since there is currently no explicit way in the StateInfo class to set the topology of the GraphicPipeline

PrimitiveStateInfo or StateInfoPrimitive ?

It may be that we need to have two builder classes - one for shapes, and one for free forms geometry setup. I need time to think about the topic though.

Vulkan specifies several primitive types. Perhaps an additional PrimitiveBuilder or BuilderPrimitive class would fit.

I see a current use for such a class in osg2vsg to avoid multiple implementations when converting osg geometry to vsg, since the necessary steps are basically the same.