Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Chaos overhaul #540

Draft
wants to merge 12 commits into
base: ui2
Choose a base branch
from
Draft

Chaos overhaul #540

wants to merge 12 commits into from

Conversation

katestange
Copy link
Member

By submitting this PR, I am indicating to the Numberscope maintainers that I have read and understood the contributing guidelines and that this PR follows those guidelines to the best of my knowledge. I have also read the pull request checklist and followed the instructions therein.


This should eventually resolve #518 #447 #384 #317 #539

Still to do:

  • update snapshots
  • put images in the documentation
  • there's a lag issue (?help?)
  • remove console.logs
  • go through the issues above
  • featured specimens
  • more

@katestange
Copy link
Member Author

Ok, this is far enough along to put in a draft PR. There's still a bunch to do, but I think the code is as readable as it gets for me (heavily based on turtle, which helps), and the thing works in WebGL. You can try it out if you're curious. There's one issue I'm unsure how to resolve, which is reproducible in the following way and appears to be something to do with P5GL.

  1. Open the console so you can see the console.logs
  2. Go to this url: http://localhost:5173/?name=Random+integers+0+to+9&viz=Chaos&corners=3&stepFormula=0.50009&seq=Random&last=10000&length=10001
  3. Wait for it to finish drawing -- it will log "Stopping"
  4. Then (and only then) attempt to drag the image.
  5. You'll see it log "Starting" and then it will hang for a little while. The length of the hang depends on the number of terms in the sequence it has used. After a while it will say "Starting1.5" and continue and then you can zoom and pan to your heart's content.

The catch? There's zero lines of code between console.log("Starting") and console.log("Starting1.5").

@gwhitney
Copy link
Collaborator

gwhitney commented Feb 19, 2025

Some to-do items:

the "label corners of polygon" checkbox does nothing at the moment. Weird, now it seems to be working...

  • Shouldn't the default walker to move be n % W to match the old behavior of W walkers taking turns?
  • The description string for the "Number of Walkers" says "The number w of walkers" with lower case w, but in formulas right now you have to use upper-case W to get the number of walkers. There should be consistency one way or the other.

@gwhitney
Copy link
Collaborator

2. Wait for it to finish drawing -- it will log "Stopping"

I attempted to check this issue out for you, but I never observed "Stopping" in my console, so is perhaps something else awry?

@gwhitney
Copy link
Collaborator

  1. Wait for it to finish drawing -- it will log "Stopping"

I attempted to check this issue out for you, but I never observed "Stopping" in my console, so is perhaps something else awry?

Oh, I see you commented out most of the code in that stopping section, including the console.log of "Stopping". I am observing the lag on the initial drag. But there's a lot of chatter in the console, and the console doesn't seem to be telling me much about where in the code it's freezing up. In particular, sometimes I see a last line of "Starting" while I am waiting for the lockup to end, but other times the last line is "end drawing loop 10001". And if I add a console.log of "Starting1.7" after "1.5", it seems to change the distribution of what I see. So I expect we're seeing variations in async scheduling and execution. So I am really not sure what we're waiting on before that first drag starts... But I don't think it's particularly happening at that spot in the code between Starting and Starting1.5.

@gwhitney
Copy link
Collaborator

I am not at all sure I have gotten to the bottom of this, but it seems to me that the first time that Chaos needs to execute a model() command on a given chunk, it incurs some processing time penalty -- maybe this is loading geometry information to the GPU?? -- and that penalty depends on the complexity of what is in that geometry object. I am going to push a commit, that we may want to revert mostly or completely later, that (a) reduces the chunk size to 256; (b) draws squares instead of round dots, because I am assuming they have significantly fewer vertices; and (c) every time a chunk is added, voluntarily redraws the whole thing so it has now used that chunk at least once -- the idea there is to spread out the instants at which a chunk is first used, instead of, on that first drag at the end, drawing every chunk for the first time. With these changes, I think the lag is greatly reduced -- I won't say it's gone. You can give it a whirl and see what you think, and whether you want to investigate more/more deeply, or whether you want to just go ahead with something along these lines.

I don't think the above observations really explain why Chaos seems much harder on my poor computer than Turtle, though -- and I don't think we do anything in Turtle to avoid all of the chunks being used for the first time on the first drag. Those deficiencies are a big part of why I don't think I've really gotten to the bottom of this whole thing...

If you decide to abandon pan, roll, and zoom, I wouldn't cry -- they are regular polygons anyway, so rotating is not too helpful and you can just make the vertices as spread out as possible so the image won't go off the canvas. But having made the switch to WebGL, if you want to keep it that way I am OK with it, too.

@gwhitney
Copy link
Collaborator

I was glad to see that it Just Worked to take the sierpinski triangle gallery specimen and set the step formula to 1.5 -- produces a very nice picture. Not certain whether or not steps over 1 worked before.

@gwhitney
Copy link
Collaborator

I was glad to see that it Just Worked to take the sierpinski triangle gallery specimen and set the step formula to 1.5 -- produces a very nice picture. Not certain whether or not steps over 1 worked before.

Along those lines, this makes a pretty picture: http://localhost:5173/?name=Chaos+Game&viz=Chaos&corners=3&stepFormula=max%281.7-.0001n%2C+0.5%29&seq=Random&max=2&last=13999&length=14000

The length here is chosen so that it doesn't run too long with the "standard" step value of 0.5.

@gwhitney
Copy link
Collaborator

I think in light of #541 we should just move ahead with this for alpha with an "all-formula" interface, and then after alpha, split it into its operational "pre-visualizer" and a skin that restores some of the options that have been blown away (but which behavior can be reproduced with the proper formulas), like the different coloring schemes. Question: do we need to document what options we want to restore other than via looking at the git history?

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