Arma 3 Particle Effects documentation

[HorribleGoat 1473]

Yes, cannon fire effect is created different way in A3. This effect was created by scripted particle effects in A2 and now it is created via config. There is still support of the old way used in A2. If you are porting some stuff from A2 or creating new stuff based on A2 scripts, you can simply use the old way.

Great! Thanks! This was what we suspected after reading through the configs and trying out multiple different ways to get hold on the effect.

We can then use the old method and create the effects via script but is there any way to control the cofig based effect via scripting? Is there any particular performance advantage in the new config based way or is the old just as good?

[mad rabbit 0]

SPOTREP #00027:

• Particle effect modules localized
  
• Fixed: Wrong default values (getVariable) in the fire and smoke effect modules fixed (it is only safety-check, it shouldn't have any impact on functionality)
  

I was coming back to make a more detailed ArmA3 feedback tracker entry but it seems like you guys (BIS) already fixed some of these issues.

I'll try the particle effects modules again in MP.

[DarkDruid 96]

We can then use the old method and create the effects via script but is there any way to control the cofig based effect via scripting?

No, there is no way how to do this.

Is there any particular performance advantage in the new config based way or is the old just as good?

Yes, all things around this effect (position, direction etc.) are processed directly by the engine, which is more efficient than scripting processing. On the other hand, your ability to manipulate with this effect is limited in comparison to scripting. There is only limited set of parameters and if you want to do something which we haven't expected (and which is not supported so far), only way is to create a request on Feedback Tracker and ask for new parameter.

Edited July 3, 2014 by DarkDruid

[HorribleGoat 1473]

Yes, all things around this effect (position, direction etc.) are processed directly by the engine, which is more efficient than scripting processing. On the other hand, your ability to manipulate with this effect is limited in comparison to scripting. There is only limited set of parameters and if you want to do something which we haven't expected (and which is not supported so far), only way is to create a request on Feedback Tracker and ask for new parameter.

Thank you DarkDruid for clearing this up! We'll try if we can work around this and post a Tracker when we know what kind of parameter might be required!

[Pappschachtel 10]

how exactly does

blockAIVisibility = true; 

block the Ais vision ?

does it calculate the particles alpha ? size ?

is it just a ray/cone intersection test ?

Which parameters does a particle need to successfully block the Ai's vision completely ?

[milosv123344 37]

Good post , i'm interested in experimenting with arma 3 effects and changing them to look more realistic in some ways. If any of you might be experts on this sort of thing can you take a look at the thread i made yesterday and maybe help me out via reply there? Thanks, this is all too complicated....

http://forums.bistudio.com/showthread.php?182798-How-to-change-muzzle-flashes-and-where-are-they

[Gudsawn 93]

Sorry for digging up an old thread, but my question is relevant.

With config-based Cloudlets, is it possible to choose a random particleShape from an array rather than use the same one every time? For example:

class CfgCloudlets
{
class Flare1
{
	...
	particleShape="\A3\data_f\ParticleEffects\Universal\Universal.p3d";
	...
};
};

This will use Universal.p3d with every effect. Instead, I want to be able to pick a particleShape at random (e.g. Universal.p3d, SomeOtherFlareEffect.p3d, AnotherFlareEffect.p3d, etc). Is this possible?

Edit: For example:

class CfgCloudlets
{
class Flare1
{
	...
	particleShape[]={
		"\A3\data_f\ParticleEffects\Universal\Universal.p3d",
		"\A3\data_f\ParticleEffects\Universal\SomeOtherFlareEffect.p3d",
		"\A3\data_f\ParticleEffects\Universal\AnotherFlareEffect.p3d"
	};
	...
};
};

Or instead, define a random particleFSIndex to start playing from?

Edited June 11, 2015 by MisterGoodson

[super-truite 54]

how exactly does

blockAIVisibility = true;

block the Ais vision ?

does it calculate the particles alpha ? size ?

is it just a ray/cone intersection test ?

Which parameters does a particle need to successfully block the Ai's vision completely ?

 

I was digging in the forum to find this topic and ask the very same question due to a never ending debate about blatcore vs vanilla smokes!

I am betting on the alpha detection (size and density of the effect look similar on BC/vanilla), but would like a confirmation too as I don't have much time to experiment unfortunately...

Two videos illustrating the differences between vanilla/blastcore:

Blastcore:

https://www.youtube.com/watch?v=UUutetyAM1

Vanilla:

https://www.youtube.com/watch?v=elgkUBcanAw

[NeoArmageddon 958]

Does anybody here knows if the aggressive mipmapping on particles can be eased?

I am using a 4096px² texture and it looks really crappy ingame:

https://youtu.be/mXzIdGG9Q8U

 

Looks like nearest lod is always taking the 512 or 1024 mipmap

[samatra 85]

Necro bumping the thread.

 

Since Apex particles started to fade right after they are emitted and there are several problems with it:

1) Particles sometimes not fade and behave like they did before Apex

2) If you move camera away from fully faded particle and then look at it again, particle will be fully visible until end of its life

 

Question is, what is logic behind deciding if particle should fade or not? Is there a way to enforce fading or no fading?

[NeoArmageddon 958]

1 hour ago, samatra said:

Necro bumping the thread.

 

Since Apex particles started to fade right after they are emitted and there are several problems with it:

1) Particles sometimes not fade and behave like they did before Apex

2) If you move camera away from fully faded particle and then look at it again, particle will be fully visible until end of its life

 

Question is, what is logic behind deciding if particle should fade or not? Is there a way to enforce fading or no fading?

 

I can just speculate that atleast the particle hardlimit is enforced by a first-in first-out principle but I dunno if that is also applied to your fading problem. What you describe sounds like a bug or a misconfigured animation.

[samatra 85]

12 hours ago, NeoArmageddon said:

 

I can just speculate that atleast the particle hardlimit is enforced by a first-in first-out principle but I dunno if that is also applied to your fading problem. What you describe sounds like a bug or a misconfigured animation.

Yeah, I guess there is some kind of limit on amount of fading particles. If its true then I'm out of luck with stopping particles from fading. I wish we had some kind of particle array (class) parameter which controls fading.