I had the idea to add a method to the FilterPostProcessor class that asks if it contains a certain filter, as well as a method in a Filter to see if it’s connected to an FPP. Something like:
boolean containsSomeFilter = fpp.contains(someFilter);
and
boolean isAttached = someFilter.getHasFpp();
Something along those lines. I’m having trouble with some things and it’d be a big debugging help.
Hm, actually it could use something akin to the controls/appstates, like if(fpp.getFilter(BlurFilter.class)!=null){doStuff();}
Yes, that would work too. I’m just having trouble with detaching/attaching some filters. Namely the PostWater effect. It seems if I add it, remove it, then add it again, there are 2 of them in the scene. Repeat the process, and now there’s 3. I wanted to track when it was added, removed, etc. so I could try to find the bug. But it’s very difficult without something like this.
@normen said:
Hm, actually it could use something akin to the controls/appstates, like if(fpp.getFilter(BlurFilter.class)!=null){doStuff();}
Actually you can have several filters of the same kind
@vinexgames you can launch the app in debug and see what's in the fpp filter list.
how do you remove the filter?
@nehon said:
Actually you can have several filters of the same kind
...and you can have several controls of the same kind and several app states of the same kind... so that's probably not a valid reason not to have an API for the most common simple case.
For anything else you can iterate over the filters. Though as a general pattern, it's a little odd that we don't expose List for these things... at least we're consistent with that.
@pspeed said:
...and you can have several controls of the same kind and several app states of the same kind... so that's probably not a valid reason not to have an API for the most common simple case.
Well actually i always found that strange for control and appState too.
Also in this particular case this kind of API wouldn't help.
but ofc i can add that and a way to get the complete filter list.
@nehon said:
Well actually i always found that strange for control and appState too.
Also in this particular case this kind of API wouldn't help.
but ofc i can add that and a way to get the complete filter list.
You can already iterate over the complete filter list. But if JME, as general policy, exposed List getAppStates(), List getControls(), List getFilters(), etc... as read-only lists, then the API is already there for finding a specific instance or iterating a variety of ways. Spatial.getNumControls() makes me cry a little bit each time I see it. :)
Though I guess on Android, avoiding the Collections.unmodifiableList() wrapper is desirable for apps that have to manually iterate over controls a lot... I'd argue that app is "doing it wrong" but mostly that's just residual anger at Android's crappy GC taking Java development back 10 years. ;)
1 Like
@pspeed said:
That's just residual anger at Android's crappy GC taking Java development back 10 years. ;)
hehehe if only it was just Java :p
Also i can't tell if returning read only lists would be very problematic with android...
I’m removing the filter by calling fpp.removeAllFilters(); yet it seems it doesn’t remove the water. I’ve tested it and it does remove other filters (SSAO, PSSM shadows, bloom filter, light scattering) but just not water. After about 4 or 5 quits and rejoins of the game, if the water is in the viewport the lag is unbearable.
Sounds like the filter is probably removed but that it is leaving some garbage behind in the scene/renderer/whatever… like a scene processor or something.
mhhhh…that sounds bad
i’ll test it.
Yeah unfortunately I had to get rid of all the iterator() calls as they were showing up high in the Android garbage collector. It made me quite mad …