I saw a tutorial by the guys that made R.A.T.S. how to make a single material in udk house several textures each with it's own UV mapping, like a single material containing multiple materials, and the plus side of this is to cut down on drawcalls and increase performance, but I'm not sure how would it be the best way to use this method for my project. If my gun has lots of optional attachments, like different scopes and sights, flash and sound suppressors, magazines of different sizes, underbarrel attachments like foregrips and grenade launchers, and so on and so on, what should I put in one material and what in a separate? If I put all in one, but I don't use the majority of the optional attachments, how's the performance going to be compared to having separate materials for the attachments?
I see, that's good, but I'm asking because I don't understand how exactly this works, like, for example if I include the texture of the empty shell in this material, and I make the empty shells stay on the ground very long, is it going to render the rest of the gun or the rest of the textures in the material or something like that for each of the empty shells on the ground? Or just instancing them or something?
UDK only renders what's visible on the screen at any given moment. If the gun will be on screen then the full texture will be loaded anyway. Since shells are separate objects I'm not sure if the same material will have to be loaded a second time for them, so if someone else confirms this, it might be a little better to have a separate smaller texture (like a 64x64 or even smaller) for the bullets. But honestly I don't think something like bullet shells should really have much of a performance impact if you use the material from the gun. It will definitely save on texture memory though. My method is to usually not focus on small details like this performance wise and just get something together. It's usually faster to just cut things here and there from a more finished state if it's needed than spend so much time worrying about performance of something that might not even be a problem. It's good that you're thinking of performance, but it takes a lot longer to focus on that with every object at all times than to optimize with an estimate and fine tune things when you're farther along in development. (Kind of like a car manufacturer halting production on a car because a nut on a bolt doesn't seem right. it'd be faster to look for an alternative while still producing the rest of the car than to halt production to investigate the issue)