by date
Recoloring DTS shapes
Recoloring DTS shapes
| Name: | Geom |  |
|---|---|---|
| Date Posted: | Feb 14, 2007 | |
| Rating: |  4.7 out of 5 | |
| Public: | YES | |
| Comments: | YES | |
| RSS Feed: |  or Subscribe with  . | |
| Profile Page: | View profile page for Geom |
Blog post
I've run into an interesting problem while developing Orcs vs. Martians. I need to recolor my RTS units and buildings, so that they show the color of the player that owns them. But, Torque doesn't have any native ability to recolor DTS shapes at run-time. At first, I thought about manually recoloring the DTSs' material files in a paint program. But since OVM supports up to 9 players, that'd mean recoloring every DTS shape with nine different colors. That seems like too much work, and besides I might want to tweak the player colors later and then I'd have to do that work all over again. So, I've come up with a programmatic way to recolor DTSs at run-time. If there's interest, I can post the code for this feature as a resource.
The basic idea is that you tell Torque the rectangular region in the DTS's material file (.png, .jpg, whatever) that you want to recolor. E.g. to recolor the Torque Orc's "shoulder pad", the region would be this rectangle:
You can also say to recolor only certain colors in on the color wheel. This is somewhat hard to describe (and not quite implemented yet), but you basically specify the range of colors you want to recolor as an arc on the color wheel. It would be delimited by a "low" color and a "high" color. Only colors inside the arc get recolored.
Then you specify your new color. All the recolor specs go into a datablock, like this:
In order to preserve bright-and-dark variations in the original material, the algorithm modulates the brightness of your new color pixel-by-pixel.
Here's the current effect in Orcs vs. Martians:
Viola! Team colors in an RTS. Now players can tell who's on whose team. The game definitely looks and plays better for it.
The basic idea is that you tell Torque the rectangular region in the DTS's material file (.png, .jpg, whatever) that you want to recolor. E.g. to recolor the Torque Orc's "shoulder pad", the region would be this rectangle:
You can also say to recolor only certain colors in on the color wheel. This is somewhat hard to describe (and not quite implemented yet), but you basically specify the range of colors you want to recolor as an arc on the color wheel. It would be delimited by a "low" color and a "high" color. Only colors inside the arc get recolored.
Then you specify your new color. All the recolor specs go into a datablock, like this:
datablock RTSUnitData(OrcAxeman)
{
shapeFile = "~/data/shapes/units/orc/orc.dts";
// ...etc...
recolorRect = "256 280 92 100";
recolorLow = "98 46 255";
recolorHigh = "157 199 255";
recolorNew = "255 0 0"; // new color is red!
};
In order to preserve bright-and-dark variations in the original material, the algorithm modulates the brightness of your new color pixel-by-pixel.
Here's the current effect in Orcs vs. Martians:
Viola! Team colors in an RTS. Now players can tell who's on whose team. The game definitely looks and plays better for it.
Recent Blog Posts
| List: | 10/04/08 - RTS game features and when to tie a bow 01/02/08 - Old fonts, new fonts 11/29/07 - Tab Control WIP 11/11/07 - OVM Beta1 test! 07/11/07 - Orcs vs. Martians 05/31/07 - work on programmatic DTS billboards 02/14/07 - Recoloring DTS shapes 01/24/07 - Orcs vs. Martians alpha |
|---|
Submit your own resources!| Tim Heldna (Feb 14, 2007 at 01:29 GMT) |
Quote:
The basic idea is that you tell Torque the rectangular region in the DTS's material file
How exactly is this done? Is it a flexible system, so that if one had differing player textures isolating regions wouldn't be a hassle?
Why not store alpha information in the texture to determine regions (like you can with environment mapping)?
| Geom (Feb 14, 2007 at 02:20 GMT) |
I suppose that could be done, too, if it doesn't interfere with other ways that Torque uses the alpha channel.
| Orion Elenzil (Feb 14, 2007 at 02:27 GMT) |
that's pretty cool.
the alpha-channel idea is neat.
you could have up to 256 different recolor families.
| Geom (Feb 14, 2007 at 02:42 GMT) |
To save memory, if you have two datablocks that use the same shapeFile and the same recolor specs, only one new texture is generated. The two datablocks share it.
| Todd Pickens (Feb 14, 2007 at 02:54 GMT) |
Cool stuff.
By the way, have you done much work with the camera controls for the game? I ask for two reasons. One being that if you limit the view of the camera to some range of "top down" style, then it is easy to insure a perfect sort of alpha objects for the environment, like tree foliage and such. And the second reason is that having worked on a number of 3d rts titles, I was quickly converted from the "free roaming" camera school of thought to a "limited range of manipulation" for the camera.
Limiting the degree to which a player can pitch and rotate the camera, reduces a big ranges of issue with game play and design.
Of course, having a fully maneuverable camera makes for a good "screen shot mode".
| Geom (Feb 14, 2007 at 03:31 GMT) |
Thanks for the advice. I allow the camera to be as low as about a meter off the ground. I've never noticed any rendering issues with DTS's -- until just now, when I was looking for it! Lo and behold, some tree branches do appear to be incorrectly rendered in front of their leaves, when the camera is that low. Interesting.
So you're saying that render order is only guaranteed to be correct, when the cam is above the trees?
Thanks for the info. I'm not familiar with the nuances of DTS shapes - although I'm learning more as I dig through the source code. DTSs are complex beasts, to say the least.
| Todd Pickens (Feb 14, 2007 at 04:14 GMT) |
Without getting into heavy detail here, the way TGE works, if you know the general view the player will have in game, the artist can construct the objects to sort correctly in almost all cases.
There are things like the SORT command that can allow you to correct most alpha sorting problems, but it should only be used on very simple shapes and only when absolutely necessary.
I was still learning the way all of that worked when I did the RTS Environment pack, and did make a couple of mistakes here an there, but mostly not noticeable. Those will be addressed with a free update for the content pack I am working on.
Any way, the real point was that as a developer, its easy to lose perspective on the game play mechanics, because you are intimately familiar with every aspect. My single biggest issue with most games is the camera movement, or camera control.
My experience taught me that although 3D RTS games can be visually very nice looking, the "3D" does not necessarily add to the quality of play, and can actually detract from it, and often does.
I have found that simplifying the camera controls allows the player to focus on the game play rather than on fighting with the camera. If you plan a specific range of movement for the camera and limit it to that, then it also allows the environment artist and level designer to develop around the cameras range of movement and play to its strengths.
As an environment artist and designer, I found that limiting the camera allowed me to greatly refine the levels and eliminate more "potential problems" with the map design, like units getting stuck behind things while moving around in the environment.
If for example, the camera can't rotate, but can pitch up and down a bit and can zoom in and out a bit, then the artist can actually build the collision for and object (say a building for example) to make it Impossible for a unit to walk behind a structure and out of view.
There are a wide range of approaches and available solutions. As is always the case with game development, finding the one that best serves your needs is the trick.
This is way to involved for me to write up here at the moment, but I can explain some of the advantages and disadvantages in detail if you like.
Email me and I will take the time to go into detail. Or we can arrange a phone chat.
On the other hand, if I am just stating the obvious, please ignore me :P I don't know what you experience in this area is.
| Ulf Ackermann (Feb 14, 2007 at 08:23 GMT) Resource Rating: 4 |
| Geom (Feb 15, 2007 at 01:27 GMT) |
that idea about making the space immediately behind a building be impassible, is a really clever idea! I'm going to have to mull that over -- that might benefit Orcs vs. Martians too. You're not stating the obvious, I would never have thought of that.
I'm not entirely gung-ho about 3-D and RTS's either. (this old thread on indiegamer touched on that). What do think ideal camera control should be? Just elevation (or zoom) + pitch, but no rotation around the z-axis? We can discuss via PM if you want, but I figure others GG'ers may be interested in this too.
Another camera trick I've been considering is to do what Empire Earth 2 does, have the mouse wheel control both elevation + pitch simultaneously. At high elevations, you automatically look straight down; at low elevations you look nearly horizontal. It keeps things simple for the user, though sometimes it bugs me, because I can't see the whole landscape from a high elevation.
BTW I didn't mean to rag on the tree in the RTS pack, I doubt I would have ever noticed the sorting issue if you hadn't mentioned it (and even knowing about it, it's still hard to spot).
@Ulf
thanks! I hadn't thought of selling this stuff, but I'd like to put out one or two free resources in the near future. Maybe this recoloring code, and my pathfinding code. I've benefited quite a bit from resources on this site, so I'd like to contribute back. But I probably won't do more than a few resources right now, because until Orcs vs. Martians get released, I won't have any income :(
Edit: fixed link.
Edited on Feb 15, 2007 01:28 GMT
| Todd Pickens (Feb 15, 2007 at 02:10 GMT) |
Rag away, I wasn't sweating it at all. There are definitely some objects that need to be reworked for the content pack. :O)
The camera zoom/elevation/pitch thing you are referring to is commonly called a "hook zoom". It "can" be a good thing, but again depends on whether it serves the needs of you particular game design. Its was originally introduced to RTS games to optimize performance. With the camera looking more directly down when at a high elevation, it reduces the amount of rendered.
Regarding the camera limitations, my personal preference...and there are exceptions depending on the particular RTS style and design, is to first rotate the camera at 45 degrees to the geometry grid of the terrain. Second, counter rotate the mini map so that when moving the camera "north" it corresponds to the corner of terrain geometry. (this is basically what you see in The Age of Empires games). It is actually a throw back to 2d games (ala the original AOE), but has benefits that can be capitalized on in 3d games.
Third, I would restrict the camera controls to movement, zoom, and pitch. No rotation allowed. That may sound crazy, "Whats the point of it being 3D if you can rotate around an object"...3D adds dimension to the environment. Rotating around an object is rarely a useful feature in actual game play, and the need to do so is usually a result of something getting lost or stuck behind a structure or terrain feature.
The degree of zoom/pitch/elevation would depend on the game and the play style. I personally have found that once you are actually playing an RTS, you rarely have time to be screwing with the camera and generally need to see as much of the play field as possible at any one time. Again, that depends on the fundamental nature of the game. A non combative RTS type game would be less inclined to require every possible competitive edge for the gamer, so a slower pace with closer zoom could be appropriate.
It looks like your game is standard "kill the other guy" format, so the player is going to want all the visual information they can get. This means they will probably zoom the camera out as far as is possible and still allows them to clearly identify the units on the map. Unless the design of the map requires them to rotate the camera, they will probably pick a rotation that they like and never touch it again.
If we say that looking straight down is 180 degrees and looking straight ahead is 90 and 0 its looking straight up, then I would limit the pitch to something above 9o, and limit the zoom to a level above the terrain exceeding the tallest structure on your map, this will prevent the camera from colliding with the structure in any way, and will also allow for the objects to be developed with that "perfect alpha sorting" I was talking about.
Whew! typing bad, hand needs rest.
| Geom (Feb 15, 2007 at 23:10 GMT) |
| Todd Pickens (Feb 15, 2007 at 23:28 GMT) |
I hate it when that happens.
| Geom (Feb 16, 2007 at 01:02 GMT) |
First of all thanks for typing that up. I like the 45 degree idea too. In fact it was already on my "maybe" to-do list. Which is my list of "stuff I'd like to do, time permitting". Grumble grumble about software development being so time consuming... I could rant here (and I did in my lost post), but I won't now :) .
I am somewhat mixed on the notion of having no rotation around the z-axis. During normal gameplay, I generally agree there too, I think rotation adds more tedium than it adds gameplay value. At least for the typical player...I do know one person though, who loves rotating the camera while playing RTSs, so maybe that varies from player to player.
But there's also a special case where I like camera rotation myself. That's near the end of the game. When the need for micromanagement is mostly over, I enjoy watching my units stomp their foes from a near-1st-person perspective. I.e. like a chase cam, where the camera hovers over the heads of a squad, facing in the direction that they're (generally) facing.
And I actually had an idea I haven't seen in other RTSs. Make a distinct chase cam mode for the RTS, like most FPSs have. Invoke it via a hotkey, and have it automatically follow around one of the squads that you've designated a number-key to. By hotkeying and automating the chase cam, you'd eliminate the tedium that you normally get when maneuvering the camera that much.
Of course, that still wouldn't solve the DTS rendering issue. Hmm... I guess I'm not convinced that that particular issue is all that bad. True, it'd be nice to always render DTSs correctly. But from a player's perspective, I think the fun of a easy chase cam may outweigh any annoyance of occasionally seeing DTSs rendered wrong. I mean I'd hate for the DTS issue to make my game look unprofessional. But still. The only instances I've seen of that problem have seemed pretty minor to me.
BTW, those famous quotations you've got on your Shapes and Lines website are great - that one by Albert Einstein about the income tax being hard, is awesome hilarious! Heh.
| Todd Pickens (Feb 16, 2007 at 01:10 GMT) |
Thanks, I REALLY need to update my web page, but want to completely rework it, yet have not had the time, so it sets waiting.
The chase cam mode is a cool idea, but make sure that you account for the max height of all terrain objects to set the height of the camera by, other wise I guarantee that you will have the camera following a unit that will move behind and object, or something crazy and the camera will get funky running into stuff.
You must be a member and be logged in to either append comments or rate this resource.
