Game Development Community

TSStatic Instancing Speed

by addict^2 · in Torque 3D Professional · 02/01/2011 (5:11 pm) · 13 replies

Is there a way to increase the loading speed of TSStatic object instances? I'm working with a level that requires about a thousand instances of a single DAE placed in the mission file as TSStatics, and "loading objects" seems to take about 10 minutes. Since, as far as I know, these are not ghosts and they are being instanced, I don't know why it is taking so long.

#1
02/02/2011 (12:16 pm)
This may not be your problem, but I'll mention it in case it's helpful:
There's a long-standing T3D bug with mission loading and vsync; if vsync is enabled the loading rate seems to get capped along with the framerate, which can result in some seriously long load times if you have a lot of datablocks or your scene has an extremely high number of objects.
#2
02/02/2011 (2:41 pm)
@addict

Can you send me your mission file... i don't need the art or files or anything, but just the .mis file. tom@sickheadgames.com

Also are you using PhysX or Bullet collision?
#3
02/02/2011 (3:23 pm)
@Tom
Sure I will send you the mission file right away. I believe that I am using PhysX collision.

@Henry
Vsync is disabled.
#4
02/03/2011 (1:04 pm)
The problem with TSStatics is that (I think) they need to send the model filename to the client for each instance, so it can take a while to load several hundreds of them, specially if the model filepath is long. It doesn't matter if they all use the same model. For such situations, using some kind of replicator or even StaticShapes (which send only the datablock number) would be faster.

Changing the TSStatic ghosting code to use tagged strings to send filenames would help too (since a tagged string only needs to be sent once).
#5
02/03/2011 (1:38 pm)
@Manoel Thanks I will take a look into these solutions right away. Can you point in the right direction for modifying the ghosting code of TSStatics? My first instinct is to delve into netGhost.cpp
#6
02/04/2011 (7:35 am)
Addict it's probably in the tsstatic.cpp (or whatever it's called) in the packupdate() and corresponding unpack functions that deal with sending the data over the network.
#7
02/08/2011 (2:07 pm)
I've been screwing around with the pack and unpack functions the past few days trying to implement a tagged string functionality with the mShapeName. I feel like I'm manually trying to accomplish something that should already be built into the engine somewhere. I'm really new to Torque's source so I don't where the implementation for tagged strings is located or how it's done. I've dug into core/strings a little bit and I -think- I understand the whole String Table, but I don't think that this is where tagged strings are located. Any help would be greatly appreciated.
#8
02/10/2011 (3:45 am)
Well I am definitely stumped on this problem. I'll post again if manually tagging the strings gives any results.
#9
02/23/2011 (4:14 pm)
Sorry to bump; new (related) question. I switched to using StaticShape instances, and now the mission load time greatly improved. Was kind of dumb to be using TSStatics. However, now when the level finishes loading, my instances "pop" into existence. This wouldn't be a huge problem because the StaticShape buildings surrounding the player are rendered quickly enough that the pop is not seen. The roads however are a different story. Does anyone have any advice on how to get the roads to render just as quickly after the mission loads? I am using the road editor to build my roads so I thought that a flat texture on the terrain would be rendered quickly, and around the same time as the terrain itself.
#10
02/23/2011 (4:33 pm)
What you are seeing is the delay as the server version of those objects is ghosted to the client (even in singleplayer mode, Torque renders with a separate client SceneGraph).

Try increasing the number for $pref::Net::PacketSize (defaults to 200 and caps at 1024 for singleplayer)

You could also play with increasing $pref::Net::PacketRateToClient (defaults at 10 and caps at 128 for singleplayer)

Note that if this is a multiplayer game, you could potentially cause some serious problems by increasing these too much depending on the network hardware your users will be using (which is hard to predict).

For a singleplayer game it is pretty safe to jack these up considerably but you may have to make some changes to NetConnection::checkMaxRate() to remove some of the hard caps.
#11
02/23/2011 (6:05 pm)
Just to note: single player packetsize caps out at 900, 'cos of a bug (Dusty Monk posted a fix/workaround for that though). And checkMaxRate causes an invalid packet if you spawn a huge amount of Ai all at once (can't remember if there's a fix for that or not).
#12
02/23/2011 (7:02 pm)
Thanks so much!
#13
02/23/2011 (8:38 pm)
Quote:What you are seeing is the delay as the server version of those objects is ghosted to the client (even in singleplayer mode, Torque renders with a separate client SceneGraph).
I would have thought this would be dealt with while the client is connecting to the mission, but I guess not. In that case, I'd just cover up the pop-in after the mission has loaded and the player has joined with a GUI dialog on top of the PlayGui, which is removed within a second or two.