Is 3D limited to triangles? Any other traps to trip me up?

[Cliff3D]

Can I enquire whether the 3D capability of GLBasic really IS limited to triangles? I need to be able to manipulate quads as well as triangles you see

[backslider]

huh? 2 triangles are one quad!?

[Slydog]

Right, you actually create two triangles, and there is no way to create a quad directly.

Using the 'X_OBJADDVERTEX' command, you would specify the four corners of the quad (top-left, top-right, bottom-left, bottom-right for example) and it will automatically create two triangles.
Then use 'X_OBJNEWGROUP' to lift your 'pen' to begin your next triangle/quad.

[matchy]

Just to note X_OBJSTART has only one mode (triangles) but STARTPOLY has 3 (fan,strip,triangles).
More simply, plotting four points as a "Z" is makes a quad like "|Z|" not "[ ]". 

[Cliff3D]

Yup, 2 triangles make a quad, sortof, but I was hoping that I could easily retain the connection between quads-in-file to quads-in-GLBasic. The numer of workarounds to achieve what I wa shoping to do are getting unmanageable (I've been basically absent from programming for over a decade and was hoping GLBasic would be a simple re-entry for me). I currently have, as a starting proposition, these workaround routines on my "todo" list:

Wavefront .OBJ importer
Wavefront .OBJ exporter (where although the vertices and UV co-ords may have changed, everything MUST be exported in the same order as it was imported)
.JPEG importer
.JPEG exporter
(because it seems GLBasic JPEG support is flakey)

...and I'm not entirely sure about how well GLBasic will cope with being able to read in 10's or even 100's of thousands of lines from a text file to perform the .OBJ importing.

But now would need to add "managing quad to triangle translation", before I can get anywhere near actually trying to write the utility/ies that I'm interested in

Quads-to-triangles isn't much, perhaps, but it's adding to my list of concerns that this isn't the language for me. I should re-evaluate where I'm heading, or at least how I'm going to get there. Thanks for the help!

[Slydog]

I'm not too sure of the details of what you are converting.
But, you don't have to worry about triangles if you already have quad coordinates.
Just create a 'CreateQuad()' routine and pass it the four corners, and add the four vertices of the quad, and it will create a quad for you, consisting of two triangles, but you don't have to worry about creating two triangles as GLBasic will do this for you.

Just make sure you add them in the proper order (ie. top-left, top-right, bottom-left, bottom-right).

Being new to game programming myself, I find GLBasic extremely easy to use, and very intuitive to what I want to achieve.  I've tried other game programming languages, and it doesn't get any easier than GLBasic, for both 2D and 3D.

I'd say give GLBasic a try, and if you have any problems / questions, the GLBasic community if very knowledgeable and willing to help.

Good luck

[Cliff3D]

I must admit that the apparent helpfulness and friendly attitude of the community is one of the things that appealed to be about GLBasic. It's a definate "selling" point, though I'm a bit surprised that there aren't more "canned functions" ready to go in the "shared code snippets" forum. I rather expected to find a homebrew JPEG solution there and didn't.

To further expand on what I want to do... there isn't much of a "game" aspect except for writing the programs in-use the programs would be more utilities than games. Here's some of my objectives:

At the extreme low end of what I want to achieve there would be a simple box in Wavefront Alias .OBJ format and a simple texture in any format. I'd want to be able to "render" an othagonal view of the original cube at screen resolution, change the coordinates of the vertices at will, and "render" the cube either with texture or as some kind of wireframe at both screen and high resolutions (probably up to say 4096 pixels by 4096 pixels). The "wireframe" view could be an issue as I couldn't just use "switch to wireframe now" if the quads have changed to triangles - I'd have to build a seperate model, at a guess, that would LOOK like the same quads model, but in wireframe. This seems hinky

Perhaps I could forgo the wireframe view, maybe. Although then I'd be making compromises on capability to suit the language instead of finding a language and/or improving my skillset to suit the problems.

At the extreme high end I'd want to be able to do that and more (like selecting which "groups" and/or "materials" from within a .OBJ file to work on) on .OBJ files of which a typical example would have:

# NumVerts/NumTVerts/NumVNormals/NumFacets   68498/70769/0/66830
# NumGroups/NumMaterials 63/30

in 206,529 lines(over two hundred and six)  of text-based .OBJ file (including comments). The .OBJ files cannot be assumed to end in a consistent manner (i.e. some .OBJ files may end in a CR, while others end in a CR+LF combination. There may be a variety of line endings, I haven't checked - there's too many possible sources of .OBJ file!).

At this higher end I'd HAVE to be able to use JPEG files, reliably, as well as .PNG and .BMP.

One of my thoughts had been to write a .OBJ reading routine and offer that up in the "code snippets" forum if I get it working, but as I always seem to be short on time I was reluctant to spend TOO much time on GLB if I am going to end up using VisualBasic or Python.

For the record, GLBasic appeared to be the easiest route to a clean .exe that doesn't require others to set up any runtime environment. The simplicity of setup, both for programmer (me) and user (probably mostly me!) seemed better than (say) freeBasic or VisualBasic. I LIKE "lack of hassle", but these little niggles (like JPEG still not working, so on and so forth) dent my confidence. Maybe I'll put a bit more work/effort in though because, as you say, the community is welcoming and knowledgeable. These features may be of huge help as I try to dust of the coding portion of my brain!

I'd dearly love to avoid just writing the parts that Poser or DAZ Studio can't do for me in Python/QT Script - self-contained programs appeal to me much more.

Thanks

[Cliff3D]

I couldn't sleep, so I thought I'd slap together a first pass at opening a text-based .OBJ file and displaying it line by line, then screen by screen, then parsing it a little deeper...

{snip}


Now, there's a lot missing - I haven't declared my types, or even quite decided if I'm going to just dump comments or try to preserve them somehow (ditto with the material commands, though it seems likely I will try to retain those one way or another) much less made any attempt to parse the individual parameters for each command.

As a sample TINY .OBJ file (rather than the thousands-of-lines-strong file I've tested this against quite happily) I'm using something like:

# NumVerts/NumTVerts/NumVNormals/NumFacets   8/16/6/6
# NumGroups   1
# Original File Name "Cube 03 (normals).obj"

v -1.00000000 -1.00000000  1.00000000
v -1.00000000  1.00000000  1.00000000
v  1.00000000 -1.00000000  1.00000000
v  1.00000000  1.00000000  1.00000000
v  1.00000000 -1.00000000 -1.00000000
v  1.00000000  1.00000000 -1.00000000
v -1.00000000 -1.00000000 -1.00000000
v -1.00000000  1.00000000 -1.00000000

vt  0.50000000  0.66666669
vt  0.75000000  0.66666669
vt  1.00000000  0.66666669
vt  0.75000000  0.33333334
vt  1.00000000  0.33333334
vt  0.25000000  0.66666669
vt  0.00000000  0.66666669
vt  0.00000000  0.33333334
vt  0.50000000  1.00000000
vt  0.25000000  1.00000000
vt  0.50000000  0.33333334
vt  0.25000000  0.33333334
vt  0.25000000  0.00000000
vt  0.50000000  0.00000000

vn  0.00000000  0.00000000  1.00000000
vn  1.00000000  0.00000000  0.00000000
vn  0.00000000  0.00000000 -1.00000000
vn -1.00000000  0.00000000  0.00000000
vn  0.00000000  1.00000000  0.00000000
vn  0.00000000 -1.00000000  0.00000000

g Cube
f 4/1/1 2/6/1 1/12/1 3/11/1
f 6/2/2 4/1/2 3/11/2 5/4/2
f 8/3/3 6/2/3 5/4/3 7/5/3
f 2/6/4 8/7/4 7/8/4 1/12/4
f 6/9/5 8/10/5 2/6/5 4/1/5
f 3/11/6 1/12/6 7/13/6 5/14/6

The .OBJ file format is a little loose, so I'm going to have to take care of situations where texture coords are misisng, or normals are, but the basic framework seems to be coming together for the reading in of actual files.

Does anything look hinky? Does anyone see an obvious pitfall that I'm heading towards? For example, while that .OBJ was crafted largely by hand to meet pre-defined criteria, I can't predict the order of the vertices or facets in .OBJ files in general - I'm quite nervous about the idea of trying to turn the quads into triangles so that they display as quads both when textured and wireframe - especailly as I must be able to output the model with vertex and facet orders intact.

Thanks,

Cliff

PS it's nice to be messing around with BASIC again. I've missed it for all those little bits of code that I could have done with over the years - just to make life a little more interesting.

[matchy]

It would be cool have the data stored in a object group tree then matrix pushed so that mulit-texture maps can be used. Currently, only one object file can be imported which means only one texture, when originally two were assigned. A UVMap viewer/editor also has been discussed on the forum.

[Cliff3D]

Ouch - only one texture map/image per model? Thanks for the heads-up - I definately need to manage more than that, and other aspects of material/texture definition (like different diffuse colour even when using the same texture map). It's looking like actually displaying .OBJ files at random is going to be a bit of a chore. Of course, if GLBasic can itself be improved/extended then that would be even better. In the meantime I'm having fun fiddling around.

A UV Map viewer/editor? One of the things I have in mind to do would be sortof related to that, though far from a full editor and probably not included in a lot of editors. A bit of an offshoot. An actual editor would be lovely - I'll have to search for that thread and read up   I would certainly want to be able to apply a texture to a model that was itself in the same shape as the UV map, and "render" that (with ambient lighting and othogonal projection) to produce an exact 1:1 copy of the texture. Not a brilliant goal, but much easier to understand than my full goal in THAT direction

[matchy]

Try to import a .obj with 2 textures as it can't be done!  The mesh needs to be exported from a 3D editor (currently) with each separately assigned texture and 3d object, which is a hassle if there are existing, complex models. I think it's an important function and cooler if run-time-able.

I have not peeked into .obj files yet.  Can objects be simply filter imported by texture id?

[Cliff3D]

Well, technically anything can be done - so long as you're willing to write it!

As displaying is technically not at the top of my list, I'm considering trying to include a function within the type of "facet" that draws the facet using GLBasic, and only that facet. The facet type would be one of the members of type "3dmodel" which would call each facet one at a time... this would avoid having to work out reasonable "strips" from the 3D model and would get around at least the lack of support for multiple textures, but I suspect would be rather slow. Perhaps we shall see.

As for the .OBJ format, in theory every facet (triangle, quad, or dreaded n-gon) could be part of a different group to the one before and after it, AND a different material to the facet before and after it AND a different material to the other members of that group.

In practise things tend not to be QUITE that bad. However, quite a lot of files have fragmented groups and/or material zones.

I can't find my favourite reference to the .OBJ format right now, so here's a quick summary.

Ignoring advances which most programs (certainly those I use) don't support, .OBJ files have the following properties:

1. A Vertex cloud. This colleciton of points may be stored in consecutive lines or may be fragmented throughout the file. I have never knowingly encountered a .OBJ file where a facet refers to a vertex which comes after the facet definition, but I am not sure this is dissalowed either. the "shape" of the 3D model could be seen by displaying these as dots/spheres, in a rough hazy way. the vertex order is implied by the order the vertices are found in the text-based file.

2. Optionally a Vertex Texture co-ordinate cloud. this often has a different number of points. In theory it's a 3-coord cloud like the vertex, just (u,v,w) instead of (x,y,z) but I have never seen a VT cloud that uses the w parameter. the shape of the UV map could be seen by displaying these co-ords in a roucgh, join-the-dots kind of way. As with the V cloud, the VT vertex order is implied by position (NOT line number within the file).

3. Optionally a Normal table. The Normal position within tth eNormal table is implied by order found in the text file.

4. A facet table, which comprises integer indexes to the V cloud/optionally an index to the VT cloud/Optionally an index to the N table. Use of facet order is rarer than vertex order, but still happens - and is important to me, personally.

Obviously, vertices are reused by several faces - which is presumably at least part of the reason they are stored in a seperate table, rather than storing each facet as a direct (x,y,z) coord using floats. I have never knowingly seen (noticed!) a "face" line which has a VT or an N at one vertex which didn't have them at all vertices, but I suppose it's possible to do that.

Additionally:

5. At any line, the current "group" (arbitrary name of a collection of facets) or current material - by name - can be changed. And/or changed back. Also the "material library" can be changed (this holds a definition of the materials, their ambient colour, diffuse colour etc.). I have never noticed a .OBJ file that used more than one material file, but it seems to be a theoretical possibility. Since this would allow for materials of the same name with different definitions, I currently plan to ignore this possibility and hope it never hits me in the face.

6. There's an extra version of groups that I have not researched yet - smoothing groups. It would be a good idea for me/us to support these if I/we can, but they are a LONG way from being vital to MY intended use/s.

None of the tables (or attributes like "groups" or "smoothing groups" or "materials") have to be stored on consecutive lines. As 3D modellers tweak the model, adding here, deleting there, changing group and material zones, the tables tend to become fragmented. The more the model is worked, the more fragmented it becomes. One semi-useful tool could be simply to re-order the model to be better optimised (e.g. ordered by material first and then by group name, or by group name and then material) so that it loads faster in most 3D programs and is also passed to render engines more efficiently. As I say, I have a number of little utilityish functions I'd like to try out.

I've written a crude .OBJ viewer in the past to make it easier to see where there were certain technical flaws in the mesh, using C or C++ (I don't recall which - probably a hackily-coded version of Borland C++). I don't think I even approached handling textures at the time though, and I don't know where my source is... but the file format is easy enough that I should be able to do it using BASIC - especailly as reading lines of text from a file is platform agnostic regarding line endings (this makes life easier as .OBJ files are platform agnostic too). I'm very willing to attempt a "community .OBJ reader", as in sharing my code, but I will probably need help displaying the model and probably odd things I haven't thought of - like I hadn't thought to check GLBasic could apply more than one texture to a model!

Oh - the amount of white space between parameters (the number of spaces) is undefined. It could be one, but equally it could be five. Some programs expect 1 space and crash on loading certain .OBJ files. Ooops!

I'm quite pleased at the apparent speed of the GLBasic-produced code thus far - it nips through reading the 7.61MB test .OBJ file quite quickly, so I now run through the file in two passes - the first pass simply counts the number of vertices, VTs, Normals etc. so tha tI can redimension arrays to hold the tables just once, before populating them on the second pass. I expect this to be better on memory management, not redimensioning the tables every line or even every n lines of .OBJ file.

[matchy]

Hey dude, so textures are too complex? If you can't work it out then I have not hope. 

[Cliff3D]

I doubt it. We'll see

I should have referred to some .OBJ file format reference instead of doing it all by memory - in the code above I have assumed the command "n " for normals. This should have been "vn". Hopefully I'll find some time in the next few days to start interpreting individual commands. The .OBJ file format as I intend to use it isn't complex.

[Cliff3D]

Slightly updated code, moving away from my previous prefixes for variable types and trying to use GLBasic postfixes. Plus I've added some types for actually holding 3D data. Thanks to Moru and Jaywat pointing me to SPLITSTR I've started to populate a 3D model in memory from .OBJ files instead of just skimming through the files. I'm also still ignoring actual materials for the present, as I'm less bothered about multiple materials than just about anything else for now.

I am, however, tempted to see if I can draw a dot cloud in 2D to at least partially verify that the model is loading correctly. Possibly even a dot cloud for the UV Template/map as well. Hmmm - I've got to look at the 2D graphics capability sooner or later...

I'm also trying to apply GLBasic techniques as I come across them - like using INC A instead of a=a+1