@bgolus I'm wondering if there wil be another fx offset type implemented like reclaim for example? It would add that polish to the nanolathe. Code: "fx_offsets": [{ "type": "build", "filename": "/pa/effects/specs/fab_combat_spray_rec.pfx", "bone": "socket_muzzle", "offset": [0, 0, 0], "orientation": [0, 0, 0] }, { "type": "reclaim", "filename": "/pa/effects/specs/fab_combat_spray_rec.pfx", "bone": "socket_muzzle", "offset": [0, 0, 0], "orientation": [0, 0, 0] }],
I just spend an hour trying to figure out why my mesh effect was acting so strangely (i tested it on the wall and the effect appeared twice for every 100 walls) and then I realized I had to place the delay in the particle SPEC instead of outside..... fml EDIT: actually delay doesn't even work in the spec... wtf EDIT 2: So can anyone actually explain why this effect is so strange? Code: Code: { "emitters": [ { "spec": { "shader": "meshParticle_transparent", "shape": "mesh", "facing": "EmitterZ", "red": 6, "green": 6, "blue": 6, "sizeX": 1, "sizeY": 1, "alpha": [ [ 0, 1 ], [ 0.5, 0.1 ], [ 1, 0 ] ], "papa": "/pa/effects/fbx/particles/tele_base_indent.papa", "materialProperties": { "Texture": "/pa/effects/textures/particles/energy_wall.papa" } }, "offsetZ": 0.2, "lifetime": 1.5, "emissionRate": 1, "delay": 0.1, "maxParticles": 1, "emitterLifetime": 0.5, "killOnDeactivate": true, "endDistance": -1, "useArmyColor": 2 } ] } .papa: https://mega.co.nz/#!d4EFFajb!14_lyLG32f61d8gAuGUbbZumVp-6qh4BAV1E1XFm8oo
I found a solution again. I looked at the delay description in the guide and it says it needs to have at least one emitter without delay so I created a point light with no alpha and now it works fine.
I found bug I think. It seems that the facing key in a particle spec does not always work as expected. I found that if I have two emitters in an effect file, the first facing EmitterX, the second facing EmitterZ, both particles will face EmitterZ. It seems the facing is taken from the last emitter in the 'emitters' array. Code: { "emitters": [ { "spec": { "facing": "emitterX", "dataChannelFormat": "PositionAndColor" }, "sizeX": 40, "offsetZ": 25, "emissionBursts": 1, "lifetime": 6.0, "bLoop" : false, "endDistance": -1 }, { "spec": { "facing": "emitterZ", "dataChannelFormat": "PositionAndColor" }, "sizeX": 40, "rotation" : 1, "offsetZ": 25, "emissionBursts": 1, "lifetime": 6.0, "bLoop" : false, "endDistance": -1 } ] } Try putting that inside of ping.pfx. You will note that both particles are horizontal. If you make the second particle's facing direction 'emitterX', then both will be vertical.
I'm just going to request something here So with the supreme commander nukes, the screen is lit up and it makes it really hard to see the ground, and that's something i'd like to have in this engine Unless someone knows a hacky way to do that?
Going to request another thing from sup com. Watch the UEF nuke shockwave which appears to shake up a lot of dust on it's way. I tried to accomplish this, and it looks like it's impossbile. Currently the SHELL, SPHEROID, and CYLINDER_Z shapes spawn particles inside the emitter when the offsetRange values are increased and this will spawn particles everywhere instead of right on the edge of the cylinder/shell/spheroid. So an emitter type like "RING" would be really awesome
That's how cylinder Z works though. OffsetX,Y controls the radius of the cylinder, and offset ranges control the thickness of the spawn area. Have a look at the nuke effect and find the soft smoke wave.
yep i've already seen the smoke thingy in the nuke but that doesn't work like the thing in the video. There's no way to make the cylinder hollow, meaning particles only spawn on the edges. The current cylinders will spawn particles everywhere within the offsetX Y frame. I thought about using radial velocity but I dont think the snapToSurface and useArcLengthSpace works with velocity.
It only spawns on the edge though, it's in the particle spec doc bro. What I mean is that if you set the offset range to 0, it will spawn on the edge of the cylinder. The edge of the cylinder is controlled by the offsetX,Y. So offset range controls the thickness of the spawn area, from the edge. https://docs.google.com/document/d/...eG3A1dN2m5oik6f3Fw/mobilebasic#h.ek3yz2hmstd8
actually yeah you're right. I never though the offset values would change thickness, i probably should have read more about that before making that post
Probably not much of a bug, but it isn't quite right. Beam weapons always spawn effects as if the end-point is the target, not the point where it actually hit something. So if a beam weapon is firing at object A, but hits object B instead (because it is in the way), object B will receive the damage, but object A will still be the end-point for the beam effect and the particle hit effect.
Two emitters with the same shader and textures will somewhat randomly choose a single facing direction for an entire system. This is only for camera and the emitter facings, the axial and velocity facings aren't affected. You can work around the bug by setting a different baseTexture or rampTexture (even if it's not used by the shader) on each emitter. I think I have a hack fix for this I can push out maybe with the next PTE. You could use a giant "particle_transparent_screensize_nohdr" shader particle with a lot of cameraPush, or an even more giant "particle_transparent" shader particle with a lot of cameraPush. Yep, not a bug with effects as much as the server doesn't inform the client of the actual hit location. I'll look to fix that someday.
Thanks. I'll try out that shader. So in the PTE with the asteroid belt effect, I noticed it's spinning. But I also noticed that there is a new type called "TORUS" and it looks like that is basically a simplified version of a cylinder. I was trying to figure out how the entire particle system rotates, but there's no offset keyframes nor an emitterRotation flag which I was hoping to see xD So i'm wondering, how did you get the particle system to rotate because it's clearly not defined in the emitter? Is it bound to an invisible model hidden inside the sun that rotates?
The torus: https://upload.wikimedia.org/wikipe...6/Simple_Torus.svg/310px-Simple_Torus.svg.png My guess is that it is simply attached to an entity that is rotating. Probably using the new puppet system? @bgolus One more thing, it seems that camera push is ignored for beam particles? I only say this because I tried using it to stop the beams of sniper bots from being mostly invisible because of being on a small planet.
Yeah haha I know what a torus is xDD And yep there's probably something in the sun that's rotating. I think i just found out how to make a hacky tornado effect
Using the cylinder types creates a kind of boxy torus shape that was apparent when doing something the scale of the asteroid belt, so I added torus which is kind of like a combination of the cylinder_z and spheroid types. It's actually about twice as much math as the normal cylinder type. The system is being rotated in the code (it's roughly matching the orbital speed of the asteroid planets). It's not using the puppet system. It's something I'd love to add to the effects system to be able to handle on it's own, but that requires a lot more work than just making the game rotate this one emitter with a bit of custom code. Beam and string emitters don't respect camera push. They're data hungry particle types as is, so there was no place to store the push value.
Btw, the way I would do a tornado is with mesh particles or have the unit have a spinning bone I would attach to with a beam emitter or a keyed offset / velocity direction emitter.
Hi @bgolus, I am afraid I have found it really difficult to phrase this question, but here goes: I am making an effect which is using a mesh particle (the mesh being a sphere). I would like this mesh particle to be using additive blending, which I can do, that's fine (using shader : meshParticle_add). The problem is however, if I use additive blending, I get some weird consequences with respect to rendering that mesh underwater and among other particles. What I am seeing is that the additive mesh particle seems to be rendered on top of water, and on top of other particles too. I noticed however that if I instead use the shader : meshParticle_color, I get the desired behaviour where the mesh's depth interacts as expected with water and other particles. But then the colors are not right . So finally, here is the question . What is it about the description in particle.json, or, what is it about the fragment/vertex shaders which allow the expected behaviour I want? I am willing to change the particle.json for my mod, and also add any of my own fragment (or vertex) shaders that permit this behaviour. I just need to grok how this rendering pipeline decides to depth blend as expected Picture for perhaps an illustration: This walls are on the other side of the water, but they are rendered on top.
