[CGW121]

@ Shay
Its in the routes world tiles. Open with Context or some such editor and look for forest object. I put one in an earlier post. If it does not have a tree shape listed leave it alone.

@ Charlie
I am going to try that later after I get the routes mile post and sidings etc entered Then I can go back and edit the forest objects. I picked 3000 out of the air, but with msts it looked like a park rather than the densly packed trees of northwest Illinois. But I liked the result. Too many dynamic shadows got it to studdering as well.

[charlie]

CGW121, on 17 August 2011 - 11:49 AM, said:

I picked 3000 out of the air, but with msts it looked like a park rather than the densly packed trees of northwest Illinois.

Well, be careful. As you've noticed with some frame rate changes, setting all to the max might put you down on your knees, especially with the results for smaller forest areas.

I said I wouldn't do it, but I did. Here's a subjective comparison of where I left that last experiment. All Populations are edited to 1000. I really do not have a particular problem with the visual densities in MSTS.

Click on it...


1) The first pair of views is the maxed out forest size. Subjectively, if anything the MSTS view appears to be little more dense to me. :rolleyes: At any rate, I'll probably never find a use for a forest object 1000 meters on a side.

2) The second pair of views are of the 4x4 array, and the OR view is observably more dense.

3) The last pair of views is of both the 2x2 and single patch forests. I think the OR view shows absolutely unusable denseness. Too many small forests set this way is likely serious in OR.

That's all I'm trying to say.

Editing Populations to max is not a problem in MSTS. Throw rocks as you wish about other stuff, but somebody at Kuju did his best to protect us from ourselves. If you edit densities in the RE to max or edit world files populations to max, the actual achieved densities are limited the same way with the same result.

Might be something to look at in OR...

Charlie

[James Ross]

charlie, on 17 August 2011 - 03:19 PM, said:

3) The last pair of views is of both the 2x2 and single patch forests. I think the OR view shows absolutely unusable denseness. Too many small forests set this way is likely serious in OR.

It's hard for me to be sure, but could MSTS be limiting itself here based on the size of the trees? I'm not sure exactly how it places them (beyond "randomly") but it may well be intentionally avoiding putting any trees too close together.

[charlie]

James Ross, on 22 August 2011 - 09:59 AM, said:

...could MSTS be limiting itself here based on the size of the trees? I'm not sure exactly how it places them (beyond "randomly") but it may well be intentionally avoiding putting any trees too close together.

That's entirely possible, but there are no shape files (as *.s files) involved at all in MSTS forest objects, just ACE files. Each item in the object is a simple cruciform constructed by MSTS. You can apply any ACE file to the collection of cruciforms in a forest object.
http://msts.steam4me...ls/forests.html

For the demos in this topic, I used a default tree with unedited entry in forest.dat as follows:
Forest ( "JP1Tree1" "JP2AutoTree1.ace" 16.0f 20.0f 0.9f 1.1f )

The first number is width of the cruciform in meters and the second is height. The last two numbers are variability factors. With variability factors of 1.0, all trees/bushes would be the same size.

I do not know how the first (width) entry plays with final achieved density in MSTS. On the face of it, it looks like OR doesn't care about that anyway. If I get a little time I'll play some more with Demo 1. :thumbdown3:

Given what you can see in the last screenie I posted in this topic, the problem is not that we cannot achieve any density we want in OR. The difficulty is twofold. We have no "viewer" to see what we just did before we pop into OR. We presently have no tool to keep us out of trouble with excessive density when we edit world files. I might take a look at the last...

regards,
charlie

[James Ross]

charlie, on 22 August 2011 - 01:42 PM, said:

That's entirely possible, but there are no shape files (as *.s files) involved at all in MSTS forest objects, just ACE files.

But as you explained, they still have a height and width. MSTS could be, for example, laying out a grid of 'width'-by-'width' squres and then planting a tree in up to 50% of the squares. I doubt we really want to replicate all of it or anything, but it's interesting.

[Genma Saotome]

MSTS does take into account the width of the trees. Don't recall where I came across that but I do recall reading it somewhere and in fiddling around afterwards determined that's why my forests were not as densely planted as I thought they should have been. IMO, kinda a dumb feature given trees do touch.

[CGW121]

Genma Saotome, on 22 August 2011 - 05:24 PM, said:

MSTS does take into account the width of the trees. Don't recall where I came across that but I do recall reading it somewhere and in fiddling around afterwards determined that's why my forests were not as densely planted as I thought they should have been. IMO, kinda a dumb feature given trees do touch.

Exactly. Here in northwest Illinois, it is like a carpet of green. The way MSTS sets it up is totally unrealistic.

[charlie]

Genma Saotome, on 22 August 2011 - 05:24 PM, said:

MSTS does take into account the width of the trees. Don't recall where I came across that but I do recall reading it somewhere and in fiddling around afterwards determined that's why my forests were not as densely planted as I thought they should have been.

I've been working around that in the mountains of SW Colorado by providing at least a 100% overlap in evergreen forests. If two slightly different ace files are used, I think it turns out better. And then I went back into it and sprinkled a bunch of aspen tree stands.

Since I was already set up for it, I did look at the effect of the tree width entry in forest.dat. But first I "cleaned up" the Area entries in the world file to be exact fractional sizes. They are now ( 1000 1000 ), ( 500 500 ), ( 250 250 ), and ( 125 125 ). This provided for no more decimal fractions in the reported results.

1) This is the condition with the default 16 meter tree width after setting density in the RE to 99999, saving, exiting, and reentering.
- Densities reported by RE, left to right: 732 1536 2128 2496
- World file Populations: 732 384 133 39
Populations converted back to density are an exact match:
(732 x 1) (384 x 4) (133 x 16) (39 x 64) = 732 1536 2128 2496

2) Tree width increased to 32 meters in forest.dat.
- Densities reported by RE, left to right: 386 548 624 960
- World file Populations: 386 137 39 15
Populations converted back to density are an exact match:
(386 x 1) (137 x 4) (39 x 16) (15 x 64) = 386 548 624 960

With the aid of a screenshot, paintbrush and dollops of yellow paint, I could easily count the trees in the two smaller forests. When the numbers of trees are converted to trees per sq. kilometer, the final densities reported by the RE are proven accurate.

That allows me to "predict" that if I actually counted trees in the two largest forests in the wide tree experiment, I would find 386 and 137 there. I guess it's not for nothing that the parameter is named "Population". :sign_sorry:

regards,
charlie