11–20 of 31 posts
> On the topic of memory, with millions of particles the server barely breaks over 100mb Although experimental as of now, but use of arena package is a natual fit here.
> Note, 2023-01-17. This proposal is on hold indefinitely due to serious API concerns.
https://github.com/golang/go/issues/51317
Potential successor: https://github.com/golang/go/discussions/70257
Gaffer (Glenn Fiedler, mentioned in the article) would also say, and I quote, "if you use Euler, then you're a bloody idiot" :) This simulation is using Euler integration.
Earlier quoted context omitted.
you should probably read the article then, it's pretty clearly explained
I did and don’t understand why the title is “simulating particles on a smart TV” if that is not what it is doing.
> The challenge, simulate millions of particles in golang, multi-player enabled, cpu only, smart tv compatible.
Usually you wouldn't do that on the server, but if you want performance metrics, it's probably easier to measure on the server than on X clients?
Is this on a smart TV or a server feeding the results to a smart TV? Seems like quite an important difference.
Seriously
My suggestion to the OP talking about compression. First up, consider just PNG compressing the image for simplicity. It's a mostly black image with color dots. That would generally compress really well with PNG. But also, knowing the nature of the image, you could pretty easily compress the image by doing offsets to the next pixel. The format could look roughly something like this [offset byte, color byte, offset byt…
My suggestion to the OP talking about compression. First up, consider just PNG compressing the image for simplicity. It's a mostly black image with color dots. That would generally compress really well with PNG. But also, knowing the nature of the image, you could pretty easily compress the image by doing offsets to the next pixel. The format could look roughly something like this [offset byte, color byte, offset byt…
I did try a large variety of encodings and the best was delta encoding frames followed by RLE encoding similar to what you describe. It did pretty well. However, when things start to move, it only shaved ~10-20% off the size at a significant complexity and compute cost. This was before I allowed each client to have its own frame and it was more common for there to be significant areas of black.
Gaffer (Glenn Fiedler, mentioned in the article) would also say, and I quote, "if you use Euler, then you're a bloody idiot" :) This simulation is using Euler integration.
This uses a simple delta time to smooth updates across frames rather than attempting something more formal. Based on the sister comment I think this is actually Semi-implicit Euler which still makes me an idiot.
Eg, velocity += acceleration * dt; position += velocity * dt;
Although, I add friction in a bad spot so maybe that is what you mean.
My suggestion to the OP talking about compression. First up, consider just PNG compressing the image for simplicity. It's a mostly black image with color dots. That would generally compress really well with PNG. But also, knowing the nature of the image, you could pretty easily compress the image by doing offsets to the next pixel. The format could look roughly something like this [offset byte, color byte, offset byt…
Author here. Surprised to see this show up. I did try a large variety of encodings and the best was delta encoding frames followed by RLE encoding similar to what you describe. It did pretty well. However, when things start to move, it only shaved ~10-20% off the size at a significant complexity and compute cost. This was before I allowed each client to have its own frame and it was more common for there to be signif…
It'd definitely be tricky to get the computational performance that you'd want out of it. I'd imagine it'd be pretty easy to accidentally bust caches.
To solve for that, you could double your frame size and store the prev/next in an alternating fashion. IE [n, p, n, p, n, p] That way when you xor you are always working with highly local memory sets. You'd want to keep the frame basically global to avoid allocating.
If you wanted to be super clever then you could probably SIMD this up doing something like [n, n, n, n, p, p, p, p]. I'm not sure how you'd turn that into RLE in SIMD. I'm not clever enough for that :D (but I'm sure someone has done it).
But as you said, complexity would definitely increase rather than decrease even though you could get much better compute time.