Gfx Improvement Ideas / WZM Format proposals

Improving the artwork in Warzone2100 - not for mod discussions
elio
Regular
Regular
Posts: 508
Joined: 09 Jun 2007, 22:11

Gfx Improvement Ideas / WZM Format proposals

Post by elio » 13 Sep 2008, 11:57

Ok i have two ideas:

1. Outsourcing Teamcolors
teamcolor outsourcing.png
teamcolor outsourcing.png (10.32 KiB) Viewed 11342 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
Regular
Regular
Posts: 615
Joined: 23 Jun 2007, 22:41

Re: Gfx Improvement Ideas / WZM Format proposals

Post by EvilGuru » 13 Sep 2008, 12:46

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
Warzone 2100 Team Member
Warzone 2100 Team Member
Posts: 3775
Joined: 03 Aug 2006, 19:39

Re: Gfx Improvement Ideas / WZM Format proposals

Post by Per » 13 Sep 2008, 17:19

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
Regular
Regular
Posts: 508
Joined: 09 Jun 2007, 22:11

Re: Gfx Improvement Ideas / WZM Format proposals

Post by elio » 13 Sep 2008, 17:41

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 :D

User avatar
Buginator
Professional
Professional
Posts: 3285
Joined: 04 Nov 2007, 02:20

Re: Gfx Improvement Ideas / WZM Format proposals

Post by Buginator » 14 Sep 2008, 06:48

elio wrote: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
Regular
Regular
Posts: 1017
Joined: 30 Jul 2006, 15:23

Re: Gfx Improvement Ideas / WZM Format proposals

Post by Kamaze » 14 Sep 2008, 13:13

Displacement mapping seems more interesting for Warzone. Adding geometrical details to near all objects without touching the pie models :)
We all have the same heaven, but not the same horizon.

EvilGuru
Regular
Regular
Posts: 615
Joined: 23 Jun 2007, 22:41

Re: Gfx Improvement Ideas / WZM Format proposals

Post by EvilGuru » 14 Sep 2008, 13:34

Kamaze wrote: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
Regular
Regular
Posts: 1017
Joined: 30 Jul 2006, 15:23

Re: Gfx Improvement Ideas / WZM Format proposals

Post by Kamaze » 14 Sep 2008, 13:50

EvilGuru wrote:Needs geometry shaders.
Vertex shader seems sufficient: http://ozone3d.net/tutorials/vertex_dis ... php#part_3
EvilGuru wrote: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.
We all have the same heaven, but not the same horizon.

EvilGuru
Regular
Regular
Posts: 615
Joined: 23 Jun 2007, 22:41

Re: Gfx Improvement Ideas / WZM Format proposals

Post by EvilGuru » 14 Sep 2008, 14:44

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
Trained
Trained
Posts: 235
Joined: 18 Aug 2007, 06:58

Re: Gfx Improvement Ideas / WZM Format proposals

Post by Deus Siddis » 14 Sep 2008, 22:44

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).
Per wrote: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. :)
Buginator wrote: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?
EvilGuru wrote: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
Warzone 2100 Team Member
Warzone 2100 Team Member
Posts: 3775
Joined: 03 Aug 2006, 19:39

Re: Gfx Improvement Ideas / WZM Format proposals

Post by Per » 15 Sep 2008, 18:08

Deus Siddis wrote: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.
Deus Siddis wrote: 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
Trained
Trained
Posts: 235
Joined: 18 Aug 2007, 06:58

Re: Gfx Improvement Ideas / WZM Format proposals

Post by Deus Siddis » 16 Sep 2008, 17:31

Per wrote: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.
Attachments
missile pod test model.zip
(417.02 KiB) Downloaded 412 times

Per
Warzone 2100 Team Member
Warzone 2100 Team Member
Posts: 3775
Joined: 03 Aug 2006, 19:39

Re: Gfx Improvement Ideas / WZM Format proposals

Post by Per » 16 Sep 2008, 18:08

Deus Siddis wrote: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.
Deus Siddis wrote: Also forgot to mention, specularity mapping support. That should actually be a priority before normal mapping.
You mean like https://gna.org/patch/?867?
Deus Siddis wrote: 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
Regular
Regular
Posts: 615
Joined: 23 Jun 2007, 22:41

Re: Gfx Improvement Ideas / WZM Format proposals

Post by EvilGuru » 16 Sep 2008, 18:47

Per wrote:
Deus Siddis wrote: 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.

User avatar
kage
Regular
Regular
Posts: 751
Joined: 05 Dec 2006, 21:45

Re: Gfx Improvement Ideas / WZM Format proposals

Post by kage » 17 Sep 2008, 04:03

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.

Post Reply