Particle wings are coming along.. My art skills or not so great. I can not speak to fps on any other system. I've worked with solid beam , moving beam and moving none-beam particles. I used a 2 planes (one each wing) and vertex animated them with a noise like movement. I then used vertex points on the planes as particle locations. I've also used my spline code.

Pictures and videos within the up-coming week.

Take Care --

Here is an un-optimized version. 1000+ particles!!! I left the vertex animated planes 50% alpha. Also the noise on the planes doesn't do the over lapping on the z axis like the video.. I'll add that later. So let me know if your still interested in the particle solution, or I can stop.



video https://youtu.be/HI_4JiiEL4M -- available up top x1080

I think it looks pretty cool. How much fps would this cost on a decent system, 1-3 fps? Or perhaps more cause of the functions to 'connect/position' the particles?

The biggest problem would be I think would be that in order to make it really cool, you would need 6-12 wings instead fo ~4, so that probably will cost some fps. Except if it could be still optimized alot ofcourse.

This is really variable on each system, background software and of course every other thing in the level. First you have to pick a target fps , a max fps and a min fps. I use fps_max =60; and try to keep everything at 60 fps. To do so your whole scene must render in 16 milliseconds or less. Checking your render time for levels, ents, and script will give you a total. Subtract that from 16 milliseconds and the remainder is your head room for more actions. I personal can render 1000 particles in 1 millisecond, leaving 15 milliseconds for other actions.


It can be a lot more optimized for sure. First with changing the curve algorithm. I currently use a simple 3 point curve causing the need for two separate for_loops for each wing line. Using a better curve solution can reduce this. Next there is the step size. Small steps make smoother curves but finding a good balance is smarter.Because with smaller steps comes more particles and draws. Also I wouldn't render the wing surface at all or as transparent. I'd ignore it in the render stage. I just want it's vertex positions. However, loading a vector map of the them and there animation changes into memory could save the cost of loading the ent , animating it and doing the look-ups for the vertex positions.

New videos <-- UP top x1080 Of course my art skills are lacking..
https://youtu.be/JJo7kta0Soo
https://youtu.be/L_y-XLLh3d8

Over all I never spent no more than 1 millisecond and rendered up to 1500 particles.

I would call this a bad solution. It's a lot of work that can be done better in a shader or texture fx.

A high level of particles would be needed for a great looking fx and would eat as much as 2 milliseconds for set. x4 ent thats 8 millisecond or 30 fps.

ok I have already this guessed , but thanks for trying.

Unfortunately, I came not yet to give it a try yourself , not on THEREFORE I admit .

Can you send me the 2 examples on PN ore upload .
i want to expand your work .

A final truth.

https://www.youtube.com/watch?v=lgnEJ7K5gnw

Download

Salud!

, takes the cake. Though I could see a combination work. When you use txesmi's solution/shader as the base and add some additional sparkles sparkles or falling feathers or whatever as details.

txesmi for the win!!!

It's a shader world now, no point in living in denial.

@txesmi --> the default.c debug panel shows a ENTITY render time of 0.1 milliseconds is this how we measure the shaders cost? And how expensive is it to make a whole set of wings? Is there a better method for finding the render cost of shaders?

@BlackJack -->

I'm not sure what you would like. The code base is an un-optimized mess, that is only partly realized. Besides clean up, it needs rewriting and redesign ( most of all on the curves methods and implementations). I have rushed to show-and-tell but it's no where no ideal for release. I'd be happy to write a document on the process I used and the greater idea.
In the end txesmi's solution is the correct way and shaders are almost always the better solution when GPU particle systems are not part of an engine (or direct x implementation as dx9), like is the case with 3dgs. The entity vertex animation and the particles are run on the CPU and GPU systems shader cores and now particles have long-ago eclipses CPU systems. I would avoid CPU operations and particles as much as possible.

It is not easy to meassure shaders real cost because it encreases two values on the stats panel: ent and ref