Particle Systems - Anomalie....it ain't my fault! It is a bug! :

#1 Post the particle emitter DataBlock, I might have an idea of what's going on.

Specifically the colors[x], sizes[x], and times[x] arrays.

#2 I had this same problem at one time. Then I got to looking at it a bit more and then I found out that it was playing a animated set of files and not just one file like I wanted it to. Stupid me :/ anyways I just removed the parts that was reffering to the other files in the animation that I had not made and it no longer displayed the white box. :/

Maybe the same thing your encountering then ageain it maynot be.

#3 Well I know it is just one file because it is a PNG not a DML that I am trying to play...quite irritating...


datablock ParticleEmitterNodeData(defaultParticleEmitterNode)
{
timeMultiple = 1.0; //time multiple must be between 0.01 and 100.0
};

datablock ParticleEmitterNodeData(tenthTimeParticleEmitterNode)
{
timeMultiple = 0.1;
};


//particle control data

datablock ParticleData(BigfireParticle)
{
//----------Image variables---------------
textureName = "~/data/shapes/crossbow/smokeParticle";

useInvAlpha = 0; //default = "false"

inheritedVelFactor = 0.5; //default = 0.0
constantAcceleration = 0.0; //default = 0.0

dragCoefficient = 0.9; //default = 0.0 (must be >= 0.0)
windCoefficient = 0.4; //default = 1.0
gravityCoefficient = -0.8; //default = 0.0 (negative rises)

lifetimeMS = 7000.0; //default = 1000 (minimum 100)
lifetimeVarianceMS = 3000.0; //default = 0.0 (must be < lifetimeMS)

spinSpeed = 8.0; //default = 0.0 (range -10000 to 10000 ; deg per second)
spinRandomMax = 40.0; //default = 0.0 (range -10000 to 10000)
spinRandomMin = -40.0; //default = 0.0 (range -10000 to 10000; < spinrandommax)

//---------Interpolation variables--------
times[0] = 2.0;
times[1] = 6.0;
times[2] = 9.0;
colors[0] = "0.3 0.1 0.0 0.3"; //Red,Green,Blue,Intensity
colors[1] = "0.2 0.1 0.1 0.2";
colors[2] = "0.1 0.1 0.1 0.1";
sizes[0] = 15.0;
sizes[1] = 29.5;
sizes[2] = 44.0;
};

datablock ParticleEmitterData(BigfireEmitter)
{
ejectionPeriodMS = 100; //1000 = 1 particle per second (1ms minimum)
periodVarianceMS = 10; //variance has to be less than ejectionPeriodMS

ejectionVelocity = 1.3; // >= 0.0, from 1.0 to 3.0 meters per second
velocityVariance = 0.15; //has to be less than ejectionVelocity
ejectionOffset = 0.1; //ejection start distance from the emitter point >=0

//theta,phi rotation matrix axis angles (degrees) [eg. phi * (PI / 180)]
thetaMax = 120.0; //0-180 degrees
thetaMin = 10.0; //0-180 0 = All heights (min has to be less than max)
phiReferenceVel = 210.0; //0-360, 360=all directions
phiVariance = 40.0; //0-360

overrideAdvances = 0; //0 or 1 function ???

//orients the particles out from the emitter source (1) or as billboard (0)
orientParticles= 1; //0 or 1 "true" or "false"
orientOnVelocity = 0; //0 or 1 billboard if no velocity in mission file

//when tied to an ParticleEmitter object, then these work;
//if ParticleEmitterNode then don't need
//useEmitterSizes = 0;
//useEmitterColors = 0; //default = 0, has to be 0 for ParticleEmitterNode

particles = "BigfireParticle"; //call particle data
};

#4 anyone see a problem in the script?

#5 Dont' see anything obvious.

Does the flashing occure when anything else is on the screen, like a building, or tree, or something. Sometimes rendering problems are caused by other shapes in the scene not clearing or restoring their OpenGL states. I've noticed something going on with the buildings that causes a problem with our player, maybe it's related?

#6 Just to let you know, I independently get this effect. I noticed it yesterday when I was playing with creating fire effects. My settings are completely different as far as I can tell.

It looks like it's the last frame of each particle gets rendered completely opaque white, just before it snubs out.

#7 I've just had a look through the C++ particle code and discovered a few interesting facts.

First of all, there are upto 4 time[n] blocks, not the three commonly used in the scripts.

Also, the times in these are normalised e.g. 0.0 is beginning of lifetimeMS and 1.0 being the end.

In-fact the ParticleData::packData(BitStream* stream) function uses a time of 1.0 or greater to signify the number of interpolations used. You will get a crash if none of your times are 1 or above.

I got rid of my flicker by using this method.

I think the flicker is caused by the last colour, number 4/colors[3], as it is initialised as <1,1,1,1> in the ParticleData class.

The strange thing is that the class also initialises the times to:-

times[0] = 0.0f;
times[1] = 1.0f;
times[2] = 2.0f;
times[3] = 2.0f;

... in it's constructor which seems to be incorrect.

Should these be something like 0/.33/.66/1.0 ??

In the sample script above, the times are 2/6/9 which are outside the interpolation scope. I've not looked at the rendering code but if I put in these values with the corresponding colours then I get a white flicker as the last particle dies.

Hope this helps.

#8 Now that you mention it, the times in the ubove script are incorrect, the times should be 0.33, 0.66, 1.0. If you look at the fps/server/scripts/crossbow.cs and rifle scripts, the last time is always 1.0. Thanks Melv :)

#9 No problem Tim. !)

Brian,

That script looks familiar. Isn't it off a site somewhere demonstrating particle effects?

If the time[n] values are straight off their page then you may want to let them know so as they don't cause this confusion elsewhere.

[EDIT]

Yeah, it's under:-
> "Community Sites" \ "Torque Tutorials"
> http://holodeck.st.usm.edu/vrcomputing/vrc_t/tutorials/
> Under "Effects " \ "Part5 - Particle Nodes"

The example has times of:-

times[0] = 3.0;
times[1] = 2.0;
times[2] = 1.0;

... which won't work.

- I've just sent an email to the web-admin.

#10 Thanks Melvyn,

You'll notice in the particle effects tut there are some other parameters which I haven't had time to research--if you figure them out let me know and I'll update the tut.

Again, thanks

#11 Try this:

times[0] = 2.0;
times[1] = 6.0;
times[2] = 9.0;
times[3] = 1.0;
colors[0] = "0.3 0.1 0.0 0.3"; //Red,Green,Blue,Intensity
colors[1] = "0.2 0.1 0.1 0.2";
colors[2] = "0.1 0.1 0.1 0.1";
colors[3] = "0 0 0 1";
sizes[0] = 15.0;
sizes[1] = 29.5;
sizes[2] = 44.0;
sizes[3] = 0;

I think the last color has to be "0 0 0." I'm really not sure though :\

#12 Shouldn't those times be:-

times[0] = 0.0;
times[1] = 0.33;
times[2] = 0.66;
times[3] = 1.0;

?

also ... no problem Desmond, anything I can do to help.

#13 Desmond ...

I had a quick look this morning at the parameters you mentioned.

"overrideAdvance"

Strange one this as there seems to have been a problem with it in the past! There is a code-block that WAS dedicated to sending a general error to the console if this setting was 'true', stating "ParticleEmitterData: Not going to work. Fix it!". Does this mean it's been fixed Tim?

Anyway, it looks like it's related to the advancement of particles over time. If the delta-time passed into the 'emitParticles' procedure is larger than the particle lifetimeMS then this parameter would seem to allow an override on the fact that the particle would normally be created and then destroy in a single pass! I suppose if you have short-period particles and a potential for large time-deltas' then you normally wouldn't see any particles, with this you can override?


"spinSpeed, spinRandomMax, and spinRandomMin"

Controls the spin of particles interpolated over time. The spin used is spinSpeed + randomspin between (spinRandomMin & spinRandomMax). Note that this only works for 'Billboard' particles e.g. 'orientParticles = 0'. Presumably because you have a fixed rotational axis with Billboards.


Hope this helps.

#14 I have no idea what the overrideAdvance flag was trying to correct, or whether it's been fixed and/or is working correctly :) This is not code I'm overly familiar with.

#15 Melv, are you basing the idea of the times being normalized from the below code found in void ParticleData::packData(BitStream* stream)?

for(count = 0; count < 3; count++)
   if(times[count] >= 1)
      break;

Desmond, some more info for your tut:

Quote:I'm not currently sure what impact the next parameters (inheritedVelFactor, constantAcceleration)have on the particles.

inheritedVelFactor (default of 0.0) is a multiplier that affects velocity. The factor portion deals with the addition of vel to inheritVelocity. A value of 0 gives you no change. A value of 1 gives you 2x the velocity, value of 2 gives you 3x the velocity, and so on.

init->vel += inheritVelocity * inheritedVelFactor

From what I can see, vel is assigned to inheritVelocity.

constantAcceleration (default 0.0) is multiplied with vel and dumped into acc.

init->acc  = init->vel * constantAcceleration;

These are located in void ParticleData::initializeParticle(Particle* init, const Point3F& inheritVelocity). The name of the variable is misleading, as it's not an actual value, but rather another multiplier (or factor, if you will). (nice site, btw, Desmond).

#16 Hi James,

Why do I feel like this is a trick question?

I must admit I only took a cursory glance at the particle engine but I found that the examples I saw just didn't do what I wanted. It seems to work fine with two frames as you tend not to actually time the particles so you assume that they are ok.

I found ...

times[0] = 0.0f;
   for (U32 i = 1; i < 4; i++) {
      if (times[i] < times[i-1]) {
         Con::warnf(ConsoleLogEntry::General, "ParticleData(%s) times[%d] < times[%d]", getName(), i, i-1);
         times[i] = times[i-1];
      }
   }

 ... blah blah blah ...

... and ...

// Now update the particle's color
   t = F32(particle->currentAge) / F32(particle->totalLifetime);
   AssertFatal(t <= 1.0f, "Out out bounds filter function for particle.");

   for (U32 i = 1; i < 4; i++) {
      if (particle->dataBlock->times[i] >= t) {
         F32 firstPart = t - particle->dataBlock->times[i-1];
         F32 total     = particle->dataBlock->times[i] -
                         particle->dataBlock->times[i-1];

         firstPart /= total;

 ... blah blah blah ...

The first showing that particle times must be in ascending order and the second showing that the particle times are fractions of the current age.

I noticed the reference you mentioned which seems to indicate that values => 1.0 are not ghosted and is used to directly indicate the number of frames.

If I've made a big whoopi here then please let me know so that I can unwrap my humble pie. :)

All the best.

#17 Melv:

It was from a tutorial covering percipitation effects by Ed Gardner. There was a tutorial several weeks back in the resource section. It seems that the last bit of the particle life right before it is terminated is rendered 100% opaque with no alpha channel.

Who knows. I am sure I screwed up something ;)

#18 Brian,

If you have a look at my post following yours you will see that the effect goes away if you use the correct format for the 'times' array ... or did you try this already? :)

All the best.

#19 Thanks everyone,
I've already made the changes to times as posted by Melv and will update the tuts with the new info on inheritedVelFactor, etc.

#20 Yes. The times were FUBAR. They are working now. Thanks!