Forest Object Density
#11
Posted 17 August 2011 - 11:49 AM
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.
#12
Posted 17 August 2011 - 03:19 PM
CGW121, on 17 August 2011 - 11:49 AM, said:
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
#13
Posted 22 August 2011 - 09:59 AM
charlie, on 17 August 2011 - 03:19 PM, said:
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.
#14
Posted 22 August 2011 - 01:42 PM
James Ross, on 22 August 2011 - 09:59 AM, said:
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
#15
Posted 22 August 2011 - 02:49 PM
charlie, on 22 August 2011 - 01:42 PM, said:
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.
#16
Posted 22 August 2011 - 05:24 PM
#17
Posted 23 August 2011 - 06:11 AM
Genma Saotome, on 22 August 2011 - 05:24 PM, said:
Exactly. Here in northwest Illinois, it is like a carpet of green. The way MSTS sets it up is totally unrealistic.
#18
Posted 23 August 2011 - 08:45 AM
Genma Saotome, on 22 August 2011 - 05:24 PM, said:
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