Precomputing and storing render-information efficiently

[pk274]

Hello,
I recently started using SFML for my university-project and I'm very happy with it.
I'm working on a two dimensional simulation that uses a lot of particles.

Since the computation of the particles' positions can take a lot of time and therefore my simulation does not run smoothly in real time for a high amount of particles, I need the simulation to be able to precomute all the particles' positions and then, after several hours of parsing, show me a video of the simulation result.

Currently in the precomutation phase I store the particles' positions and then, when I want to watch the result, this information gets read and images are then drawn and displayed in real time.

I am pretty sure that this is one of the dumbest ways to do this, but I also could not find many resources for how to improve on it, so I thought I might as well ask here. Thanks in advance for your help

Bonus points for methods that are rather simple, I absolutely dont get graded for the performance of the rendering, so I dont want to spend an excessive amount of energy on it, but I'd still at least want to know what would be the proper way to do it and implement it if possible.

[eXpl0it3r]

I guess it depends a bit what result you need/want.

In theory you could just do all the calculations, which seems to be the expensive part, save that in memory, or even allow it to export, so you could reuse it later.
Then "play back" the information in real-time. So effectively you end up with two separate components, one that does the computation and one that does the displaying.
The same method could also be used to dump the information as images to disk, from which you can then create a video (e.g. with ffmpeg).

Alternatively, you could also dump the images in "real-time" as in, whenever the next frame is ready.

What's not clear to me, is whether the rendering performance drops due to the amount of particles, or whether it's really the calculation that slows down the rendering. For the former part, there might also be rendering optimization that could be done. For the later, you'd have to find more efficient calculations, e.g. with a proper math library.

[pk274]

Thanks for the quick answer.

If I do it in real time, the performance drops because of the calculations, which is why I implemented a way to do the calculations first, export the positions. Later when I want to view the results, these positions are read and images are created from them in real time. I think this is what you refered to as playing back the information. Sadly (I think it's the reading process, not the rendering itself), for large amounts of particles, this method of rendering too gets pretty slow, as for every update several thousands of positions have to be read and drawn. So I think I'm looking for the second strategy you mentioned, which involves exporting images in the process.
So my SFML-related question would be "Is there a way to create a video from the frames my program creates within SFML or, if not, can you recommend a compatible library for that?".
Your previous answer hinted at ffmpeg for that, is that it?
Or of course if you have a good idea to optimize the procedure which I described above, I'm also grateful for any suggestions.
Thanks

[eXpl0it3r]

Reading from disk is extremely slow, as such you could consider loading everything into memory at the start, then you can be sure you won't have slow disk reading speeds. More complex methods of threads and buffers I recommend if you do have sufficient experience with multi-thread programming.

SFML doesn't have anything video related, so if you want to encode a video, you'll need some other software, such as ffmpeg.
SFML can then just render one image at a time to disk and ffmpeg can take these series of images and turn them into a video.

[pk274]

Alright, I'll look into both options, thanks a lot

[Garwin]

How do you create and store these particles? What container do you use?
It seems to me quite strange that for just several thousand of particles, it is slow.

With 60 FPS you have about 17 ms for one frame so updating 10,000 particles one by one means about a little more than 1 microsecond for updating one particle - this is quite a huge time for that if particles are stored in the contiguous memory block.

[pk274]

I'm doing a fluid simulation where I iteratively have to find all neighbors of each particle (done with spatial hashing) and solve a system of equations to calculate the pressure per update. So while there certainly is a lot of room for minor improvements, the general order of magnitude of my calculations' speed is about what is expected.
I'm using std::vector as a container for the particles and move a single shape around the screen and draw it repeatedly for rendering. But the actual update of the values and rendering are negligible compared to the neighborhood search and pressure computation when computing in real time.
When computing beforehand though I'm now certain that the bottle neck is reading the stored particle-positions from disk to then draw them. Therefore the advice which eXpl0it3r gave hits the target pretty well.
I am of course grateful for any additional advice concerning optimization of these kinds of simulations.

[Hapax]

Pre-calculations are common in animation, especially with complex calculations such as simulations, and it's known as "baking" the animation. This means the simulation runs once and the actual animation is then just a set of recalled values, which is exactly what is happening here.

It does seem that reading values from a disk will be the problem here, especially if you're reading them in real time. Of course, it'd be fine to "bake" them disk, then read them all into memory at once when ready to animate and then use the values from memory.

Just as an aside, since you're happy with the speed of simulation calculations already, but make sure you're reserving that vector (or just resizing it to its full size in advance and then accessing the already created items) so that it doesn't have to constantly relocate everything.