Search the Community

In this post, I will compare volumetric lighting and particles in Ultra with Leadwerks. 1- Volumetric Lighting The volumetric lighting in Ultra Engine is very poor, so I recommend the volumetric lighting from Leadwerks 4.6 to be brought to Ultra. Because; 1.1- The volumetric lighting in Leadwerks looks realistic than Ultra. (Check 1st photo) 1.2 -The volumetric illumination value cannot be increased directly; to do so, the “brightness” of the light must be increased. 1.3 -Causes an FPS drop (I'm not sure if this is only happening to me) 1.4 -When you move a little away from the light source, the volumetric lighting is not visible. 1.5 -Volumetric lighting in Leadwerks dynamically emits light based on surrounding objects. in Ultra, volumetric lighting is static. (Check 2nd photo) In other words, the current volumetric lighting in Ultra is an incomplete feature. 2- Particle Effects I'll speak for myself about particle effects: The particle effect settings are confusing. I can never get the particle effect I want. For example, I couldn't figure out how to change the speed of my particle effect in ultra. Or the alpha value, duration time etc... Also, the curve editor in Leadwerks was a good feature. For example, I don't think such a particle could be produced in the same way in ultra: The particle effect in Leadwerks had more features and was easier to understand. At least, I knew what I was doing in Leadwerks.

In ParticleEmitter class Instantiate and Copy are private. If i do it via Entitiy's Instantiate i getting ParticleEmitter with default mat and params. Copy() seems to copy a mat, but not params. #include "UltraEngine.h" using namespace UltraEngine; int main(int argc, const char* argv[]) { //Get the displays auto displays = GetDisplays(); //Create a window auto window = CreateWindow("Ultra Engine", 0, 0, 1280, 720, displays[0], WINDOW_CLIENTCOORDS | WINDOW_CENTER | WINDOW_TITLEBAR); //Create a framebuffer auto framebuffer = CreateFramebuffer(window); //Create a world auto world = CreateWorld(); //Create a camera auto camera = CreateCamera(world); camera->SetPosition(0, 1, -2); camera->SetClearColor(0.125f); //Create a particle emitter with 50 particles auto emitter = CreateParticleEmitter(world, 10); emitter->SetVelocity(0, 0, 0); emitter->SetParticleTurbulence(10000); emitter->SetMaterial(LoadMaterial("/Materials/default.mat")); auto emitter2 = emitter->As<Entity>()->Instantiate(world); emitter2->SetPosition(1, 0, 0); //Main loop while (window->Closed() == false and window->KeyDown(KEY_ESCAPE) == false) { world->Update(); world->Render(framebuffer); } return 0; }

1. Create particle in the editor 2. Change size to anything from default. 3. Save and reload map - size reset to 0.5

Is therer a way to make particles move in emitter's local space? So when emitter moves, it's particles move with it, while still having their own speed?

Particle engines are commonly used for fire and smoke effects adding a lot of eye-candy for little effort. Every frame an emitter creates a number of billboard sprites along a vector. Normally this is not an issue when movement along this vector between frames is quite small. But what if you're talking about something that moves really fast between frames? Such as a rocket launcher or space-ship? Fellow Brit and indy developer Cliff Harris of Gratuitous Space Battles fame ran into the same problem. Here's a screenshot from his blog of a rocket. The rocket moves too far between frames to space out the particles in a pleasing manner. By adding a line of particles between each frame update a more pleasing effect is achieved. In Combat-Helo the hero-ship is typically loaded with several 70mm rockets that accelerate to 700 meters per second in approx 1.5 seconds. Even maintaining a short smoke trail of 10 meters can't be maintained as the rocket distance between two frames might be 50 meters or more. A linked list of billboards (TMesh CreatePlane()) is being trialled. UsingMacklebees billboard shader tweak and changing... ... gl_Vertex.x,gl_Vertex.y to ... gl_Vertex.x,gl_Vertex.z ...to work for Planes a 2D billboard function was implemented which handled colour and timing properties with a deviation (waver) offsets. This creates a ribbon of 50-150 quads (TPlanes) aligned to the camera using the billboard shader. Scale of each quad is roughly double the space between them to ensure some overlap and consistency. The smoke texture has baked lighting with a normal map however a normal map is redundant since the quad is camera aligned and rendered in the transparency layer. The spacing produces a good fill between two positions each frame. In the example image below the length of the trail is 75 meters, each particle doesn't require much updating since this was written for a specific purpose. As the shader takes care of orientation only timer tests, waver and alpha-colour needs updating although some extra instruction for management could be implemented (see footnote). Don't attempt to use ScaleMesh() as that slows the whole pipeline down. If you need to change the size of a particle you'll either have to do it in the shader or delete the particle and replace it with a larger one. Same again showing the AABB of each TMesh/Plane. That's about as fast I can can come up with using LE commands. The next stage is to replace the TPlane billboards with a single entity built using a TMesh and adding triangles as needed. Other optimisations might include changing the number of particles depending on the 2D length between the head and tail. We need more 'filler' if seen from the side than head on. Worst case would be a full salvo from 4 pods (each pod carries 9 rockets), in this event the particle manager could limit them. With the Leadwerks emitter function, once created you can't change the number of particles so having this level of control is handy for all manner of effects that need adjustment over time. This is of course slower than the LE particle system.