OSP Kit Optimisation Flora Kinds Source

Users who are viewing this thread

xenoargh

Grandmaster Knight
What is this?

This is a coder's tool- it replaces the stock build_module.bat and modifies the 1.134 Flora_kinds to integrate with standard Module System builds for Warband. Simply unzip to your source directory and overwrite the existing build_module.bat.  Does not require any changes to info or any other file changes.  Writes the final output to the /data folder, which is the expected behavior.  IOW, code, fire and forget.

If all of the above is confusing to you, you don't need this yet- if not, you're probably eager to hack this instead of doing it the old way :smile:

Linky
 
A couple of notes:

1.  To do the fancy stuff, like new grass mixes, you will need new grass skins and meshes.  This gets tricky; basically, the requirement is that they're all on an atlas.  I've done it and the guy who did the "whole world looks like fall" thing did so, also.  The ancillary price is that you currently have to ship with a modified materials.brf or at the very least, a different grass texture file.  This is problematic for a variety of reasons that I suspect only me and three other people care about, but be aware that it's not entirely risk-free.

2.  You can do some fairly powerful stuff with this, by playing with frequency settings and adding new objects that can be spawned.  For example, you can place a few village hovels on maps occasionally or make the grass a lot more dense (warning, this costs some GPU).  Taleworlds was working on a "cluster" feature that would have allowed to do that and perhaps have clustered objects around it; the code's there, but I don't know if it works yet.

3.  Anything that isn't fkf_grass gets drawn into the baked shadowmaps for the level's static geometry.  This is usually a good thing, but can produce some strange results with stuff that's using the grass material that is not using fkf_grass, because the shader uses a distance-from-camera trick to hide geometry culling, so you can have shadows for invisible things.  It's a tradeoff; ideally, you'd probably be better using a different material and incorporating a one-triangle LOD for distance LOD, but depending on how far away it is, and how large it is, you won't have perfect choices.

4.  Trees are one of the most powerful examples in the file.  Use the code to create various "forest mixes" of realistic terrain.  I'm seriously thinking that I need to include stumps and fallen trees into my forest mixes, along with some rocks.

5.  There's a fkf_rock setting.  So far as I can tell, rocks are functionally identical to trees; it's a mesh and collision reference, they're both dealing with the ground in similar ways, and both can use LODs.  The engine only rarely generates a "rocky" terrain, though, while usually generating considerably more trees and bushes.  I think it's fair to say that in most cases, one wants to mix some rocks and other debris with trees to create a natural feel to forests.

6.  It's doubtful that you can include more than one fkf_guaranteed item per terrain type.  That seems to be reserved for grass.

7.  None of the content generated can be searched, post-processed, or otherwise altered.  Which is too bad- I'd like to randomize the density for grasses and things.  But it's still pretty powerful.

8.  Whatever code deals with which mix of objects is picked is black-box code, like the code dealing with AI weapon choices.  I hope that as people play with this to create more interesting terrains that they figure out what does what and document it here.

Oh, and ... if anybody is bored... I'd like some desert plants and some sandstone rocks, to prototype a better desert with.
 
This should save some time. Thanks!
Is there a limit on how much flora can be included in a single terrain type?
 
Simple answer:  I don't know.  I've built a sampler for grass that uses 20 different grass meshes, and it worked just fine, though.  Still puzzling out the fkf_point_up system, to see if it would support quad billboarding for grass.
 
OK, broader testing has been done.  Looks like you can do some pretty big things without losing much if any performance with stuff using fkf_grass, so long as it's using the grass material and grass.dds texture (which you can modify).  It's very easy to build the atlased stuff for this- it's just quads, triangles and strips.  These objects don't cast shadows to the shadowmap, which is good, since they don't render up close.  You don't want to use this for large bushes, but it works great for small flora.

I've built a "weed mix" test, and it had 67 different categories- it worked.  The limit's probably < 255, but it's almost certainly > 100, which ought to be massive overkill for practically any purpose.

Strongly recommend that people try out different mixes now that you can, it can make your battlefields feel incredibly unique.  For example, I set up one mix that basically is mainly flowers all over the field.  Messing about with tree settings can also produce some really interesting results- try building clones of one tree type def, but with 3X density, for example.  I am planning to do dense underbrush that occasionally generates in forests, just for realism's sake.
 
S'more notes, because, well, you can hit some issues, if you're as dumb as me, and decide it would be a "great idea" to just dive into whole new re-writes of things.

1.  Double-check your speeling.  One typo == CTDs, without any helpful RGL errors in the log; because this feature of the engine wasn't intended to be modded and has only been opened up recently, the RGL log doesn't handle exceptions at all gracefully.

2.  Don't make giant changes in one go.  I'm going to raise my hand, and admit that yup, I'm that dumb.  Because of issue no. 1, you will find yourselves trying to hunt down the errors for hours. 

3.  I'm still exploring performance limitations, but I think that it's fair to say that, as a general rule of thumb, you want to keep the total number of non-guaranteed spawned items using fkf_grass under 2500 (i.e., that is the maximum that will be spawned, for all types) and all of the objects that don't use fkf_grass are fairly expensive, because they draw at all distances and impact the generation of the static shadowmap (i.e., levels take longer to load).  There are probably other factors that can add to expense, but I haven't identified them yet.
 
Oh, and one more note (a correction, actually):

It is not just the fkf_grass setting that determines whether an object is drawn to the static shadowmap.  The shader on the object also seems to play a part.  What that part is, and what the performance ramifications are, I don't know yet.
 
This is wonderfull information. Thanks. I'll post my good mixes and notes here as well when i start messing with it.
Btw, is there any setting to adjust the distance at which fkf_grass items are loaded.
Thanks again for posting your results and notes, i couldn't find any info about flora_kinds anywhere in the forum last time i looked.
 
what i tried for myself before reading this thread was to make more other plants into a plain/steppe like scene via adding them as fkf_tree. since forest scenes have mostly same amount of trees you can handle it that like a bit.
 
ahh that is what you ment

well yeah i push down the other tress density to prevent that problem.

not a big problem since i want a free steppe with more plants than trees in it.

still have forest scenes where i can make enough trees :smile:


to the second:

crap :/ !

would  have been really good if they had made this flora system better...

i thought there is maybe something more in it. i dont know much of coding but i thought maybe it could have been more like when scripting LUA´s.


well if u have any other hint for me with this system would be really great!

BTW. what is the code u mentioned in second post here ? "Taleworlds was working on a "cluster" feature that would have allowed to do that and perhaps have clustered objects around it; the code's there, but I don't know if it works yet."


and where can i get it from ?

regards

kabs
 
BTW. what is the code u mentioned in second post here ? "Taleworlds was working on a "cluster" feature that would have allowed to do that and perhaps have clustered objects around it; the code's there, but I don't know if it works yet."
fkf_has_colony_props... but I really don't have a clue as to what it does or how it's supposed to work, due to the lack of any examples; it would appear to need a colony tuple referring to another object, but it doesn't seem to want that.
 
ahh i see. yep i was also wondering about how it works :I

sadly also dont know :/

cant understand why tw doesnt make better exsamples there...
 
well i ask around and it seems that colony_props arent working... tw just didnt write it down there -.-
 
Back
Top Bottom