Maya 6.0 has changed the OBJ and MTL file formats.
I've revised my OBJ importer to suit.
This version handles Materials better than ever.
Multiple Materials with one or more textures is fine.
Materials without texture? fine.
Faces sorted by Material to eliminate texture thrashing during rendering.
Exports to HSM binary file format (Custom file format, reasonably tight).
Can render at the import stage.
Can supply an executable demo to load and render a model.
Collision detection with object surfaces not yet implemented, and may never be,
as I'll probably throw theoretical hulls of simpler geometry around entire objects.
The World will be a BSP generated from a larger one of these models, and it'll have proper surface collision detection, as creating Planes is a natural part of creating a BSP.

Also included: HSM class for loading and rendering HSM binary files.
Optimized rendering and memory usage.

Anyone alive?

Posted on 2005-04-28 11:12:46 by Homer
Please try to use attachments instead of creating such huge posts, makes things easier to read :)
Posted on 2005-04-28 15:37:07 by SpooK
mmk :P
Posted on 2005-04-29 02:57:22 by Homer
Nice HSM format :D
And nice coding style ;)

> Anyone alive?
I'm kind of, uni was suffocating me this week, and now I'm off to coding a 3D demo game for some new phone that I don't have yet ^^". It's a pity I can't develop for PC - making good use of the cpu and gpu, but at least - I've got an "undiscovered country" here :)
Posted on 2005-04-29 11:46:26 by Ultrano
The importer now better supports large models.
I've screwed down the HSM binary file format even further.
I no longer support importing of FaceGroups.
I no longer export UNUSED MATERIALS (imported from the OBJ) to the HSM file.

HSM class now supplies its own Render method which has been optimized further by converting indicies into pointers at load time - we perform no vertex lookups at runtime, yet our faces are still built from the same shared vertex array.

What's wrong with my coding style? :)
Does it look horrible to you?
What suggestions would you make to improve this?

I'll post an updated zip tomorrow,there's a small bug in the HSM quad renderer I'd like to resolve first.
Posted on 2005-04-29 12:04:44 by Homer

What's wrong with my coding style? :)
Does it look horrible to you?
What suggestions would you make to improve this?

Now your coding style is very very good ;) , it is properly idented and well-commented. This was not the case before ^^" . But hey, my coding style was also bad till a few months ago :P . So bad that I couldn't immediately understand code I had written a year ago... I remembered how it worked just for one year - then - poof, nothing.
Posted on 2005-04-29 12:41:04 by Ultrano
I resolved the issue in the HSM class render method.

There is a problem with the Vertex Normals I'm importing, with regards to untextured materials.

Rather, there appears to be a problem in Maya 6.0's OBJ exporter - for some reason, it's exporting pervertex normals with all the same values per face - ie, sets of face normals rather than "corner normals".
Example - if we export two adjacent quad faces at angles to each other (six vertices), we get six normals containing just two values (the face normal of each quad face).

It becomes really obvious since I added lighting and a toggle for smooth/flat shading - flat shading always looks nice, since the vertex normals are all facing in the same direction per face - but smooth shading looks absolutely ghastly.
The solution is to average the existing normals, or recalc them entirely.
In the former case, for each vertex, we find all faces which share this vertex, and then we average all normals applicable to that vertex.
In the latter case, we don't bother importing or exporting Normals at all, we calculate face normals for each vertex-per-face and then average them as before.

I don't want to take this much further until I resolve all current issues, but soon I'd like to write a manager for instances of load-once reference objects, I'd like to revisit my BSP code with regards to supporting quads as well as triangles, I want to be able to embed instances of ref objects within BSP leaf nodes so we only have to perform collision detection between the object and the BSP planes which form the leaf node.

Collision detection is a little expensive.
The leaf nodes in a BSP have an interesting property - they denote a region of space which is bounded by the planes of all nodes between that leaf and the bsp root.
If we want to perform optimized collision detection between a moving object and the world, we need to identify which surfaces the object could possibly hit.
If we calculate (and track) which leafnode an object is currently in, we can reduce the number of planar collision tests required to (Tree Depth) tests.

The regions enclosed by leafnodes are not totally enclosed spaces, or else we couldn't visit them :P
This means its possible IN THEORY for vertices of an object to exist in two or more leafnodes at once.
We can create special planes which totally separate the leafnodes.
They are invisible planes over the "entrances" to a leafnode.
We'll call them "interleaf portals", which each join two leafnodes.
We can perform collision detection against these planes as well, and if an object begins passing through a portal, we mark it as being in both leafnodes.
If the object totally passes through the portal, we remove the reference to the object in the node which it has exited.

Ultrano - tell me more about your current work - even though you are not PC coding, I'm sure we can still trade ideas and algorithms.

Posted on 2005-04-30 04:14:09 by Homer
Basically, I'm trying to make a vertical-scrolling spaceship/airfighter shooter for mobile devices. Just a few days ago the task was a bit shifted - I have to develop it for a QooL phone. I tested a lot of ideas on making the game run smoothly on 100MHz, too -but I just wasted my time then. For instance, I took a whole week in making 2D tilemapping (+ lots of artwork), but it was taking lots of memory to look OK, then by accident I found out that 3D rendering actually is fast enough and looks better. And the only bottleneck is the cpu cache - I should make textures to fit nicely in there. Which will be solved nicely by my next idea:
I found out I should be using 4-bit color (with 8 palettes for each texture) instead of the current 8-bit with 32 global palettes. I use palettes just because I need shading(to look much better). Thus, I'll be more likely keeping palettes in cache :) . For sure it will all looks better, I wonder if it'll be faster too.
Anyway that shooter is very much still in initial development ^^" - today I have to remake my tools and engine to use 4-bit color. Then, finishing my level and event editors.
And finally - making as many meshes and general design as I can ^^".

I study a lot from PSX's design and games, and right now only the artwork and level design are problematic ^^" .
Culling and the like have been already implemented, and dropping 2000 objects to DrawMesh(), of which only 10 are visible, does not introduce any noticeable slowdown, so it won't be a problem.
I use two camera rays (I defined a ray as a structure of a position vector and a rotation vector) to render first the level, then render the enemy/friend airfighters. Thus, I can easily animate moving through the whole world in non-linear ways. For instance, if I want a battle to be fought while circling around some building - it will be done extremely easily :). (and I will save the bother of designing more buildings :> )

Music is essential in games, and sync-ing it with some timer-events can boost the user experience. This sync has been something I wanted to make for 3-4 years already, and now I have the chance - for being a musician too :) .

So, for now I've got everything under control. Once I set up one level of the game, and  it turns out good, I will have more people in my gamedev team :) .
Posted on 2005-04-30 07:41:43 by Ultrano

Have you considered using some kind of heightmapping for terrain generation?

Using these can dramatically cut down development time because "editing" the terrain geometry is performed by "painting" the bitmap from which height information is sourced.

It means you and/or your artists can worry more about making nice models and level designs..

Posted on 2005-05-01 06:51:46 by Homer
Yes, I thought a bit about it, but I find it easier just to subdivide a textured quad, and then use a magnet to form relief. And probably it will run faster. Also I don't want to code anymore on the engine - I need some game demo quickly, and the engine is ok as it is. Last night, for the latter reason I also decided to delay the moving to 4-bit palettes. I want transparent textures too, which is already implemented in the engine now - but it will take more code to make that possible for 4-bit ^^". My morale drops lower and lower if I don't see results, and thus I decided to immediately start building the game :) . I hope till tonight it will be possible to play a dynamically-generated level, to blast some enemy planes :> .
The first game should be just like a debute should be - with little financial and development investments to see if there's market for such games. Simple, OK-looking, but good enough to get customers :) . And good enough to lead to some deals with OEMs (right now, the QooL labs).
I was looking at some awesome games till now, and my morale was going down a bit, but when I revisited "1942" and the like, I started feeling much better. That game shows the raw basics, and finally it's up to my creativity to build on top of these basics :) . And also now I remember the ideas I had for "1942" that I've had for more than 6 years - before I started coding.

I miss the ObjVector and VarVector classes, and the "foreach" macro here a lot T_T . I've completed 7 "managers" so far, and around 5 more are to be done. And for each manager, I have to remake a new vector-manager. Later I'll miss classes with virtuals (for enemy and friends' AI and graphics) - function pointers are by default wrong when your app boots T_T . But I'll cope with that, though I'll lose a few more hours :) .

But otherwise, the game in its state looks promising and extendable, - I just need to code more extentions and complete the 5 extra managers.
A "manager" is actually an engine: explosions manager, 3D effects manager, bullet manager, code-effect manager (for animation of data), SFX manager, dynamic-music manager and so on...
Extentions are: types of bullets, enemies, explosions, effects ...
Posted on 2005-05-01 09:21:01 by Ultrano
Sounds like you are in "manager Hell" - something I can relate to :)

I performed a test for transparent materials today for HSM class actually.
I've discovered that the transparency information for MTL materials is what is stored in the Tf fields. There's three floats, I'd assumed they were "default color". They are alpha values, and all three seem to always have the same value -  RGB per-channel alpha? Anyway, I implemented a quick alpha blend of a textured object without a hitch.
What I need to do now is make this thing smarter.
I've not rendered objects of mixed opaque and transparent (translucent) materials yet, but I know when I want to that I have to do thiings in a certain order.
Rendering needs to be performed TWICE.
I must render all the opaque surfaces first, and then all the transparent materials second.
Materials should have been sorted so that all 100% opaque materials appear first.
This will cause my renderer to render those first.
We should note at load time which Material, if any, is the first of the transparent materials.
During rendering, when we find the first transparent material in an object, we should quit the render loop for that object. Render all the opaque surfaces of all visible objects.
Now the materials with alpha values need to be rendered. Render all the objects again, this time starting at the first transparent material.
We should disable depth testing for this second pass if we have not sorted them in view Z depth.
Now all surfaces will be rendered correctly (I think).
Just something to bear in mind for alpha transparency stuff :)
I fixed a small bug in the OBJ to HSM code regarding texture coordinates.
Vertex normals are still screwy, but seem to have no effect on textured objects even under lighting and with smooth shading, which I find peculiar - perhaps opengl can tell they are illegal somehow?
Posted on 2005-05-01 11:07:18 by Homer