Rantako on 12/8/2005 at 15:19
After experimenting with custom emitters and seeing how horrendously complicated they are, I thought it would be a good idea to start a thread where we can all post what we know/discover about them, so we can eventually expand the information on the wiki page and have a comprehensive guide to making emitters.
Here’s some things I’ve found:
The emitter archetypes in the gamesys (under FX -> Emitter) don’t actually emit anything on their own. The things that do emit are hidden in the archetypes’ properties. I’ll use the archetype TorchFlame as an example here. Look in its properties under Emitter -> Emitters and you will see there are in fact two emitters on this archetype, named [0] SpriteEmitter'T3Gamesys.SpriteEmitter__100' and [1] SpriteEmitter'T3Gamesys.SpriteEmitter__102'. These are separate emitters with their own properties (though they can’t be moved separately – they are both ‘stuck’ to the actual archetype which you place). The second one is the torch’s flame, the first one is the smoke.
So, if you are making a custom emitter that is simply a combination of these already existing pieces, it is really easy – you just need to copy and paste their names. However, if you want to make something completely new, you have to make a completely new piece.
Say, for example, you want to make a purple flame. If you create a new archetype under TorchFlame you will see it has the same emitters as TorchFlame. However, we can’t edit these here, because they will change the properties of the ones on the TorchFlame as well. This means we will have to create a completely new emitter for it. New emitters need all of their properties set up manually, which is a lot of work if all you want to do is change the flame’s colour. So for little changes like that, it’s much easier to place a concrete TorchFlame and edit its properties. You can do this without messing up archetypes. (On a side note, purple flames look cool! :cheeky: )
These are the properties I’ve experimented with so far (they’re all from sprite emitters)
General
MaxParticles – the maximum number of particles from this emitter that can exist at the same time. When there are too many, some will be deleted as more spawn.
Size
SizeScale – seems to make particles change size as they are moving. I assume RelativeSize is relative to the value set in StartSizeRange, and RelativeTime is relative to how long the particles exist for, set in Time -> LifetimeRange.
SizeScaleRepeats – how many times to repeat the size changes in the SizeScale property
StartSizeRange – sets the size of particles
UseSizeScale – True: the values in the SizeScale property will be used and so particles will change size. False: the values in SizeScale are ignored.
Texture
BlendBetweenSubdivisions – doesn’t seem to do anything.
DrawStyle: (These might not be correct) PTDS_Regular – texture is fully lit and transparent. PTDS_AlphaBlend – same as PTDS_Regular, but darker. PTDS_Modulated – texture is tinted black and transparent (and any invisible areas, like around the border of fire textures, show up black). PTDS_Translucent – seems the same as PTDS_Regular. PTDS_Darken – doesn’t seem any darker than Regular. PTDS_Brighten – seems the same as Regular. PTDS_TextureAndVertexAlphaBlend – seems the same as PTDS_AlphaBlend. PTDS_MultiplyColorByAlphaThenAddToFrameBuffer – seems lighter than PTDS_AlphaBlend, but darker than PTDS_Regular.
Texture – the texture to use on the particles.
TextureUSubdivisions – sets how much of the texture to use on each particle. Must be more than 1 (a value of 2, for example, will use half of the texture). Only works if TextureVSubdivisions is set too.
TextureVSubdivisions – same as above, but on the V plane. Only works if TextureUSubdivisions is set too.
Time
InitialDelayRange – how many seconds before particles start spawning
InitialTimeRange – made my T3Ed crash to desktop. Don’t know what it does/if it works
LifetimeRange- how many seconds particles exist for
Velocity
GetVelocityDirectionFrom – having this set to anything other than PTVD_None seems to stop the particles from moving.
MaxAbsVelocity – seems to overwrite whatever is set in StartVelocityRange
StartVelocityRange – used to set the direction the particles go in. Having a different Max and Min value makes them go somewhere between the two values.
VelocityLossRange – seems to make particles go less distance in the specified direction
If anyone knows more, please post here. *Gazes at the hammer fountains in Schism*
Ziemanskye on 12/8/2005 at 16:58
Chech the schism unr file. (
http://rapidshare.de/files/3914198/Schism_UNR_files.zip.html) (newer version of the unr's here)
I started with blank emitters (just Actor>Emitter, rather than a sub-class) and built them myself. Most of the properties of sprite emitters work, though it can take a bit of experimentation or extreme values to make the changes show.
The texture subdivision controls for example, are good for animated particles where you can put all the frames on the same texture - I don't think any of the Thief 3 particles do that, but there are some good examples in UT2k4.
The Colour options are great too - turn on the colour scale, and add entries to the scale with times on them and it'll blend between them, so you could have a particle that starts blue, fades to white then to orange, and in combination with the SizeScale options could have a tapered multicoloured gas-lamp, which further combined with velocity, rotation or animated textures could then be made to wander a little like a real flame.
They are kind of a play-with-it-till-it-looks-good kind of thing though.
Location>
The start location range is the area the particles start in. Editing this means you can have wide beams effects like the window light shafts, or sparkles in the air, or whatever.
The start location offset is how far away from the icon the particles start - if you have move than one emitter in the effect, you can have for example the hammer head start above the handle, other wise you end up with a cross or inverted T shape.
Dark Arrow on 13/8/2005 at 07:15
Last time I tried to create a custom emitter to the gamesys, I wound up with a missing emitter archetype next time I loaded the mission. Perhaps I should try again...
ProjectX on 30/8/2005 at 20:08
I wrote a tutorial on teh wiki on how to make a sprite emitter from scratch, it doesn't go into much detail, sinc there's the udn for that.
massimilianogoi on 23/9/2009 at 21:53
I need of a 256x256 emitter, to simulate the fog-like effect typical of the water vision. This emitter has to be in the shape of a cube.
I tried by expanding in the Z axis the disc emitter of the fountain, but just a large amount of discs popped out.
Could someone help?
ascottk on 23/9/2009 at 22:07
Quote Posted by massimilianogoi
I need of a 256x256 emitter, to simulate the fog-like effect typical of the water vision. This emitter has to be in the shape of a cube.
I tried by expanding in the Z axis the disc emitter of the fountain, but just a large amount of discs popped out.
Could someone help?
Is this for when you look into the water or when you're in the water? If you're in the water then follow my tutorial:
(
http://206.135.105.20/wiki/Underwater_Vision)
massimilianogoi on 24/9/2009 at 10:24
Already tried :) But it has a trouble with the third person vision. I spent an entire day trying to do modifies so this could be avoided, without disabling third person, resultless.. That's why I need of an emitter in 3D.
Judith on 24/9/2009 at 10:30
That's why I locked the first person while underwater, temporarily deleted player inventory, so it can be restored later and made Garrett model invisible. It's easier :)
massimilianogoi on 24/9/2009 at 12:37
Quote Posted by Judith
That's why I locked the first person while underwater, temporarily deleted player inventory, so it can be restored later and made Garrett model invisible. It's easier :)
The problem is when you emerge from the water, then you could have troubles with the restoring of the third person view, because you could enter in the waters with the camera, and have the fog disabled. Naah, here we need of an emitter.
Let me explicate the situations of the problem depicted above:
Inline Image:
http://i35.tinypic.com/59vgpt.jpgFrom the place where the cam is located, you see under water, but with the fog effect disabled, so the water "disappears", while if we have a 3d cubical emitter, the cam is forced to see through it.
