cfehunter

Yes, but not without significant amounts of work in the rendering code. We can basically do custom metadata now. It may come to adding multiple file versions in the exporter and in either case I have no intention of writing a WWSkin modifier in max. The stock skin modifier may not mimic the in-engine IK or anything, but the weighting tools are worlds better.

Frankly, it would be easier to port the game code to a new engine than re-write the core game systems *and* keep them compatible with stock renegade. That said, there's plenty that can be tweaked.

I can't really comment on the the editor. Shininess is supposed to impact specular intensity, but when the engine was moved over to DX9 with a DX8 emulation shader, instead of being actually DX8, the specular was broken and it hasn't been fixed since. Translucency likewise actually should work, but it'll only effect specific material types.

It depends on the workload. For renegade GPU skinning is probably the right choice as the GPU isn't the performance bottleneck and most skinned objects are using common skeletons. We can always move to CPU skinning, but our min-spec is a single core CPU and in that particular case it would absolutely murder the frame rate.

Nations are randomly selected (filtered by map) for both teams at the start of the game. So if you're Korea you will be able to buy beagles if you're Russia, Tesla tanks

Actually that's an upgraded W3D engine. We could make a UE4 version of AR/Reborn/Tiberium work on an iPhone, the engine itself is not the issue. The engine itself is about the most advanced, most highly optimised piece of gaming software in existence right now. How it actually performs for a game is much more down to the artwork and game specific code. Render state switching is what kills performance in most cases (unless you're doing something stupid in game logic)

It would be standalone but this has mostly turned into consideration of ue4 not udk

I have to point out that if you have a computer with parts created in the past decade that UE4 on minimum is likely to run and look better than W3D because it actually takes advantage of modern hardware features.

I wish I made more money, but the day to day work is something I actually enjoy. It helps that I get on OK with my coworkers and manager

Well even up to this point if you had subscribed for a single month at any time you could have had the full engine source code and the full editor source code. Now that I don't have to keep paying for updates I want to get the UE4 experiments going even more.

Just a small update to this. jonwil has invited me to work on W3D. So I'm going to be spending some time tweaking W3D and creating scripts in addition to looking at UE4. W3D being the priority.

I'm going to start poking around with UE4 tonight. See what I can get working and figure out how feasible things are. Again i'm not representative of the team. Just experimenting with stuff. I'll make a public thread for tracking how it goes

Pure grayscale makes plastic-like specularity. If that's what you're going for, then that's what you'll get with a pure grayscale specular map. It obviously comes down to artistic preferences, but if you want realistic specularity you'll need to approximate how the material reflects light - and many materials reflect more than just 0-255 shades of gray. Yeah granted, that allows you to modify the colour of the specular at the cost of tripling the size of the texture. There are multiple posts even in that thread you linked that say to just use a monochrome texture though. In any case, Blinn-Phong is plasticy regardless of what you do. Which is why modern games have moved over to PBR now. On that note, this is really worth a read.

You should tell that to the Unity devs. They use the alpha channel of the normal map for theirs (in the default shaders), it's nothing but 0-255. I've attached two specular maps (downsized for size reasons), one made by Ben and one made by another friend of mine. This is the most common use case. If the shaders you plug your art into use colour spec maps that's great, but it's not the norm

Normal Mapping - You can do this in any program you feel like doing it in. It's hard to explain without going into technical detail about how they work. But here goes. I'm going to talk about tangent space normal maps here because world space ones are weird and hardly used any more. The red, green and blue values of each pixel of your texture represent a 3D vector, an arrow in 3D space that points in a direction. Red represents X, Green represents Y and Blue represents Z. A perfectly flat surface will have a normal pointing directly along the Z axis. (Put a pencil point down on a desk, that's a flat normal). This is why normal maps appear to be mostly blue. Relative to the geometry most surfaces are relatively flat. Now there are two major ways of creating a normal map. Using actual 3D information or faking 3D information. The preferred way for most "actor" models (players, vehicles, weapons, etc) is to create a high poly version of your model and then to render the detail of the high poly model onto a lower poly version of the same mesh. Tools such as Z-Brush make this fairly trivial to do and are really worth investing in. If you can't do this, or require a normal map for a general reusable texture, then you can manually paint a normal map and use the knowledge of what the Red Green and Blue channels of the map do to get the effect you want. I recommend using something like the CrazyBump plugin for photoshop to give you a base. Specular Mapping Paint over your unwrap in grey scale. The closer to white something is the shinier it will appear to be in game. Ambient Occlusion Mapping Effects how much ambient lighting effects a part of your model. You can use this to create global highlights and lowlights. Diffuse Mapping Fancy name for colour mapping. In scientific lighting language "Diffuse" means the light that is reflected from a surface. So it's what you actually see when you look at an object. This is where you actually paint stuff.

With the UDK we could use the same artwork and rigs as we used in renegade. I haven't really dug too deeply into UE4 but, since Ben managed to rig the TSR GDI soldier to the UE4 default skeleton at games jam this year, I believe we could do the same. The general art process is like this: Model High Poly Version -> Sculpt in Z Brush -> Re-topologize -> Bake High Poly into a normal map for the low poly version. PBR Pipeline (UE4) Unwrap Low Poly Version -> Paint Diffuse -> Paint Roughness -> Paint Metallic Blinn-Phong Based Pipeline (UDK, Renegade, All the things prior to the last few years) Unwrap Low Poly Version -> Paint Diffuse -> Paint Specular Map We can do the full set of work for the PBR pipeline and just take the mesh, rig and diffuse texture and drop them straight into renegade with very little extra effort.

Sorry, to rephrase. Best practice is to do whatever allows you to work comfortably. As long as you get an unstretched, neatly packed unwrap at the end. It's all good

Best practices don't really matter here. You can map everything together or separately. When you combine meshes they keep their UV information and you can then pack them together. Remember though. One big texture is better than multiple small textures

In renegade the alpha map is probably a smaller cost than shading the tris for a full wheel mesh (assuming it actually depth sorts) In a modern engine with deferred rendering the mesh would be quite a bit more efficient... Unless the overdraw is ridiculous..

I don't think the engine has much to do with how the actual game turns out. A move to a different engine would basically mean re-implementing all the stuff we love from the renegade engine (mostly just the C&C game mode because screw the network code) and giving us more scope for artwork. We could do normal and specular maps as a base and do fancy shader effects for things where appropriate. I'm not speaking for the rest of the team, just myself.

That's $34k btw. But I'm only on the bottom rung of the programming ladder and Ben's in QA at Creative Assembly right now. It's about a 20%-30% paycut to work on games instead of software and software is easier to get into, so you either do it because you love it or you just don't do it.

Depends what you want to do and where you're aiming to do it. I'm a programmer (£22.5k a year atm, graduated last year with 1st class honors) and unless you're a prodigy and have an absolutely amazing portfolio you need to have a degree. It's also not worth going past a Bachelors degree unless you just want to learn more or cover a bad Bachelors grade with a better masters grade, or you just want to stay at university for another year .

We could do this and make the game support more modern features and be more portable. There isn't much to gain from doing this though. Particularly when unreal gives you full source code access.

Nice work. Not sure where 20k Poly's went but I imagine there is a lot more detail than is visible from a still. Textures look pretty good to.

From a tech perspective an extra thousand Poly's don't mean much*. Switching render state is what costs. Having lots of small objects with separate texture maps or material attributes will tank performance. Having too many bones can screw performance to but that isn't normally an issue with hard surface. * The exception to this is when you go beyond the index limit and the mesh needs to be split. An unsigned 16bit index can index up to 65535 indices (tris * 3). So if you have 65536 indices,21846 triangles it will have to be split into two draw calls