Skip to content

feat: add options for brownian_tree - #3

Open
vmobilis wants to merge 11 commits into
wbruna:sd_brownian_treefrom
vmobilis:patch-1
Open

feat: add options for brownian_tree#3
vmobilis wants to merge 11 commits into
wbruna:sd_brownian_treefrom
vmobilis:patch-1

Conversation

@vmobilis

Copy link
Copy Markdown

Addition for leejet#1899.

@wbruna

wbruna commented Sep 12, 2026

Copy link
Copy Markdown
Owner

UI-wise, I believe turning it into a decoupled, specific property would be better: say, "brownian_tree_rng=cpu" instead of "brownian_tree_cpu". Then, we could consider if having a "brownian_tree_rng" implies turning on "brownian_tree". Either way sounds fine to me, so it'd be up to leejet.

Code-wise, the name -> subclass mapping is replicating StableDiffusionGGML::get_rng functionality; we should probably have instead a virtual constructor somewhere (src/core/rng.hpp would be natural for the declaration, but would need to be implemented elsewhere to avoid running into a chicken-and-egg issue with the hierarchy; so probably util.h would be a better place), and convert the name first with str_to_rng_type.

About the functionality itself... to be honest, I'm not sure what would be the best approach. Note that the BrownianTreeNoiseSampler::bridge member also creates an internal generator, and is recursive 🙂 I would suggest just either passing the secondary rng type to the Brownian tree constructor, and let it do its own thing as it is right now, or (as fszontagh suggested) add a virtual clone() to the rng class and duplicate the original generator edit: I see you are already copying the generator, so it'd be enough to copy the main one on bridge as well..

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants