Oni Central Forum

SomeGuy

Member

Registered: 08/29/17

Particle questions

Useful titbits from the .
Particle file naming:

_e emitter
_p particle
_x expiration / explosion
_f fire
-------------
d_ decal
w_ weapon
h2h_ hand to hand
env_ environment
super_ daodan / daodan related

> But why didn't they just use a single file?

If i remember correctly a particle cannot spawn itself with copies. (Blame their structure.) So you always have two files in such scenario, minimum. The e as emitter with location/spawn rules, the p as with the actual appearance. They work in tandem. Watch out for links such as

<Emitters>
  <Emitter>
    <Class>env_rat_p01

There's only one file type for particles, but they can be very diverse. When you look at the binay (or "hex" form) of a particle it is stored with all its properties in - may they be relevant or not (certain flags can disable sections). Options, Properties, Appearance, Attractor tags always fully extracted to xml. So one difficulty is to learn what parts of the files are in actual use.

Particle sub-types (families):

I don't think there are many distinct sub types however we never really got around in documenting their condition (what flags make what tags active). Decals are probably the most distinct and easy ones to understand.

Necessarily not all but few of the properties can be used to define sub types as some properties can be combined and others exclude each other (e.g. decal and lensflare).

        <Properties>
            <HasVelocity>false</HasVelocity>
            <HasOrientation>false</HasOrientation>
            <HasPositionOffset>false</HasPositionOffset>
            <HasAttachmentMatrix>false</HasAttachmentMatrix>
            <HasUnknown>false</HasUnknown>
            <HasDecalState>true</HasDecalState>
            <HasTextureStartTick>false</HasTextureStartTick>
            <HasTextureTick>false</HasTextureTick>
            <HasDamageOwner>false</HasDamageOwner>
            <HasContrailData>false</HasContrailData>
            <HasLensFlareState>false</HasLensFlareState>
            <HasAttractor>false</HasAttractor>
            <HasCollisionCache>false</HasCollisionCache>
        </Properties>

I think those sub types are exist for sure:
- decal
- lensflare
- 3d object (instead of lensflare)
- contrails (white / colored, flat texture attached to attack TRAMs)
- damage dealer
- helper particle (anything with one of those: location, orientation, attractor, emitter, event, used as emitter or in between a chain)

Or maybe think of "typical particle families" instead of "sub types".

Investigating particles:

Example:

God I wish this forum had spoilers, anyway one more question, how do particles work with sounds? Do they just use same emitters or is there something more sophisticated going under the hood? Can you assign a sound to a specific particle for example?

Last edited by SomeGuy (09/02/17 07:09)

paradox-01

Member

From: Germany

Registered: 01/14/07

Re: Particle questions

Sound in particle:

The answer to all of these is "yes". You use emitters most of the time however you should be aware under what event they get played and you must know if you want an ambient or and impulse sound. Impulse is played only once.

Sounds can be played at 3 locations within the particle.

Use OSBD*.amb for
BINA3RAP <AmbientSound> (action type)

Use OSBD*.imp
BINA3RAP <FlyBySoundName> and <ImpulseSound> (action type)

Not every sound is either available as imp or amb, so watch out here a little.

Particle overview
in Event
in Event
in <Options>

 particle
  |
  +-- event
       |
       +-- action type
            |
            +--sound

Actual examples

BINA3RAPbarwave_e02.xml

        <Events>
            [...]
            <Create>
                <ImpulseSound>
                    <Sound>barabstomp</Sound>
                </ImpulseSound>
            </Create>
        </Events>

BINA3RAPenv_shinzom_sound.xml

        <Events>
            <Start>
                <AmbientSound>
                    <Sound>shinzom_ambient</Sound>
                </AmbientSound>
            </Start>
            <Stop>
                <EndAmbientSound />
            </Stop>
        </Events>

The engine then walks through the files to receive the actual sound (SNDD).

Ambient sound:

OSBDyourfile.amb.oni
  |
  +-- OSBDyourfile.grp.oni
        |
        +-- SNDDyourfile.oni

Impulse sound:

OSBDyourfile.imp.oni
  |
  +-- OSBDyourfile.grp.oni
        |
        +-- SNDDyourfile.oni

Stationary  particle - those who can be addressed via BSL - can be triggered to fire their events.

Can be helpful for testing stuff.

Last edited by paradox-01 (09/02/17 09:09)

s10k

Member

Registered: 01/14/07

Website

Re: Particle questions

Sorry for the bump, but had anyone actually got the FlyBySoundName work? I never could get that one working.

AmbientSound and ImpulseSound work good.