Conversation
|
In order to add the NoiseVectorEffect, I also will have to add a procedural noise library to the engine. The best choice for a fully-fledged noise library in java would appear to be the JNoise library, however I believe that would be overkill for basic noise functions that are needed for this PR, so instead I am choosing to implement the java FastNoiseLite library into the engine. This is a very light weight single class noise library that should be more suited to include in the engine than something like JNoise. Let me know if anyone disagrees or prefers a different noise library, otherwise I will move forward with this plan to include FastNoiseLite.java in the engine's math package. I also will update this PR to include javadoc before merging. |
Add FastNoiseLite (MIT license) from https://github.com/Auburn/FastNoiseLite/tree/master
|
🖼️ Screenshot tests have failed. The purpose of these tests is to ensure that changes introduced in this PR don't break visual features. They are visual unit tests. 📄 Where to find the report:
✅ If you did mean to change things: ✨ If you are creating entirely new tests: Note; it is very important that the committed reference images are created on the build pipeline, locally created images are not reliable. Similarly tests will fail locally but you can look at the report to check they are "visually similar". See https://github.com/jMonkeyEngine/jmonkeyengine/blob/master/jme3-screenshot-tests/README.md for more information Contact @richardTingle (aka richtea) for guidance if required |
|
I re-ran the jobs and this time the screenshot tests passed. I guess something must have bugged out during the first run. |
|
Yeah, that's decidedly weird. I can't see why it decided to post that (especially not 2 hours ago). Hopefully just something bugging out as you say |
|
I just need to upload the final example for the noise effect and then I'll merge this PR. I will wait atleast another day since no one else reviewed. However, I've done some thorough self-review, also using AI analysis tools to critique my code and the approach. And I'm very confident that this is the best way to handle these types of effects, as opposed to hard coding things like fading and flickering into the shaders or java classes for lights, emitters, and custom shader effects. |
jme3-effects/src/main/java/com/jme3/vectoreffect/VectorEffectManagerState.java
Outdated
Show resolved
Hide resolved
jme3-effects/src/main/java/com/jme3/vectoreffect/VectorEffectManagerState.java
Outdated
Show resolved
Hide resolved
jme3-effects/src/main/java/com/jme3/vectoreffect/VectorGroup.java
Outdated
Show resolved
Hide resolved
jme3-effects/src/main/java/com/jme3/vectoreffect/NoiseVectorEffect.java
Outdated
Show resolved
Hide resolved
jme3-effects/src/main/java/com/jme3/vectoreffect/VectorEffect.java
Outdated
Show resolved
Hide resolved
jme3-effects/src/main/java/com/jme3/vectoreffect/VectorGroup.java
Outdated
Show resolved
Hide resolved
|
I believe I've addressed all of the requests brought up in the previous review. But I'll wait another few days just in case anyone still sees any issues or anything I missed. Then (once I'm sure there are no more changes) I will do a final update to this PR to fix all of the formatting and add javadoc, and then I'll also wait another few days after that before merging. |
| */ | ||
| public class VectorEffectManagerState extends BaseAppState { | ||
|
|
||
| private final ArrayList<VectorEffect> activeVectorEffects = new ArrayList(); |
There was a problem hiding this comment.
| private final ArrayList<VectorEffect> activeVectorEffects = new ArrayList(); | |
| private final ArrayList<VectorEffect> activeVectorEffects = new ArrayList<>(); |
There was a problem hiding this comment.
I'll be sure to fix this along with a few other remaining formatting issues in my final edit for formatting and javadoc.
| vectorEffectManagerState.registerVectorEffect(this); | ||
| } | ||
| } | ||
| } |
There was a problem hiding this comment.
convenienceRegister is never used, let's remove it,maybe, since it adds confusion.
The dev can just keep the VectorEffectManagerState around
There was a problem hiding this comment.
I do use this method in my own project, but I avoided it in the examples so that they can show the full way to fetch an appState for users who may be using the examples to learn from, and since I also want the examples to show that the effects rely on a manager state.
But this convenience method does reduce appstate-fetching boiler plate code in a project that registers lots of vector effects (and prevents having to keep a reference to the VectorEffectManagerState or repeatedly fetch it in classes that make multiple registries) so I'm opting to keep it.
There was a problem hiding this comment.
Ok then, lets call this registerTo and maybe make it append the VectorEffectManagerState if its not present in the stateManager
| for(Runnable r : onFinishedCallbacks) { | ||
| r.run(); | ||
| } | ||
| onFinishedCallbacks.clear(); |
There was a problem hiding this comment.
is it really expected that the finished callbacks are fired only once and then cleared?
There was a problem hiding this comment.
I'll remove the clear() call in case someone wants to reuse a VectorEffect. And, in hindsight, the clear() method shouldn't even needed for cleanup since the class will automatically clean up the references when the VectorEffectManagerState cleans up the effect (assuming the user isn't holding a reference to it themselves if they are intending to reuse it)
| } | ||
|
|
||
|
|
||
| public void registerRunnableOnFinish(Runnable runnable) { |
There was a problem hiding this comment.
If clearing callbacks once they fire is the way to go, maybe this should be called differently.
Usually when you register something it fires every time the conditions are met, maybe we should call this runOnFinish(Runnable), like we have enqueue instead of eg. registerTask
There was a problem hiding this comment.
Sounds good, I'll rename the method.
|
|
||
| } | ||
|
|
||
| public void registerVectorEffect(VectorEffect vectorEffect){ |
There was a problem hiding this comment.
| public void registerVectorEffect(VectorEffect vectorEffect){ | |
| public void playVectorEffect(VectorEffect vectorEffect){ |
| } | ||
| } | ||
|
|
||
| public void cancelEffects(VectorGroup vectorObject) { |
There was a problem hiding this comment.
can we add a cancelEffect(VectorEffect) for completion?
Adds a simple but highly reusable AppState that runs effects directly on a valid Vector type object (being Vector2f, Vector3f, Vector4f, and ColorRGBA).
Useful for lights, particle effects, and essentially every Color or Vector based MaterialParamater that shaders and special effects rely on.
The most useful functionality of this system will be the ability to quickly deploy an
EaseVectorEffecton colors to smoothly fade in/out things like lights and special effects, as to avoid the sudden and unsightly impact of removing something from the scene instantaneously in one single frame. This type of smooth fading is a very important aspect of polishing a game. And while the code to fade out colors can be simple, it is something that is used over and over again for a variety of different effects in a project and can sometimes requires some not-so-simple extra bells and whistles (like a delay timer or chaining), thus a versatile system like this becomes necessary to handle this in an efficient way.In addition to smooth fading, this library also enables a variety of other compound loopable effects by using the SequencedVectorEffect class (such as flickering, pulsing, oscillating, etc), and I also will be adding a NoiseVectorEffect class soon as well.