Particle sorting error - please help

My project was going really well until about an hour ago. I am having a problem with particle sorting. I found the docs about the d3d_entsort command and tried that but no change. I searched and found a thread about this that dealt with the origin, but my particles are all being emitted from invisible models. The models are positioned to set where the particle effect begins and the origin of all models is at the center in MED. After getting my smoke and fire particles looking good, this surprised me.

This first image shows the error. Notice on the bottom image the location of the fire particles on the shadowed wall in relation to the smoke particles to the left of these fire particles. In the first image below, you can clearly see that from the viewpoint of the camera, the fire particles should be seen in front of the smoke particles, but it's reversed with the fire particles appearing to be "projected" onto the side of the building. What is the fix for this? I thought I almost had this project whipped, but this has brought things to a halt. Remember, I have tried d3d_entsort and have turned flare on and off without any change. I have a very good video card - ATI Radeon Pro 128 9800 - so that shouldn't be it, or I'll about crap

Please help if you can. I will wait here patiently and try whatever else I can think of.

Regards, Ron

d3d_entsort sorts entities and not particles. Transparent particles have no determined order. If any, they are displayed in the order of their creation, so that later created particles cover earlier created particles.

A sorting of particles, like with entities, was ruled out for performance reasons. There are plans to sort particles according to their creator entities, however as no user requested this so far, it's not scheduled yet for a certain date. The best solution at the moment, if you need a certain order of transparent particles, is using sprites instead.

Ahhhh... That's like the curse of death, JCL. I know you're just telling me what the engine can or can't do, and thanks for doing it right away, but this will just kill my project if I can't work around this error. The images I posted were a "rough" demo and already it looked pretty realistic. With particle motion, this building looked like it was on fire.

Particles are perfect for this project. This is a shame. Framerate wasn't even an issue, I was having no problems there. I took the 128x128 maps for the original particles and reduced them to 32x32 with about a 100% increase in the framerate I was getting. Heck, it ran decent on a PIII laptop!

Funny thing is that I've never run into this before and I have another project where you are inside a building, it is full of smoke, and the fire appears through the smoke as you approach it - BUT - I coded my own particle transparency function where the fire fades in and out based on my distance to it.

I was going along on the assumption that the engine would simply render the particles that were emitted closer to the camera before the particles emitted from a farther point.

If this was your project, and you had to use particles, is there any work-around you would try???

I'm grasping here.

Regards, Ron

If this was my project, I would use animated, facing sprites for the larger fire and smoke parts, and real particles just for small items like sparks. As long as the number of sprites in the sight range is well below 100, as seems to be the case in your images, it shouldn't affect the frame rate even on a PIII.

Jcl,

I created a sprite and just put it right in front of the player's head to make this test. This is what it looks like. Even with a sprite, I have the same error. Are you saying I can't use particles at all?? This makes no sense to me. That smoke seen in front of the sprite is particle smoke way back on the other end of the building. I have to use some.

Thanks, Ron

Jcl,

I did another search and found 3-4 other users who had mentioned the same, exact problem over the past year. I have also found that particles draw in front of *anything* that is using transparency - models, sprites... - not just other particles.

I understand that the aim is to make the particle effects as fast as possible and they certainly are - in my case, though - I would take a speed hit to resolve the problem.

Let me be the first to officially request an option to have sorted particles that play nice with other entities using alpha transparency.

Can I ask, how slow is it going to be if I try to make my own particle effects using regular sprites? 50% as fast, 25%, don't waste my time?

Could a dll take advantage of the zbuffer and use a custom particle engine as fast as the native A6 particles, but with the sorting?

I tried the sprites and models with transparency some time ago, I'm not ignoring your suggestions at all. I will look into them again. What is disappointing is earlier today I thought - after several months of free hours here and there - I was about 95% home in developing a working prototype and was preparing to make finished levels. Honest to God, I had not noticed this issue before then, so you can imagine my surprise.

Thanks, Ron

You can make your smoke out of sprites too: voila! no more sorting errors.

Particles do not appear in front of models -- just sprites. I haven't tested other kinds of entities.

I guess you probably know this but I found that it is pretty easy to replace particle effects with sprite effects: you call "ent_create" for each sprite you want to make and use a slightly modified version of the existing particle function. One big difference is the need to move the objects yourself: you don't have vel_x,vel_y,vel_z -- so I use internal skill variables to store the velocity and use ent_move or just say:
Code:

---

vec_set(temp,my.Skill51);

vec_scale(temp,time);

vec_add(my.pos,temp);

---

The level looks great!

feature creature,

I'm working on sprite-based particles today, btw. Sounds like we had a similar idea. Have you noticed your fps dropping much using them this way?

Thanks for the tips,
Ron

I did not notice it but I did not test it in great detail either.
I did however find that I could esaily reach the max entity count.

Right now, I have a custom particle action & function that allows up to 300 entities (just an arbitrary number right now) created within it. It, surprisingly, wasn't too bad to implement, but I need to improve the movements of the particles and test it out under the same scenario in my level that caused the original problem for me. I'm using very small bitmaps, BTW - 32x32. This seems to make a big difference.

I plan on using my own global var named max_sprite_particles. When I create one, the total is decremented, but in the custom sprite/particle function when I remove one, I increment. I am finding that it does not take as many of them as I first thought to make good looking effects.

If I get this thing running smooth, I'll probably post the custom particle code for other users.

Thanks for your input,
Ron

Wow, hard to believe that what felt like a negative yesterday may turn into a positive. I just discovered a neat advantage to creating particles this way. I had some fire particles already working, so I added an action and function for smoke.

Get this, when the smoke particles (since bright is not on) travel into the shaded area of the building, they are shadowed also, so my grey smoke turns dark grey, but just the ones that should You couldn't get this with particles, AFAIK.

I have a nice plume of fire and smoke operating right now with less than 50 sprite entities total.

Regards, Ron

That's great!

Any chance of showing us a screenshot and maybe how you coded the effect.
Your screens are very impressive, if your system solves this problem it seems to me to be a better method than using particles.
Just one thing, the 33*33 sprite size sounds a little big.

I'm away from my house today and my PC but will post an image tomorrow. The custom particles are indistinguishable from the native particles, as you will probably see. I seem to have more control.

The orignal .tga's that I was using for the native particle effects were 128x128. I have reduced them considerably to 32x32, but kept them at 32 bit.

I'll post tomorrow.

Regards, Ron

Here's a new image. These particles are the sprite-type that I built. This is a different angle, but you cannot tell any difference between these and the built-in particles. Notice, though, how the sorting problem is gone. When I get my code into a more finished state, I will post it. Right now, all the particle movement routines are hard-coded in the function and I want to make it adjustable via WED properties and flags. These effects really look cool when you see them in motion.
Thanks, Ron

Hey Ron, looks like you really cracked this problem. One more thing - how did you get those great looking windows. Gives the image so much realism.
Regards, PeterC

PeterC,

Thanks. I use textures from TextureMonk
Regards, Ron