Models by MaNGusT (AR)

[MaNGusT]

If I remember correctly, wmit calculates tangents & bitangents using the standardized mikktspace algorithm. It doesn't, however, calculate normals, but imports them with the models (so blender users need to check the "include normals" option when exporting obj)

yeah.. tangent-space normal mapping requires precalculated normals, right.

Per, MINMAX_TSCEN is used for object collisions. Not in wzm branches this parameter was calculated for each load(wz's load or the load of a map, don't know), in wzm branch it stores in wzm model, another speed optimization. It is a min&max of aabb points(x,y,z for each) and the center of the oblate(compressed?!) sphere.
This is what I've understood from the logs.

TC is implemented the same way how it's done in wz.

EDIT: I also want to recall you to split the gfx stuff from the stats.
EDIT: here locates shader for the latest wmit and for the latest build of the wzm branch.

[MaNGusT]

added viper model to AR's repo without normal & specular maps.

[Per]

Now that I've changed the Warzone renderer to use VBOs, adding support for WZM loading would be rather easy, I think. However, there are some changes I'd like to make to the WZM format first. Would that be a problem for any reason? I'll change WMIT to match. But I hope nobody has converted their entire model collection to its current WZM format, or anything like that...

Regarding tangents, is there any reason why we can't write a converter program for PIE -> WZM that calculates decent normals for each vertex based on neighbouring vertices, and then calculating tangents based on those? Is there something that would make this a waste of time?

[MaNGusT]

Regarding tangents, is there any reason why we can't write a converter program for PIE -> WZM that calculates decent normals for each vertex based on neighbouring vertices, and then calculating tangents based on those? Is there something that would make this a waste of time?

If I remember right, then why WMIT imports normals exactly from obj that's because the normals that were created in a 3d editor are correct than an auto-generated normals. I mean that they have right direction.
EDIT: while wz's normals are flat. I jsut don't understand, how do you want to generate right normals from nothing. Also, normals' direction bases on smooth groups.
I often use 1 smooth group on entire model but there are situations where I need to set up 2 or 3.

Would that be a problem for any reason?

it wouldn't if changes will not brake important things like tangent-space normal mapping and specular mapping. I mean its correct mapping. We spent many hours debugging mirrored uv:s dispay.

[Jorzi]

The problem with generating vertex normals for pie models is that they probably don't have any kind of smoothing groups (i.e. split edges) which means they'll be shaded like ugly blobs. Not sure but the smartest solution for converting from .pie is to continue using flat shading, possibly by having unique vertices for each triangle.

As for generating normals it's not very hard actually, but since they can be interpolated in multiple ways, I guess they might not look just like in your preferred modeling program. This causes some normal maps to look quite ugly.

[Per]

I know nothing about 3D modeling. So let me ask what is probably a dumb question: If I wrote a program to export all current PIE models to a portable format like OBJ, then imported each model into a top-of-the-line, expensive 3D modeling program, would there be a button that said something like 'generate normals' that would create nice normals? Then I could export the model back to OBJ and convert it to WZM, and that way get decent normals for the existing models... (Bonus dumb question - could not such a 3d modeling program also generate tangents?)

[MaNGusT]

As for generating normals it's not very hard actually, but since they can be interpolated in multiple ways, I guess they might not look just like in your preferred modeling program. This causes some normal maps to look quite ugly.

well, at least we chose a universal model format for exporting from our preferred 3d software and this makes wmit obj importer quite universal too.
Also, as I posted somewhere on the forum, there is another interesting universal format. It's called COLLADA. The main advantages are: xml structure, bone animation support, connectors support(as dummy objects) and it's known by most popular 3d modelling software.

If I wrote a program to export all current PIE models to a portable format like OBJ, then imported each model into a top-of-the-line, expensive 3D modeling program, would there be a button that said something like 'generate normals' that would create nice normals?

Might work. Don't know how to do this in blender, but in 3dsmax you should just apply at least 1 smooth group on entire model, then you will be able to export a model back into obj with proper normals. But for the current wz's models you don't need to that, as Jorzi said:

The problem with generating vertex normals for pie models is that they probably don't have any kind of smoothing groups (i.e. split edges) which means they'll be shaded like ugly blobs.

because they have too many sharp edges on model, the old models are just cubes and each side of the cube should have its own smooth group i.e. divided at the edge.

could not such a 3d modeling program also generate tangents?)

3d software generate the all values we do ever need, but external file formats(obj) don't save all the information.
3ds format saves even less than obj, that's why it was deleted from wmit.

[Jorzi]

A quick image to illustrate the concept of normals.

Current wz trunk uses flat shading, while wzm uses smooth shading with vertex normals. "Smoothing groups" require no special shading features, but they only make a difference with smooth shading. In fact, they are only a modeling tool to allow us to treat degenerate vertices as one vertex.

[MaNGusT]

Jorzi, you're almost right, except one thing. Some time ago I've found a plugin for the 3dsmax that enables use of one smooth group on all types of models. So the cube with 1 sm and this plugin will look ok only with apllied normals map.
Just for the record.

[Jorzi]

Yes, but if I understand you correctly, the normalmap will be very colorful to compensate for the wildly varying normals of the underlying mesh, which makes it less editable/reusable, almost like object space.

[MaNGusT]

Yes, but if I understand you correctly, the normalmap will be very colorful to compensate for the wildly varying normals of the underlying mesh.

well, yeah.. but I already use same type of normal map for the viper and it works fine.
editing also works very well, I just set the overlay mode for the layer with a custom created details(created via plugins).

[i-NoD]

As for i-nod's branch... It is interesting, but it seems to need some work before it can be merged, and i-nod as far as I can tell has not expressed any interest in doing this or having it merged.

Hi,

Well... considering how time-consuming (partly because of no prior knowledge) for me and AR team was that WZM experience with basic functionality and shader changes for it, it was clear for me: i should infuse iIMDShape structures with Ogre3D (with OpegGl backend due to shaders and terrain renderer) and outsourcing all that hard gfx work in half the time i've spent on WZM, giving a sky-high punch to other wz2100 gfx parts for free: animation, GUI, particles...

[MaNGusT]

Ogre3D has its own file format for models, called *.mesh. And there are quite few exporters/importers that support it.
EDIT:
Well, seems that Ogre has free for non-commercial use plugins for 3dsmax and blender.

[Per]

Well... considering how time-consuming (partly because of no prior knowledge) for me and AR team was that WZM experience with basic functionality and shader changes for it, it was clear for me: i should infuse iIMDShape structures with Ogre3D (with OpegGl backend due to shaders and terrain renderer) and outsourcing all that hard gfx work in half the time i've spent on WZM, giving a sky-high punch to other wz2100 gfx parts for free: animation, GUI, particles...

If you could just document a few of the things you did on WZM, then perhaps that work would not be wasted, and we can get WZM models into the game with just a tiny bit more work.

MINMAX_TSCEN - what does it mean, and what does its values mean in relation to the standard iIMDShape minmax values (ie are they interchangeable)?

MATERIALS - why was this put in the global section instead of under the MESH part? Shouldn't each mesh be able to have its own materials?

TEAMCOLOURS directive, is this needed anymore, when there is a separate TCMASK directive?

[MaNGusT]

MATERIALS - why was this put in the global section instead of under the MESH part? Shouldn't each mesh be able to have its own materials?

No need to, since everything is controlled by textures.(except emission light params.)
Well, there are no situations where we need to set up different light params for each mesh of a model. That was my wish, so if you think it isn't right, you can always move it back to the mesh section.

Following your logic, each mesh could have its own textures too. Could be usable to create custom multi-mesh effects with texture animation, though.