[WIP] Supplies Outpost

[Snake]

Woww! Nice work Ep.

[Epifire]

Looks like my luck is starting to run thin. I've been trying to implement a good shadow volume to the building meshes I have. Such a pain as well, because I've been getting awful, in-game performance and the munge likes to dice my shadow meshes to pieces. I didn't think 330 tris was a bad number but I guess I'm mistaken.

Any ideas? Cause currently I'm looking at having to make some awful looking meshes just to cover a rough silhouette of the buildings at best.

[Sereja]

Perhaps, you may just try to add -hiresshadow line, in msh.option file. Usualy, it's no need to make shadow models for props.

[Epifire]

Oh really? I've never had to use an .option file yet but that would be really handy if I didn't have to go around making shadow meshes. Back when I learned about modeling for BF 1, I was always instructed to parent a low resolution mesh to the detail model, so that's all I've had to go by.

If that's all there is to it (without any performance loss) I'd like to do that. I'd assume that's an override command to use the detail model/collision mesh for lighting calculations, but I didn't program the thing. But if it's a more effective technique, then I'm all for it.

[SleepKiller]

Oh really? I've never had to use an .option file yet but that would be really handy if I didn't have to go around making shadow meshes. Back when I learned about modeling for BF 1, I was always instructed to parent a low resolution mesh to the detail model, so that's all I've had to go by.

If that's all there is to it (without any performance loss) I'd like to do that. I'd assume that's an override command to use the detail model/collision mesh for lighting calculations, but I didn't program the thing. But if it's a more effective technique, then I'm all for it.

Per-pixel lighting is enabled by adjusting some material options. The option Sereja said just forces the munger to use the model itself as the shadow volume. I was going to suggest trying it myself. It may just what you need.

I'm really tired atm. I was going to post some tips for getting the best performance out of the game... But I'm tired.

[Epifire]

Per-pixel lighting is enabled by adjusting some material options. The option Sereja said just forces the munger to use the model itself as the shadow volume. I was going to suggest trying it myself. It may just what you need.

I'm really tired atm. I was going to post some tips for getting the best performance out of the game... But I'm tired.

Well when you get the time after waking up, I'd like to hear about it. Nothing worse than running into constant performance issues to stop a project. 

[SleepKiller]

Basic performance tips off the top of my head.

Use as few textures as possible. Basically from what I've learnt changing the texture the GPU is drawing from is expensive for it. Consolidate your textures for your models where possible. Sadly SWBF doesn't support embedding the bumpmap into the alpha channel so you'll need to balance your use of them

For static lights take advantage of the -vertexlighting parameter in .option files on your models. When you have a static light in your world that's position does not change, what is the point of dynamically calculating it for the static geometry in your world? The above option tells the munger to interpret vertex colours as burned in lighting. You most also mark the lights as static in their odf by setting "Static = 1" This let's you save the game having to calculate lighting for the model.

Grab some new effects and make custom sides. I have some quite lovely effects in The Battle Royale that are less intensive on the CPU meaning more explosions and better performance. Check them out in the sides folder here http://www.swbfgamers.com/index.php?action=downloads;sa=view;down=1026.

Take advantage of the games LOD system. No point in rendering a high detail model at a distance when one with low detail will do. You can adjust the values at which models switch between low-res and high-res in the .sky file. Should be ObjectVisibility I think. (I don't actually have the modtools installed so I can't check myself. I just pulled that from what RC posted earlier.)

Now I started writing this yesterday but kept getting distracted by real life and stuff. So I may have forgotten something or not made something clear. But following all or some of these tips should hopefully save you those precious milliseconds in the rendering process.

[Epifire]

I think the biggest issue for me then will be the number of textures. I have tried to combine several detail panels into a single texture (which I think is four into one). I'd understand this to go along the lines of draw calls the game makes, and for a engine so old it's totally understandable.

I'd assume that if you're going to have more textures (say for detail props) you're gonna want to have the texture sizes smaller if you're gonna add a lot of different kinds of props. I have a default texture pack going for structures as you've probably already noticed, but I do have an issue with wanting all props to have their own baked texture. Baked ambient occlusion helps this game look tons better, so I use it where ever I can.

So my question: Is the number draw calls the bigger issue? Or the actual texture size be of greater concern? Because I could pack four 512x512s into a single 1024x1024. But because of the size, would that end up hurting performance more?

[SleepKiller]

I think the biggest issue for me then will be the number of textures. I have tried to combine several detail panels into a single texture (which I think is four into one). I'd understand this to go along the lines of draw calls the game makes, and for a engine so old it's totally understandable.

I'd assume that if you're going to have more textures (say for detail props) you're gonna want to have the texture sizes smaller if you're gonna add a lot of different kinds of props. I have a default texture pack going for structures as you've probably already noticed, but I do have an issue with wanting all props to have their own baked texture. Baked ambient occlusion helps this game look tons better, so I use it where ever I can.

So my question: Is the number draw calls the bigger issue? Or the actual texture size be of greater concern? Because I could pack four 512x512s into a single 1024x1024. But because of the size, would that end up hurting performance more?

Well once the texture is loaded into memory it is all on the GPU to handle it. Combining four 512*512 textures into a single texture may cause poor performance on older hardware, but even then just turn down your texture detail in the game settings. On newer hardware however I would expect it to handle it no problem. I don't know for sure, but cutting down on texture count and draw calls should help eliminate the bottleneck caused by the old engine SWBF uses allowing you to lean into the raw power of a modern GPU more.

[Epifire]

Well that's good to know. I may end up compiling four-eight of my default world textures into two mega textures if that's the case. I've been counting tga numbers in existing maps to get an idea what a stock map would have.

Currently I've been trying to get glow effects into my models. I'm using Ande's addon and have been trying to follow his direction for using the additional render options but still no in-game effect. Kinda sucks when there isn't direct guides for the small little things, cause I can test different theories for days unless I got someone to point me in the right direction.

EDIT: Still getting this z-plane stuff and bad performance going on with these shadows. Crazy cause it's just the buildings, I mean my lamp model has a relatively complex shadow model and it runs like a breeze. As a matter of fact I have eight lamps in the test map and they work like a charm. Not sure what is up with structures though. I just have a detail mesh and it's collision_ parented to it. I totally removed the shadow meshes I made for them and they still have the same problem. 

[Epifire]

Post has been removed by author.

[SleepKiller]

Are you using collision geometry or collision primitives? The later can give much better performance.

[Epifire]

Ohhhh, and this is why I ask these things. As far as I can tell I'm using collision geometry. It's about as cheap as I can get for detail level but it's how I make a collision mesh in any other engine and it's what I was shown for the original modeling tutorial I had for BF 1.

But if there is a better way of doing it I'd like to know. Not sure if that'd help the z-plane shadows though. Interestingly enough I only have frame drops when I am actually seeing this visual error. When my own shadow mesh was being used I could help it not do it so much, but when I ran the special option file lines it got worse.

[Epifire]

Guess who's back in action today? ...AND TEXTURING!

Note: these are still subject to change

[MileHighGuy]

Whoa awesome! that looks amazing. I'm thought you had abandoned it!