T3D 1.1 Beta 2 - Mission Editor - After a certain number of objects, new objects in the level don't render
by Dusty Monk · in Torque 3D Professional · 09/26/2010 (2:58 pm) · 7 replies
Win 7, 64bit
Problem:
While editing a large level, after some number of objects is reached, new objects in the level don't render.
Repro:
Create a new level, and either through programmatic means or cut & paste, add roughly 3500 objects to the level -- TSStatics are fine. Then through the editor, use shift-move to create more objects. At some point the new objects cease to render.
Expected:
New objects to the level should render regardless of number of objects in the level.
Commentary:
I wasn't able to accurately determine the exact number at which the problem begins to occur. I will perform some additional testing as time permits and update this bug with more information if I can, but I wanted to get the bug logged asap, as it's a major breakdown of our workflow.
The editor definitely appears to be reaching some threshold. Once the bug occurs, all additional objects cease to render. If you save the level, exit the game and reload the level, all of the objects render correctly, so it definitely appears to be a function of the editor's add process. In the same editing session in which the bug appears, I can delete objects and eventually they will begin to render again, and then I can re-add objects and the bug will occur again. Again, evidence that some threshold is being reached.
I first referenced the bug in a general query for more information here. The level in which I personally am encountering the bug has 1977 statics, 493 prefabs, the majority of which have only 2 static objects, but some have a dozen or so. So straw-man estimate is between 3200 to 3500 objects.
Problem:
While editing a large level, after some number of objects is reached, new objects in the level don't render.
Repro:
Create a new level, and either through programmatic means or cut & paste, add roughly 3500 objects to the level -- TSStatics are fine. Then through the editor, use shift-move to create more objects. At some point the new objects cease to render.
Expected:
New objects to the level should render regardless of number of objects in the level.
Commentary:
I wasn't able to accurately determine the exact number at which the problem begins to occur. I will perform some additional testing as time permits and update this bug with more information if I can, but I wanted to get the bug logged asap, as it's a major breakdown of our workflow.
The editor definitely appears to be reaching some threshold. Once the bug occurs, all additional objects cease to render. If you save the level, exit the game and reload the level, all of the objects render correctly, so it definitely appears to be a function of the editor's add process. In the same editing session in which the bug appears, I can delete objects and eventually they will begin to render again, and then I can re-add objects and the bug will occur again. Again, evidence that some threshold is being reached.
I first referenced the bug in a general query for more information here. The level in which I personally am encountering the bug has 1977 statics, 493 prefabs, the majority of which have only 2 static objects, but some have a dozen or so. So straw-man estimate is between 3200 to 3500 objects.
About the author
Dusty Monk is founder and president of Windstorm Studios, an independant game studio. Formerly a sr. programmer at Ensemble Studios, Dusty has worked on AAA titles such as Age of Empires II & III, and Halo Wars.
#2
09/26/2010 (5:52 pm)
Nice comments in netconnection.h! Always great to have idiot proof explanations squirreled away in the code.
#3
After upping GhostConstants, I've noticed that I get a crash if I try and change the player's control object.
10/24/2010 (7:01 pm)
Just a note:After upping GhostConstants, I've noticed that I get a crash if I try and change the player's control object.
%this_object.setcontrolObject(%to_different_object);
#4
QA: please flag this post regarding archaic limits!
10/24/2010 (7:46 pm)
any chance this was fixed in B3 ?..QA: please flag this post regarding archaic limits!
#5
10/24/2010 (9:04 pm)
I'm using B3, so no.
#6
Any particulars on the crash? Stack location or the like?
I'm still using B2, so there is a possibility this (the crash) is something that was introduced in B3.
Dusty
10/24/2010 (11:23 pm)
Hmmm. Well for what it's worth, I upped the GhostConstants enum to 16384 (GhostIdBitSize = 14), and do quite a bit of switching of the control object, and haven't noticed any crashing of the client at this point.Any particulars on the crash? Stack location or the like?
I'm still using B2, so there is a possibility this (the crash) is something that was introduced in B3.
Dusty
#7
Thanks Dusty, I'd just gone and doubled the values in the mistaken belief that if it's 4096 as stock, then x2 would give me 8k (on everything as well - but just read it again and realized why that would be stupid).
So, yes, you're quite right, it works fine. Self inflicted issue over. :)
10/25/2010 (3:23 am)
A-ha! A classic case of me doing it wrong!Thanks Dusty, I'd just gone and doubled the values in the mistaken belief that if it's 4096 as stock, then x2 would give me 8k (on everything as well - but just read it again and realized why that would be stupid).
So, yes, you're quite right, it works fine. Self inflicted issue over. :)
Torque Owner Dusty Monk
Windstorm Studios
So I don't think this is a bug. What was happening was I reached the maximum number of ghosts that transmitted to the client at any one time (4096). By increasing the constants found in the GhostConstants enum, this completely fixed the error. It also makes perfect sense. Because all the selection information is on the server side, I was still able to see, select, and save the object. But because it's the ghost that is rendered, it made sense that it wasn't getting rendered.
Big thanks to Steve Acaster for giving me the magic number to go hunt for.
and HUGE thanks to whomever the working joe was that put the excellent comments at the top of netconnection.h, which not only told me about the constraint, but told me where exactly to go to change it.
Comments rule. :)
Dusty