In my post-apocalyptic mod, there are city ruins which I have implemented as "features". Geomodder has been helping me out by creating a new nif file which has a better mixture of ruined buildings; see this post (http://forums.civfanatics.com/showpost.php?p=7122993&postcount=61) and around there in the thread.

In the screenshots, you can see that the ruined buildings appear right on top of rivers and roads. But, the forest feature is "smarter" somehow -- trees never appear on top of rivers or roads.

Does anybody know what part of the code arranges to have trees deleted when river or road appears there? We would like to clone / borrow this code for ruins as well.

It is the joys of the LSystem. Look in the XML/Buildings folder for the files. They are quite confusing and most people tend to clone or avoid them. Completely new graphics struggle at cloning them sadly.

Can you give me a little more information? For example, in vanilla BTS, with a bunch of rivers and forests, there are never any trees in the rivers. If this is done by the L-system, can you show me where? For example, is there something I could change to *remove* this behavior and have trees growing in rivers? This by itself is not useful, but if I am sure I understand how it works, then I can apply that to my ruins.

Hrm... I tried to look up more information for you and it seems that only improvements utilize the LSystem. Routes and Features are handled semi-seperately. Each entry in the LSystem has a field for "<Attribute Class="Scalar">bCutTrees:1</Attribute>" which would sure seem to be tied into the current issue, but I find nothing matching this in the DLL.

So I guess I am going to have to amend my assumption and instead state that it is controlled via "Resources/Themes/Civ4/Civ4Theme_Tree.thm"

Thus far I am very hazy on theme files at best, and I can barely tell enough about this one to convince myself that it IS for controlling forests. I cannot see just yet precisely how it is linked in to anything else to tell you how to manipulate attachment elsewhere. Best guess would be rename the file and load the game, see if you get an error. If so, hopefully it points you to the connection point. If not, load a game and see if you managed to break the ability of trees to be "smart" or not.

EDIT: Was curious so I toyed with changing this myself. No errors, and no change in tree behavior. So once again stumped.

Er, I *highly* doubt that the theme files are related to display of forests. I cannot tell offhand what the syntax in the theme file means. But, by the names of the other files in the themes directory, I believe that these have to do with nuts and bolts of gui elements like sliders and spinboxes. Inside Civ4Theme_Tree.thm, the only file reference is to Civ4/tree_icons.tga, which has inside it the little "+" and "-" icons you would use to open up levels of directory tree in a file explorer. I think that is the kind of tree it deals with, not the kind in a forest.

Are there any other types of files which might be related to not drawing trees on top of rivers?

Wacky partial guess based on no information: how about Assets/XML/Art/CIV4RiverModelInfos.xml giving a BorderFile like Assets/Art/Terrain/Routes/Rivers/xxx.dds. These dds files have a transparency layer which might correspond to the river course. Maybe forests get laid down first, and then rivers are selected. For each river which is selected, the related dds transparency layer is used to find where trees must be chopped.

Looking in BTS/CvGameCoreDll/*.h, I can see get/setBorderFile, but as far as I can tell it's never used for anything. I haven't spent much time (hardly any time) inside the SDK; but I can't find any trails to confirm or deny this theory. Anybody?

What I'm looking for is to have my feature nif file fill the square except for rivers and roads.

Yeah, I forgot to actually look at those icons first, and I figured it was a stretch when I peeked in there, but led myself on pretty well :)

Peeking at RiverModelInfos (and Route while I am at it), it seems to just be the definitions for the rivers themselves.

Maybe approaching from the opposite tack might prove useful? Find the NIFs for the forests and replace those with your Ruins, see where/what you have to modify to get them in by that method, and attempt to clone it at some point with a re-definition?


EDIT: This looks more promising:

Assets\XML\Terrain\CIV4FeatureInfos.xml - Contains pathways to the NIFs for the trees themselves. Refers to them as Symbols.

XML\Terrain\CIV4SymbolMeshPaths.xml - Contains entries for many things which would have to interact with other things. But I cannot seem to find the NIFs mentioned, even in the PAK.

EDIT2: Seems that Symbol was the key. It is still used to just mean "icon" as well in the DLL, but there are numerous locations where it is talking about features/routes/rivers and the map. Mostly in the CvDLLSymbolIFaceBase.h, but also in a few other CvDLL____.h files and in CvPlot.

Assets\XML\Terrain\CIV4FeatureInfos.xml - Contains pathways to the NIFs for the trees themselves. Refers to them as Symbols.

We got to this point in the original thread. For each feature, there are 15 nifs, which represent all the different combinations of corners: N, S, E, W, NS, NE, NW, SE, SW, EW, NSE, NSW, NEW, SEW, NSEW. There is going to be some code for figuring out which nif to use, based on which corners touch other plots of the same terrain. That is an interesting problem too, I'd like to make the new feature have rounded edges like forest does.

XML\Terrain\CIV4SymbolMeshPaths.xml - Contains entries for many things which would have to interact with other things. But I cannot seem to find the NIFs mentioned, even in the PAK.

This is a mystery. It is suspicious that there are 9 identical entries, for example for oasis or fallout. The index must be in some other place, maybe a C-level enum. Searching for "MeshPath" or "SymbolMesh" in the *.h, *.cpp doesn't find anything, so I don't know how to proceed on that.

EDIT2: Seems that Symbol was the key. It is still used to just mean "icon" as well in the DLL, but there are numerous locations where it is talking about features/routes/rivers and the map. Mostly in the CvDLLSymbolIFaceBase.h, but also in a few other CvDLL____.h files and in CvPlot.

Hm, I'll look into that tomorrow.

Well, CvPlot::updateRiverSymbol() is starting to look promising:

//force tree cuts for adjacent plots
[...]
ForceTreeOffsets(pAdjacentPlot->getX(), pAdjacentPlot->getY());

But then I stall again because ForceTreeOffsets isn't defined anywhere I can see. If ForceTreeOffsets only deals with trees and isn't programmable, we may be stuck. I'm not good enough with nif to create the 15 nif files needed to replace trees. If I could, or somebody could, maybe we could make the feature as a FeatureVariety of the trees?

gDLL->getEngineIFace()->ForceTreeOffsets(pAdjacentPlot->getX(), pAdjacentPlot->getY());

You left out the "gDLL->blah" part in your post above. I think, and an accual SDK elite can correct me if I'm wrong, that gDLL->getEngineIFace() is returning the exe object and calling ForceTreeOffsets from that.



And glad to see you are looking into the SDK davidlallen. I think you will be able to do alot of the stuff your asking about over the last few weeks, once you get the basics down. :goodjob:

You left out the "gDLL->blah" part in your post above. I think, and an accual SDK elite can correct me if I'm wrong, that gDLL->getEngineIFace() is returning the exe object and calling ForceTreeOffsets from that.

It is true that I trimmed out the bits which did not seem relevant. But the point is, I can't see any way to figure out what ForceTreeOffsets does or how to make it work on my new feature also.

And glad to see you are looking into the SDK davidlallen. I think you will be able to do alot of the stuff your asking about over the last few weeks, once you get the basics down. :goodjob:

Thanks for the encouragement. Note that I still have no interest in *compiling* the SDK, that is the hard part. Reading the code is easy.

Yeah, at that point it goes into the EXE and there is nothing which we can do. But if you expose that function call to python then you could play with applying it when YOU want to do so. See what happens when you apply it to some tiles with rivers and your new graphic (though I am reasonably certain that you NEED to have the NIF split up into multiple parts because it is actually placing numerous Forest NIFs to accomplish the look of each tile).


Other promising functions are the ones which call on updateRiverSymbol, most notably at the moment would be setNOfRiver & setWOfRiver. Both of those are called during ::doRiver, but that seems less useful than shortcutting straight to the functions to see what can happen.

This mystery function ForceTreeOffsets must make some decision about which features to modify. Evidently it modifies only the forest and jungle feature. Is that because it modifies all features which have the 15-nif variants? Or is there some flag which we can't spot immediately to tell it what to do? Or are the names "FOREST" and "JUNGLE" hardcoded into it?

We know from experimentation that a feature with a single nif (our city ruins feature) does not have this function applied, or at any rate it is not having any effect. So we see ruined buildings on top of the river. What we are trying to figure out is what we can do differently, so that ForceTreeOffsets will remove the buildings on top of the river. It would be some amount of work to create the 15 correct nif variants and make sure the game is using them right; so before trying that I'd like to know if that is enough.

Can anybody give us more insight into what is actually happening to remove the trees on top of rivers?

I believe its hard coded. Just as road and river intersections are hard coded (placing bridges, etc), and forests and jungles account for roads passing through them.

I would not assume that making 15 variations would account for either road placement or river placement.

It is definitely NOT hardcoded. I just went into my FeatureInfos and copied all the data for Forest into a second field, renamed it to Forest2 (different enough a program can't link them, even if minor) and bumped it up to provide 100 Commerce so I could tell the difference between them. End result was that it translated the forest into 3 different versions for me (Normal, Arctic and whatever the other thing is, looks also normal), and they still reacted properly to rivers and roads.

I would say it is worthwhile to get someone to cut up the NIFs you are using and try placing some in the position of the Jungle Nifs. Worst case scenario you completely replace Jungles and just do without them in the Post-Apocalyse, mildly appropriate anyway. Best case scenario, you see that it looks horrible and doing any further work is pointless ;) But maybe something will finally give us an error and point at a new location to investigate.

Could it be tied to the Tile Art Type?

Ok, so the 3 types of Forests appeared because of 3 cases of <FeatureVariety> setups.

The multiple NIFs are all listed in each Variety as Feature Art Pieces.

Deleting 2 of the 3 Varieties caused no Issue.

Deleting all but 1 of the Art Pieces resulted in a very small clump of trees in the middle of the tile which still reacted to road placement.

I changed out the TileArtType to be NONE, and on a lark I changed FfH's Ancient Forests to be defined as TREES in this field. End result: My new trees quit reacting to roads, and the Ancient forsts started doing so. It would appear your answer may be as simple as creating 15 (or however many you want to fill the tile) NIFs and calling them TileArtType TREES.



I am curious what the FeatureDummyNodes are used for....


Anyway, things are loaded via CvInfos.cpp: CvArtInfoFeature::read. Lots of very non-standard lines of code in here, so I am pretty sure this is where things get linked up in the EXE or wherever it is being handled.


EDIT: New test: I placed 15 copies of the same NIF for the Ancient Forests using the connection schemes from normal Forests to see how it looked in game. I am suspecting that it will fill in the tile more and react to roads/rivers properly, while not looking like an empty parkinglot. End result is what I wanted: The tile is filled with the trees, reacts to rivers, Mountains and Roads properly. So your answer is pure XML if you want it.

Awesome! It seems that you made two changes, and then the proper cutting happened. First, you used something which already had the 15 nifs. Second, you changed the TileArtType to TILE_ART_TYPE_TREES. I cannot experiment for another 6 hours or so; but what happens if you apply TILE_ART_TYPE_TREES to something which does not have 15 nifs? These are two separable aspects of display. I'd *like* to have 15 good nifs, but I don't. So if the tree cutting happens for anything with TILE_ART_TYPE_TREES, then I can get by with one nif.

There is a specific nif to try, if you want, in the original thread (http://forums.civfanatics.com/showpost.php?p=7125434&postcount=65) which spawned this. All the files should be there in the rar. Does your magic work on that?

The 15 NIFs isn't so much to use seperate NIFs, I used the same one for everything. It is for the Connection types. Not having those means your NIF will only be placed dead center in the tile. Having all 15 means you will fill the entire tile if allowed to do so.

So all that you NEED is to define TILE_ART_TYPE_TREES, but that gives you a boring, nearly empty tile with just a single non-connected NIF. Make it that same NIF with 15 Connections (might get away with fewer, haven't tested that) and you get a much nicer effect (and if the tile has no road/river, it looks just like it would the normal way)

EDIT: Tried it out real quickly, and having all 15 fields with that NIF caused my system to slow down considerably, and they were appearing beneath my terrain. So just subbing them in for the Forests I was using doesn't work so well :)

I did try things out again with a single NIF definition this time, and it seems that just listing <Connections>NW NE SE SW</Connections> fills the tile nicely enough, so no need for a full 15 NIFs. I kinda figured as much, but wanted to change as little as possible in initial tests :)

Mildly curious why Ice defines 3 NIFs per connection type. A tad bizzare.

Great find Xienwolf (and very good news on the ancient forests as well)!

Ewww... I take back my comment about just using NW NE SW SE and being covered. It splashes the feature out along the neighbor tiles. when you do that (did it with Scrubs and it was very obviously just 4 copies of the same NIF centered on each corner)


Now that I am looking at individual tiles instead of huge chunks it seems even with the full 15 entries (and a 16th with no connections listed) it is doing the same thing. So need a smaller NIF file. But I really want to know why a normal forest doesn't overflow the tile the same way....

Seems like using no connections listed on Scrubs resulted in the same 4 way duplication of the original NIF on a blank tile.


Oh, and there are 3 NIFs listed per entry on Ice because it uses Half_tilting instead of Trees. The options for the field are:

TILE_ART_TYPE_NONE = -1,
TILE_ART_TYPE_TREES,
TILE_ART_TYPE_HALF_TILING,
TILE_ART_TYPE_PLOT_TILING,
NUM_TILE_ART_TYPES


I would suspect the reason the Forests remain in the tile is that each of those 15 NIFs are set up to work only in the appropriate corner to keep it in the tile. So if you cut your city Nif into 4 pieces, place each of them off-center, and assign the proper connections, you should be good.


No luck on figuring out what the bGenerateRotations field does.

FeatureDummy node holds a Tag and a Name, and nothing in plain BtS uses it.... maybe a Final Frontier thing? Yup, used for Orbit rings in Final Frontier. Might be nifty for the Ring of Carcer in FfH, but not going to get into playing with those just yet. Need to do some work again at actual "they pay me" work. ;)

The 15 NIFs isn't so much to use seperate NIFs, I used the same one for everything. It is for the Connection types. Not having those means your NIF will only be placed dead center in the tile. Having all 15 means you will fill the entire tile if allowed to do so.

So all that you NEED is to define TILE_ART_TYPE_TREES, but that gives you a boring, nearly empty tile with just a single non-connected NIF. Make it that same NIF with 15 Connections (might get away with fewer, haven't tested that) and you get a much nicer effect (and if the tile has no road/river, it looks just like it would the normal way)

I don't understand. I have a single nif which fills the entire square. You are saying that if I use that, I will wind up with a nearly empty tile? What is responsible for trimming away my buildings? I have not looked into the details, but I assumed that the 15 nifs were in charge of "corner trimming", and if I didn't have the 15 nifs then I would not get any corner trimming.

Craps. I did some final testing before I went back to work using Scrubs, which were not built with roadcutting in mind initially, and even setting them to be Trees didn't respond to roads properly. So there is still something that needs sorted out with the NIF side of things (nodes maybe?)


This will probably come up with your stuff as well. But if it was initially based on city sets, which that post you linked seemed to indicate, then maybe not. I suspect it relies on having multiple nodes in your NIF which it will decide which to keep and which to remove based on a location of road/river relative to that node.

Also not sure how it decided to place the Ancient Forest only in the center of the tile, but it decides to duplicate the scrubs 4 times and place them on each corner.

Also, I can't seem to duplicate the "trees only in the middle of the tile" thing anymore. Now it is even placing 4x the Ancient Forests. It might be that when I did that particular test I was surrounded by Rivers or something.

I have been working with Geomodder on this one, and I have pointed him to this thread. Probably each of us will do some experimentation on this. If it's a one word change in the XML, that will be tremendous. Thanks for your help so far.

I sure hope you guys figure this out. That's the main obstacle for creating new foilage types and lot's of other stuff.

I did a small amount of work with resource graphics which do some of the same things, (well, they're supposed to at least) and poking around with nifscope I noticed that in the case of the 'cotton' resource the geometry consisted of about 7 or so different models of cotton pieces along with the house and rack that were clearly intended to be arranged depending on the circumstances. That functionality broke when I tried to change the name of the directory that the resource was in, and instead I got the whole set of models all at once. I could never really figure it out so I could make some new leafy resources.

Well, I'm still stuck. The magic word TILE_ART_TYPE_TREES is not enough. I have created a small standalone testcase. I created two features, FEATURE1 and FEATURE2. FEATURE1 is the ruins.nif created by geomodder, which is what I want to use. FEATURE2 is a copy of treeleafy01_15.nif with the texture set to bright red. The files are here, unzip into your My Games directory so they go into customassets:

http://jendaveallen.com/fury-road/ruins-cities.zip

Use worldbuilder to load file feature-12.wbs, and look in the center of the continent. The bright red trees are hard to miss.

When I set FEATURE1 to TILE_ART_TYPE_TREES, it doesn't display at all. When I set it to TILE_ART_TYPE_NONE, it displays as a full plot of buildings, and the buildings appear on the rivers. Neither of those is what I want.

When I set FEATURE2 to TILE_ART_TYPE_TREES, it avoids rivers, and spreads over the nearby half of the adjacent plots. This is the behavior I want. Well, I do not really want the spreading, but I accept that I can control this by supplying a full set of 15 nifs.

You can see FEATURE1 at the left and FEATURE2 at the right in the screenshot:

http://forums.civfanatics.com/attachment.php?attachmentid=185694&d=1218589739

Based on xienwolf's great research so far, I was hoping that just using TILE_ART_TYPE_TREES on the FEATURE1 would be enough. However, in order for TILE_ART_TYPE_TREES to work correctly, it appears that something in the nif must be done differently.

Now the question is, can somebody rebuild FEATURE1 so that it avoids rivers, or suggest how to do it?

I know almost nothing about nifskope except how to run it. I brought up the two feature nif files and looked at them. The structures seem pretty unrelated.

In the treeleafy file (FEATURE2) there are two shapes: one contains all the trees, and another contains what seems to be one boundary square for each tree. I assume that this arrangement is critical -- the boundary squares are tested against the river somehow, and for each boundary square which overlaps the river, the corresponding tree is removed. I cannot see how a boundary square is linked with its tree, but I assume this information is in the nif somehow.

On the other hand, the ruins file (FEATURE1) has a deep hierarchy of shapes with specific names, and no boundary squares. So converting this into a form matching the treeleafy nif would appear to require redesigning it from scratch. That is certainly way beyond me.

Unless somebody has a good insight into how the nif could be rebuilt, it seems that new features which behave correctly with rivers and roads are beyond the reach of today's modding technology.

Ok, toying around with Jungles, since they seem to be the easiest of terrains which act "properly"


Jungle01_01.nif - Contains a small square with some trees on it. All of them are located in one quadrant of the vertices when I open it with NIFScope. Pointing the camera to look with Green Arrow pointing up and Red Arrow pointing right, this places them in the NorthWest Corner, which coresponds to the <Connections> field for the NIF in the Art Define.

Trimming all the other FeatureArtPieces from Jungle and loading the game, placing a single square of Jungle results in 4 "jungle chunks", one in the square I clicked on and the tiles to the North, West & Northwest. Passing a road through one of these causes some trees to move/clear.


Not too surprisingly, with Jungle02_02 I open it in NIFScope and see it is in the NorthEast quadrant (again, green up, red right), just like the Connection would indicate.

I trim the XML to only contain this NIF and place it in the world to see the results: Sure enough, 4 "chunks" are placed, North, East, and Northeast tiles and the one I clicked on. Each reacts to roads.


Now, models are NOT my thing, so this is mildly foreign territory. However, the NIF doesn't seem to hold much data. I know that KFMs need to be in the same files as the NIFs they work with, and I don't see how they would use an animation to do the clipping, so that I don't have to worry about.

One thing I have noticed is that if I view the Block List there is an entry for the Shadow and one for the Scene Root. In each of them there is a cute little Painter's Pallet and a trees.dds entry. I can delete either of these without much notable change in the displayed model (deleting the pallet causes things to move from glaring white to a relaxing grey). Deleted the DDS entry and loaded the game, no noticeable difference sadly.

Removed the Pallet, this time the game crashes when loading the map.


Just spotted a ton more information when I had the BlockDetails field set to display as well. Not quite as simple of a file as I was initially thinking from the other view... so I'm heading to bed for the moment :) I was really hoping when I opened the NIF that it wouldn't all be one big chunk of trees, but rather a collection of individual ones, corresponding to the ones which can be removed for a road/river....


EDIT: I didn't look at the same NIF you did, but I suspect the boundary boxes you are talking about are the shadows. We're both out of our normal field though :) Need someone with 3DS Max to pop in at this stage :(


EDIT2: Morning update. I mixed some NIFs to see how the connection things work precisely. I placed Ancient Forests (basically recolored normal ones) in the NE, NW, NE NW, NE SW, SW blocks and the snowy forests in the other blocks. Placing the new mesh forest into the game with a single tile gets you mostly Ancient Forest, with a small patch of Snowy forests in the North Eastern corner. But placing a large section of them results in a huge area of Snowy Forests that has a BORDER along the West and South which are Ancient Forests.


The fact it is along the West and South seems to indicate that the NIF used is selected based on which neighbor tile shares the feature. So it would seem that the base tile (no neighbors) is a light mixture of the 15 NIFs. If the neighbor to the NorthEast (and only that one) is also a Meshset, then it uses the NE connection NIF on this tile, and the SW Connection NIF on the other one (combined with the light amalgamation from the base tile).

This is supported nicely by the Mesh in tests by showing Ancient Forests in all 3 tiles when I do the SW & NE tiles (there is still a small snowy tree in the northeastern corner of each tile), and then showing mostly Snowy trees when I instead do the SE & NW tiles (with a cross-hatch of Ancient Forest running from SW to NE on each individual tile)

Now, while an isolated clump is mostly Ancient Forest, a Surrounded clump is ENTIRELY Snowy pine. Not quite sure what to make of that yet. But I am trying to think of how I can use a combination of Jungle, Snowy Pine, Evergreen & Ancient Forest (too hard to tell the difference between Evergreen & standard Leafy to use that one) to see how the meshing works a little bit better.


Also just realized that the trees sway in the wind, so there might be a KFM for them afterall. Perhaps something can be learned from which clumps sway as one piece?


I decided to go simple and just placed one of each of the various types into a blended Feature type, as the NE, NW, SE, SW connection types, leaving the other options blank.

Placing a single tile of this results in all trees staying ON the tile. I assigned Snowy a connection of SW, and it appears on the NE of the tile. So that is how the base tile is made, fairly easy and nice there.

Adding a single neighbor in any direction results in some trees being placed off-tile. In each case it is the Jungle style of trees, which happen to be listed first in the XML. And in each case the trees are sticking out to the North & East if possible (so if I place them to the NorthEast or SouthWest of the base clump, nothing. Place them due West of the clump, to the north, place them north of the clump, east). Jungle happens to be my connection NE. Swapping the order in the XML shows that having Ancient Forest (NW) listed first results in the AF being used each time, and appearing to the North and West of the meshing. So if it cannot find the appropriate connection type it apparently defaults to the first listed in the XML, and since it is placing it in the "wrong" spot, the result is trees appearing on tiles you don't want them to appear on. This becomes much more evident when I place numerous forests on the map, as I wind up with nothing but small clumps of Jungle except at the corners of the forested area where the other 3 begin to show up.

I believe having figured out the missing peaces.

If someone needs more painfull technical details, give me a note.

The tiling works basically as Xienwolf described:
*The niffles are alighned at plot cornes;
*Depending on how many/which plots adjacent to a corner have the feature, a appropriate niffle will be choosen.

I did not investigated the works of "Feature Variety" yet - i.e. when snowy trees get displayed instead og the other ones...

The Tree Cutting (and adjustment to terrain Height map btw.):
*A Geometry object has NiStringExtraData; It is a list of coordinate pairs (called Offsets there) - check any forest niflle for example.
*If the coordinates of one offset are within a tree cutting area, the trees associated with this offset will be removed.
*What tree belongs to which Offset is coded in the vertex colours of the mesh (Since all trees are a single mesh...)
* From what i see the mere existence of this offset list makes the trees sway (even without the proper VC)

Tree Cutting Areas:
* Road/Railroad (apparently area=mesh)
* Water
* LSystem Obejcts (i.e. Cities) seem to have a tree cutting raduis defines
* TreeCut objects in the nifs (Terrain, Improvements, Ressources) - check Forest Preserve for example. Rivers do have TreeCut objects as well (despite beeing routes, they seem to work different from Roads)

Open Questions:
* Can we have Tree Cutting without sway ?
Ruins swaying i the wind won't look good... Right now it seems that the same information in the nif is responcible for both... So the answer is probably "NO"... But maybe people with some code insight can tell more (I.E. where are the "TILING_TYPES" defined ?)
* Can "CutTrees" Object be made work on units ?
My first tries on this were not successfull... But again... Maybe someone can see somethig i missed.

The only tile types are:

TILE_ART_TYPE_TREES,
TILE_ART_TYPE_HALF_TILING,
TILE_ART_TYPE_PLOT_TILING,


As I recall, Half Tiling was used for Icebergs. Can't remember seeing Plot Tiling anywhere, might be a Final Frontier thing.


Overall, nice work. I can see that the location of things which are important have been isolated mostly, but have no experience in the graphics side yet, so can't make heads or tails out of most of the post beyond "we know more now" :)


I assume that feature variety just comes to play when the adjacent plot has a different feature type, so that they mesh into one another.


Having Units cut trees might look a bit odd, but it would allow for taller forests without blocking unit models, so it would be nice. For the swaying buildings in the ruins, you might be able to cheat by having a large transparent section above the roofs (so basically the entire ruins structure counts as a tree-trunk.

I already tried the different tiling options. TREES is the only one wthat will have cutting (and sway).

I had asked for where the possible types came from hoping there was maybe something in the SDK that would allow to control the sway... I have found it now, and there seems to be nothing usefull.

I am rather sure adding additional "fake" objects to the nif won't help, as the sway is applied based on the vertex height - so while the higher objects will sway more, this will not prevent it on the lover ones.

Tree cutting on units is not possible from just the Nif. I am afraid the SDK does not have nothing helpfull either.

Well, what I suggest is probably completely impossible as I don't understand the graphics and am making a blind programming analogy.


Can you attach the Building Data to a Tree Node? Such that the extra Graphic of the Building will only appear is a specific tree is placed? Then you can shrink the tree (which sways) to fit inside of your building (and thus not be seen), and the building will be a completely seperate graphical entity, thus ought to be immune to the sway programming.

Kinda like how weapons are attached to units I guess.

I think this is not possible.
Edit.: Actually i am sure that is impossible unfortunately. The tree cutting (and the sway) is applied on sub-object level - directly to the vetices - and you can only link something to the object itself.

Another question... Do you know something in the code that would maybe allow to disable tree sway completely (globally) - i mean on forest as well... It's bettet to have both forest and ruines static, than to have both swaying...

The trees keep sway even on "frozen animations"...

I am thinking maybe detail manager or something... I found nothing so far... but maybe others have a idea...