Apel is a library that brings particle animations to the table with flexible behaviour and a clean developer interface. It promises also lots of predefined shapes & paths to help the developer on their particle scene
This has a bunch of unrelated changes in it, but I think it will be easier to do it this way vs. lots of small PRs. Let me know if you prefer otherwise, I'm flexible in how we approach these.
Brief summaries of each commit, in order:
Mark client class final - no one should extend these.
Optimize drawing... - This applies quaternions to the line-based shapes and cleans up some excess allocations.
Draw from ParticleObject subclasses - This cleans up ParticleObject by having each subclass use the renderer directly. There's no value in having the abstract class supply the same particleEffect that the subclass can already access.
Document ParticleObject... - Provides guidance to devs on what to watch for when subclassing to make a new object.
Use diacritics for Bézier - Honestly, this is just to make IntelliJ stop warning me, but it is a guy's name, so we should type it correctly.
Log exception... - Found a lingering e.printStackTrace(), those are not ideal in production releases.
Make objects declared in Apel final - We don't want inadvertent bugs from someone deciding that Apel.scheduler should be recreated, etc.
Update Bézier curve documentation - Tidying up docs, finals, etc. I do think there might be a bug in length for quadratic/cubic/parametric -- will investigate and fix separately.
Clarify documentation... - Docs pass, no functional changes here.
Move trig table ... - ParticlePolygon is the only user in the ParticleObject hierarchy, so use it directly from polygon.
Not sure how many more "parts" we will have, that will depend on finishing a doc pass, testing various combinations of objects, animators, and renderers.
This has a bunch of unrelated changes in it, but I think it will be easier to do it this way vs. lots of small PRs. Let me know if you prefer otherwise, I'm flexible in how we approach these.
Brief summaries of each commit, in order:
final- no one should extend these.rendererdirectly. There's no value in having the abstract class supply the sameparticleEffectthat the subclass can already access.e.printStackTrace(), those are not ideal in production releases.Apelfinal - We don't want inadvertent bugs from someone deciding thatApel.schedulershould be recreated, etc.lengthfor quadratic/cubic/parametric -- will investigate and fix separately.Not sure how many more "parts" we will have, that will depend on finishing a doc pass, testing various combinations of objects, animators, and renderers.