Max number of objects in Mission Group == 1024 ?

#1 Of course, I say Mission Group above, when I really meant SimGroup.


:)

#2 Can't really give you the answer you want, but I can tell you that T2 did the same thing (discovered this when using scripted tree placement).

#3 Yes that is a real limit. Nothing really enforcing it other than the network code, which could be easily modified.
--Rick

#4 Almost everything network related has some limit on it, mainly so that packets can be squeezed down to their smallest size.

The network ghosting code uses a 10 bit ghost id, and I think some ghost id tables also use that size (1024). As Rick suggests, it shouldn't be to hard to up the number. Check the net* files in the engine/sim directory.

#5 Let me ask a question here:

Are we talking about a 1024 limit on objects in the SimGroup such as interiorInstances, TSstatic shapes, etc? If so, and each client has this data on their machine, what does it have to do with network code exactly?

#6 Well, there shouldn't actually be a limit on # of objects that would crash the game... the limit of 1024 is the maximum # of ghosts that can exist on any one client. It's possible that there's a bug in there causing it to crash if this # is exceeded.

As for why interiors/terrains/static shapes are considered network objects - the mission data is stored only on the server and is transmitted to clients at connect. Because most of these objects can change over the course of a mission (lights on interiors, animations on statics), they have to be network aware. For cases where large numbers of completely static objects are present (ie trees), you could make them non-ghosted objects and send them over via NetEvents when a client connects to the mission (I believe this is how trees were handled in Trophy Hunting).

#7 hehe, I was wondering if Mark was going to jump in on this one :)

#8 If they are non-ghosted objects then why is NetEvents involved (excuse my lack of understanding RE: networking)? And, how would one type of static shape be flagged for non-ghosting (non-animating, etc.)?

#9 Great answers guys, thanks. I'm not shy about upping the limit (I need about 8 xmore) but most (90%) of the objects are actually *really* static - ground clutter.

So what would I do to make my static objects non-ghosted ? Add them to another arbitrary group ? If so, what would I do ?

(mebbe this thread belongs in the Engine forum ...?)

#10 Anything that the client sees must be ghosted otherwise it will not exist on the client's side of the game. You wouldn't need to ghost triggers (for example). So "ground clutter" I think would need ghosting.

#11 Ok, I admit I don't understand the networking much. But from the docs: "A ghost is a copy of an object persisted and transmitted to a remote host." So why would ground clutter that exists on the same world for each client need to be ghosted--(assuming they are completely static)?

#12 OK if you host a server on your machine (and play on it not a dedicated) you'll have both the server objects and their ghosts.

All objects are updated via the packupdate and unpackupdate methods it's a method gameconnection I think.

Everytime the maskbits are set (or changed?) the server sends/packs data for the client and then the client unpacks it. The client interpolates positions for objects like players and projectiles. When the update is received if the ghost position is off from the server position (by a certain threshold) it'll fix it.

So even a static non moving object (for example the sky, or mission interiors) must be ghosted. It is ghosted at the start of the mission and data is packed and sent off then for it. There's no point in updating that as it's not changing.

So your completely static objects would need to be ghosted and then only updated once (set their positions on the map and such).

I've only had Torque for 6 days so I may have understood things incorrectly. Please let me know if anything I said is wrong.

#13 Lets see if I can word that better:

Ghosting is the process of duplicating server objects on the client.

The ghosts are what you see in game. Server objects are not rendered. If you're a client you only have ghosts, if you're hosting a server and playing off of it (non dedicated) you've got both the ghosts and the player objects (if you set debug mode on you should see the outlines on the player bounds box, the big yellow one is the server object and you'll not it updates "jumpily" while the white one around you is the ghost bounds).

#14 Pretty good grasp of it for only six days :) Thx

#15 I would be more interested in what Mark referred to. Not being familiar with NetEvents, I assume he is implying that a ghost is an object on the client that may be altered by the server (repositioned etc.) but that by using (sending) a NetEvent, you can set up a static object on the client that simply can't be referred to by the server afterward.

Perfect for, say, a rock, which is never going to move, be destroyed or otherwise changed in any way. Seems things like a player standing on it would not need any info about the rock passed to the client, just the player's position. The rock still exists on both client and server, but the server no longer has a 'handle' to use to implement changes to it.

If your trees, etc, are not destroyable, they could be instantiated the same way on the client, making them exceptions to 1024 limit (ie, don't need ghost id's) as well. Am I understanding that correctly?

If so, I, like Desmond and Kenny, would be interested in any insight into how this is done.

#16 Well said Tim.

#17 Exactly, Timmey :-)

#18 It would be cool to do this. As I mentioned above, I ran into this limit in T2 when programmatically adding foliage, etc, to a map. The thing is, the terrain and fog levels I had allowed framerate to stay reasonable with a dense forest. I wanted to cover the map, and some, but found this limit killed me. Ack.

I'm really looking forward to being able to use visibility tricks to give the feel of truly dense forest, etc...

#19 What kind of visibility tricks are you thinking about? I'd like the dense forest also.

#20 Nothing too outrageous - or even that clever. No flat terrain to speak of, fog, good lod on tree objects. That's about it. Just keep as few trees in sight as possible while still giving the impression of density. Simple solutions can go a long way.

It's just that my testing showed that if you are careful, you can get a fairly dense forest without killing framerate or making a Myrkwood. I must admit that using a dense and very dark fog goes a long way in a night forest scene.

Start with max density and fog, and back off slowly. Fiddle with tree placement. Wander around and watch frame rate to get an idea what to tweak.

Try a low (waist level) fog and add a lot of shrubbery that falls below that height, then use a bright night sky with a full moon -- The shrubbery seems to appear out of shadows and provides a very closed-in sensation, but overall it feels rather bright, so it doesn't seem as dark. The idea is to give the feeling of closeness and density without actually providing more than necessary.

Put your densest areas in terrain hollows and use bigger and fewer trees on the higher ground. Big trees will give a better 'closed in' feel without increasing polygons. Like I said, nothing clever - just try stuff like that and you will find you can get 'density' out of no more than carefull placement.

Good LOD would help a lot too. As well as careful use of terrain. I tried increasing the square size of the terrain and working there -- it helped because I halved the time spent rendering terrain and it left more time for foliage rendering. I also tried creating 'terrain tiles' in WC, on the assumption that it seems to render faster, but the results were inconclusive. Might be worth fiddling with again tho.

Bottom line - I can get a lot of denseness in and still keep framerate, but I need to be able to add more objects to the mission, most of which are never even seen (that being part of the goal), let alone altered. I just want the atmosphere I create to cover more than a small area of the map.


BTW - any ideas along these lines that any of you might have would be appreciated.