SP Native [WB] Blood and Steel 2.0

[xenoargh]

The mod's not dead, exactly.  And I still fire up this engine and code.  At this rate, I might be done before Bannerlord 

That said, development took a bit of an unexpected hiatus due to Real Life, however.  I worked on some other stuff elsewhere, among other things.

That said...

1.  I'm in the middle of rewriting the core shaders, again, because I want to redo a few things.  I've built a dynamic sky shader that responds correctly to editor controls and I'm working on a re-write of the ground shaders that will make me happier with the crummy systems, maybe.
2.  I have something really cool to screenshot as soon as I'm happy with it.
3.  The previous stuff with the map I talked about is getting revisited.
4.  I built some snazzy new armor-stuff I think folks will like.
5.  I'm thinking that DTheHun's Wardrobe work gets integrated into this, because, well, I wouldn't have put all the warrior-women into the mod in the first place if he hadn't made his snazzy female armors at the beginning of time (and seriously, I never thought he'd show up again, let alone make new content for Warband).

 

[fladin]

I have something really cool to screenshot as soon as I'm happy with it.

I built some snazzy new armor-stuff I think folks will like.

Can't wait 
I don't know why but  I'm very happy now 

 

[ArnulfFloyd]

Maybe in future...

 

[trooper828xx]

all i would like to say, is once a week or monthly, either an update saying what has been going on with the mod and real life that are interfering with each-other, or progress in general, just so people know "hey i am still here and i am alive". i loved the original and remember silly videos on youtube of this mod getting me interested in the M&B series. good luck friend

 

[alster52]

YAY ITS NOT DEAD MY LIFE HAS MEANING ONCE MORE YAY TIME TO GO DANCE IN THE MOONLIGHT

 

[Graeghan]

... you need to get out more. 

 

[alster52]

If i did then i wouldn't have time to play blood and steel 2.0.

 

[MezMez]

Oh God, how I wait for this. I just hope it'll have Virake's face compilation or at least better faces lol. Other than that, by God, do I love how this mod made the game. Years later and still excited for this. Godspeed Xenoargh.

 

[xenoargh]

Testing a new set of shaders for ground, the new dynamic approach to skies, etc.  Don't mind the background assets; they're still in-process.

Spoiler: screenies

...see?  I do occasionally work on this thing; it's only 99% vaporware, lol.

 

[gokiller]

Nice work!

 

[Mr.Milker]

What's new about the ground shaders?

 

[Pumpkin Lord]

What's new about the ground shaders?

I noticed it is noticably sharper and has been added randomness with extra detail textures like rocks and cracks?

 

[xenoargh]

It's a new version of my parallax / occlusion shaders; it and all of the other major shaders take the dynamic sky into account, instead of faking it through various hacks.  I think it's coming together pretty nicely, although there are bits here and there I don't like.

 

[alster52]

You make me want this more then bannerlord. why must it  take so long

 

[NPC99]

Testing a new set of shaders for ground, the new dynamic approach to skies, etc.  Don't mind the background assets; they're still in-process.
...see?  I do occasionally work on this thing; it's only 99% vaporware, lol.

Given scenes are for short periods of time, I'm curious about the focus of your new dynamic approach to skies. Are you changing the level of cloud blocking sunlight minute by minute?

 

[xenoargh]

Well... short answer:

1.  Yes, clouds being mobile and changing behavior is one of the sub-projects for this.  Potentially, now that the shadow-map can get regenerated at a decent speed, we could do a truly-dynamic day / night cycle in scenes, too, without any hacks, but that isn't the focus; I merely want the skies to be Really Pretty Random every time.

2.  The main reason for the dynamic approach to skies is that the way light's created and distributed in the scenes in Vanilla and all the mods (paid or not) I've seen has never matched up well with the lighting, and then that lighting isn't reflected (literally) by the materials used on meshes very accurately. 

Basically, we have a fixed HDR sky, a weird sun-mesh that's rendered in a way that clips things and blooms, etc.

What you're seeing in those screens doesn't use any of that old system.  There is no bitmap on the sky-sphere, there is no sun object; that's just some mathematics doing its thing.

Spoiler: the long answer, for tech-heads

1.  Warband's shaders are, under the hood, a bunch of things that were all kind of nudged together until they looked all right.  I'm not trying to be nasty by saying that; they were moving as fast as they could to get a DirectX 7 title over to DirectX 9; props!

My goal has been to unify the approaches used, optimize the code, and get rid of the huge amount of duplication, replication-by-another-method, etc., in Native's code. 

It's been kind of a hobby-project since they released the shader source, trying to figure out how to get X working without running into trouble with Y <insert weird exceptional behavior for very specific situation / kludge / etc.> 

There are, unfortunately, a lot of <weird exceptions> that have to get worked around.  For example, when object meshes are rendered in the Inventory, they don't use standardized lighting variables or a Skybox, and the behavior's unexpected. 

Hair and faces do some odd things during LODs; grass objects can only use the grass Material, which can only use the grass shader; it's all hardcoded, for no particular reason that I can discern.

A lot of these things feel like they were intended to be optimizations, but they don't work like we'd expect. 

For example, the grass doesn't need a hard-coded Material and shader; it needs to call all grass-system meshes whose Material is X, then render them all, then Y, then Z, to reduce the texture loads per frame, instancing each set of meshes, preferably. 

In general, Materials should all get sorted by diffuse texture; if two Materials are identical other than specular components or shader, they should run right after one another, to reduce texture loads.  In  the case of grass objects, it's not rocket science, and it'd still make sense to use a texture atlas... but we wouldn't be forced to. 

As it is, most of the performance improvements were lost, in all practical situations, by calling all of the bush objects, etc., etc. that use their own Materials, textures, etc.  And those objects cast shadows, which makes them... impractical for a few situations, or look weird because they suddenly have grass pop-in around them, etc.  I'm hoping to do things a little better, now that I feel like I understand the issues.

2.  However, given that I don't have the engine's source, I can't straighten out the interior kludges, hard-coded rendering situations, etc., etc., so it's taken quite a lot of time, and I've stopped a few times for months or a year because I figured Bannerlord would be done before I got anything polished enough to be released.

3.  Meanwhile, I came up with a bunch of toys and things, like working SSAO, a much-better parallax-occlusion shader that doesn't shimmer or shift, better water, etc. 

4.  But I kept coming back to the fundamentals of light.  Bannerlord promises some form of "PBR" rendering.  Yet-another Industry slang term that basically means, "a little more like raytracing this time".  It's meaningless otherwise; there isn't a "PBR" standard system of shaders or rendering environments; it's basically a more-realistic treatment of light. 

While I can't do some of the things that are supposed to be in Bannerlord, like baked-in static lighting with precomputed light bounces, I felt like there were tons of ways to improve the core lighting equations, so that what we see in a scene is all pretty unified.  What I've got, thus far, is not bad, although I'm a little leery of showing it before all of the assets are ready.  That last screen showed some issues I'm still having with grass that I'm working through, for example; I think that when it's done, it'll be pretty cool, though.

But yeah, that's part of why this has taken forever.  That, and I really should have found modelers, sceners and Photoshop people with serious chops for what I've been messing with- there are huge changes to content that I've gradually whittled away at, largely because what's the point of a Tech Demo for a game that's a decade old now?

 

[NPC99]

Thanks for both the short and long answers - fascinating stuff. I’m amazed by your patience and dedication. I hope you manage to get an alpha out before Bannerlord’s release distracts you.

BTW looking at the coloured sunlight you used to demonstrate its impact on ground shadow and colouring, I was wondering if this could also be triggered by the player or ai as some sort of weather magic - a darkening of the sun spell to intimidate & dishearten your enemies.

 

[Mr.Milker]

Oh, so you're completely replacing the skybox and all that?

We've run into a problem in TLD where if we scaled background (or "distant terrain") meshes too much, they'd clip through the skybox and only show the unclipped part.
So our solution was to move the largest ones into the skybox space (can't tell you the details really, InVain or Swyter would know). Weirdly, they render properly size-wise, but things like shadows and fog/atmospheric perspective don't affect them.

So there's this disconnect where the majority of a scene is covered in a light haze and fading properly into the back and then props like mountains that are supposed to be the furthest back are actually rendered as fully lit, sharp and popping forward visually.

Would you perhaps know how to work around that, or would your system allow for very large distant terrain while keeping lighting consistent?

 

[Marko͘]

Does increasing far_plane_distance distance in module.ini not fix this? I had some really distant border terrain objects and this setting far_plane_distance to 10 000 m fixed the clipping while keeping the border terrain lit consistently with the scene. Maybe my distant terrain isn't as distant as yours.

 

[xenoargh]

For really distant objects, there are probably some fundamental limits on where the shadowmap stops getting rendered to a Scene, but frankly, I've never tested that. 

far_plane_distance is the maximum clipping distance and influences the depth-map, which should address issues with fog, but I doubt shadowmaps are effected, because of resolution limits (although frankly, I don't know; maybe shadowmaps are stitched internally into a megatexture- I don't think so, though).

Moving stuff into the skybox space, if using the old HDR system, would mean that you could simply render the objects along with a sky in <pick your favorite application> in a panoramic view suitable for stretching around the sphere; that seems like a solid way to make sure the shadows are consistent.  However, this would mean syncing up shadows with the lighting in the HDR really perfectly, which is one of the many time-consuming boring things I want to entirely quit worrying about this time. 

What I want is a system where I plug in some variables and boom, custom sky.  And yes, that could be used for dynamic, real-time effects, although altering the sun's primary vector would mean rebuilding the shadowmap, which isn't practical frame-by-frame.  I could certainly change its colors or whatever dynamically, though.