T3D 1.1BETA 1, 2 and 3 BLUE SCREEN OF DOOM! Possibly reflections - RESOLVED
by Steve Acaster · in Torque 3D Professional · 02/11/2010 (11:54 am) · 111 replies
WTF? Bad crash of some kind. Right-click and select "view image" for it's full bizarreness.
And yes, that clock does say 05:15, which is why I'm running a trace now.
All the "speckles" are flashing and it's all over the desktop. New_Project.exe stops responding. Flashing "speckles" remain on the screen after closing the application. Requires a reboot to clear them.
GTS250 (Galaxy), latest driver, Win7 with Aero.
Obviously you can see a rocket, a cloud layer and thus lot's of relection - which is what I'm thinking/wildly stabbing in the dark at is the issue here. That's a big old lump of water plane to reflect stuff, that is.
Problem is when running from a Debug I get a full blown BSOD, so it's not possible for me to call a stack.
If I turn FullReflect off, it doesn't crash or glitch when I do the same thing.
---
still an issue in T3D 1.1beta 2
Update 27Jan2011
RESOLVED!
One line fix here
And yes, that clock does say 05:15, which is why I'm running a trace now.
All the "speckles" are flashing and it's all over the desktop. New_Project.exe stops responding. Flashing "speckles" remain on the screen after closing the application. Requires a reboot to clear them.
GTS250 (Galaxy), latest driver, Win7 with Aero.
Obviously you can see a rocket, a cloud layer and thus lot's of relection - which is what I'm thinking/wildly stabbing in the dark at is the issue here. That's a big old lump of water plane to reflect stuff, that is.
Problem is when running from a Debug I get a full blown BSOD, so it's not possible for me to call a stack.
If I turn FullReflect off, it doesn't crash or glitch when I do the same thing.
---
still an issue in T3D 1.1beta 2
Update 27Jan2011
RESOLVED!
One line fix here
About the author
One Bloke ... In His Bedroom ... Making Indie Games ...
#82
01/25/2011 (9:38 am)
I will download and test it, there also may be something in the release notes of the driver to specify this. 
#83
01/25/2011 (9:40 am)
Im testing it now too, but I wasnt able to see anything in the notes that could be related to this.
#84
01/25/2011 (10:03 am)
And the answer would no.
#85
01/25/2011 (10:07 am)
I do not see it on the open issues list in the driver so I would assume it is not even on the plate to be resolved. It really needs to be placed on that list, maybe if "everyone" of us hits nVidia with it they will see an issue.
#86
01/25/2011 (10:07 am)
It seems to have fixed it for me?
#88
01/25/2011 (10:31 am)
Submitted a bug report at nVidia under Issue Reference #110125-000072
#89
01/25/2011 (11:02 am)
Sean, no changes were made. I just installed the driver and tested my game where I was getting the driver lockups.
#90
01/25/2011 (11:14 am)
GPU still locks when shooting particles over fullRefelect water. 
#91
01/25/2011 (11:53 am)
I got this (speckles) yesterday testing out the latest Blender (64bit). Launched Torque after exporting a Blender asset said, "whoops, full screen mode! better change that!" and WHAM, speckles everywhere! 
#92
So guess what?
I finally have a fix for this.
In engine/source/T3D/fx/particleEmitter.h at the bottom of the ParticleEmitter class add:
Then in engine/source/T3D/fx/particleEmitter.cpp around like 627 in the ParticleEmitter constructor:
Then further down in ParticleEmitter::prepBatchRender() around line 795:
The again in ParticleEmitter::addParticle() around line 1168:
And finally at the bottom of ParticleEmitter::update() around line 1358:
This should fix this once and for all.
01/26/2011 (4:40 pm)
See my post below first!So guess what?
I finally have a fix for this.
In engine/source/T3D/fx/particleEmitter.h at the bottom of the ParticleEmitter class add:
#else GFXVertexBufferHandle<ParticleVertexType> mVertBuff; #endif /// Set when particles have changed and /// the VB needs to be updated. bool mDirtyVB; // ADDED! // These members are for implementing a link-list of the active emitter
Then in engine/source/T3D/fx/particleEmitter.cpp around like 627 in the ParticleEmitter constructor:
mCurBuffSize = 0; mDirtyVB = false; // ADDED! mDead = false; // ParticleEmitter should be allocated on the client only. mNetFlags.set( IsGhost ); }
Then further down in ParticleEmitter::prepBatchRender() around line 795:
RenderPassManager *renderManager = state->getRenderPass();
const Point3F &camPos = state->getDiffuseCameraPosition(); // CHANGED
// Only update the particle vertex buffer once per frame
if ( mDirtyVB ) // CHANGED!
{
copyToVB( camPos, ambientColor );
mDirtyVB = false; // ADDED!
}
if (!mVertBuff.isValid())The again in ParticleEmitter::addParticle() around line 1168:
void ParticleEmitter::addParticle(const Point3F& pos,
const Point3F& axis,
const Point3F& vel,
const Point3F& axisx)
{
n_parts++;
mDirtyVB = true; // ADDED!
if (n_parts > n_part_capacity || n_parts > mDataBlock->partListInitSize)And finally at the bottom of ParticleEmitter::update() around line 1358:
updateKeyData( part ); } mDirtyVB = true; // ADDED! }
This should fix this once and for all.
#93
01/26/2011 (4:44 pm)
trying this now. if this works, I will be super happy, AFX literally kills my system with the particles because of this 
#95
The idea that we only have to update the particle VB once per frame is incorrect in the first place.
Torque particle code makes camera aligned particles on the CPU... not the GPU. So building the VB has to be done per-camera for each frame. Yes this means more CPU work and bus traffic updating particle VBs, but this is something that is required if you want them to render correctly into reflections.
Anyone have any counter arguments to this?
01/26/2011 (11:07 pm)
Well looking closer at it... there is a simpler fix that is more correct.// Only update the particle vertex buffer once per frame
//if(state->isDiffusePass()) // REMOVED!
copyToVB( camPos, ambientColor );The idea that we only have to update the particle VB once per frame is incorrect in the first place.
Torque particle code makes camera aligned particles on the CPU... not the GPU. So building the VB has to be done per-camera for each frame. Yes this means more CPU work and bus traffic updating particle VBs, but this is something that is required if you want them to render correctly into reflections.
Anyone have any counter arguments to this?
#96
01/26/2011 (11:40 pm)
Haven't tried it yet but this is great news, the game I was working on the character would always be on water and thus always crashing.
#97
I confirm, this resolves the issue! Volleys of rockets no longer crash the engine. FYI this also resolves this issue www.garagegames.com/community/forums/viewthread/116583/
01/27/2011 (4:13 am)
Thanks Tom for the fix and the diligence!I confirm, this resolves the issue! Volleys of rockets no longer crash the engine. FYI this also resolves this issue www.garagegames.com/community/forums/viewthread/116583/
#98
01/27/2011 (5:02 am)
Just tried this out with a row of rocket-spamming AITurrets over fullreflect water, didn't experience any driver resets, graphical glitching or other obvious issues. Thanks for sticking to this and coming up with the answer. 
#99
01/27/2011 (6:50 am)
great work Tom - thanks. So far no issues from this fix, so all good. 
#100
01/27/2011 (7:14 am)
Somebody pin this thread somewhere prominent, and a medal on Toms chest! 
Torque Owner Adam Beer
Ignition Games Inc.