#FXMaster — Relative options vs. absolute options

1 messages · Page 1 of 1 (latest)

placid root
#

I don't know if the latter is a valid use case but maybe some other module that interacts with FXMaster's API might want to do something like this.

Does anybody have any opinions on what would be better? Would anybody like to discuss?

wooden moat
#

Eh, in my opinion, and as a user of FXMaster in the past, I never ever cared about the actual value of the slider. To me the important point was that left was "I want a little bit" and right is "I want a lot". So imho mathematical consistency doesn't matter so long each of the sliders gives a consistent feeling that going left is reducing it and going right is increasing it. If the values bother to the developer perspective, you can just mask them with something like Lower and Higher or Smaller and Larger corresponding to the meaning of each

#

And if you allow me to add a suggestion, it was in that module a bit of a pain in the arse to experiment with, because after pressing "Update" the Dialog would close, and already then the values were meaningless to the user, so one never got it "right" at the first shot, having to go back and open the menu again for further adjustments.

#

If you can keep the left is small and right is big consistency, plus making the "Update" button stay after experimenting (and perhaps adding a Close button), then you will be already gold!

#

And thanks for taking care of this amazing module! my two cents

rapid linden
#

I have been a huge user of FXMaster in the past, but had to abandon it with so many bugs and performance issues. So my biggest ask is to pay attention to those things, and how FXMaster combined with Levels and Token Magic FX can really start to add load onto a machine. So draconian attention to performance, with options for auto-configuring low-powered machines, are always welcome.

now, to answer your question, I agree with Jeansen about just wanting sliders for 'more' or 'less', EXCEPT that I want to be able to save, share, and edit pref-configured ways of doing things. The abiliity to auto-create a macro that automatically activates a certain set of FXMaster filters, for example, was very important functionality to me.

placid root
#

Thanks for the feedback!

Regarding keeping the window open when saving: That's a pretty easy change. I might either just add this or add a setting for that.

Regarding performance: I will consider that at some point but it's not a top priority right now. I did notice that there are a couple of effects that seem to be pretty resource intensive (most notably clouds and fog). I am using a relatively weak laptop myself, so I am also running into these kinds of things.

But for now, my main goal is to get the module back into a state where it's stable and usable easily/intuitively.

#

Functionality like being able to auto-create macros etc. is here to stay of course.

keen pawn
#

I agree on the "Numbers don't matter" point and would even go so far as to suggest just cutting them out entirely. Label the sliders with an arbitrary "Min" and "Max" and call it a day.

placid root
#

I think the numbers are still useful to know if you want to put them into a macro or invoke it from some other module. So I'll keep them (for now). But it's good to know that people don't care that much about what the numbers actually are.

keen pawn
placid root
#

It’s still difficult to guess what the values should be without any reference. So you will most likely try it out and then use the values you see

keen pawn
#

I've given it some more thought. Given my prior experience dealing with particle systems in environments like Unity or Blender, I'd say the following would feel most natural to me:

  • Spawnrate in particles per tick
  • Speed in either pixel per tick (or kph/mph)
  • Scale as either absolute pixel dimension (or in cm/m/inch/ft) or relative size to particle graphic dimensions.
  • Lifetime in seconds*
  • Direction in degree, with deviation in degree (i.e. 90°, 5° deviation = 85°-95°)

Those would go great with a range option where appropriate. Direction has that with deviation. But speed for example would work great as min/max pair. Real world measurements would of course only work if the map has gridsize and scale (distance & units) set.

I'm assuming that Fx Master works with, or like, a particle system here. If that is the case, I'd be very interested in seeing options for emitter, attractors, and all the neat stuff particle systems usually come with.

  • Lifetime in ticks wouldn't work, as that setting can vary from client to client.
placid root
#

I think all of these are good ideas for a more fine granular particle system. But that's not the idea of the weather effects. those should be easy to use and adjust for regular users. They shouldn't need to know about spawn rates and particle lifetimes. The effects are not meant to be completely customizable, they should only be adjustable in appropriate ranges.

#

the current version of FXMaster is actually closer to what you suggest: It gives the speed in pixels per tick etc. But that's actually confusing users because they don't get what this number means

#

The ease of use is also why the spawn rate and max particles settings are hidden behind the "density" property. That's not going away as this is also an option for the foundry core special effects. I want to keep things compatible.

#

Of course this makes things less flexible for users who are experienced with particle systems. But that's a trade off that needs to be made, imo.

#

regarding ranges: the effects already have ranges built into them. Another reason why i like making the sliders relative: you just change all of the steps of those ranges (it can actually be more than 2).

#

It doesn't really make sense for these ranges to be adjustable by users. It affects the way the effects are set up too much.

#

again, the idea is to have weather effects and to be able to adjust these weather effects in ways so that they still make sense

#

for example, with rain, you should be able to create an effect of slightly drippling rain from the top left and a heavy rainstorm from the right. But something like making the raindrops increase in size at the end of their life time is not a valid use case. So that option shouldn't be exposed to the user.

#

as we have already discussed, a separate feature (and layer) that allows the user to configure particle effects in much more detail by himself is a valid and good idea. But it should be kept separate from the built in weather effects.