Lots of progress

It's been a little over a week since I last posted. I've made a ton of progress but not alot that can really be shown. I'll do what I can with some quick screenshots.

First of all I decided to just ignore the particles issue for now. I'm nowhere near ready to start really working on fx and what i have works for what is needed.

I fixed a bug that had been annoying me since I first wrote the flight physics. When the aircraft was near 180 and the velocity dipped more or less the flight physics would go crazy. This was most obvious when I tried to implement barrel rolls. When upside down the angle of attack would get stuck at + or - 180 and you would either turn into a rocket ship or get slammed into the ground. well I fixed it! before I was finding the difference between your 3d forward vector, projected to 2d space, and the 2d physics engine velocity vector. This worked for small values but not larger ones. I now project the 2d velocity vector into 3d, and convert it to a "local" vector for the plane. I then project the local 3d vector back to 2d and find the angle. Theres actually less math involved in this case since atan2, which is expensive, is only called once instead of twice. All other math involved is fast multiplication, and I get the results I need for ALL angles!

I also fixed the "Snap" that was shown here.

As you can see in the gif I now have a better camera. It centers on where the player is looking while making sure the players vehicle stays on-screen, that way you have a good view of whats in front no matter your angle.

The next big step is terrain editing. I am working on an editor to make generating terrains fast and easy for myself. I'll do a more in depth post on it when it's in a more finished state. Once I'm happy with terrain editing I'll of course need a more general level editor where I can define terrain, player spawn, enemies, objectives, scenery, etc.

This project is definitely the longest one so far, but also the most complex yet!

Particles

I'm having some trouble with particles. On one hand I'd like to keep them simple so I can re-use the assets between emitters. On the other hand jMonkey's built in particle system doesn't like dark particles.

I am happy with the effect I came up with for rockets, and I was able to re-do my old particle system to keep persistent trails around after the rocket entity dies. But I am not happy with the blend modes available to jme.

Jme has 9 different blend modes for it's particle material, and of those modes 6 are "additive" type modes, or modes which when combined make the color brighter. This makes sense for alot of particles, white smoke, clouds, fire and electricity all make things brighter. When you want things to get darker though, it gets more complicated.

So much of the effect gets blown out from the additive modes.

Alternatively I can use alpha blend, and color all the particle effects in an image editor. This results in some nice looking effects but it becomes much harder to re-use assets. Currently all of my particles are simple black and white textures which makes it easy to use the same effect for fire, smoke, fog, water, etc.

I think I am going to look into adding more blend modes myself over the next week or so.

Zay-es and "Blueprints"

One of my favorite libraries for jmonkey is Zay-es entity system. Zay-es is a powerful entity-component system that really forces you to consider an entity-component system from a very "pure" perspective. This is really great for rapid prototyping as I have built up a collection of components that are very easy to drag and drop from project to project. The only thing I really need to change are the underlying systems.

That said, entity-component systems to have their shortcomings. One problem I have been trying to find a good solution to is saving and loading entities. Zay-es has a way to do this, though from what I've read it's focused more on saving/loading the entire system as opposed to a single entity. I am interested in saving/loading a "blueprint" of an entity, much like Unity's prefabs. In the past I have used factory type builders to get an entity when I needed to spawn many similar objects, such as bullets or enemies.

Today I figured out a way to achieve this using json files! I came up with a simple way to use Gson to read and write easy to read files with all the components you would like attached to an entity. These files are simple text files so modifying them outside an ide is simple. Here's an example file for you :

com.mru.lib.scene.TransformComponent
{"position":{"x":0.0,"y":1.0,"z":0.0},"scale":{"x":1.0,"y":1.0,"z":1.0},"rotation":{"x":0.0,"y":0.0,"z":0.0,"w":1.0}}
com.mru.lib.scene.ChildComponent
{"parent":{"id":1},"offset":{"x":0.0,"y":1.0,"z":0.0},"scale":{"x":1.0,"y":1.0,"z":1.0},"rot":{"x":0.0,"y":0.0,"z":0.0,"w":1.0}}
com.mru.lib.scene.ModelAssetComponent
{"key":{"name":"models/MG.j3o"}}

My simple Gson parser assumes that every component is preceded by the class path. This is read using a buffered reader and the class is located. After a class is located the reader will read the next line using Gson which will instantiate the component.

The read/write commands are held within an "Entity Blueprint" class, which is basically just a set of components and the read/write commands to parse the files. During run time the blueprints can be used to quickly set components of entities as they are created.

In the example above you will notice a "child component". This is an example of the pitfalls to my system. Any component that references another entity (id:1) will not work after loading. There is no way I can guarantee entity's id's at runtime. For now I can design around this by not making blueprints of entities that rely on such components, but in the future this is a problem I will need to address.