Gfx Improvement Ideas / WZM Format proposals

[elio]

Ok i have two ideas:

1. Outsourcing Teamcolors

teamcolor outsourcing.png (10.32 KiB) Viewed 15978 times

to keep texture details, the color is blended with this formula http://docs.gimp.org/en/gimp-concepts-layer-modes.html "Grain merge"
E = I + M - 128

this would reduce much redundant work for me / artists

2. Event driven Animation
viewtopic.php?f=6&t=2044&st=0&sk=t&sd=a&start=15#p20045

these improvements so far are not very cpu intensive

3. Bump/Normal mapping
http://en.wikipedia.org/wiki/Normal_mapping
http://en.wikipedia.org/wiki/Bump_mapping
http://en.wikipedia.org/wiki/Parallax_mapping
This would hugely improve the graphics quality, but needs at least OpenGL 1.6 if not 2.0

i'm looking forward to alter the WZM format specification & tools so say what you're thinking about

[EvilGuru]

Dot3-bump mapping (aka, normal mapping) can be added without increasing the requirements significantly; http://www.paulsprojects.net/tutorials/ ... ebump.html achieves it with the following extensions:

• ARB_multitexture
• ARB_texture_cube_map
• ARB_texture_env_combine
• ARB_texture_env_dot3

The following OpenGL compatibility table: http://www.cs.ubc.ca/~xgranier/OpenGL/e ... cards.html lists all of the aforementioned extensions being available on a GeForce2 GTS and above.

Edit: confirmed support for these extensions on an Intel 945GM under Linux.

Regards, Freddie.

[Per]

Event-driven animation is on my TODO-list for WZM already.

Mask-based team-colours is something we could test. I have always thought that creating such masks is too hard, but maybe I am wrong. Would it be possible to somehow create such masks automatically for existing graphics, so that we can avoid having to support both kinds of team colours?

Bump mapping should not be so hard to add. We need a good test case to work on when implementing it, though. Preferably some existing texture where you can see the difference quite clearly. This could be added as an extension to the existing PIE format, even.

[elio]

Mask-based team-colours is something we could test. I have always thought that creating such masks is too hard, but maybe I am wrong. Would it be possible to somehow create such masks automatically for existing graphics, so that we can avoid having to support both kinds of team colours?

hmm, i would simply use the 'grey' teamcolour and blend the other colours. doing a mask isn't very hard. but the pie/wzm must use the right uv coordinates (the third = grey)

i am very happy to hear that bump mapping can be implemented

[Buginator]

Ok i have two ideas:

1. Outsourcing Teamcolors

teamcolor outsourcing.png

to keep texture details, the color is blended with this formula http://docs.gimp.org/en/gimp-concepts-layer-modes.html "Grain merge"
E = I + M - 128

This has been talked about before:
viewtopic.php?f=6&t=1104&start=75&st=0&sk=t&sd=a

Yep, we would need 2 textures, and the second texture would be grayscale and then you modulate it with the team color.
I guess the loading code can be made multitexturing, to simplify this.
We could also make a little utility that does this, and then just stick them in a texture page like we have now.

We could also use bump mapping + normal maps for the terrain, but this also needs multitexturing IMO.

[Kamaze]

Displacement mapping seems more interesting for Warzone. Adding geometrical details to near all objects without touching the pie models

[EvilGuru]

Displacement mapping seems more interesting for Warzone. Adding geometrical details to near all objects without touching the pie models

Needs geometry shaders. Displacement mapping adds geometry — bump mapping techniques do not.

Regards, Freddie.

[Kamaze]

Needs geometry shaders.

Vertex shader seems sufficient: http://ozone3d.net/tutorials/vertex_dis ... php#part_3

Displacement mapping adds geometry — bump mapping techniques do not.

For that reason i want it. Models could be very polished without much work.
Also the current volume shadows would show correct shadows then.

With (dot3)Bump-Mapping, all models still lock "blocky" excepting you're zooming in.

[EvilGuru]

That does not add any more geometry, just changes what is there. Nothing that a modeller can not do themselves in almost any modelling package. (Just deforming the vertices by a specific amount.)

Regards, Freddie.

[Deus Siddis]

Way to go elio, you seem to be leading this project's graphics evolution down a good road.

There are just a couple more things that really have to be added to the list though:

1) Keyframe Animation (essentially just linear interpolation between vertex frames in warzone's engine)

2) Realtime Lighting (this is a prerequisite to normal mapping, otherwise it is useless for in-game rendering).

Bump mapping should not be so hard to add. We need a good test case to work on when implementing it, though. Preferably some existing texture where you can see the difference quite clearly.

I have already created just that for the new missile pod and twin missile pod. I used a high res model and a bump map to create a normal map and then baked the lighting with the normal map applied to create an 'ordinary' texture. But I did not throw away the normal map or even the bump map, so everything is there for you to play with.

I just couldn't find a method that worked for getting them into a working PIE format given my total lack of coding knowledge, so I can not help you there, I'm afraid.

But let me know if you still want the model in a more standard format that blender can export to easily and you've got it.

We could also use bump mapping + normal maps for the terrain, but this also needs multitexturing IMO.

I don't understand, why would you need both?

That does not add any more geometry, just changes what is there. Nothing that a modeller can not do themselves in almost any modelling package. (Just deforming the vertices by a specific amount.)

Very true. In fact, displacement mapping usually doesn't offer good looking results unless you have a very, very dense mesh. For a project that worries about upping the minimum hardware requirements on a 10 year old game, using displacement mapping would be kind of an odd choice. :-S

[Per]

There are just a couple more things that really have to be added to the list though:

1) Keyframe Animation (essentially just linear interpolation between vertex frames in warzone's engine)

You do not want keyframe animation (at least not in-game, it would be a different matter for FMV sequences). The interpolation between frames is horrible for a game like this, unless we stored way too much data for each object. Eventually, we would want to go over to real bone-based animation and physics. Although we are a long way from there at the moment, that is the path we should go.

I have already created just that for the new missile pod and twin missile pod. I used a high res model and a bump map to create a normal map and then baked the lighting with the normal map applied to create an 'ordinary' texture. But I did not throw away the normal map or even the bump map, so everything is there for you to play with.

I just couldn't find a method that worked for getting them into a working PIE format given my total lack of coding knowledge, so I can not help you there, I'm afraid.

But let me know if you still want the model in a more standard format that blender can export to easily and you've got it.

Sure. If you could post the model as PIE, OBJ or 3DS, I can have a first look at it and see if it can be used as a test case.

[Deus Siddis]

You do not want keyframe animation (at least not in-game, it would be a different matter for FMV sequences). The interpolation between frames is horrible for a game like this, unless we stored way too much data for each object. Eventually, we would want to go over to real bone-based animation and physics. Although we are a long way from there at the moment, that is the path we should go.

Fair enough. Out of curiousity, are there any engine changes that need to take place as a prerequisite to someone working on creating support of bone animations and an advanced physics engine?

Also forgot to mention, specularity mapping support. That should actually be a priority before normal mapping.

Eventually, LOD support would be really, really useful for a game like this as well.

Sure. If you could post the model as PIE, OBJ or 3DS, I can have a first look at it and see if it can be used as a test case.

Okay then, files attached. Note that I didn't triangulate the models, wasn't sure if I was supposed to. Since this is for testing, I also sent the extra large 512 maps of everything. Note that missile_pod is supposed to be an in game texture for warzone with the current graphics engine, normal and light bakes and all. While missile_pod_texture is what you would want to use in conjuction with the normal mapping. There is no team coloring in the images, so we can also use this to test elio's teamcolor mask idea, I would just need to create the mask.

If you have any problems, let me know all that needs to change and I'll modify and upload them again.

[Per]

Fair enough. Out of curiousity, are there any engine changes that need to take place as a prerequisite to someone working on creating support of bone animations and an advanced physics engine?

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.

Also forgot to mention, specularity mapping support. That should actually be a priority before normal mapping.

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

Okay then, files attached. Note that I didn't triangulate the models, wasn't sure if I was supposed to. Since this is for testing, I also sent the extra large 512 maps of everything. Note that missile_pod is supposed to be an in game texture for warzone with the current graphics engine, normal and light bakes and all. While missile_pod_texture is what you would want to use in conjuction with the normal mapping. There is no team coloring in the images, so we can also use this to test elio's teamcolor mask idea, I would just need to create the mask.

If you have any problems, let me know all that needs to change and I'll modify and upload them again.

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.

[EvilGuru]

Also forgot to mention, specularity mapping support. That should actually be a priority before normal mapping.

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

Specularity maps (also known as 'gloss maps') is another per-pixel lighting effect whereby each pixel has its own specularity. It can be pulled off with the following OpenGL extensions GL_ARB_multitexture and GL_ARB_texture_env_add. (Or, a fragment/vertex shader pair, of course.)

ATI provide a nice demo of it in their ATI OpenGL samples: http://developer.amd.com/gpu/archive/Ra ... fault.aspx

The .exe provided in the download works fine under Wine (just tested it) — although in order to get it to run one must grab a copy of glut32.dll and place it into the directory.

Regards, Freddie.

[kage]

I do like the WZM format proposal. Except for a few naming conventions, I think it's a positive push. However, now that I've thought about it more, I believe that making a clean break and phasing in a binary format, since, besides something like XML/YAML, there's a limit to how far you can take human-readable formats, and as we progress forward with a textual model format, in order to add more visual features, we will either have to frequently revise the model format (many times in backwards-incompatible ways), or depend on external files (like defining additional turret locations outside of the PIE file). Neither of these solutions are very good, yet with a binary format that has a feature set that is way beyond what the engine can currently handle has many benefits:

• We need not worry about hitting a format barrier for the majority of graphical improvements
• We can use an existing API -- less code to write (and model API's tend not to be intrusive)
• Backwards/Forwards compatibility may be handled gracefully by the API

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.

At the same time, I'm very reluctant to endorse any previous suggestions of using something like .3ds as the model format (potential copywrite issues aside), since being a "document format", it carries along with it a lot of baggage -- many data structures that will never have any use in game, but which are difficult or infeasible to strip out of the file, often including per-project toolbar settings, undo/redo, etc. In essence, using .3ds, or the maya format, or rhino (or whatnot) would be like using odt/doc for our message strings, or gimp's xcf for textures.