Stoner makes big TOEs


Every time I use the stoner tool I delete these ops first thing.

For some reason the locked TOP doesn’t seem to have anything to do with the real output, yet it saves that data with the TOE and it’s easy for the toe to be huge for no reason.

I had 3 4K stoners and the file was 150 mb. Remove these ops and the toe goes to 140KB

Stoner throws errors when moving points after deleting these, however doesn’t seem to impact the functionality of the stoner, it still outputs the correct UV and warp texture. It still persists the data after a save.

Can someone explain why those ops are even there? it looks only like it’s saving the demo image before you start using it.

Hey Harvey - I got you sir. I should have a good example ready to share sometime tomorrow.

The locked TOP can be used as a look-up texture so you don’t have to run a full stoner. It’s about .1ms vs almost a full ms in terms of computation time. The Project parameter on stoner will create this network in any target component. This essentially lets you use one stoner as the UI, but create multiple distortion maps. The one wobble I’ve found is that you need to see the output from the stoner’s UV map (the second output) in order for the projects to update. I’ve been meaning to make an example of this for several months, and I’m finally getting around to it. More soon.

Here’s a quick link to a little description

Longer overview here for posterity: … er-tricks/

Yeah - I’ll fix this so that stoner doesn’t come with the op locked by default.
Contemplating if Stoner should prompt the user to safe out the uv map when specifying the project parameter and it could then either load from file or if a stoner is present, use the live uv map from the stoner…


Hey Markus,

+1 to starting with an unlocked TOP.

I’d also love a workaround so you don’t have to display that disparagement map when using the stoner.

My 2 cents here is that I’d love for the target project to get a set of custom parameters that could include a path for externalizing the texture, the offsets/table vals, and any other data for the component. It could also just save the whole tox as a binary, and I’d be okay with that as well - but some helper pars / functions to smooth that process out would be killer.

I think a default behavior of locking the TOP and keeping it in the toe file is probably a direction that will create the lease amount of user error. I’d rather have a big file that works than one that forces me to save an external file that could break my calibration if I don’t move all the files correctly.

Will you be at the summit - happy to talk in person if it’s helpful to have some outside perspective.

Will see you at the summit :slight_smile:

Ah thanks Matt I get it!

Thats nice that stoner has multiple project location options, I just didn’t know. For years I was just re-writing those DATs in the project op.

I usually do the remap from the stoner output and save to file before locking the stoner, didn’t know that feature was integrated, interesting.

I would prefer the files be externalized anyway still because of doing this remotely, I don’t want to save the toe on a machine that will be overwritten on next sync. I want to extract or swap exr remap files as a calibration file.