real-time vehicles : normal maps or lots of poly ?
greentooth
Let's considerate it's for a next-gen car or plane game. What would you use ?I've seen both used here. Does it woth it to model an high-poly model in subD to generate a normal map, or is it smarter to model directly the "low-poly" with a high count of tris but still optimized topology ? Also I'm not sure if a reflection shader works correctly with a normal map.
Thanks !
Thanks !
Replies
Also just consider how vehicles are mostly about super-smooth, flowing bodies, and not tons of greebled detail. The latter is a much more grateful subject for normalmaps.
and regarding reflections and normalmaps: yes it works, most pieces I have in my portfolio show this working.
Games like GTA IV, Mafia 2, Blur, Need for Speed, Dirt 2, ect, all use textures/normals on things, but thats mainly tires/interiors/paint effects/decals. Otherwise they just use pure polys for the chassis and chrome bits and so on and just use shaders.
This way, like he said, it doesn't take as much time to make a HP model and rip, and you also don't get the artifacts from normals or weird shading issues. Especially if you have realtime damage like GTA IV.
BUT.... then comes games like Crysis 1 or 2, Halo, older GTA Games, ect, that use pure textures and normals for their vehicles instead. The whole to texture or not to texture comes down to realism sometimes, and also if you need/want to get those perfect spec/reflection hits and have a smooth look or not.
Games like Crysis/Halo/COD, etc do bake normalmaps (not sure about MW2 though I think they do) because the vehicles are not the focus and they can't afford to spend so many polygons.
I'm not sure i entirely agree that forgoing the HP/Bake would automatically be faster/easier. You will likely still start with the same modeling methods, create a nice smooth sub-d model to get a good silhouette, and then remove edges for the ingame lowpoly mesh.
Normals version, you have a bit more straight forward workflow optimizing, and dont need to worry much about your mesh normals.
No normals version, you will spend a lot more time optimizing and tweaking and adding and removing geometry to make sure your mesh normals "look highpoly", you can just spend that time creating a bake instead.
So where do you want to spend your time?
Now if you're already going to loading a normal converted from bump, for anything.. small details, whatever, there really is no argument at all there, you want to do low->bake, if you're already using that texture memory, it would be silly to use more tris to get the same result.
You could make the argument that you'de model it all from scratch with traditional modeling tools, but that means you loose all the advantages of nice and easy curve creation that you get with subd, so again its a complex process and not really easier/quicker. In the end it comes down to the individual i guess, if you're slow with sub-d work it would probably take less time to just make a low instead of a proper high, but if you're slow with sub-d you should be practicing.
Specifically talking cars/planes, I have to disagree here. It's much faster to just model "mid-poly" (bit of a vague term) straight away. At least it is for me, and I'm experienced with vehicles. Really, if you're good with this sort of polyflow, then modeling something midpoly compared to lowpoly is just marginally more work.
As for the normalmap baking: I'd say it's not necessarily just the SubD that's slow, but also the baking process. I definitely know what i'm doing with SubD, yet it can still take up to double the amount of time when I bake HP.
Really, there's a reason studio's like DICE never bake any normals for vehicles, it's just not worth their time. Same for every single current-gen racing game not using normalmaps on vehicle bodies.
I tried both and production time wise higher poly takes the prize. And visually too. At least for me. The only actual thing that could scream for Normal map would be the small crevices but all the main shapes should be defined with slick poly flow anyway. By throwing away NM and throwing in another couple thouthands poly I'd say you probably end up with a more optimized model. And don't forget that the car will probably be split up into drawcalls per material types so think of your polycount in terms of it.
And yeah I've studied GTA pretty hard and I haven't seen them use normal maps on their vehicles except for the decals.
10-15k tris should do the trick for almost any kind of ingame asset and if you're specialising in cars, like Gran Turismo for exmaple, then I think you can afford yourself even more, so whu bother wiht normal maps.
But! That doesn't mean you don't need to unwrap stuff. There are parts of the car that need some real texturing and if you want to have yourself some believable dirt.
echoing this
For me, its all about - The Focus. If your playing a game like MW2, you would normal ma detail in and fake curved surfaces with normal maps etc.
If your main focus is the car or plane, then nice smooth geometry is the way to go.
I have tried baking complex objects such as cars an planes and it doesn't work as good as you would hope when your trying to get nice perfect smooth surfaces. It works to a degree, and you can get there in the end but it MASSIVE effort.
Polygons all the way.
+1 for Earthquakes video
I think we're having a slight misunerstanding here, due to coming from different vehicle modeling backgrounds. Checking out 3 Point portfolio -> Vehicles section I think it's obvious that you go with normal maps there. But,
If you are doing a game with realistic vehicles, then I, personally, see no place where hormal maps could be of use in most cases. NM don't make squares round and stuff like that. You can fake some small details or get more control of how you model is lit, but do you really need it at 10k or higher? The usuall modern day vehicle is a set of shapes - not details, and if your veicle is going to be seen from any angle, then I say you need to have theese shapes "physically" present.
Here's a number of pictures of non sci-fi vehicles. I personally can't point out a place on them, that needs normal mapping and could actually justify using it. Can you?
As I said before the small crevices kinda scream for it, but if you're making a funcional model with doors, hoods and everything else really opening up then you'll get most of them naturaly. And the remaining hardly justify wasting resources on a normal map. Another couple thouthand tris would probably come cheaper and I'd say would make for a prettier model.
The rule of thumb I roughly work to is under 20,000 tris I think its worth baking a high poly onto your low poly mesh. That will givee you a very nice looking car for not a lot of tris. This will work for 6,000 poly props for the Unreal engine, and generally make art leads happy in games where cars are not the focus, like props on a street etc. This approach at the 10-20,000 end will also work nicely for racing sims where for whatever reason you cant use lots of polys.
If you are developing for the more modern racing games that can accept 50,000-500,000 tris plus, it very much makes sense to do it like that, not so much from a speed point of view as it still takes a bloody long time, but for detail and features like destructability, its the best way. Theres a few good threads on here of ppl making 300,000 poly cars for gran turismo etc.....very interesting reading as the materials are set up very diferently to a conventionally unwrapped model.
Seems they used quite abit of polys on the car, mentioned somewhere there using a subD level of 1.
I'm pretty sure Polyphony Digital uses the same approach for the latest GT, I've seen glimpses of wireframes in videos that definitely looked like subdvision models.
Using this method is probably faster than going for a really high-quality midpoly model.
You could store cheaper midpoly cars and procedurally subdivide them on level build to help you save memory. That is if you can't do it dynamically. If you can, then go ahead and use it as LoD 0 directly ingame.
But all of it seems really overhyped to me. On the average 20inchish monitor If you fit the whole car on screen I doubt you'll be able to tell much difference between 20k and 100k model. And during dynamic gameplay I bet you couldn't. If you're playing on a TV you're usually farther away then from the monitor, so even if it's a bigger TV it's pretty much the same.
So I doubt the usuall case should be more then 20k. I even think that 10k is enough for actual geometry you play with. And all the sub-ds and higher polycount stuff would make sense in closeup replays and special masturbation gallery modes.
It's amazing how much art is done sometimes for the sake of screenshots and magazine covers. I remember when we've got some statistic from Order of War players, people were spending most of the time sseing LoD3 models, spending literaly seconds to look around in closeups. Of course the issue is more visible in RTS genre, but i think it's applicable to other genres to some extent. So subdividing stuff from midpolys seems like a great way to save some working hours.
First off, if I was approaching this sort of asset, the first thing i would do is create a nice sub-d model. This i think would be the fastest thing to do. If we're talking a high quality 20-40k asset(which i still feel would benefit from good normals). Poly modeling everything from scratch would just not be an option for me, i haven't really poly modeled stuff like this for, i don't know i guess like 6 years, so all of my work tends to be based off a sub-d work-flow, and i actually think that lends itself quite well to something like a realistic car. The tools we have for with sub-d for creating nice flowing shapes and curves are just so much better than if we modeled it all from scratch. So you've got a sub-d model already, this takes care of what people would say is probably the most time consuming part of doing a proper bake, but i feel in this situation i would start there regardless.
So, you've got your HP, and now you've got to make an ingame version. If you're going to end up making a bake, doing the optimizations here from high should be much faster, and result in a lower count, while still reaching an as good/probabbly better result if you're doing a bake than if you arent. So the time goes into baking, now i'm not going to say that its FASTER to do a proper bake, because its probably a bit slower, but i think there is a good arugement that can be said for taking a little bit more time, and getting more quality in the end result. You can always find ways to do things faster if you're ok with a lesser end result, and i wont really make an argument on what is/isn't good enough because that is very subjective.
Now, lets look at the big issues with baking. For those of you asking for tutorials, its actually something that has been kicked around in-house at 3ps, i can't really comment on it any more than that. But lets look at the likely issues most people have when doing bakes. It seems like everyone always wants to know the settings you use or the buttons you press to get good bakes, but when i talk work-flow i'm talking the entire process, a lot more goes into it than just hitting the "correct" settings in your app. You need to model for a baking pipeline and understand the concepts of how and why bakes go bad. People often look at baking as some sort of secretive magic art and come up with all of these very strange work-arounds and hacks to make things look good, and really spend much more time than they should if they took the time to understand the issues they face, why they are problems, and common sense approaches to fixing them. So saying that, lets take a look at the basic problems most people have with bakes.
1. Smoother errors, this can be a very complicated subject, and everyone seems to have some half-baked way to deal with them, i myself have done some pretty silly things in the past to try and overcome them. The easiest thing you can do as an artist, is to use an app that has properly synced tangents, like 3ps Shader with Quality Mode, or maya, or getting your baker synced up with your in-house tools. Failing that, a very simple piece of advice: think about hard edges/smoothing errors when doing your uvs, set uv seams where you are likely to use hard edges, and setting up your mesh normals and getting quality bakes becomes a much more simple matter.
Now, the resolution of these types of meshes that we're talking about, smoothing errors shouldn't be much of a problem. I'm not saying that anyone should consider substituting a 4,000 tri mesh with normals for a 40,000k mesh without, that would be silly, i'm talking a mesh with the same silouhette, with normals, will use a lot less geometry because you do not need to use anywhere near the amount of supporting geometry to get smoothing, we're talking vertex normals compared to per-pixel normals here, if you're doing bakes your really just have to concentrate on the shapes.
2. Your lowpoly should match your highpoly as well as possible. People have a lot of trouble with this, most of it stems from trying to use too little geometry to represent shapes. simply making your low match up better with your high will solve a LOT of baking problems. I'm not just talking about making them as close as possible(which is important) but also making sure that you dont have a huge variance in silhouette, which often results in wavy artifacts.
3. Modeling your highpoly for the low, and not being afraid to tweak the high when you encounter problems with your bake. Simple things like not modeling holes in your high where you do not plan to have holes in your low, avoiding massive height variation in the high where you do not plan on supporting it in the low. Modeling for your low is one of the most important aspects of getting a good bake, people far too often think that a high is something, a low is something, and a bake is something else, and all of these
are entirely separate, you just press some magic button at the end of the day that makes them all work together. Your bake starts with your High, and ends with your psd file, and encompass everything in-between.
On the flip side of that, is modeling your low for your high, understanding what direction your lowpoly mesh normals point, and how that will affect your bake is essential to a good lowpoly as well. When your low isn't modeled well for your high, then you have to resort to hacks and tricks to get things to look right, spending lots of time messing with custom cages, which you will have to redo from scratch any time a simple change is made, composting all sorts of separate bakes together, which you will have to redo from scratch any time a simple change is made, all of these things can be avoided if you're thinking about the whole process.
So when you're thinking like this, as I try to approach all assets, adding a bake shouldn't be this monumentous task, it should just be part of the job, part of the process and it shouldn't be something you need to avoid. At the end of the day a "baking tutorial" from me would cover everything from initial high create to final PSD scene setup/AO stuff, not simply a matter of what settings i use in max.
If i can find some time i might whip up some very quick and dirty example showing a "car shape", modeled with simple geo and hard edges, modeled with lots of supporting geo to look "high-ish" and simple geo with a good bake, just to show a comparison of the geometry use, quality, etc.
One last thing, people seem to have sort of a misconception that normal maps are only good for greebled sci-fi stuff, when in most cases they are essential to the look and lighting for any asset, no matter how simple or complex or how stylized or realistic, its the form and shape of your mesh, and unless you've got a 100k budget for your assets, a normal map is going to do a better job than verts.
sorry for tl;dr
This one surprised me slightly, as I remember reading the exact opposite here on Polycount. Not sure who posted this, but I remember an experienced member stating the the Highpoly is king and should be as accurate as possible, the lowpoly should just follow suit.
I never really followed this advice though, as practically it's almost impossible.
Amen to that, A lot of realtime folks don't seem to have had the 'EVERYTHING has a bevel epiphany yet.'
EQ: I hope 3Point do a tutorial, I'd certainly buy it, Your posts have been so damn helpfull in the past that Id buy it just to give something back.
It seems like as usual, it's a matter of compromise. Looking at this http://www.propergraphics.com/3dlowpoly/Koenigsegg_video.htm and assuming it's in-game model (200k o_O), i guess they used subd level 1 (even 2?) model that they have optimized, trying to keep tris on silhouette and holes. I guess the normal map is mainly used for the interior (seats, leather, wheel...)
Looking clother, i don't think there is any bake there (2048 for the all thing?)
So i assume they built a subdivided model to get "easily" the nice curves, but then didn't use it to generate normal maps.
I guess subd is the way to go, then, depending details/slickness/tris budget of objects, only optimize the high-poly or optimize it and generate a normal map.
In his exemple you only have the car, a plane for the ground and a sphere around (for the skybox).
In a game; you have many cars, a real environmenet, reflections (way more complex 'cause you have the cars around that reflects in yor own car) , IA, UI etc etc.
I think there is some games that used 60k (it's tons of wasting polys i think, i understand they need many for the tires but still ...) tris for cars, but 200k seems a bit exagerated ...
yeah, it's always the problem, you never know if it is a demo, or if it is the actual game. Even if GT5 is a bit extreme, i don't think they were using normal maps on car bodies in GT4.
Yeah really everything works together, if you think the HP is the only thing that matters, or the most important thing and everything else should be compromised to suit it, you'll be giving yourself a lot more problems. Modeling a HP that can easily translate to a low is very important.
Simple stuff like making sure your shapes in your HP line up in ways that dont make your lowpoly overly complex, so you dont have to add all a bunch of small strips to connect pieces together etc, but just flow from one bit to the next.
Sculpt your HP mesh.
Model your LP mesh.
Extract a displacement map or vector displacement map(in case you need mushroom/ears).
Then, your DX11/GL4 engine will use the LP+displacement to reconstruct an approximation of your original HP-sculpted mesh.
Realtime tessellation anywhere!
have you put it to practice it doesn't work as well as you would think.
to get high frequency detail you need to tessellate things more which results in a slowdown, and you need to make you base with fairly even topology or it tessellates like crap, and stretches when you displace it. so if your going to spend some extra polys to get even tessellation you might as well use those to better define the silhouette and use normal maps and ao on the rest.
well the idea is that your taking the detailed smoothing off of one model and putting it on the low poly one to make it appear to have more detail, so not that strange of thing.
(that is, using dxt1 for the normal maps. engine didn't let me use dxt5_nm).
I've seen that in Blur they use normal maps for small details like the fuel tank door. And there are some quite noticeable compression artifacts...
As for interiors, it's a hybrid of low polys with painted normals and baking normals from a high poly. I do a proper high poly and bake normals for pretty much every interior part except the major ones like the dashboard and door panel, which have fairly simple forms and the only normal map details required are panel gaps which are easily done in PS. You could easily do the entire interior with the traditional high poly normal baking workflow but I've found it's not necessary to do every part that way. If there's anything I've learned in the past few years it's that there are a lot of cases where you can make a damn good normal map without baking any normals.