Creating an Android application. Personalization
I want to share with you my small initiative in the arena of Android-development and talk a little about the interesting points of implementation.
Long thought and decided to start my journey with personalization and live wallpaper. I agree that this area is rather limited in comparison with, say, games, but at the same time it leaves the authors the opportunity to demonstrate some idea to the user. I wanted to do, first of all, something interesting from the point of view of programming, well, not quite normal.
It turned out the following:
')
The simulation, rendering, and part of the interface are written in C ++.
The simulation is based on the particle system and dynamics described in the Particle-based Viscoelastic Fluid Simulation article. The algorithm is slightly simplified and implemented for the two-dimensional case. Based on the fact that the whole system is built on the interaction of a particle with its environment, the most important part is the search mechanism for this environment. Consider this search in more detail.
So, at the entrance, we have an array of particles somehow distributed in space. Our goal is for each particle to iterate over all neighboring particles located at some fixed distance R.
To avoid complete enumeration, we divide the space into cells of the same size. This will make it possible to search for potential neighbors not among all particles, but only among those that belong to adjacent cells. Cell size is a multiple of the distance R.
Next, we sort our array by cells using the Counting sort . In addition to speed, sorting by counting gives us a set of partial sums (for each cell we will know the number of particles located in the previous ones).
Now, in order to iterate over all potential neighbors, we need to sequentially read the required intervals (the amount depends on the initial choice of the cell size) in the array. Offsets to the desired elements are calculated trivially on the basis of partial sums obtained in the sorting process. In our example, these are half-intervals: [0, 3), [4, 9), [11, 14), for a cell size that coincides with the distance R.
After sorting, following the dynamics from the article mentioned above, the positions of all particles are updated. Updated data is sent for rendering. As for the number of particles participating in the simulation, there are few of them, only 1000 at the maximum quality level.
Based on OpenGL ES 2.0. It consists of 9 passes (2x vertical / horizontal blues).
The presence of a native interface was dictated by necessity. The fact is that live wallpapers can be displayed in two modes
With the first mode, everything is fine, but in the preview mode, the activity does not behave in a standard way. In this mode, when overlapping, the update cycle and rendering of live wallpaper stops. And no matter what we overlap (I could not find a reasonable explanation for this behavior). As a result, the use of translucent android dialogs for setting will not allow us to preserve the necessary interactivity.
I will be glad to your comments and feedback. Thank!
Long thought and decided to start my journey with personalization and live wallpaper. I agree that this area is rather limited in comparison with, say, games, but at the same time it leaves the authors the opportunity to demonstrate some idea to the user. I wanted to do, first of all, something interesting from the point of view of programming, well, not quite normal.
It turned out the following:
')
Little about implementation
The simulation, rendering, and part of the interface are written in C ++.
The simulation is based on the particle system and dynamics described in the Particle-based Viscoelastic Fluid Simulation article. The algorithm is slightly simplified and implemented for the two-dimensional case. Based on the fact that the whole system is built on the interaction of a particle with its environment, the most important part is the search mechanism for this environment. Consider this search in more detail.
So, at the entrance, we have an array of particles somehow distributed in space. Our goal is for each particle to iterate over all neighboring particles located at some fixed distance R.
To avoid complete enumeration, we divide the space into cells of the same size. This will make it possible to search for potential neighbors not among all particles, but only among those that belong to adjacent cells. Cell size is a multiple of the distance R.
Next, we sort our array by cells using the Counting sort . In addition to speed, sorting by counting gives us a set of partial sums (for each cell we will know the number of particles located in the previous ones).
Now, in order to iterate over all potential neighbors, we need to sequentially read the required intervals (the amount depends on the initial choice of the cell size) in the array. Offsets to the desired elements are calculated trivially on the basis of partial sums obtained in the sorting process. In our example, these are half-intervals: [0, 3), [4, 9), [11, 14), for a cell size that coincides with the distance R.
After sorting, following the dynamics from the article mentioned above, the positions of all particles are updated. Updated data is sent for rendering. As for the number of particles participating in the simulation, there are few of them, only 1000 at the maximum quality level.
Rendering
Based on OpenGL ES 2.0. It consists of 9 passes (2x vertical / horizontal blues).
- In a separate texture (smaller in size than the screen resolution, the size is determined by the quality settings) with sprites we draw all the particles:Result
- Blur with a large ratio:Result
- Cut the unnecessary (based on intensity) and form the surface:Result
- Blur with a small coefficient;
- Blur with a small coefficient. In one pass, it was not possible to achieve the desired effect without the appearance of artifacts:Result
- With the last pass we draw the surface along with the background. Also, based on the intensity, the normals are calculated.
- Refraction:Result
- Inside and outside shadows:Result
- Mixing:Result
- Lighting:Result
- Refraction:
Interface
The presence of a native interface was dictated by necessity. The fact is that live wallpapers can be displayed in two modes
- Home or / and Lock Screen;
- Preview;
With the first mode, everything is fine, but in the preview mode, the activity does not behave in a standard way. In this mode, when overlapping, the update cycle and rendering of live wallpaper stops. And no matter what we overlap (I could not find a reasonable explanation for this behavior). As a result, the use of translucent android dialogs for setting will not allow us to preserve the necessary interactivity.
I will be glad to your comments and feedback. Thank!
Source: https://habr.com/ru/post/276431/
All Articles