Author Topic: Large number of tnobjects  (Read 1905 times)

voncarp

  • Jr. Member
  • **
  • Thank You
  • -Given: 13
  • -Receive: 2
  • Posts: 91
    • View Profile
Large number of tnobjects
« on: March 29, 2015, 03:00:43 PM »
I am trying to have a large working forest.  Maybe 1-2 thousand trees.  When a player cuts a tree down, it needs to stay down when new players join.  I can do this on a small scale by adding an individual tnobject to each tree and making an RFC call.   

For a few thousand trees is this the best way?  My game streams, so by doing it this way some of the trees aren't loaded up yet.  So many of the tnobject numbers conflict.  I can write each individual tno id down and assign it individually so they don't conflict, but that seems so tedious to do for a few thousand trees. 

Would you have a suggestion on how I could implement a large forest in a game that streams?  Maybe a tree manager per level/scene with only one tnobject?  Curiously, does a large amount of tnobjects in scene effect performance?  Sometimes tnmanager.udpate has some crazy spikes or takes the up the most amount of cpu usage in the profiler.

I have 50 scenes that can potentially stream in when a player moves across the map.

Thanks for any suggestions.

ArenMook

  • Administrator
  • Hero Member
  • *****
  • Thank You
  • -Given: 337
  • -Receive: 1171
  • Posts: 22,128
  • Toronto, Canada
    • View Profile
Re: Large number of tnobjects
« Reply #1 on: March 30, 2015, 01:59:21 AM »
Single RFC function that you pass an array to containing the state of each tree. If the tree positions are known in advance, then all you'd need is an array of booleans. If not, an array of Vector3 positions would do. Each time the player chops down a tree, send an RFC message to the host, then have host update the array and send it out to everyone else in a saved RFC.