* Adapt particle at runtime
* Refactor EffectHosts
* fix issues
* cleanup
* Remove live transitive particles
* paticle hosts now do local correctly
* Fix effecthostparticle local mode
* again
* Set particle host orientation
* I don't like mixed local and global vectors
* agaiiin
* Fix validity check
* parent foo
* Fix bugs, hopefully finally
* refactor
* Flip new table option for intuitiveness
* Fix support for GCC9 due to issues with LWG3052
* Address feedback
* Two 1-line fixes for new particle lights
This PR provides 2 semi-fixes for the particle lights with 2 simple conditionals.
------------
First, it fixes#7124. In sum, it fixes the issue that new particle lights not affected by light quality slider. This fix is done by adding a conditional check so that particle lights only render when weapon lights do, at the highest lighting setting. This ensures that lower end machines can properly turn off particle lights to help with performance.
------------
Second, this PR adds an extra conditional to ensure that the system does not attempt to render particle lights if the radii is <= 0.
Light emitters logically do not cast light if the light emit radius is <= 0. In 2015, there are assertations in each of the `light_add` functions that trigger if the radii are <= 0.
With the new particle lights and addition of curves for particle lights, this can make result in light radii <= 0. This approach is useful to allow things like hit effects to only give off light if the hit effect is large enough (IE if it hits a large ship scale the radii to be larger, and if it is too far away or a small ship scale the radii to 0). So, in those situations of <= 0 light radii, the modder would expect that the light point is just not shown and simply not attempted to be rendered. Unfortunately, this is not quite the case, as any light radii <= for particle lights will trigger the assertation within the `light_add` functions.
The fix for this is simply to have early conditional checks for light radii. There is already precent for this in the code in 3 locations--1) within the weapon light code in `object.cpp` line `1365`; 2) within the beam light code in `beam.cpp` at line `2009`; and 3) within the fireball light code in `object.cpp` line `1457`. Note these sections also early out if the light intensity is <= 0 as an optimization step, which also makes sense.
This PR simply follows that precedence for particle lights by adding an early out if the light radii are 0. This allows modders to properly use a range of radii and helps ensure internal consistency with the code mentioned above that already does this early out for weapon and beam lights.
----------
Given the benefits listed above, having this PR in before stable would be fantastic (or a relatively quick point release after stable).
Tested and fixes the issue as expected. Happy to answer any questions and/or discuss!
* comment signpost
* Add parent / host input curves
* reorder some includes to allow particles access to ship.h
* Allow modular_curves to deal with functions returning optionals
* Add convenience function to return an optional from an objp and an instance type
* Add a bunch of particle curve inputs
* Fix internal linkage warning
* Add hitpoint and shield fraction (albeit limited to ships)
From Sept 15 onward in fast debug I hit this error when using weapon create
ASSERTION: "cur_frame < part->nframes" at particle.cpp:371
Assert: "cur_frame < part->nframes"
File: particle.cpp
Line: 371
Thanks to lafiel, `that assert should have an `|| (part->nframes == 0 && cur_frame == 0) appended beaause while we need to stay inbounds for animations, frame 0 for both is valid for static images`
* Make particles aware of the effect that spawned them
* Allow modular curves to call global functions from submember inputs
* Add more in and outputs for particle lifetime curves
* Allow post-curve velocity as a curve input
* fix warning and incorrect assig
* Disable CheckTriviallyCopyableMove
* Clang Tidy
* initial version of default_settings.tbl
* Add a way to change player detail level defaults and implement a couple more options to detail_settings.tbl
* support the rest of 2d.cpp options
* Allow enforcing options to a specific value
* modernize detail defaults, levels, and values
* Fix parsing issue and remove lambda capture by reference
* fix print
* clang
* More efficient +Enforce parsing
* cleanup
* typo
* don't negate this
* error_display
* clarify language between presets, levels, and values
* add default case
* small fix
* use a map to minimize string lookups
I took a close look at the code involved in parsing particle tables. There is no smoking gun, but there are several ways to polish the code which I have implemented here. The most likely culprits for the slowdown, IMO, are the repeated conversions between SCP_string and C-string, especially in `ParticleManager::getEffectByName()`; followed by the omission of `std::move` in several places.
This adds a new field to particle effects so that particle rotation can be configured on a per-type basis, not just on a blanket basis. Implements #5941.
#5328 added a very useful culling for particles created by specific particle effects (ie weapons, now beams), though in an effort to simplify the culling process, that PR removed the necessary culling of default smoke on ships. This PR restores the culling of default smoke while also keeping the new culling of particle specific effects. Tested and works as expected, including fixing the slowdowns caused by the aforementioned removal of smoke effect culls.
The current particle system uses dynamic allocation of particle
instances for keeping track of particle instances. This adds unnecessary
overhead in case the code does not need a handle to this particle which
is the case in pretty much all instances.
The new non-persistent particles are stored in a standard vector without
dynamic allocation which should make the processing steps using this
vector much faster and allow better scalability in case more particles
are used by a mission.
BMagnu