Elvas Tower: Forest Enrichment - Elvas Tower

Jump to content

Posting Rules

All new threads will be started by members of the Open Rails team, Staff, and/or Admins. Existing threads started in other forums may get moved here when it makes sense to do so.

Once a thread is started any member may post replies to it.
  • 9 Pages +
  • 1
  • 2
  • 3
  • Last »
  • You cannot start a new topic
  • You cannot reply to this topic

Forest Enrichment Enhancing Forest Region Definition Rate Topic: -----

#1 User is offline   longiron 

  • Open Rails Developer
  • Group: Status: Elite Member
  • Posts: 3,179
  • Joined: 25-July 08
  • Gender:Male
  • Location:Manasquan, NJ
  • Simulator:Open Rails, MSTS editors
  • Country:

Posted 16 November 2015 - 05:47 PM

I would love to be able to define at least three different ace files within the same forest region. Unfortunately, MSTS compatibility restricts Forest region definition to a single ace file as per below

Forest ( "MSMajesticOak36A_01" "MSMajesticOak36A.ace" 41.0f 30.0f 0.9f 1.1f )

What would be great is to define a Forest region as follows:

Forest ( "Diversified NE Forest" "MSMajesticOak36A.ace" 41.0f 30.0f 0.9f 1.1f 60; "usdecidtree1.ace" 16.0f 18.0f 0.9f 1.1f 30; "US2autofir1.ace" 12.0f 22.0f 0.9f 1.1f 10 )

so the forest would be populated with 60% Oak; 30% USdecid and 10% fir trees

Comments?

chris

#2 User is offline   roeter 

  • Vice President
  • Group: Status: Elite Member
  • Posts: 2,420
  • Joined: 25-October 11
  • Gender:Male
  • Country:

Posted 17 November 2015 - 01:15 AM

Fully agree, I would welcome such a move not only to have a mixed forest, but also to have multiple ace files for the same kind of tree so we can get some variation in these 'forests of clones'.
One way to do this is to follow the same path as for the signal definition files. The program could search for a 'forest.dat' file in the OpenRails subdirectory in the route's main directory, and use this more extended definition if it finds it. This would allow the route still to be opened in MSTS, which is required for using the route editor.

Regards,
Rob Roeterdink

#3 User is offline   disc 

  • Foreman Of Engines
  • Group: Private - Open Rails Developer
  • Posts: 818
  • Joined: 07-October 12
  • Gender:Male
  • Simulator:OpenRails
  • Country:

Posted 17 November 2015 - 02:01 AM

View Postroeter, on 17 November 2015 - 01:15 AM, said:

Fully agree, I would welcome such a move not only to have a mixed forest, but also to have multiple ace files for the same kind of tree


Or an UV mapping support, so a single texture can contain multiple tree textures, to save draw calls.
But the best would be a full 3D shape forest support, with viewer facing materials. But i didn't see svn commits about the graphics, since long time.

#4 User is offline   James Ross 

  • Open Rails Developer
  • Group: Status: Elite Member
  • Posts: 5,488
  • Joined: 30-June 10
  • Gender:Not Telling
  • Simulator:Open Rails
  • Country:

Posted 17 November 2015 - 07:13 AM

View Postlongiron, on 16 November 2015 - 05:47 PM, said:

What would be great is to define a Forest region as follows:

Forest ( "Diversified NE Forest" "MSMajesticOak36A.ace" 41.0f 30.0f 0.9f 1.1f 60; "usdecidtree1.ace" 16.0f 18.0f 0.9f 1.1f 30; "US2autofir1.ace" 12.0f 22.0f 0.9f 1.1f 10 )

so the forest would be populated with 60% Oak; 30% USdecid and 10% fir trees

This is a unique syntax (the semicolons) so I'd like to avoid that, but the idea is principally sound - and has come up a few times before, IIRC. Same goes for the suggestion from disc to use shape files.

If adding new parameters after the existing ones works in MSTS, we don't need to support forests.dat in an OpenRails subdirectory, but I would support doing so as a means of separating content. I'd start with the above example but without the semicolons.

#5 User is offline   roeter 

  • Vice President
  • Group: Status: Elite Member
  • Posts: 2,420
  • Joined: 25-October 11
  • Gender:Male
  • Country:

Posted 17 November 2015 - 07:41 AM

Quote

This is a unique syntax (the semicolons) so I'd like to avoid that, but the idea is principally sound - and has come up a few times before, IIRC. Same goes for the suggestion from disc to use shape files.


What about using 'proper' stf rules?
The above example would then become :

Forest ( "Diversified NE Forest" ( 3
                  Forest ( "MSMajesticOak36A.ace" 41.0f 30.0f 0.9f 1.1f 60)
                  Forest ( "usdecidtree1.ace" 16.0f 18.0f 0.9f 1.1f 30)
                  Forest ( "US2autofir1.ace" 12.0f 22.0f 0.9f 1.1f 10 )
                                 )
       )


MSTS would not be able to read that, but that's no problem if we use the OpenRail subdirectory.

Regards,
Rob Roeterdink

#6 User is offline   James Ross 

  • Open Rails Developer
  • Group: Status: Elite Member
  • Posts: 5,488
  • Joined: 30-June 10
  • Gender:Not Telling
  • Simulator:Open Rails
  • Country:

Posted 17 November 2015 - 08:02 AM

That works too, but it would probably require the use of the OpenRails subdirectory. I'm mostly ambivalent between them.

#7 User is offline   eolesen 

  • Superintendant
  • Group: Private - Open Rails Developer
  • Posts: 1,546
  • Joined: 30-October 10
  • Gender:Male
  • Simulator:ORTS
  • Country:

Posted 17 November 2015 - 09:47 AM

I like this idea. I really like this idea. I'd like it more if we can define a matrix pattern (e.g. clustered towards the center, evenly distributed, grid distributed). I've given up on the idea of a polygon definition for the boundaries.

Can we also try the same named set idea for car spawners, with an override to use a named set (vs the default) so that my side streets can have small cars, my country roads can have tractors, and my highways can have cars, trucks and buses?...

#8 User is offline   gpz 

  • Superintendant
  • Group: Status: Elite Member
  • Posts: 1,771
  • Joined: 27-October 12
  • Gender:Male
  • Location:Budapest
  • Simulator:OpenRails
  • Country:

Posted 17 November 2015 - 10:51 AM

An example forests.json in JSON format would look like this:
{
    "Diversified NE Forest" : {
        {
            Shape : "Oak.s",
            Textures : ["MSMajesticOak36A.ace"],
            ScaleRange : [0.9, 1.1],
            Probability : 60,
        },
        {
            Textures : ["usdecidtree1.ace", "usdecidtree2.ace", "usdecidtree3.ace"],
            Size : [16, 18],
            ScaleRange : [0.9, 1.1],
            Probability : 30,
        },
        {
            Textures : ["US2autofir1.ace"],
            Size : [12, 22],
            ScaleRange : [0.9, 1.1],
            Probability : 10,
        },
    },
    "etc..." : {
        {
            ...
            ...
        },
    },
}

;) This format can be extended by any number of additional keywords to fulfill all ideas.

#9 User is online   Genma Saotome 

  • Owner Emeritus and Admin
  • PipPipPipPipPipPipPipPipPipPipPipPipPip
  • Group: ET Admin
  • Posts: 15,308
  • Joined: 11-January 04
  • Gender:Male
  • Location:United States
  • Simulator:Open Rails
  • Country:

Posted 17 November 2015 - 12:18 PM

A couple of observations: Once you alter the content of how a forest is described in the world file you can no longer expect to be using RE for editing. RE might simply ignore the entry... or fail to read more of the .w file... or abort. Whatever it is, the forest now becomes a problem.

I think the most straight forward solution is simply have a side-by-side file in the \world directory that has a different suffix. For discussion purposes lets call it .ORW (or .WOR, it doesn't matter). Put the new forest definition there. Change the loader so it looks for both file types and read the second one when found, appending it's data content to what the other paired file contained. For OR itself it would appear as it all came from one file.

As other ideas for object placement get approved, add those to the .ORW/.WOR file. When there is an Open Rails editor, flip the responsibility for which file is primary (IOW the .w file is left over to hold whatever the OR editor cannot yet handle). This effective makes the .ORW file the go-forward file so an initial decision on json/kuju/xml/anything else format is required.

Once again I'll express my opinion that people need (at least) two directory trees: One that is pure MSTS (and will always stay that way) and a copy of that for OR (e.g., it uses include files, it has OR specific parameters in the .eng and .wag files, etc.) that allows file content to be altered in ways that would be incompatible with MSTS.


FWIW, I used to think the best answer was to add OR specific stuff to the existing .w file but to place it after the final MSTS paranthesis. I'm no long enthused about that idea for fear that when RE writes to a .w it will ignore/drop the OR appended specifications.

#10 User is offline   eolesen 

  • Superintendant
  • Group: Private - Open Rails Developer
  • Posts: 1,546
  • Joined: 30-October 10
  • Gender:Male
  • Simulator:ORTS
  • Country:

Posted 17 November 2015 - 01:36 PM

View PostGenma Saotome, on 17 November 2015 - 12:18 PM, said:

A couple of observations: Once you alter the content of how a forest is described in the world file you can no longer expect to be using RE for editing. RE might simply ignore the entry... or fail to read more of the .w file... or abort. Whatever it is, the forest now becomes a problem.


Yes and no... I think it reads in what it can, and then over-writes the bad entry with something the RE can handle.

  • 9 Pages +
  • 1
  • 2
  • 3
  • Last »
  • You cannot start a new topic
  • You cannot reply to this topic

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users