OK, seems this one was my mistake, due to a compositing mistake after a bunch of testing. Compositing modes are complicated!
There is a difference between the Sketch gaussian blur and the Vuo one, resulting in a slightly different distribution around the edge of opaque pixels. Apparent when Diff'ing two files that have had the same effect., one from Sketch one from Vuo. That's not a problem, per se, but I'll note it here for history.
If you're planning to work with Vuo, take this class!
Huseyin knows what he's doing and how to explain it clearly to any level of student.
This class helped to get over those first hard steps into new software. Take the leap!
Just popping back in to confirm that the new M1 Macs refuse to run FxPlug 3 modules built with Vuo, instead showing the error in the attached screenshot. Would love to see FxPlug 4 supported if it's possible.
I am using a texture, in the usual way the OBJ references the mtl file which in turn defines a material which specifies the texture image. That all works. I can change the mtl file to point to a different texture, I do this with the SaveData node. It works because the obj, mtl, and texture image are all located in the composition directory.
The problem comes when the composition is built into an application. The OBJ, (original) mtl, and texture image are in the resources of the package, but SaveData writes to the same location as the application (or to a location one chooses but for an application going to a third party machine that is a problem). Currently I change the OBJ reference to the mtl file to be in the users home directory and write my mtl file there also. But I hate it when applications write stuff randomly in my file system so would rather not do it myself.
One solution would seem for Vuo to provide a way of getting the path to the applications resources directory, but I don't think there is a way of doing that currently.
From what I have read the url for the .mtl is encoded into the .obj so you'd have to parse and replace that url when reloading the obj. if possible.
Otherwise could you just use an image texture instead of the .mtl in the first instance?
I am displaying an OBJ file which has a single textured mesh, the texture is accessed by the OBJ as an mtl file which in turn references the texture image.
I change the texture image and to get the obj to reflect that I create a new mtl file, saved using the SaveData node.
Until I save the composition as an application. The mtl file gets created in the directory the application resides but the OBJ file references the mtl file in the resources of the application package.