[9:30:32 PM] <[AP]el_Gizmo[END]> is there a way to make particles effected by the wind direction used by windmills
[9:36:11 PM] <[RoX]Tobi> hmm, don't think so
[9:36:39 PM] <[AP]el_Gizmo[END]> would be fantastic if it was, would make the game far more dynamic
[9:36:39 PM] <[RoX]Tobi> could try to make a thread about it, should be pretty trivial to add for anyone knowing spring code a little bit
[9:36:54 PM] <[AP]el_Gizmo[END]> orly !
[9:37:10 PM] <[RoX]Tobi> ya rly
So....erm....any ideas peeps ? Im thinking of nuke clouds drifting over wreckage, making fire more lively looking etc...
Particles effected by wind direction
Moderator: Moderators
-
- XTA Developer
- Posts: 266
- Joined: 24 Aug 2006, 01:33
-
- XTA Developer
- Posts: 266
- Joined: 24 Aug 2006, 01:33
I'd like to test it, and I'm glad to hear that this might be available, since I've been forced to emulate it in various ways for awhile.
"Always on" will hopefully not become mandatory, though. And it might be nice to be able to declare a scale, a max and a min, considering that some maps have bizarre wind values...
"Always on" will hopefully not become mandatory, though. And it might be nice to be able to declare a scale, a max and a min, considering that some maps have bizarre wind values...
I think a nice float parameter sounds good. And yeah, this is just always on to test if it works, and so I only need to write a couple lines.Argh wrote:I'd like to test it, and I'm glad to hear that this might be available, since I've been forced to emulate it in various ways for awhile.
"Always on" will hopefully not become mandatory, though. And it might be nice to be able to declare a scale, a max and a min, considering that some maps have bizarre wind values...
Uploading took forever, but here it is. http://xta.wolfgame.org/SimBase/spring.exe You'll need the newer dlls. I'm not sure if they're in the recent svn installers or not.
Edit: Hmm, by max and min exactly what do you mean? A way to normalize the wind intensity for its effect on particles?
Basically a ceiling and floor- if the wind on a map is 10000, do we really wanna see our particles shoved across the screen that fast? On the other hand, do we want to force mappers to only use wind within a range that keeps certain FX pretty? A ceiling and floor, specified by the FX creator, would be pretty handy in preventing the system from ever doing something terrible, under those conditions.
YES!!!
1. Weapon Explosions in general are hard-coded, with default values, and default texture expectations. See WeaponDef.cpp, IIRC.
For the love of Dog, isn't it about time to just point towards a generic set of CEGs, included with Spring, and move away from hard-coded stuff? If you're game to mess with this, then, er, I guess I need to write some FX to give away (I'll probably just take some stuff from PURE and include slightly different bitmaps, frankly), but I'd love it, if all of the hard-coded FX were clipped out or put under game designer controls, so that everything is a CEG, essentially.
2. Bubbles. IIRC, there are two kinds, for torps and for ships, and then the "foam" effect for weapons hitting water and hovercraft emit-sfx.
Torps should just have CegTag enabled by default, pointing to a default CEG for bubbles. Ships... it'd be really wonderful, imo, to make the code that allows the bubbles to work to be properly accessible as a CEG, with some user controls over particle size and stuff. Just porting it out've hard-coded-land would be a giant step forwards, tho.
The foam code is something else that, with a few controls added, could be really interesting for CEGs. We could do "liquids" that looked semi-real, and various shifting lights and other tricks with that billboard code.
3. Geovent smoke.
4. Smoke, in general. We *have* frame-animated particle systems in Spring, called smoke. What we *don't* have is any way to specify any other bitmaps! Moreover, we have *two* smoke systems, for no particular reason that I can see. I would like to see this consolidated into one new CEG called "animatedParticleSystem", with the ability to specify the particles 1-12 (defaults to smoke, of course) and at least the functionality of HeatCloud, if not CSimpleParticleSystem (or, maybe two different ones, for more-intensive and less-intensive uses).
Besides geovents, smoke is called by crashing aircraft- one of the many, many reasons why all particle systems in Spring should be CEGs- that way, we can turn stuff like that off...
6. Whatever effect the FALL | SMOKE and FALL | FIRE COB events call. I don't recall where that is in the sourcecode, at the moment.
7. Um... let's see... what else is mandatory... I *think* that's it- oh, no, there's that "flame" code caused by another emit-sfx COB code, also (for the air transports, sorry that wasn't very clear). Hardly anybody is using it, but it's still very much in Spring, should point to a CEG (perhaps the XTA peeps would be OK with their pretty one being default?).
Anybody else know any other hidden particle stuff? Those are all the biggies, I think... if you make all of that stuff point towards some default CEGs and make those few things that are not yet really usable as CEGs useable, that'd be a giant step in a very good direction, frankly!
1. Weapon Explosions in general are hard-coded, with default values, and default texture expectations. See WeaponDef.cpp, IIRC.
For the love of Dog, isn't it about time to just point towards a generic set of CEGs, included with Spring, and move away from hard-coded stuff? If you're game to mess with this, then, er, I guess I need to write some FX to give away (I'll probably just take some stuff from PURE and include slightly different bitmaps, frankly), but I'd love it, if all of the hard-coded FX were clipped out or put under game designer controls, so that everything is a CEG, essentially.
2. Bubbles. IIRC, there are two kinds, for torps and for ships, and then the "foam" effect for weapons hitting water and hovercraft emit-sfx.
Torps should just have CegTag enabled by default, pointing to a default CEG for bubbles. Ships... it'd be really wonderful, imo, to make the code that allows the bubbles to work to be properly accessible as a CEG, with some user controls over particle size and stuff. Just porting it out've hard-coded-land would be a giant step forwards, tho.
The foam code is something else that, with a few controls added, could be really interesting for CEGs. We could do "liquids" that looked semi-real, and various shifting lights and other tricks with that billboard code.
3. Geovent smoke.
4. Smoke, in general. We *have* frame-animated particle systems in Spring, called smoke. What we *don't* have is any way to specify any other bitmaps! Moreover, we have *two* smoke systems, for no particular reason that I can see. I would like to see this consolidated into one new CEG called "animatedParticleSystem", with the ability to specify the particles 1-12 (defaults to smoke, of course) and at least the functionality of HeatCloud, if not CSimpleParticleSystem (or, maybe two different ones, for more-intensive and less-intensive uses).
Besides geovents, smoke is called by crashing aircraft- one of the many, many reasons why all particle systems in Spring should be CEGs- that way, we can turn stuff like that off...
6. Whatever effect the FALL | SMOKE and FALL | FIRE COB events call. I don't recall where that is in the sourcecode, at the moment.
7. Um... let's see... what else is mandatory... I *think* that's it- oh, no, there's that "flame" code caused by another emit-sfx COB code, also (for the air transports, sorry that wasn't very clear). Hardly anybody is using it, but it's still very much in Spring, should point to a CEG (perhaps the XTA peeps would be OK with their pretty one being default?).
Anybody else know any other hidden particle stuff? Those are all the biggies, I think... if you make all of that stuff point towards some default CEGs and make those few things that are not yet really usable as CEGs useable, that'd be a giant step in a very good direction, frankly!
Addlurker wrote:Edit: uploading an always-on test version in a minute. Also, where can I aim my nerdrage over the fact that float3 * float works, but float * float3 doesn't?
Code: Select all
inline float3 operator*(float a, const float3& b) { return b * a; }
