OpenMfxForBlender
OpenMfxForBlender copied to clipboard
eliemichel
Status of OpenMeshEffects
Hi @EitanSomething, yes it is. I'm not rushing cause I have other projects as well, but I still need this somehow. I'm hopping to release a slithly more mature version soon, with at least the possibility to save files, which as you'll likely admit, a bare minimum to have.
The other important need at this stage is to support more point/vertex/primitive attributes, I'm thinking at least UVs and normals. As of now, the Open Mesh Effect standard does not provide a mechanism for it, so I'll have to alter it a bit.
What are you the most interested in regarding the project?
I’m most interested in being able to use custom modifiers that people created in Houdini to be used in blender.
Will there be an OpenMeshEffects plug-in in Houdini or it be a separate application?
The Houdini's HDAs would be loaded using a dedicated Open Mesh Effect plugin: https://github.com/eliemichel/MfxHoudini The usage will be to get MfxHoudini.ofx (the core plugin), drop the HDA next to it, then use this Open Mesh Effect branch of Blender to load MfxHoudini.ofx as a modifier. Proof of concept works, I'd like to add the support for UVs and other extra attributes before releasing. For which kind of HDA would you be interested? Effects acting on geometry only, or more advanced thing reading/generating extra attributes?
Can you created a https://blender.chat/ account. It would make it easier to communicate. Can you provide test files.
Yeah I am planning on syncing with 2.82. I try to sync with releases rather than with master, I feel it is a good trade-off between being a bit late and having to sync too often.
So you know, the current status is that I am focusing on reducing the amont of buffer copy when using the API. I'd like to minimize as much as possible the data allocated by plug-ins, by making them read data through a generic enough attribute layout mechanism, maybe inspired by OpenGL's Vertex Array Attributes.
The major problem for now is that when integrating OME in Blender, I have to 1. copy blender internal mesh representation to OME representation 2. call the plugin, that might - as in the case of the Houdini - reallocate data another time to match Houdini API's layout and 3. copy back from OME to Blender. With the ongoing work, steps 1. and 3. would be removed.
I’m currently updating to master . Can you use clang format because every time I save open mesh effect files it reformats
(I am @Elie on blender.chat) Ok yeah I'm not using the clang format yet, maybe deactivate your autoformat for now on this branch, I'd avoid mixing up formatting stuff with "actual" code changes.
Also, I have some ongoing uncommitted work about what I was saying in the previous message, which is why I haven't updated yet. Ok for formatting, since I'm no longer alone I guess I'll move my ongoing stuff to some branch.
I haven't checked is all examples are still working after the recent changes brung to the API, that could be something worth checking (including MfxVcg), and ideally automating those changes.
Test plugins are in the repo here: https://github.com/eliemichel/OpenMeshEffectForBlender/tree/openmesheffect/intern/openmesheffect/plugins
Building the branch should build openmesheffect_color_to_uv.ofx, openmesheffect_identity_plugin.ofx, etc. You can just test with a cube where you add an Open Mesh Effect modifier basically ;)
Mmh sorry if I make you work again but would you mind if I push what I was doing first and you sync from that? I was working this last hour on making it be stable enough for a commit and it is ready for push now.
Can I get commit access. There are a bunch of small code style changes that I will be making and it would be easier if I could commit them myself.
Problems are 1. you merged with master rather than 2.82 release as I suggested above; and 2. after putting some though in it, unless it causes major reading issue, I'd like to stick with the current code style for now. Either ways it makes it really hard to review that there is a mix of merging and actual changes, so I'll think I'll handle the merge.
Was there something you really need in master that isn't in stable?
If we stay with master it will be easier when we submit the code because when we move from 2.82 to master it will likely cause things to break and it will be easier to fix them if we catch them more often. I will also be able to integrate it into the asset manager when that gets committed.
all the mesh data should be put into a struct instead of the multiple variables like it is now
all the mesh data should be put into a struct instead of the multiple variables like it is now
Can you be more specific?
A struct similar to blenders Mesh struct. It would prevent mfxModifier.c from getting messy. I submitted a pull request Syncing with 2.82.
I admit mxfModifier. is messy, it is actually kind of the main where I put stuff before it eventually gets cleaned up into separate file. I try to contain messiness in that if you will. Actually I am working on a way to use directly Blender's Mesh structure, but out of curiosity what variables of mxfModifier.c would you put in this struct?
I was thinking also a good way to help would be to try to write a simple plugin to check that the instruction guide is up to date (which it is not totally for sure).
There is already a notion of vertice and face. Adding edges is being discussed for cases in which one needs to attach custom attributes to them. But I am still not sure which struct you are talking about exactly.
Just discovered this! Very interesting. I was reading this tutorial because I had a similar idea: Exposing non-destructive modeling/blender modifiers to plugin architecture, turns out you already had drawn the same conclusions :)
Will try to build this fork later today...
Cool, I've just ported it to Blender 2.83 LTS, will release a binary soon I think!