The process regarding parameters is the following:
The Describe action is called, listing the parameters
The RNA/UI is built with a widget for each parameter
The Instance is created
Parameters are copied from UI to instance
Effect is cooked
So it is important that the default values of parameters is known at step 2. OpenFX provides a mechanism for this, with the kOfxParamPropDefault property.
That being said, I havn’t implemented it yet. So you can either open an issue so that I remember (I can do it quickly) or give it a shot, I think it is an easy fix. It has to do around openmesheffect/blender/intern/mfxModifier.c#L452.
I havn’t released the Houdini part yet, I wait for it to be mature enough to prevent early deception. At the moment the most advanced plugin around is MfxVCG.
PD: Your remove doubles appear to be a better implementation of the remove doubles. Because blender “Merge by distance” do a strange artifacts, select one of the vertex merged and merge the rest to this, instead of use the center of all vertex. Also it doesn’t give us a symmetry mesh when it must to give.
@Alberto What you describe is exactly what my implementation does too ^^ I don’t take the average position, I only keep the point with the lower index, because I assume that it is used with very small threshold, and it takes more computation/memory to consolidate the average positions.
@Wazou I could, when/if I wind the time to do so. It is a quite easy modifier to write because it would have to just call the remove doubles function already implemented in Blender. If you want to give it a shot you can follow my tutorial for writing modifiers: https://blog.exppad.com/article/writing-blender-modifier
I think the reason the first patch for this feature was rejected was because it was basically a bmesh operator in the modifier. See this topic: https://developer.blender.org/T41748
The great thing about OpenMeshEffects is that anyone can write any effect for mesh data- even if it doesn’t meet Blender’s strict code review standards. That way, anyone can hack together a quick solution, share it, etc. Of course they can also make a really nice solution, or polish the quick hack into a nice solution. The point is that it enables a more lenient development process because it isn’t managed by someone else, while still providing an easy way of sharing the modifiers you create.
Just to have it clear, right now is it fully GPL compliant? I don’t want to argue against it or anything, I just want to know if there are odds that this could be implemented at some point in master, and for that it should be crystal clear GPL compliant.
But that does not answer the question, I know the code is GPL, the question is, is everything needed and everything that comes into play is GPL compliant?
At the beginning there was some issues with the Houdini part of the equation, I think @Elie worked to eliminate that part and make everything fully GPL compliant, so I want to confirm this status as of today.
Not being a legal expert here, but the compiled code (from outside) running on the ofx modifier doesn’t “know” blender, doesn’t use any blender interface, it just respects a possible standard, with known call points, so the license they use shouldn’t be a problem, but that is may take.
It is getting more stable, and I am starting to settle down on the Open Mesh Effect API, which now gets a dedicated documentation website: https://openmesheffect.org/