how do trees avoid rivers?

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:

attachment.php


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...
 
Back
Top Bottom