[sldev] Questions on the particle system

Dirk Moerenhout blakar at gmail.com
Sun Dec 2 13:46:03 PST 2007


Dale,

what version of the source tree did you start against? If it isn't the
latest windlight branch I suggest you go check out at least VWR-418
and VWR-983 first.

My particle patches for VWR-418 and VWR-983 are in latest windlight
though you need the info from VWR-3403 too because there was an issue
during the merge (latest windlight binary is corrected but I haven't
seen source yet). You can just lift the related files from the
windlight branch and put it in another one (mind VWR-3403). There's
one additional particle patch in there (VWR-2164) but apart from that
files are pretty much identical to 1.18.3.2 (I used a diff against my
personal 1.18.3.2 branch to find the issue of VWR-3403).

LL adapted my patches to their liking but functionally they did not
change them as such I can help you find improvements on the latest
version.

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. My patches have done that by implementing a
dynamic throttling mechanism. The primary basis is particle
viewability. As such a source spawning larger particles may get
priority over one that is spawning smaller invisible particles near
you. It may not be agressive enough to everyones liking but it offer a
huge improvement over the old code.

On the anti-griefing part the new code has some stuff too as the high
throttling levels will cut in the amount of live particles a single
source can want simultaneously. A source may for example try to get
thousands of live particles by spawning a few at a time but giving
them long lives. The new code will punish such sources by limiting the
amount of particles they will get.

Dirk aka Blakar Ogre

On Dec 2, 2007 9:59 PM, Dale Glass <dale at daleglass.net> wrote:
> I started messing with particles a bit, after getting rather frustrated
> when trying to take screenshots with particle effects.
>
> I modified LLViewerPartSim::updateSimulation() to sort particle sources by
> distance. This for some reason didn't do what I expected (rendering nearby
> sources and not far away ones), but at least it got rid of the sputtering.
>
> The exact problem is: Sorting works alright. If I sort then only render the
> first 5, I see only the nearest 5 work. But the particle limit seems to be
> equally spread among all active effects.
>
> I also added two new settings: RenderMaxPartSourcesCount and
> RenderMaxPartDistance. The first one is mostly for testing, the second is
> the maximum distance a source can be from the camera for the effect to be
> made. This is intended in part as an anti-griefing measure: with this it's
> possible to silence those huge particle effects while keeping the nearby
> ones.
>
> Now questions.
>
> What is LLViewerPartGroup and what is done at the end of
> LLViewerPartSim::updateSimulation()?
>
> Why does the particle limit work by keeping a counter that gets incremented
> in constructors and decremented in destructors instead of just setting it
> to 0 on each start of frame and counting what's actually getting rendered?
>
> Why do invisible effects still count towards the particle limit?
>
>
> Here's what I'm intending to achieve, unless there's some reason why this
> is undesirable:
>
> * Particle sources are sorted by distance (done)
> * No sputtering, particle effects when running into the limit reduce the
> count smoothly. (done)
> * Nearest sources have priority. If you zoom on something, it's pretty much
> guaranteed to take most or all of the particle quota.
> * If particles aren't being emitted, then it doesn't count towards the
> limit
> * When the particle limit approaches, effects are throttled gradually (so
> particles don't instantly vanish at some cutoff point unless you use the
> distance limit)
>
>
> How does this sound?
>
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html
>
>


More information about the SLDev mailing list