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

[Cliff3D]

Well, it looks like the dot cloud is loading in correctly



and so is the UV Map:



(this is the 7MB plus .OBJ that I'm using as one of my reference .OBJ files).

[matchy]

Alright! Should be easy from here.  Can I suggest breaking the code into usable and readable functions so I can test it easily? For example, passing the file-name (to) and point array (from).

[Cliff3D]

Alright! Should be easy from here. 

Errr, no. I started at the easier bits and am working towards harder as I familiarise myself with GLBasic and get used to coding again (this is my first GLBasic program - I was reading the Help Tutorial and got down to "The First Game" but was bored so decided to jump in and see some action before I return to the tutorials). I'm sure other board members would appreciate it if I learnt some more GLBasic Facet tables are harder work to decode (they have an indetermiante number of parameters), and the way I intend to handle groups, "useMtls" and "MtlLibs" is a little bit fiddly.

Can I suggest breaking the code into usable and readable functions so I can test it easily? For example, passing the file-name (to) and point array (from).

Yup, you can. Functions are planned, so there will be a "main" that gets the filename and then calls "bSuccess% = LoadOBJ(filename$, MyModel)" or something similar. I only got as much time to play today as I did because it's my birthday, so my family give me leeway and my clients have to have an expensive problem to be able interrupt me!

Ideally, I'd return to the tutorials soon so that I can relearn more about BASIC and learn GLBasic specifics.

[matchy]

I'll test it when it's in LoadOBJ(filename$, MyModel) format!

[Cliff3D]

I hope to get time to play around with interpreting some of the other data - USEMTL, Group, perhaps MTLLIB statements in a few hours, when I see the potential for some uninterrupted time

[Cliff3D]

Took a while to get there, but here's the next evolution of this little puzzle. It's still a bit untidy as I'm still a bit rubbish at this, but I may well tweak it some more here and there - it's a tad slow so I'm reluctant to split it out into calls that are called thousands of times rather than using inline code, but we'll see what I think of it after I print it out for the first time and can see it all at once instead of on this teeny netbook screen.

I've tested it - on PC - with multiple .OBJ files from different sources and it seems to work pretty well...

I've started putting functions in the .OBJ type where/when it makes sense to me - such as when trying to add a face to the model.

[Cliff3D]

I'm a bit torn as to whether to investigate if I'll be able to write a JPEG import routine, or hope that someone - including Kitty Hello - will do it so I should proceed more with using 3D to display the model better and/or interpreting .MTL files (with .OBJ files you often get .MTL files which actually define the materials used). I'll think on.

[MrTAToad]

Would be easier to read code between the [ code ] and [ /code ] tags

Would be nice if the JPEG problem could be sorted out...

[Cliff3D]

When I previewed the CODE tags here it lost all leading white space IIRC, but I've given it a go and the white space seems to be back after posting. Also fixed a minor bug and added in a "Beep" sound (you'll need a beep.wav in the Media folder to run this as-is now).

The last 2D graphic reader I wrote was for GEM .IMG format - and that's so long ago I can't even recall what the CPU or OS involved were, much less the language. But we'll see - in the short term actually working in 3D would be more interesting to me than working on a 2D reader.

[Cliff3D]

OK, I think it's looking good. the project is now split into two .gbas source files so that I can split away the "LoadOB" functionality from the "show/test" program that uses it.

The show/test module does nothing now but fetch the filename, call LoadOBJ, then display a UV dot cloud, UV wireframe, Vertex dot cloud then Verted wireframe in order. Oh - and it loads a sound so that it can beep at you when it's finsihed drawing each screen (the first one can take a while as it's got to read in the model first).


The display code takes no notice of what platform it's running on, or the scale of the model - it's just a quick dirty hack to show you how (that) the model works, on a Windows PC. If anyone wants to address that and tweak it so that it takes account of the size of the model, I'd appreciate it - and you should know that the minimum and maximum X,Y and Z parameters of the model are stored in the model object for that kind of purpose.

The LoadOBJ module contains the type definitions and functions including LoadOBJ, so it should be relatively self-contained. I plan to extend it as I go, but basic functionality should be there now - although materials still have no info so far beyond the material name.

I suspect my next avenue of experimentation will drive me insane as I try to display the model in 3D on a free trial copy of GLBasic

[MrTAToad]

Your program will run for around 5 minutes, so plenty of time to view any problems 

[Cliff3D]

Oh, I suspect I can cause more problems than THAT! LOL. But it should be fine for a start, when I get around to trying it

[Cliff3D]

Your program will run for around 5 minutes, so plenty of time to view any problems 

Actually, with one of the 2 models I'm trying to use, it seems to be timing out before I can properly see the model So I'll have to use the simple cube for now and come up with an alternative, simpler "complex" model (my model isn't 40mb but it is taking several minutes to convert for GLBasic)

[Cliff3D]

Well, based on the latest screen captures:





personally I would say it is going very well - I see no reason beyond GLBasic reliance on hardware capability (like video card RAM for sprites/textures) that I shouldn't get pretty good WAVEFRONT .obj support, even with quads (which both those models use) and multiple texture maps.

I have just come across a model that uses smoothing groups, so I plan to add support for that, and possibly lines as well, to the .OBJ loader, but otherwise things that I know areoutstanding include:

1 .mtl support to read in the definitions of multiple materials (OBJ files use them, and objects WILL display in GLBasic with multiple textures, no problem - I have 2 possible routes, one tha tlooks likely and one that is certain).

2 .jpeg support - I'm putting this off in the hopes that Kitty Hello will write jpeg support before I feel compelled to attempt it.

3 Auto texture map resizing to occupy a "2 to the power of" dimensions regardless of source image resolution. My, that seems SUCH a limited range of bitmaps sizes - it is "2 to the power of" rather than "integer to the power of 2" though, isn't it? (hoping to be contradicted here, really).

4 use of PolyVector to display uv texture rather than dot cloud or uv wireframe.

5. sort out a way to do wireframe model rendering - showing quads, not triangles (at this stage that seems fairly trivial).

6. Some kind of GUI to various features would be nice.

plus probably misc. ease-of-use enhancements and suchlike. In no particular order except, as I keep saying, I'm postponing any .jpeg effort in the hopes of having that functionality land in my lap without significant effort at my end.

Now-I should probably go do some "work" and hope I can hack at some code later. I quite fancy playing with POLYVECTOR - it already looks like the answer to one of the problems which set me on the journy to finding a language I can live with

Having solved the initial queries - "can GLBasic do quads and jpegs" (no, do it manually, no - do it manually!) this thread is probably running out of usefullness so I should probably post in a new thread when I have a new question!

Thx

[Cliff3D]

mars_chaos89 wants to display a 3D model of a plane, possibly from .obj format.