[sldev] Fwd: Questions on the particle system
Dale Glass
dale at daleglass.net
Sun Dec 2 16:18:30 PST 2007
On Monday 03 December 2007 00:33:46 Dirk Moerenhout wrote:
> > I just tried Windlight. I seems to share the same annoying behavior.
> >
> > Meaning, that when running into the particle limit, things start to
> > sputter. If you see a fountain, it doesn't shoot less water, it shoots
> > the full amount for a frame, then nothing for several, and so on.
>
> There's actually no code that is aimed at doing this so I find it
> rather odd. Feel free to send me landmarks for locations that exhibit
> this. All limits are based on chances so it should always be gradual,
> sources are never turned off and on.
windlight source, indra/newview/llviewerpartsim.cpp, line 852.
Since it picks an arbitrary starting point, sometimes a particle system
happens to be at the start of the list, and sometimes at the end, so
sometimes it gets all its particles rendered, and sometimes doesn't
To test this, take the script below. Make lots of copies so that things go
well over the limit. This is best seen with small particles. Look at just
one source, hiding all others from view. You'll notice how emission is
very irregular.
> > It also has the same issue with limiting particles. I only see an
> > effect that has about 2500 of them. I have a 4096 limit set, and
> > seeing a lot less particles than should be in the full effect.
>
> Personally I believe any effect that has 2500 particles is written by
> somebody who isn't interested in writing interesting particle sources.
> Very few effects warrant 2500 live particles. I'd advise you to set
> your particle limit to 8192 though, there's little reason to keep it
> at 4096.
The particular amount isn't important. The thing here is that particles are
supposed to be seen on screen.
>
> > > Argent already replied on the particle count stuff. If it needs to
> > > be tracked you need to count it. As such it's important to limit at
> > > spawn and not afterwards.
> >
> > Why?
>
> See my other reply. If you disagree I'd suggest you remove the current
> cap and create one for on screen particles. Then fire of a profiler
> and see what happens.
Well of course more data to track takes more CPU time. But the rendering
hit is very significant. In the latest windlight I just tested:
4x4 particles: 26 fps
0.1x0.1 particles: 47 fps
no particles: 47 fps
Here's a script:
integer g_mode = 0;
particles(vector size) {
llParticleSystem( [ PSYS_PART_START_ALPHA, 1.0,
PSYS_PART_END_ALPHA, 0.0,
PSYS_PART_START_SCALE, size,
PSYS_SRC_BURST_PART_COUNT,3,
PSYS_SRC_BURST_RATE,0.1, PSYS_PART_MAX_AGE,9.0,
PSYS_SRC_PATTERN,PSYS_SRC_PATTERN_ANGLE_CONE,
PSYS_PART_FLAGS,PSYS_PART_INTERP_COLOR_MASK ] );
}
default
{
touch_start(integer count) {
if ( ++g_mode > 2 ) g_mode = 0;
llOwnerSay("Mode: " + (string)g_mode);
if ( g_mode == 0 ) llParticleSystem([]);
if ( g_mode == 1 ) particles(<4.0, 4.0, 0.0>);
if ( g_mode == 2 ) particles(<0.1, 0.1, 0.1>);
}
}
I see a very large difference depending on particle system. Moving the
camera away from the source when it's making the big ones also makes a
very big difference.
When it's making the small ones I can't notice anything significant.
Also, with lots of emitters behind me, 0 vs 8192 particle limit makes no
noticeable difference in framerate.
> > If the particles aren't visible then IMO they effectively don't exist
> > and shouldn't be counted towards the limit.
>
> Unfortunately your CPU will disagree and there has already been done
> quite a bit of work trying to keep the CPU load of off screen
> particles low. The VWR-983 fixes for example would've been a lot more
> straight forward if it wasn't for concerns of CPU usage.
My CPU seems to disagree far less than my video card does.
Specs:
Athlon 64 X2 5200+, GeForce 7900 GS
What do you have?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071203/d8d4e410/attachment.pgp
More information about the SLDev
mailing list