Hamaar Tyne
Registered User
Join date: 17 Jun 2005
Posts: 23
|
09-07-2005 10:06
I was just wondering how "good" the design of having a particle system that will change the texture it is using every few seconds would be. I'll probably end up using two prims each putting out their own particle types for the effect, but I was wondering if the same thing could be achieved with one prim that just changed its particle system frequently.
I guess let me explain it this way. Which method is better:
1. Two prims each with its particles turned on sending out differnt textured particles.
2. One prim with a timer going that changes the particle system frequently on the single prim.
What happens when you have 3 or 4 different colors and types of particles you want in your effect? Is the techinque to use a different prim for each color and type you want, or to script in a frequently changing particle system on a single prim?
|
Aleksander Mondrian
Registered User
Join date: 22 Apr 2005
Posts: 4
|
09-07-2005 10:23
I'm no expert on particle systems, but from what I've gathered the pros and cons would be as follows.
Both ways would work (depending on the exact effect you want) but using multiple prims would give you more flexibility.
Also, since particles are rendered entirely client-side, both methods would cause pretty much the same amount of client-side load/lag, but using a single prim would cause server/sim side lag as well, and would entail more network traffic since each time the particle system changed the details would have to be sent to all viewing agents.
I guess it would depend on the frequency of the changes as to whether the extra prims or the changes would cause more lag but in most cases I would guess that multiple prims would be the way to go, especially if they're simple low poly prims like tetrahedra, set phantom and transparent.
Aleks
|
Keknehv Psaltery
Hacker
Join date: 11 Apr 2005
Posts: 1,185
|
09-07-2005 15:30
I would recommend multiple prims. Particle updates for the client are somewhat buggy, and prone to lag, especially with timers, but with an emitter in each prim, they are much more dependable.
|
a lost user
Join date: ?
Posts: ?
|
09-07-2005 15:54
Also remember to keep your texture sizes as low as possible. If you have 50 particles per second, and each particle is a 512x512 texture, it should be pretty obvious that the amount of work that the client's hardware needs to perform is heaps more than if the particle texture was only 64x64 or whatever. Ask yourself, does the texture need to be that big? Do I need that many particles per second? Can the same effect or a similar effect be achieved using scaling of the particles.
For example, for an explosion you could use a high amount of firey texture particles that explode out from the source of the explosion. On the other hand you could just use a single particle that uses a decent explosion texture, using the DROP pattern mask and then scaling the size of the particle so it starts small and grows to the total size of the explosion. This second method is far better for almost all situations. You could then add small sparks to the explosion using non-textured particles but only a small number of them to explode out at the same time and achieve spectacular results that don't cause such a dramatic frame-rate hit to the client.
|
Hamaar Tyne
Registered User
Join date: 17 Jun 2005
Posts: 23
|
09-08-2005 10:41
Thanks all for the info and insights. Thank you for reminding me about the image size also. It is a mistake I wouldn't have ever made when putting a picture up on the web, but one I made in sl. Sillyness. You guys are right, 2 prims seems to be the best move.
Again, thank you all for replying.
Hamaar
|
Neil Protagonist
FX Monkey
Join date: 11 Jul 2003
Posts: 346
|
09-13-2005 13:07
In addition to what was said above a very common method for doing this in the industry is to use a flipbook texture. Loading multiple textures causes additional demands on the system in the form of draw() calls, with one texture you just have to define a UV cell size and then this can be animated by an index number defining which cell should be used (it assumes that all cells are of a uniform UV scale) normally this is attached to a curve (linear or bezier) over life, but since we do not have that ability in sl a start and end index would be sufficient. Also with regard to particle sprite size, generally sprites should be from 16x16 to 128x128 depending on usage. Anything over this is generally useless. Not to mention the uses of animated maps in particles are so numerous that one could not mention them all but I use them regularly at work for the creation of everything from explosions to dissapating smoke. I would love to see this implimented in SL.
_____________________
" Control the things you can control, maggot. Let everything else take a flying f**k at you, and if you must go down, go down with your guns blazing." -Cort Need fire? Visit my FX Store in Bisque(232, 4 Sick-N-WrongLike Anime? Visit Nakama!
|