Gfx Improvement Ideas / WZM Format proposals

[Deus Siddis]

I do not really know, but I suspect the best answer is ... "lots". For advanced physics we better use an existing physics library, and that would require extensive rewriting of code. Not that this wouldn't be a good idea, but I do not think it is exactly on the agenda right now.

Interesting. But why go with an existing physics engine if you wouldn't want to go with an existing graphics engine? Is a physics engine something that 'ties' into the code base in fewer places maybe?

You mean like https://gna.org/patch/?867?

If by that you mean what EvilGuru described and was linking to, then awesome work, I had no idea WZ's graphics engine had been upgraded to something so advanced!

Do you want me to resend you diffuse and specular textures for the test model then? The specular will be good for the metal parts (essentially, the parts that are not to be painted with a team color).

I am afraid you will need to convert them into triangle models for use with WZM and testing of future improvements. I have code to tessellate non-triangle PIE models but not for other formats, where I suppose it is best to do this in the original 3D modelling program anyway. A mask for testing the team colour idea would be nice, too.

Okay, I'll do those. Let me know if you want the specular texture too.

[kage]

Interesting. But why go with an existing physics engine if you wouldn't want to go with an existing graphics engine? Is a physics engine something that 'ties' into the code base in fewer places maybe?

Physics engines do tend to be less invasive, yeah. Comprehensive graphics engines have to deal with a wide range of graphics cards (and rendering capabilities), since few people in the open source world would use an engine that only works on this year's hardware, while physics processing (generally, right now) is done on the CPU (and thus it's not a matter of what it "can" and "can't" do, but just a matter of how fast). Also, graphics engines tend to bundle with a sound engine, at which point they might as well bundle with an event system (at this point they might as well steal the main game loop, which they do). That's not to say that 3d engines don't often also bundle with physics engines, but for right now, it seems like you can usually pick and choose your physics stuff, though the whole situation might change if dedicated physics hardware becomes popular.

[EvilGuru]

The perceived benefits of a textual model format, including human readability and ease of reconstruction don't add as much value to a format as I once thought -- points are implicitly numbered, and thus deleting one line in the POINTS section destroys the whole model in a difficult-to-recover way. Also, because of implicit numbering, and space-seperated-values style polygons, hand-editing/tweaking anything with more that 30 polygons is an exercise in tedium.

Let us not forget that one of the big advantages with text-based formats is that they can be used meaningfully in a VCS, like subversion.

It does not make sense to diff two binary files — the output is of no use. Text files on the other hand can be diff'ed and compared. The formats are also easier to work with for the most part, in that if a file is 'broken' one can hand-edit it back into shape. Lets not forget also that the OBJ format (commonly used for exporting models) is itself a text format.

Regards, Freddie,

[kage]

The perceived benefits of a textual model format, including human readability and ease of reconstruction don't add as much value to a format as I once thought -- points are implicitly numbered, and thus deleting one line in the POINTS section destroys the whole model in a difficult-to-recover way. Also, because of implicit numbering, and space-seperated-values style polygons, hand-editing/tweaking anything with more that 30 polygons is an exercise in tedium.

Let us not forget that one of the big advantages with text-based formats is that they can be used meaningfully in a VCS, like subversion.

It does not make sense to diff two binary files — the output is of no use. Text files on the other hand can be diff'ed and compared. The formats are also easier to work with for the most part, in that if a file is 'broken' one can hand-edit it back into shape. Lets not forget also that the OBJ format (commonly used for exporting models) is itself a text format.

Regards, Freddie,

those are good points, especially regarding the OBJ format, though that would be partially mitigated by artists independently including internally-versioning model project files in the source distribution, while using a trimmed down binary format actual gameplay. We already use binary image files as opposed to something like PNM (though granted, PCX was being used from the start), and while we could also use an internally versioning image format for inclusion with the source (while still using PNG for gameplay), that might just be an exercise in tedium. At any rate, do we still consider the advantages of a textual format in a VCS (and other advantages) good enough to keep even though it means graphical improvements must either be held back, or must be added via a bundle of extra files?

Speaking of OBJ, as I'm reviewing it, it looks quite featureful -- material support, curves, et al. And if performance does become an issue, it goes in hand with the Mod format, which is the binary equivalent (hopefully which can be used through the same API).

[Deus Siddis]

Per, I have attached the triangulated models and the mask to this post. Let me know if anything else needs to be done or modified further.

Also, it just occured to me that the texture I sent you before is all bare metal anyway so try using it as the specular texture and put the team color 'paint' in diffuse.

[EvilGuru]

At any rate, do we still consider the advantages of a textual format in a VCS (and other advantages) good enough to keep even though it means graphical improvements must either be held back, or must be added via a bundle of extra files?

I can not see how this situation would ever arise — whereby a binary format would allow for graphical enhancements while a textual one would not.

Speaking of OBJ, as I'm reviewing it, it looks quite featureful -- material support, curves, et al. And if performance does become an issue, it goes in hand with the Mod format, which is the binary equivalent (hopefully which can be used through the same API).

There is no performance issue. We only parse model files once — when the game is loaded/started — so the performance benefit would only show itself when loading a game. Furthermore I doubt that this parsing is even measurable when you compare it with the de-compression of a PNG image (textures) and uploading it to the graphics card (where it is compressed again). Parsing the campaign/skirmish scripts on-the-fly is also several orders of magnitude more complex.

Parsing binary files is also more complex, you've got to deal with endian issues, integer/float size issues — all of which make writing parses in higher level languages more difficult.

Warzone requires some extra information in the model files (as you no doubt know) that makes the use of an off-the-shelf model format impractical.

Regards, Freddie.

[kage]

I can not see how this situation would ever arise — whereby a binary format would allow for graphical enhancements while a textual one would not.

Ah. I meant to point out that binary formats tend to have more capabilities as the situation is right now, not the theoretical capabilities of either (to which there is of course no difference). It's not a very good argument, but I was trying to hint that something like the quake 3 model format probably covers all our needs, and there are a plethora of supporting API's, which when open source, tend to not have endian issues, etc. As for MOD vs OBJ related to performance, I meant in case OBJ was noticably slow to parse compared to PIE

Have to run, but I'll post more (unwise and easily refutable) comments on this later

[Buginator]

Is the quake3 format OK to use in a GPL project, or will someone start frothing at the mouth?

The model format needs to support mount points (for weapons/ sensors), shadow flag, perhaps other flags as well, (translucent, or whatever else), some kind of animation support, and be easy to create & modify.

So far, there is no model format that fits in with what wz uses, and wzm would be the first step in the process.
We just need to make sure that the converting utilities work correctly, and are easy to use.

[Deus Siddis]

Well if we are going down the road of skeletal animations like Per said, then you need something with bones. None of the old quake formats support bones from what I understand.

BTW, is it true that for a model to work in warzone, no two triangles can ever intersect? If that is the case then making some geometric intersections not an engine-killer would be a nice feature down the pipe.

[elio]

don't forget event driven animation (factory opens gate and tank drives out for example) imho a custom format is necessary

[kage]

BTW, is it true that for a model to work in warzone, no two triangles can ever intersect? If that is the case then making some geometric intersections not an engine-killer would be a nice feature down the pipe.

That is not true. Just about every single effects model (like lasers, projectiles, etc) Is just a set of two intersecting, perpendicular rectangles.

Yeah, I suppose the quake model formats are antiquated now.

The model format needs to support mount points (for weapons/ sensors), shadow flag, perhaps other flags as well, (translucent, or whatever else), some kind of animation support, and be easy to create & modify.

PIE certainly doesn't cover some of those, and/or barely covers them. We have to accept that format compatibility with existing software is going to be a big plus -- we can see quite clearly that artists will leave if they have to wait for special software to be developed. In other words, custom formats are fine, but if we want people to find it a practically useful change, we need to have some kind of free software that will work with it before we put it in the engine.

At least for your requirements, Buginator, luckily most major 3D editors (Maya, Blender, 3DS, etc) support each of those, or something conceptually close enough to be usable.

I think mask-based team colors, as elio suggested, are also something we should consider a definite requirement.

[Deus Siddis]

So Per, will the test model work or do you need any further alterations?

[Per]

I need to find some time to really look into it.

[Deus Siddis]

I need to find some time to really look into it.

Okay no problem then. I was mostly concerned that you didn't see the updated version posted earlier or that you were having some kind of trouble with it.

[Deus Siddis]

Per, I made some improvements to the normal map I had posted with the other files earlier and attached it to this post. There are two versions of this improved normal map, one that is sharper and one that is smoother. Use either one of these you like, just don't use the previously posted one, it doesn't have the bump map detail baked into it.