So that's different from what you originally asked.

I disagree. I said: "I'd like to find something out there which will let me create relatively simple models and export vertex and line information to a simple file format or even C arrays etc."

If you refer to the below link, there are 2 tables describing exactly what I am talking about.

https://en.wikipedia.org/wiki/Wire-frame_model

The game I'm fiddling with stored models in the same method as described in the link above. It stores 3D vertices coordinates and then lists the vertex pairs which form each edge.

If there aren't any tools around capable of doing this, then that's OK - I'll write my own. The other thing I considered this morning is deriving this information from face vertex information in an OBJ or similar file - that should be straightforward for me to do because its just a matter of factoring out a lot of the vertex chain information.

I think we all know what wireframe models are. What we don't know is the actual data you are trying to generate, or why.

Knowing that would help come up with answers. Instead all we've gotten is that various tools and formats don't work. What are you looking for? If we know what it is, and why it is, then we can help come up with either the exact thing or a working alternative.

For example, saying you want minimal data probably means you are going to do some simple modifications to it, but you don't say what. Saying you want it as a C array as source code probably means you want it in a program so you can manipulate it, but hard-coding data like that is rarely done, there are other, usually better approaches.

You write that you want tables. Tables are a visual thing, not a data thing. Probably the closest to that is comma separated values, but you aren't asking for that.

What is your real question, what is the real problem you are trying to solve

For example, saying you want minimal data probably means you are going to do some simple modifications to it, but you don't say what. Saying you want it as a C array as source code probably means you want it in a program so you can manipulate it, but hard-coding data like that is rarely done, there are other, usually better approaches.

1. Ideally I would like a simple program (with side, top, front and perspective views where I can draw wireframe models - perhaps using primitives such as cubes, pyramids, lines and be able to move the vertices around in 3D coordinate space

2. If I had a pyramid for example, I would like it to appear as float arrays similar to this:

float vertPyramidXYZ[] =
{
0.0, 0.0, 1.0,
-0.5, 0.5, 0.0,
0.5, 0.5, 0.0,
0.5, -0.5, 0.0,
-0.5, -0.5, 0.0,
};

int linesPyramid[] =
{
0, 1,
0, 2,
0, 3,
0, 4,
1, 2,
2, 3,
3, 4,
4, 1,
};

This would allow me to export my own objects back into an Amiga game such as Mercenary written back in the late 1980's. Mercenary in particular was written in 680x0 assembly language and my language of choice for the past 20 years has been C. So when I want to manipulate bytes, I use C. Other modern day formats are far too complex for this purpose without converting the data contained within them.

Mercenary draws its objects by drawing lines. It iterates through the list of lines getting source and destination vertex indices. Those indices are used to look up the 3D coordinates from an array such as my vertPyramidXYZ example and then it draws a line in 3D space between the 2 vertices.

1. Ideally I would like a simple program (with side, top, front and perspective views where I can draw wireframe models - perhaps using primitives such as cubes, pyramids, lines and be able to move the vertices around in 3D coordinate space

For the first part, there are many programs for manipulating them. Blender, Maya, 3D Studio, and others can manipulate meshes.

From your description you generated a more complicated mesh than you needed. Subdividing models like a cube can be a very good thing on modern systems that operate on a per-vertex basis, you need more of them for your shaders and effects to appear smooth. Nothing prevents you (with your artist hat on) from reducing the model down, or generating a more simple model in the first place.

If you know what you are doing, it only takes a second or two to build the low-poly models that you describe in the modern 3D modeling programs. You just need to give it the right parameters.

2. If I had a pyramid for example, I would like it to appear as float arrays similar to this:

Not even the old tools generated output like that.

Even going back to the 1970s in the days of Evans and Sutherland's early 3D tools being everywhere, graphics tools still dealt with data file rather than trying to make it part of the executable like that.

So you'll need to build an exporter that dumps it in C format, or hunt around on the internet for someone who has written them, but I doubt there are many. Data files for graphics are generally meant to be loaded as data.

After you've got your data file exporter, the content will almost certainly not look like your example. Unless you are hand-coding every piece of data they probably won't be all ordered perfectly in a human-preferred sort order. You may happen to get lucky with your polygon ordering and your export ordering, or export immediately after creation and happen to have the model generated in your preferred way, but probably not. For just those 8, you've got 8 factorial (over 40,000) different ordering possibilities, so almost certainly they won't fall into that nice simple human-sorted ordering.

Mercenary in particular was written in 680x0 assembly language

There were games in that era where every CPU instruction was chosen by hand, where every data point was hand crafted, where every byte was accounted for by the game programmer, and the programmer knew exactly what every instruction in his game was and why it was there. If that is the type of games you want to build, it will require a far more work and learning.

I usually wouldn't recommend that route except for a learning experience because you are determined that want to learn it. The route is difficult and was abandoned for many good reasons, including the high costs of human effort, of specializations, of difficulty and time.

You can certainly do it, but that's not something you will get as output from any mainstream tool. You'll need to craft it, or at least parts of it like exporters, yourself. Artisan games generally require artisans to make.

wings3d. free, minimal, simple to use.

And open source too! Thanks for that.

If you really want to do it by hand, you can speed the process along by modeling in blender and then grabbing the list of vertex positions: http://blenderscripting.blogspot.com/2011/05/blender-25-python-printing-vertex.html

Thanks again - plenty of options.

You'd still probably be better investing the time in Blender as you are bound to want more advanced features as you develop.

Definitely. I did spend quite a bit of time with some Blender training vids on Youtube but it was taking a while. I had pinned it for a later date to return to thinking I wouldn't need it during my retro-revisitation but..

Use Blender and output as an .obj file.

Here is a cube exported from Blender:

o Cube
v 1.000000 -1.000000 -1.000000
v 1.000000 -1.000000 1.000000
v -1.000000 -1.000000 1.000000
v -1.000000 -1.000000 -1.000000
v 1.000000 1.000000 -0.999999
v 0.999999 1.000000 1.000001
v -1.000000 1.000000 1.000000
v -1.000000 1.000000 -1.000000
vn 0.000000 -1.000000 0.000000
vn 0.000000 1.000000 0.000000
vn 1.000000 0.000000 0.000000
vn -0.000000 -0.000000 1.000000
vn -1.000000 -0.000000 -0.000000
vn 0.000000 0.000000 -1.000000
s off
f 1//1 2//1 3//1 4//1
f 5//2 8//2 7//2 6//2
f 1//3 5//3 6//3 2//3
f 2//4 6//4 7//4 3//4
f 3//5 7//5 8//5 4//5
f 5//6 1//6 4//6 8//6

Ignore the "o cube" and "s off". They don't matter. The lines starting with 'v' are the vertex coordinates. The lines starting with 'vn' are face normals and are optional for export. The lines starting with 'f' are key. The faces are indices starting at one instead of zero (important!). The face format is: vertex index/uv index/normal index. If a slot is empty, as it is here with the uv indices, it means the data wasn't exported. The number of index groups per face is the number of edges per face.

To do what you want, you would parse the file and construct your line array as so:

Face '1':

int lines_array[] = {
0, Face 1, index 1
1,
2,
3
};

Add face 2:

int lines_array[] = {
0, //Face 1, index 1 (OBJ indices start at 1 instead of 0)
1,
2,
3,
4, //Face 2, index 5
7,
6,
5
};

And so on. This has the benefit of not forcing your object to be hard coded. I have an OBJ file importer I can give, if it would help.

I'm writing this at 4 AM, so I might come across a little unclear. Sorry about that.