FX ideas
-
As far as the emitter shapes, that is a good idea. All I would have to do is simply copy the code from the nebula generator. It supports sphere, box, ring, hemisphere, toroid and disc shapes. The emitter supports billboard and non-billboard particles. I finished converted the entire emitter and particles’ position, rotation and velocity to quaternion code. Now I can make it act exactly like I had intended on it. As it stands now I have just a single setting left to add (reverse movement) and I will be able to duplicate the cruise engage FX (warp FX in GE). Also since it is now quaternion, I no longer have to calculate the direction vector, using quats all I have to do is add a Z velocity and it moves forward. Since it also supports X & Y movement (used for strafing in FL), I can make the FX look like it is spewing out flames. I am planning on adding in a solar flare style FX where the stars emit large flares out of the surface.
-
**I’ve done some additional work to the FX engine. I have fixed the scaling bug and also added a feature that lets the particles end normally instead of disappearing when the emitter dies.
Special weapon
Flame test
Another flame test
** -
very nice LS
-
Here is how hard it was to make the special weapon
[effect] nickname = test_torp emtr_life = 20 txtr = FX\TORPS\WhtTorp03.png ; texture to use, max of 32 per fx txtr = FX\TORPS\WhtTorp01.png ; textures are picked randomly txtr = FX\TORPS\WhtTorp02.png ; when the particle is created txtr = FX\TORPS\BlueTorp01.png txtr = FX\MISC\Ring01.png life = 2 ; min,max death = die ; what to do at end of the particles lifetime st_color = 255,160,64,255,192,96,0,255 st_radius = 0 st_vel = 0 st_rot = -180,180 st_spin = -60,60 st_scale = 0.01,0.5 emit_rate = 0.033 drag = 0 wait_to_die = y fade = color,,1,1,1,1,1,1 ; type,trig type,min,max,r,g,b,a,r,g,b,a fade = scale,death,,,5,7 fade = color,death,,,0,0,0,0 -
**At Mini_Me, actually running it on multiple monitors is a pretty good idea. I use both a 4:3 and a 16:9 monitor so it wouldn’t be hard to test it. The only real problem with running multiple displays is that alot of computers would lag out if the information on the 2nd or 3rd screen have to updated alot. Who knows, I may try just to see, it would be nice to move the hud info to a second screen and only have the current scene running in the first screen. Since I already use a custom made full-screen window, making it create 2 of them would be easy. A side benefit would be if you are using 2 video cards like I am, the memory footprint for the textures would be spread between the video cards.
A couple of other effects that I want to put in that affects the particles is wind and gravity. I had also thought of implementing my spring code into it but first I need to find a better way of handling them. The current spring code can become unstable if the attachment forces from the other particles become too strong. The instability is caused by the fact that the entire particle soup isn’t instantaneously updated. In the real world that is what happens, but in the computer world each particle has to be handled one at a time ( times the number of cores you have ). I had been considering using an accumulating force map that is only applied after all of the forces were combined together.
Another use for springs is in creating realistic fabric. It can be used for curtains, clothing, flags, etc. My DB Modeler program supports this method of using springs.
Here is another shot of the special weapon, I was flying through the tail.
** -
Very nice. I just had that twisted idea of, if these dynamic cockpit-textures are possible, displaying the starmap on the cockpit window, like a projector or holo… Wouldn’t be different to the “cockpit controls display” as the only difference is the alpha channel. But then again this has nothing to do with FX once again.
The effects are superb. I just plain like them. Is there any hope to have dynamic lighting work more properly (FL has its limitations), for example, headlights that actually work and can be turned on/off?
As for your reply on flying outside the cockpit - in simulators (not necessarily FL) people tend to fly outside cockpit view, but always return to that to get a good aim (or prepare that missile lock). In FL you don’t need to prepare a missile lock, and don’t even need to aim, as mouse controls will have your guns swivel into position automatically. However, for me, enemy padlock cameras (when you are “looking at” the enemy or friendly fighter) are strictly outside view.
Everything depends on how many controls does the player need to operate. In XvT with the abundance of controls I rely on a “Front” and “Rear” radarscreen, which give you a nice idea on where things are, and only fly in outside view when the radar has been damaged. -
**I am working on making it as easy to use as possible. I will see later on if I can build some of those features you listed above.
Here a are a couple more FX shots I did today**
-
It is simply a cross shape object, nothing more. Below you will see the standard style of FL torpedoes.
The texture used above is
Click here for full size image
The texture used here
-
**Well, I finally got the collision detection working pretty good. At this time I don’t have to use any type of collision file for any of the models in the game. I also got the trigger FX feature working, what this does is allow one FX to trigger off another one when it collides with something.
Here is a shot of both the triggered FX (the explosions) and 3 of the torps passing through a hole in the city’s foundation…
Here are 2 shots taken within seconds of each other, pictures really don’t do it justice.
As you can see, it is working pretty good now, and I don’t have to make a SUR for it. :)**
-
Sooo, we can use this to create something like sparks when parts of an explosion impact nearby objects?
Which part triggers the secondary? Particle, Emitter, or the mesh hosting them?Nice to hear we won’t have to worry about SUR files lol. So we’ll also be able to create concave objects easier? If so, that would do wonders for bases, asteroids, cap ships; all sorts of fun stuff. Interested in how this is handled.
Edit: convex to concave
daaammit jim! cave…meep meep -
**Here is a link to get an idea of how many convex and concave parts the city model has.
http://www.galacticenigma.com/Cpm/displayimage.php?album=1&pos=50
The method I used was to get the path that the emitter is travelling on. Since I only needed the path between the current position and the next position, the length of the path was fairly short. In graphics jargon what I used is a form of ray casting. This is where you send out a straight line from the current position and end at the position you wish to be at. If it collides with something it will return the location, mesh and the face it collided with. DirectX has a ray testing routine but it requires alot of setup to get it to work. Plus each object that has to be checked has to be tested separately. I did speed up the code by making it only check for collisions if a ‘coll =’ command was part of the FX script. Another way I sped it up was by using the final matrix from the object tested and converting the ray into object space. What this means is that I won’t have problems with matrix instability testing collisions for objects near the outer edge of the systems.**
-
**Hehehe, so true it isn’t Freelancer at all
Disclaimer
The FX posted above are for Galaxy Empire, I don’t have any idea on how to recreate these FX in Freelancer. GE is of my own design and has no connection with Microsoft in any way. So feel free to post any ideas you have because I may be able to write the code for it.
Anyways, thanks for pointing that out Bejaymac, I’ve seen them mistake it for FL before :)**
-
@Lancer:
Anyways, thanks for pointing that out Bejaymac, I’ve seen them mistake it for FL before
Which I think is a great indication of the nice work you’re doing
-
Screwing with the nebula scripts
