WIP M60 machine gun
polycounter lvl 11
Hello
Well here it is, feel free to post both comments and criticisms, I will be glad to read them all. thanks.
Well here it is, feel free to post both comments and criticisms, I will be glad to read them all. thanks.
Replies
Ok the ammo box is a mistake from me as I fail to provide proper info about the whole model, here it is
the truck still needs A LOT of work, and does not have the belts to support the ammo box
i know those screenshots sucks, I took them with the prtSc key!!! and paste it in paint cause never found neither the folder wich contains the snapshot or even if the "save snapshot angle" options works at all in UDK, also I just cant navigate in the engine is still to weird for me to move inside the mesh viewer ( or whatever is the proper name) english is not may native languaje. Anyway I took these in maya I hope those give you a better detail of the model, if you want to see some specific area please feel free to tell me.
Thanks for the answers.
Show us the wires of the model and your flats and it will be easier to help
As sltrOlsson said, show us you wireframe and texture flats, and maybe we can help you
and a bit of work in the texture,
you may noticed that I'm still in my learning process and I am lerning by miself reading and watching videos on the net.
ok here it is the textures so far
thanks for yor time people.
-Second uv channel if this is going to be in udk ( you only have one right now)
- I would save some Polys and covert your ammo belt down to a simple square and normal map it in, should still read just fine.
-Go through clean up some some of the extra loops
-Some of your small details don't need to be modeled in,just think, when the whole truck is in the shot some of the small bolts and wholes will get maybe a pixel or two of screen space(just something to think about)
-If its going to be third person your detail by the sight is ok, if you want some FPS shoots, might want to clean it up a bit more and mess with some smoothing groups to help out
Besides that keep it up and hope to see more updates
Hi and thanks for your comment, I never used a 2nd UV map before but I got this info doing a little research last night, it say that the 2nd uv map is to make/use a lightmap, also I read that a lightmap is for a static mesh, so this is not going to be a static mesh, in fact is going to be all over the place shooting to the player, bottom line did I got wrong info about the 2nd UVmap? or did I misunderstand the whole thing? thanks again to all for your helpful comments.
Lightmap Tutorial
No, but you can generate them in UDk. However, there is little control in this, so it might not be the best or optimal.
As for the save location of screenshots for UDk.
C:\UDK\UDK-2011-06\UDKGame\ScreenShots
And just to make sure, when you play the game, you type in the console tiledshot 4 where the number is multiplied by your screen resolution. Be sure to access the console with the TAB key, and not the tilde for this purpose
As far as the gun goes, it's pretty good, looks like there might be a smoothing groups issue on it. It might need refining in places. I tend to match my smoothing groups to my UV seams, I find I get better results overall and when baking, BUT there are cases where that doesn't work.
On the heatshield, the holes that are modeled might be better off using an alpha map, or, just have black in the texture where the holes would be (instead of geometry) to get a similar effect.
It's coming along well. Also, a lot of metal models benefit largely from a spec map and maybe even a gloss map if you have the time.
It's usually a good idea to combine an AO pass onto the diffuse for the feeling that things are resting on each other or intersecting.
A lightmap is a replacement to the old "vertex lit" method (which did a b/w pass applied to the vertices of the model) because memory isn't as big of an issue anymore.
A normal map is only part of making a model look three dimensional. It mostly shows off where light hits (referencing the specular color/power). Sure, it might do a little bit of shading, but AO is what creates a more believable look right off the bat. If you think back to games in the past, before normals came around, they had AO baked into the diffuse and the result was believable.
Secondly. What's your end purpose with this project? An UDK project or what? I didn't find a certain answer in your replies.
Concerning your UV layout there are many areas your could optimize that seem to be using similar texture details. You do this by "stacking" identical UV islands/shells on top of each other. This way they get the same texture info, and in return you can now gain more texture resolution by fitting your new lower amount of UV shells(not counting stacking) to maximize the 0-1 UV range.
Secondly, you have lot's of light data in your texture which might not be what you want? You'd do best by first answering in what rendering environment and for what purpose are you doing this. Try to learn all the components of shading a bit more in-depth if possible. There are a lot of ideas and suggestions out there and all might not be appropriate to follow. If this is going towards a common high end approach you generally want to just have color differentiation in your diffuse/albedo/color texture, no lighting info what so ever in there if you want to use the textures as intended. Then again, at some point rules are meant to be broken right? But I'd break them first after you know what you're doing.
The AO should be separated as a texture of it's own (or packed in a channel of some other texture). The AO's purpose is just as the name implies, to Occlude Ambient lighting. Think of it this way, your lighting solution will be based both on direct lighting and ambient lighting. The direct lighting being for instance a lamp in an indoor environment, and the ambient light will represent the bounced light from the same lamp. The AO would then just tell the bounced light where it could hit the surface and where not to hit as much, or not at all for that matter. It's not advisable to just multiply your AO data into your diffuse/albedo/color texture unless you were going for a really optimized low-end render solution as it comes with a cost.
I'm not that familiar with UDK, but since they pre-bake lighting to a second UV-set they can get really nice lighting bouncing and global illumination like lighting. To me it sounds like this automated process of baking lighting in UDK does similar to what you else-wise would do with baking an AO. So the step of both manually baking an AO and then computing lighting data in UDK might be unnecessarily? This probably depends on if this is a static mesh or not. Someone else probably has a better answer for this.
I was trying some "blend if" techniques in photoshop, and is great but I need to practice more and get the hang of it. Once again thanks in advance for your comments and critics.