Hard crash in GFXD3D9VertexBuffer - LOGGED

#1 One more thing to point out:

The problem is when we have many items close each other and the player is in the same bin.

I could spawn items in the same position as many as I want. I tried spawning 50 items in the same position. If my player is apart from them T3D doesn't crash. When I approach the items T3D crashes

#2 I have found that this crash happens only in Basic Lighting. In Advanced lighting there is no problem.

I am developing my game for Basic Lighting so this is serious problem for me.

If the number of items in a bin is larger than 15 and the player enters that bin, T3D crashes.

It is a rendering trouble:
Here is the stack:

#3 Try disabling the Shadows in BL or get rid of the decals file. Have had some issues in BL since 1.0.1. Not exactly a solution, but at least would make me feel better if it worked :-).

#4 Thanks, Joshua,
removing the shadow was a really good suggestion and now i have no rendering problems.
Right now i am downloading T3D 1.0.1 and will see if this bug occures.

#5 yes, this bug is present in T3D 1.0.1 too.

#6 Well, glad to see it wasn't something we did :-). We started seeing this after we moved from Beta 4 to 1.0. 1.0.1 seemed to aggrevate it even more.

#7 This bug can be reproduces very easily in any of the example scenes in the T3D stock version. Just place somewhere more than 15 items close each other and watch how T3D crashes when the player approaches them.

I've found that 15 items is the limit not to crash. Placing 16 items leads to crash.

I really hope somebody from GarageGames to take into account that bug.
The BL shadow rendering is not stable for the present.
So now i'll disable the shadows untill this one is fixed.

#8 Bump. Making sure someone is aware of this as it is a major issue for us as well.

#9 Bumping again. Want to make sure this is known so it gets fixed.

#10 I reported this a while ago: the BL decal-based shadows will crash if you have several of them visible at once.

#11 Nod, just making sure this doesn't slide through 1.1. Probably our #1 issue right now.

#12 This is number 1 issue to everyone. May be the others haven't started assembling a game yet and that's why they don't know about it.

#13 hell, I've seen that same problem, even the stack points to the same line!!
BUMP FOR FIX!!!

#14 I don't think this exists in 1.1 at the moment, but i haven't had time to test it. It will be fixed before 1.1 final for sure if its not.

#15 Thanks Tom.

#16 Logged as THREED-811

#17 I am encountering the same problem in 1.1 alpha. I can generate this crash in basic and advanced lighting by having too many projectile decals fall in the same area. The problem occurs in the DecalManager::prepRenderImage() the first time more than 16 decal batches are generated. When the 17th batch is processed, the calls on lines 1154 and 1155

mPrimBuffs.push_back( pb );
      mVBs.push_back( vb );

cause the vectors to be resized…and relocated in memory…causing the buffers at the original locations to be de-referenced. Since the assignments on lines 1163 and 1164

ri->primBuff = &mPrimBuffs.last();
      ri->vertBuff = &mVBs.last();

store the memory location of the buffer, the first 16 ri’s created now contain a primBuff and vertBuff that have been dereference and self-deleted, causing this hard crash in the rendering.

The solution to this problem is simple, resize the vectors before the first element has been added. Before line 1102:

for ( U32 i = 0; i < batches.size(); i++ )

add the following 2 lines

mPrimBuffs.setSize(batches.size());
   mVBs.setSize(batches.size());

Then change lines 1154 and 1155 from:

mPrimBuffs.push_back( pb );
      mVBs.push_back( vb );

to:

mPrimBuffs[i] = pb;
      mVBs[i] = vb;

Change lines 1163 and 1164 from:

ri->primBuff = &mPrimBuffs.last();
      ri->vertBuff = &mVBs.last();

to:

ri->primBuff = &mPrimBuffs[i];
      ri->vertBuff = &mVBs[i];

This will eliminate that problem, but reviewing the code indicates there is another big problem waiting in the wings. Anytime the scene traversal creates a subsidiary SceneState for a portal, an additional call to DecalManager::prepRenderImage() will be called with a unique state and key value. This will cause buffers to be cleared before thay have been rendered and will cause an almost identical crash. Since it is imposible to predict the number of batches the decal manager will create in the root scene from the subsidiary, there is no way to size the buffers in advance. If your maps use portals and decals, you should run into this the first time you render a scene with decals visible on both sides of the portal. A vector of mPrimBuffs and a vector of mVBs will probably need to be created and flagged to be cleared the first pass after a root SceneState is encountered in order to preserve all buffers untill rendered. I am not going to implement a solution to this portal problem just yet because we won’t have to deal with it for a little while. I would love to hear ideas for other ways to prevent this problem.

#18 Good catch Michael.

For the 1.1 beta i'll be reworking how the VB/PB is allocated for decals as its pretty slow at the moment and has other issues as you've found.

I setup a new VB/PB pool system to avoid allocations at runtime and changed when the pool is freed to the end of the frame instead of each prepRenderImage() call.

Thanks for pointing out the portal issues as i need to test that case. Since decals don't do any portalization of any kind at this time i can probably fix the prepRenderImage to not render if its not the global zone.

#19 Thanks Tom, That sounds like an elegant solution. I’m looking forward to 1.1 beta!

#20 Logged: TQA-392