How to set Flood Fill to C16 as opposed to C32F

Rekov

I have been trying to get to the bottom of why my Flood Fill node is taking 12+ seconds to process. I compared it to someone else's graph, and the only obvious difference is the bit level of the node. We are both using the latest version of Designer.





We compared our settings for the node and couldn't find any obvious differences. What is going on here, and how might it be corrected? Is there a setting for bit level for individual nodes?

poopipe

You can force it on the node itself. Just set the depth to absolute in it's properties. 
It'll want to be a float value though I think. 

Their tile random is 3 times faster than yours.. different gpu? 
Same version of designer?

12 seconds is a really long time - is it actually taking that long to process? It could just be misreporting the time

Rekov

It's possible we're using different settings for the random tile which makes mine chug harder. I'm running a 1080 Ti so I hope GPU isn't the issue here. It does actually take 12 seconds to process.

I'm not sure I follow you about setting the depth to absolute. The lowest option seems to be 8 bits per channel, which is what it was already set to when it was on relative to input.

This is another guy offering another data point:

Rekov

I checked an older graph of mine and copied the flood fill node from it. Here they are side by side:


I can find no obvious difference in settings between the two, except that the older (bottom) node doesn't have anything inside the Instance Parameters section, while the newer (upper) node has a Safety/Speed trade-off drop down. I've tried all three settings for this, and none of the replicate the result or the speed of the older version of the node.

For now I guess I will just have to copy the node from older graphs.

poopipe

They did actually change flood fill  so that'll be a bug I should think. 
If you contact Allegorithmic support directly they should be able to advise you on what exactly to do. 

In the meantime.. 
You'll be able to find the original flood fill node in the install directory where the rest of the packages are stored.  They don't delete the legacy nodes, they just hide them from the library so you can either unhide it or put it into a custom node of your own. 

Also 

Setting the depth to absolute forces the bit depth, leaving it on relative to input means it inherits the input bit depth regardless of what the UI says.  this is assuming it hasn't been forced to 32f inside the floodfill node (not unlikely) 

oblomov

The performance drop seems to be due to the fact that the GPU engine is running out of memory with the new Fill node on your machine. The new Fill node requires to use multiple C32f textures internally, which at 4k resolution quickly fills up most graphics cards VRAM. Since the shapes you are working on at this stage in the graph are very simple and aligned with the pixel grid, you can probably work at a smaller resolution (2k ?) and upscale a few nodes later in the graph when you start adding details. Otherwise I would advise using the older, deprecated version.

The fact that the new Fill node output is forced to C32f is an oversight though. It should be C16 like the older node. Only its internal nodes should be C32f.

poopipe

Flood fill won't work at c16 without modification - I just tried it and it comes out empty. 

It appears to work ok at c16f  - You can make a 16f version by taking copies of flood_fill and flood_fill main and setting their bit depths appropriately. 
You'll be sacrificing precision of course but at 2048 the 16f version appears to processes twice as fast as the 32f version. 

This was tested with a 1080 in some sort of stupidly overpriced Xeon box with Painter running in the background. 
fwiw increasing resolution from 2048 to 4096 seems to increase processing time tenfold so you're probably better off doing as oblomov suggests. 

I can see why they are forcing 32f  but I feel it's worth reporting as a bug 

Rekov

I'm telling you, I took the C16 node from my old graph, plugged it into my new graph, and it produced the exact same result as the C32F node in three orders of magnitude less time.

Anyways, I filed a bug report so we'll see what comes of it.

poopipe

As stated above. the node has changed and categorically does not work without signed values. 

here's a picture 

Rekov

I too can take screenshots:

poopipe

It's a different node,  the old one doesn't have the same sums in.  What I showed you above is the new one, altered to allow for changes in bit depth not working if you don't give it signed values. 

Rekov

Oh, okay, I understand you now. This thing is extra confusing because the old node doesn't seem to actually get the (Legacy) label.

poopipe

Graphs can be hidden from the library - they've done it with the AO node and afaik most of the noises - you can unhide them with a button on the node attributes panel if you want them listed. 

oblomov

We're working on a fix that reduces the memory cost (and consequently brings the performance back to something more reasonable at 4K) for the for new node for the next bug fix release. It will also make the output C16 as it should.