cremaschi's picture

ArtoolkitX seems an improved and easier library to port.

zimocracy's picture
@zimocracy commented on @zimocracy's Bug Report, “VDMX/VUO

Thank you all for your help! It works perfectly now.

jstrecker's picture

depending on state of a running composition programatically

Alastair (@usefuldesign), since that's not covered by an existing feature request, you should create a new one. On that FR, it would be helpful if you could give specific examples of situations where the Edit Details context menu (exists for published input ports, proposed for the Share Value node) would not suffice. I understand that you're requesting something more dynamic than Edit Details, but I'm not yet understanding what you want to use it for.

jstrecker's picture
@jstrecker commented on @MartinusMagneson's Discussion, “VuoGenericValue1

No, it won't automatically convert.

If you want the data type's "zero" value, you can do VuoGenericType1_makeFromJson(NULL). This returns 0; (0,0); (0,0,0); or (0,0,0,0) as needed.

For non-zero values, one way to do it is demonstrated in the vuo.math.multiply.list.2 node class's source code. The nodeEvent function calls a (placeholder) function named VuoGenericType1_make1, which is intended to return the "one" value for the appropriate data type. The node class's source code defines a version of the function for each numeric data type — VuoInteger_make1 that returns 1, VuoPoint2d_make1 that returns (1,1), etc. It's long-winded but it works.

MartinusMagneson's picture
@MartinusMagneson commented on @MartinusMagneson's Discussion, “VuoGenericValue1

Thanks! But what I think I mean is, if I scale a VuoGenericInput1 by a real, will the real convert itself to a 2d/3d/4d point as needed? Since the _scale funtion takes scale values in the same format as what they scale that is?

I.e.: Vuo GenericType1 value; VuoReal scale = 0.2; VuoGenericType1_scale(value, (0.2, 0.2)) //for a 2d point?;

jstrecker's picture
@jstrecker commented on @MartinusMagneson's Discussion, “VuoGenericValue1

When your generic node class is specialized to a data type, VuoGenericType1_scale is replaced by the function for that data type. For example, when you add a Scale List node to the canvas and choose Set Data Type > Real, the call to VuoGenericType1_scale in that node is replaced with VuoReal_scale (documentation).

It's actually just a text replacement. Everywhere in the node class's source code, the string VuoGenericType1 is replaced with VuoReal.

The available variations of the scale function are: VuoInteger_scale, VuoReal_scale, VuoPoint2d_scale, VuoPoint3d_scale, VuoPoint4d_scale. While there's no entry for VuoGenericType1_scale in the API documentation since it's not an actual function, there are entries for each of these variations.

MartinusMagneson's picture
@MartinusMagneson posted a new Discussion, “VuoGenericValue1
alexmitchellmus's picture

Thanks for the great info Jaymie (@jstrecker)! As always it looks like Apple has pressed fast forward on the EOL of OpenGL. Hopefully it will be positive for the industry, and for Vulkan (which didn't look like it was gaining traction on MacOS). All I know about Vulkan vs OpenGL is that it's very different, very low level, and not always faster (for high resolution outputs no; but for 1080 much faster).

(When looking at game benchmarks etc)

UPDATE: Just been playing with the 'Vulkan Traiangle' tutorials... looks like I am wrong, and Vulkan can swap out shaders on the fly, (at least if I recompile the shaders obviously...) Having a default way to compile shaders (with error feedback) is a nice change to the silence that was GLSL.

jstrecker's picture
@jstrecker commented on @Kewl's Discussion, “Deprecation of OpenGL and OpenCL

For a while now, it has seemed like Apple has been devoting most of their resources to Metal at the expense of OpenGL. Most or all of Vuo's known issues with certain GPUs (https://vuo.org/node/2038), not to mention many issues that we have fixed, are due to bugs in Apple's OpenGL drivers.

So it's not too surprising that Apple has officially deprecated OpenGL. We've been researching and experimenting with alternatives over the past few years.

Whatever changes we may see in macOS graphics support in the future, we can count on there being a great many potential Vuo users who, for whatever reason, are on Windows. We've promised to support Windows eventually and intend to keep that promise.

Ideally we’ll be able to find a viable cross-platform solution — something that would add support for Metal while paving the way for Windows support. MoltenVK is one possibility. We would convert Vuo's OpenGL code to Vulkan, which runs natively on Windows (and Linux and Android). MoltenVK would enable the same Vulkan code to run on macOS (and iOS). Of course, we'll have to do more testing of MoltenVK or any other graphics library to make sure it's a good fit for Vuo.

If any of you have developed with Metal, Vulkan, MoltenVK, or other cross-platform open-source C/C++ graphics APIs, we'd like to hear your thoughts. Any pitfalls we should watch out for? Any slick features we could take advantage of?

Once we've done some more research and testing, we'll let you know our tentative plan.

Pages

Welcome!

Vuo is more than nodes and cables, it's a community! Feel free to browse or add your voice.

Browse Discussions

Start a Discussion


Browse Feature Requests

Suggest a Feature


Browse the Composition Gallery

Share a Composition


How can I get notifications?

Learn more about the community

Learn more about Vuo

Vuo Announcements

Sign up for the Vuo announcements mailing list to get news and join the community. We post about once per month.