I believe it first has to get tested by some users like you! I’ve had little feedback on usage so far.
3 Likes
True, but Indon’t have enough programming experience to do an OFX plugin, it needs some programmers to chime in 
I also don’t have any Houdini license anymore I’m afraid
1 Like
@Elie, thank you for this, great adition for blender toolchain.
Can I create curve modifiers with openMeshFx? like a resampler/optmizer (input==curve, output==curve) or a sweep/extrude modifier (input==curve, output==mesh).
Can I create a render time plugin with openMeshFx ? like a scatter/instancer (ex. forestpack) or a render time mesh loader from disk, freeing the used memory after render finish… (ex. vrayproxy)…
and UV map modifiers? (ex. triplanar/box/sphere uv projection).
1 Like
Hi @wilBr,
Curve modifier are not realy supported, but it would be an interesting extension, I think by adding typed primitives. For now primitives can only be faces (ngons), so it supports meshes or point clouds.
Theoretically with arbitrary attribute. Open Mesh Effect does support this but the current implementation only handles vertex colors and UVs - so yes UV map modifiers are possible. For instance the very last example of this video reads UVs to drive the grid generation effect.
About render time plugins, it depends on what you call so. You can like with any other modifier disable it from viewport and keep it only for render time, but it would still be generated in Blender before being “sent” to the render engine, so if you are talking about plugins ran by the render engine itself, it’d have to be implemented in the latter.
2 Likes
For render time plugins I think that openmesheffect need to be implemented in cycles side… blender mesh sequence cache modifier can load alembic file from disk, using lowpoly obj as host and disabling modifier viewport view icon we have a lowpoly viewport mesh and highpoly rendertime mesh like vrayproxy, but like you told, blender still loading highpoly mesh before the render and keeping it in memory after render finished… a rendertime solution would be nice…
anyway thank you @Elie
1 Like
Hello @Elie I am building your branch right now, gonna have a whack at trying to write an effect. But I have a question: do you think there could possibly be an OpenConstraints or something similar? I think OpenMeshFX could be used to create custom deformers for animation, and it would be awesome if there was a way of creating custom constraints, too (I’m not asking you to work on this, just want to know if you think it’s doable/reasonable).
In the meantime, I’ll start by trying to make a simple deformer!
EDIT: am having trouble building the Blender. I’ve written an issue on the github page which includes a CMake Error log.
1 Like
Also, I have another question-- does OMFX only work on faces, not verts/edges? I think it would be awesome to be able to create custom grease-pencil modifiers with this technology, and it seems doable if it can modify verts/edges. Maybe once I get it building I can investigate.
Hi @Josephbburg
I haven’t looked at the constraint mechanism, but I guess a similar approach would be possible, and could be based on OpenFX as well.
Regarding topology, Open Mesh Effect operates on vertices and edges too. Edge access is less explicit, there is no way to add custom edge parameters for now but if you feel the need for it let me know, the API can still evolve at this point depending on user feedback.
(As you’ve seen, regarding the building trouble we’ll follow up on github)
1 Like
Hello, I got the Blender branch to build, but now I’m having trouble building the example plugins. I tried copying the include directories into the “examples/plugins” folder and then creating a cmake build directory. Once I try to make, the build process fails at the linking step:
Scanning dependencies of target openmesheffect_mirror_plugin
[ 8%] Building C object CMakeFiles/openmesheffect_mirror_plugin.dir/mfx_mirror_plugin.o
[ 16%] Linking C shared library openmesheffect_mirror_plugin.ofx
/usr/bin/ld: cannot find -lopenmesheffect_openfx
/usr/bin/ld: cannot find -lopenmesheffect_util
collect2: error: ld returned 1 exit status
make[2]: *** [CMakeFiles/openmesheffect_mirror_plugin.dir/build.make:84: openmesheffect_mirror_plugin.ofx] Error 1
make[1]: *** [CMakeFiles/Makefile2:86: CMakeFiles/openmesheffect_mirror_plugin.dir/all] Error 2
make: *** [Makefile:84: all] Error 2
(Is this the right place to go for support?)
I have been able to get https://github.com/eliemichel/MfxVCG to build, very easily, too.
Thanks.
1 Like
A little update to say that the dev is still going on, and somebody released an Open Mesh Effect plugin based on VTK: https://github.com/tkarabela/MfxVTK This triggered interesting design discussions going on here and there!
@Josephbburg sorry for not replying earlier, maybe github issues are a more relevant place for this but never mind. The examples have been updated since then, do you still have trouble building them?
17 Likes
Thank you! I’ll check this weekend. I think OpenMeshFX could be an important feature for animation studios that need to build custom deformers.
2 Likes
Interesting project. I just read through the whole branch. I’d really like such a plugin api for mesh transforms. But I also see some quite hairy problems with it.
One practical problem: Having this in official blender would lead to .blend files which won’t (correctly) open in another blender instance if it doesn’t have all the required plugins installed. This doesn’t really need to be a dealbreaker (I think) but is is something which would need to be thought out extremely well. You would have to have some sort of fallback mechanism. And I could very well imagine this alone to be a reason for the core blender devs to reject this altogether. Because it has great advantages, but also great disadvantages in usability/support/compatibility. At least you’d need something like the linux-kernel ‘taint’ system to mark files as depending on external plugins.
A second problem I see is more of a ‘political’ problem: Adding a binary plugin api to any open source program opens an avenue for non-opensource contributions. Which can lead to more external developers choosing to keep their contributions closed and less people choosing to contribute to the open source core, thus limiting the growth of blender. The success of GPL apps is for a large part a consequence of the viral/forceful nature of the GPL (IMHO). In the worst case scenario the open-source app becomes an empty shell which only functions as a plugin host to closed source plugins. Not that the chance of this happening to Blender is significant, just as an example of the extreme case to make my point clear.
Please don’t take this post as meaning that I think this project is a bad thing. I’d really like to have it in mainline blender if only because I’m a C++ coder by trade and I’d really like an easy way to write this kind of plugins. But stuff like this is important too and needs to be discussed.
Just my 2c (And take everything I write with a grain of salt, I’m just some random coder and these are just my personal worries).
4 Likes
Thanks @Baardaap, you point out two important sources of question!
Having this in official blender would lead to .blend files which won’t (correctly) open in another blender instance if it doesn’t have all the required plugins installed.
The way I think of these OpenFX plug-ins is like resources. They could be treated like any other external resources (image textures, etc.), potentially packed into .blend if needed. An OpenFX bundle is supposed to include whatever it needs to run on all supported platforms. It is true though that we cannot enforce that the plug-in will in effect be implemented for all of them.
A second problem I see is more of a ‘political’ problem: Adding a binary plugin api to any open source program opens an avenue for non-opensource contributions.
Yes, this is a true question. I understand the concern about external developers going closed source, and agree with that prognostic. On the other hand, it could be a way to “import” developers from the communities of other 3D software; hopefully in the end everybody wins because the overall dev effort of the VFX community is better put in common. But this is uneasy to precisely anticipate.
I guess this point is a also the main reason why I did not have any feedback from the core team, especially since this started as a bridge with Houdini that must have felt against some philosophical standpoints.
But I don’t know, I still feel that such a mechanism could bring a lot regarding interoperability of 3D scenes, so I could also focus on other hosts software, since we need them anyway (I actually have a standalone prototype loosely inspired by Houdini and some wips in game engines). I just feel that Blender is a good start point, cause I like it, I like its design, and I’ve been using it for a long time so I’m happy to contribute back in some way.
the […] app becomes an empty shell which only functions as a plugin host to closed source plugins.
Sounds like what Maya has become. ^^
5 Likes
I don’t think that the “developers going closed source” fear is a proper fear.
What’s happening right now is that there are developers that don’t want to deal with GPL and don’t like it, and there are developers that accept to deal with GPL, the difference this will make is that SOME developers may accept the GPL with this, because the plugins themeselves would be binaries, after that anyone can ask for the code with the written offer, or the plugin can include the code in it’s download, as the GPL mandates.
Also developers know that they can make the code as obscure as they want, in the case they want to, I don’t like the idea, but the GPL / Open Source thing IMHO is just a excuse in some situations, in some others those developers want to retain all the I.P. as theirs to sell the source to a bigger company but…
… I think in this case developers don’t understand two things:
- They can dual license their code, so they can still sell the code to closed source companies, because in practice they CANNOT implement a single line of code in their packages unless they purchase the code, even when the code is open source, so ADesk for example has only one way of implementing an Open Mesh Effect that is licensed under GPL, and that is purchasing the code from the original author, because also the original author is the only one that can actually dual-license the code, since any other Open Source version developer got the code under GPL and that cannot be changed unless the original author agrees.
So IMHO all that Open Source fear is a non-sense, and the more I dig into the GPL the more I realise that it only helps Open Source but does not damage anything in other platforms.
So while some developers may prefer to distribute their Open Mesh effect plugins as binaries, that does not means those plugins are not under GPL, but at the same time that does not means that they cannot have another version under a custom license fully closed for other packages like Max, Maya or any other, and no company can “copy” and implement their code into their packages unless they purchase the code from the original author.
In the long run I only see a situation where both developers and users understand the GPL better and loose fears.
On the other side, Blender will not become an empty shell because the main core development team has never depended on what addon developers do, so the development will continue, with a big difference, right now there are things that can only be tackled from core, and some of them are not implemented because of many reasons, like that the main core dev team don’t like what is being done there, so some patches are never commited regardless they may be super useful for the users, or for SOME users.
With Open Mesh Effect this can be avoided, and this won’t avoid developers contributing to Blender, but will allow many developers to properly implement their vision without “affecting” the main branch, and without leaving the users to decide if they want that perspective of a plugin/addon or not, but the developers would not be constrained to some requirements, that on the other side, are totally needed to maintain Blender with a high standard in code quality, something that they themeselves are still solving, and that’s why they are so strict with some of these things, and I agree with them personally.
But this will bring A LOT more freedom to the table, I sincerely hope they don’t react based on “fear” or possible “what if’s” but they react based on what could be a huge improvement and a big help to users and developers, always under GPL
Ok… I’m done with my chat, in resume, I don’t think that the fear to some people trying to go closed source should punish users in general.
1 Like
To whom it may interest, I’ve built a nightly branch based on current master (2.92), binary available for Windows here!
2 Likes
Embedding binary executable code inside a .blend file seems like a terrible idea from a security perspective, for python code we at least warn and give the option not to run it, so you can inspect if for any “mischief” before you decide to run, binary code does not have that option (to inspect it for mischief), “Hey this blend contains binary code? Run ? Yes/No, roll them dice! what’s the worst that can happen right?!”
That’s a very dangerous road to walk on, and honestly not one we should even consider looking at.
1 Like
Indeed oops, I don’t know where I had my mind when thinking about this. 
So let’s rollback: Yes this will imply that some blend file could not be loaded correctly on system that don’t have the required plugins installed, but well it is the case for images already, and we are already planning on taking care that the parameter values are still remembered so that a user who don’t have al the plugins can still modify other parts of the scenes and save the file, it’ll open correctly for users who have the plugins afterwards.
(related issue on GitHub: #40)
2 Likes