Looking for the best particle system. Where is it?
Blitz3D Forums/Blitz3D Programming/Looking for the best particle system. Where is it?
| ||
| Dear All, I seem to recall that either Halo or Swift sold a particle system. But I cannot find it anywhere! I need the following: - Recycling of existing particles (instead of the slow destroying and creating) - Lifetime / Cycle management (event based / types) - Custom tris instead of 3D sprites - Rock solid / Efficient / Scalable Where is it. I am prepared to shelf out some money for it. Kind regards Reda Borchardt |
| ||
| im working on a particle system right now with all those features but im afraid i have alot more to do to it before its ready for any sort of release. |
| ||
| well personaly to me particle systems are some of the fun parts to create. and its quite an easy concept even if there lots of cool stuff u can make to optimize the basics can be made in a night. |
| ||
| My old particle system is not currently available. My new particle system is on hold until Mark implements zbuffering for surfaces which use vertex alpha. Without that you are either limited to multiply/add blend, or you have to use animated textures with animated alpha in order to make the particles fade in/out. Single surface particle systems are only about 2x as fast as systems that use multiple entities, at least on mid-range 3d cards. And they limit the effects you can create a lot. For example, a lot of the particle effects you see in movies use solid objects rather than little flat 2D shapes. Like the dragon fire in Shrek was made with brightly colored spheres with a 2d glow superimposed over them. Doing the same kind of thing with single surface particles would require a TON of particles, whereas in shrek a long burst of dragon flame only used maybe 100 spheres max and it looked a ton better. I think maybe I will experiment in my tank game with rendering smoke as a set of 3d spheres instead of the current 2D shapes I have right now which don't look that cartoony. The nice thing about a multiple-entity particle system is that each particle can have lots of polygons and thus do a lot more. Like you can make a particle a sphere, or a torus, or a cylynder or cone. And that can save you tons of particles. |
| ||
| Shawn, the particle system I use in my stuff uses alphaed png sprites which I then fade in/out uing the entityalpha command and it works fine, no zbuffer issues at all. |
| ||
| Shawn is refering to single surface particle systems, not using entity alpha but vertex alpha. Which has zbuffer issues. |
| ||
| Yeah, what he said. :-) |
| ||
| Surely the z-order issue is the same whether you use vertexalpha or "hardwired" animated alpha? |
| ||
| i get the feeling its time to have a alook at shrek again when i get home :D |
| ||
| Look at the "making of" extras. They show part of how the particle effects were done for the draogn chase scene in the castle. |
| ||
| Ah yeh. i get the feeling i seen that part :) gotta pay alil extra attention to it this time :) |
| ||
| "Surely the z-order issue is the same whether you use vertexalpha or "hardwired" animated alpha?" Nope! Entites which have alpha channels, or which use entity alpha are rendered in a second pass after the solide parts of a scene are rendered. During this pass, Z writes are disabled, but Z checking is enabled. However, when Mark implemented vertex alpha, for some reason he neglected to have the entities that use the vertex alpha EntityFX flag check the zbuffer as they are being written. So as it currently stands, vertex alpha is all but useless. Useful for a few limited effects, but not for widespread use. Space_Guy: Another movie with good particle effects is "The Road to El Dorado". They show in the extras how they used a realtively few simple 2D particles with animated textures to create highly realistic effects like a fountain with water that splashes and spreads out along the ground. It's also a really good movie too. :-) |
| ||
| Oh - I never knew vertex alphaed objects don't check the z-buffer... I guess that due to some quirks of the ways I am doing things, this problem has miraculously failed to crop up for me. Er, hooray! I just checked my game, and it certainly seems that they ARE checking against the z-buffer in my case (I only ever use the z-buffer in a special compatibility mode so I had to check to be sure - normally the game is just one big manually sorted surface). One thing is that all my vertex alphad stuff is textured with alpha masked textures... maybe that makes a difference? |
| ||
| I have a single surface particle system working using vertex alpha and alpha masked textures and get no z-buffer problems at all. |
| ||
| http://www.geocities.com/gsclano/blitz3D.html or the Weibo one is also good...and FREE :-) But I'd wait a next b3d update before to start a so long project Reda :) I'm getting TONS of bug (not in the source code of course) from testers, they complain (win2000 and winXP) users of a lot of things, I will be more precise soon. They are about Changing resolution with Endgraphics - Graphics3D command, win98 is very slow in doing this, but it does thousand of times with no problems. I tried a simple program with no resources, and is able to switch resolution 100 times (on win2000) without problem. This is the (working on all the OS) example I used: Global gwidth=800,gheight=600 Global counter=0 Graphics3D gwidth,gheight,16 cu=CreateCube() c=CreateCamera() While counter<100 counter=counter+1 cleanupandgo() Wend Function cleanupandgo() Text 0,0,"Hi, test #"+counter Flip EndGraphics If GfxMode3DExists(gwidth,gheight,16) Graphics3D gwidth,gheight,16 SetBuffer BackBuffer() Else RuntimeError "Unable to init video mode: "+gwidth+"x"+gheight+"x"+bitdepth End EndIf End Function So the problem seems about EndGraphics make loose the Global Variables (wow quite a not small bug if so) after being called by the same EXE 6 - 7 times...very bad if you expect to produce a huge complete 3D game with it. I will try to write the same source code with more resources and variables so to be able to reproduce the bug. I think this is the first time anybody finds that. Am I right ? |
| ||
| "One thing is that all my vertex alphad stuff is textured with alpha masked textures... maybe that makes a difference?" It may. I will have to do a test to see. I'm pretty sure aobut this vertex alpha thing, cause someone tried to write a terrain engine using an alpha blending technique I suggested, and they ran into a problem and I tested their code and it seemed like vertex alpha was to blame for the improper sorting. |
| ||
| Thanks for the tip using spheres. im far from shrek gfx but it did make some effects alot lively :) ill be working more on this. |
| ||
| For everyone debating the 'Vertex Alpha' question, this text is from Mark's version history: Vertex Alpha has been added, via an extra, optional parameter on the end of VertexColor. This is currently rather limited: polys are NOT sorted for you, and you'll need to use the new entityfx value of 32 which 'forces' alpha blending even if an entity is apparantly opaque. The alternative would have been to add some 'per vertex' overhead to calculate/update whether a surface has at least one vertex with alpha<1 - but I wasn't happy about doing this. MK |
| ||
| "Im far from shrek gfx but it did make some effects alot lively :) ill be working more on this." Here's another trick. Make a texture map which is a gradient that is bright in the center, and completely black at the edges. Next, add a second surface to your particle sphere, and add a second sphere to that surface, which is 1.25x as large as your first sphere. Set this second surface to add blend mode. Load your texture as a spherical environment map, and apply it to the second sphere. Voila, you now have a solid glowing sphere particle. This would be perfect for creating a fire effect very similar to the one in Shrek. You can also probably get away with making the outer sphere pretty low polygon, though if you go too low it might introduce distortions in the blur, but if you have a bunch of them together you wouldn't notice this. "polys are NOT sorted for you" That just means within the object itself. Not with regards to each object being sorted with other objects in the rest of the scene, and it does not refer to zbuffering. |
| ||
| Yeah, we know that the polys aren't sorted back to front - that has always been the case with transparent stuff in blitz though. What sswift is saying is that vertexalpha polys don't seem to check against the z-buffer either; a rather more serious problem... Is it a problem with entityfx 32? Is it a problem with sswift forgetting to set entityfx 32? I can't say. All I know is it's working for me... |
| ||
| No, I didn't forget to set Entityfx 32. In fact, you don't even see any alpha in the vertices unless you set Entityfx 32! |
| ||
| In that case, I guess it's a problem with entityFX 32, which is overridden by the use of "regular" alpha? |
| ||
| Interessting ideas sswift. too bad i have to sit all day now at work before i can try em out hehe |
| ||
| " In that case, I guess it's a problem with entityFX 32, which is overridden by the use of "regular" alpha?" Well if you are correct, and your stuff is working right, then yeah, that is what I was thinking might be happening. Forgive me for not taking your word on it, but I don't take anyone's word for anything. :-) When I was working on System Shock 2, I noticed the transparency in the engine was wrong... Whenever a computer with a transparent monitor would be visible through a window, the transparent parts would be drawn in front of the window. I brought this to the attention of him, but he could not see the problem! Somehow he was incapable of seeing how obviously wrong the transparency order was. One look at it and you could see that the computer monitor didn't have a milky tone to it like everything else behind the window. He insisted on doing a test, and even when he did THAT he couldn't see it. It took like 20 minutes to convince him something was in fact awry. (What was happening was the game was drawing transparency front to back.) The moral is, programmers can believe something looks right when it actually does not. :-) Now where's that terrain rendering test. That would let me test this theory of yours. That would be pretty cool if indeed the case! |
| ||
| Ah, crap! |
| ||
| Edit |
| ||
| Don't tihnk what is the problem? If you'll notice I posted something in the General forum. I fixed your code. It works fine now. |
| ||
| The bonus of using the built in 3d sprites is the auto-facing of the sprite towards the camera. I have an emitter-based particle engine that uses pools of pre-created sprites. You attach the emitter to an entity and set basic parameters like lifespan, smoke size, particles per second, and fade rate. VERY realistic looking and a breeze to use. Are you interested in this? I would NOT recommend using a catch-all particle engine but many different ones that are specific in their purpose. For instance, you should have a separate particle engine for smoke, fire, rain, snow, etc. Much more efficient that way. |
| ||
| I'd be interested in something like that, or at the very least some AW1946 news. ;D |
| ||
| Go to my site to download my particle system, which seems to work the same as Chroma's! |
   |