FX ideas
-
Yes, I know - was just an idea on improvement.
I am unsure how much control you have over the particle system, but one of the weapon effects that are plain impossible to perfectly reproduce in FL is a sort of a ‘beam’ - or a continuous laser. In FL, you can make it up of several thin projectiles of uniform width, refired incredibly fast, but it is still not the same.I’m not sure how clear or easy to understand I was…
-
I am going to put a beam FX in the code. I will generate a solid beam of any length or pulses like FL makes. I will be using a ray cast style of collision detection to limit the beam length if it intersects anything in it’s path.
-
Well, thats not going to be a problem since I am writing my own code. I am going to be making the beams as a particle fx that is simply stretched from starting to point to the end point. It will only require a total of 2 particles to make it. I have also been thinking of making it a line which draws even faster.
-
Depends on what properties you can give to the line. For example attaching a simple texture has an extremely nice effect, especially for thicker beams. It makes the “inside” of the beam glow in, say white, and the rest take on the colour of the beam (having fun with alpha channels there).
Back to torpedoes, it always felt strange to me that in FL all I see is a massive glow, and a trail. The torpedo mesh is so minute in size that I’d bet some never even noticed it.
This is a non-effects question, but to what extent are you making a simulator? That is, how much control the player is having on the ship. One of the things I liked in some other games, an example being X-Wing vs TIE Fighter, is that you can balance your fighter’s power supplies between weapons’ recharge, shield regeneration and engine power.
If you are planning any features similar to that, my question is, how much chance is there to make the cockpit “dynamic”? For example, attaching the targeting computer as a sort of “dynamic texture(?)” to the cockpit’s very own mesh, the same applies to all these ship settings. In that case, the cockpit actually has a use, as that hides all the instruments, and the player HAS to switch back to cockpit view to see his speed, radar, targeting computer, throttle, and so on. XvT did it with a simple 2D cockpit, with the screens “pasted” on top of it - but I have never seen this done to a 3D cockpit; they don’t know what they missed - this adds an amazing essence to the game itself. -
**At the moment I don’t even have a mesh for the emitter, which is where the torp mesh would be placed. I will be adding that in too since I want to put the pulse beam fx as the emitter mesh. The size of the trail is completely adjustable and each setting is range based. As in you can set the starting scale like st_scale = 0.5,5 which means the emitted particle can range in size from 0.5 to 3 times it’s size.
The power system will be adjustable and you will be able to move you power use around to different systems. This is real common in Star Trek style games as well.
As for a 3D cockpit, Evochron has that. I will have I believe 8 different camera modes, cockpit included. As far as limiting the HUD display to the cockpit, I doubt I will even do anything like that. That is because I hate flying in a cockpit, the frame of the cockpit gets in the way of seeing around me. Plus it is easier to tell if I am being shot or who is around me. BTW, the cockpit will be a 3D mesh just like in FL. I had also considered adding in internal ship layout for walking around in but that would mean I need to learn how to model good. ;)**
-
Walking around inside…now that sounds interesting indeed. Perhaps could use that for enabling / disabling weapon systems, mounting newly tractored equipment, processing fuel type loot… o.0
Any plans for a “chase cam” type window? I recently have been trying out X3, and I gotta say having the main view and 2 other optional view windows available rocks. Opens up some nifty game play ideas with one able to be tied to a observation satellite. Remember the 'ol missile cam on some games? That’s always fun for “scouting” in skeery areas you’d rather not fly directly into first.
Edit: woops uh yeah kinda got off the FX track, sorry LS
On that note, how about some additional shapes for emitters? Ring, Triangle, Square could all have enough attributes to make the variety huge. Now, what I’m meaning here is the particles would emit from a spline shape.
Think of the Liberty capship engine effect, it’s kinda cool, but…. it’s flat… which isn’t cool. That’s bugged me a while now, same with many large capship engine effects; why attach 15 engine effects where a rectangular (square) spline would look better?Edit 2:
As for easy implementation - the format: Shape_type, Center location and Orientation, and Diameter. Though you could also throw in Rotation -as in at 0 degrees, the effects emit in the same direction stated in Orientation, but at say… 90 degrees you get effects looking like planet rings.Edit 3:
lol ok was re-reading a little on the view thang. It might be beneficial to think modular. We’re already seeing many systems with 2 monitors, but only the high end graphics programs are starting to really make use of this yet. If you can set the view to be “projected” on a face itself, and make your display based upon that and camera label… You’d be able to support 3 monitors when we’re wanton enough to have that many on hand (enabled & configured in start-up options) - one for the standard front view, one for left, one for right… or left / right split on one and rear on the 3rd… or one with your e-bulletin board system, one with ship stat monitors, etc etc.Since I’m a n00b tool in the programing area, I have no clue what all that entails. Just got the projected idea when looking through ffdshow settings and tweaks. But that was for 2d movies, so not sure how applicable it is for a real-time 3d rendered environment.
-
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.**
