Based on fps numbers, I’m assuming that Genome doesn’t optimize for Switch, Mux, or LogicalOr. Meaning, if we wanted to apply some complicated effect only on the vertices/faces that were either selected or actually mattered to the effect, we wouldn’t make anything faster, and could actually make it slower?
For cases where we want to have an OUT:Selection Genome with options like “Add (0), Subtract (1), Replace (2)” and “Invert (1)”, this means we either have to have a slow Genome with many branches, or a pack of 6 Genomes with only the exact branch we need.
As an aside, if we did care about speed enough to have the 6 Genomes, this would be an awesome use case for HotBLOPs.
Also, but much much much less important, Power doesn’t appear to optimize based on the Exponent being connected to a Integer.
This is true. In the current implementation Magma/Genome will always execute every node, and Switch/Mux will just select a branch after the fact. At some point we will address this, but it complicated the algorithm enough to not warrant it in version 1.0.
It does actually. The implementation of std::pow(float, int) provided by the MSVC C++ standard libraries has a different codepath compared to std::pow(float,float). Perhaps the implementation is similar in cost anyways.
pow(float, 5.0) was ~5.6 fps
pow(float, 5) was ~5.9 fps
floatfloatfloatfloatfloat was ~6.3 fps.
As an aside, testing this made we wish for HotBLOPs even more. I had one BLOP in my Genome that did the pow(float, float) then daisy chained that so it ran a total of 10 times. I edited the first instance of the BLOP to be pow(float, int), but then I had to then save and reload it 9 times. I’m finding myself “unrolling” “loops” and not being able to “instance” a node makes changes tedious.
How about a “warm” BLOP?
It would not do it automatically, but you would get a button to replace all other instances of this BLOP in the current flow with whatever changes you made.
It would match only by node name, so to exclude some BLOPs from updating, you could just rename them.
If you reload one BLOP from disk, you could then hit this new button and all other “instances” of the BLOP would be updated automatically.
A real HotBLOP would possibly require actual instancing under the hood.
This would be the next best thing at UI level and I could do it for 1.0.
I just noticed that you can’t really use a TexmapEval in a BLOP since you can’t choose the map except in the editing mode. So I’d have a save out that BLOP with the map built in, which would of course stink as I’d eventually have one .MagmaBLOP for every map I ever wanted to use.
But for more “fire and forget” BLOPS, this would work. But of course that’s assuming that you actually NEED to edit it. Something like DegToRad.MagmaBLOP isn’t ever going to get edited. Not sure how much intesection there is between these different types of BLOPs, those that can be properly exposed so nothing stupid (like the map) is burned into them and those that actually need editing.
Genome nodes can have their properties changed without a license. This includes things like setting the Texmap or spinning a spinner. The major operations that are restricted are creating nodes and changing inputs.
Nope, that’s a bug. The attached update for Beta 4 should fix it. Both TexmapEval, Curve and InputChannel nodes should be exposable from inside nested BLOPs. But I was missing a counter and they only exposed if there was already a Float that was exposed, plus the order was wrong. If you are on Beta 4, please try the update and see if it solves the problem.
There is another known problem here - when you create a BLOP from selection, the TexmapEval loses the map reference. I have logged it as bug to be looked at for Beta 5. Genome_MagmaFlow_20120329a.zip (69.4 KB)