Il y a eu un cas où je voulais transmettre les informations de pixel d'une image de texture telle que RenderTexture de Unity de manière native, donc j'ai eu beaucoup de problèmes (surtout du côté Android), alors prenez note. Au fait, Android baise. Je veux que vous disparaissiez rapidement. Pour être plus précis, il s'agit d'un cas où vous souhaitez transmettre les données d'image à une bibliothèque Java à l'aide de WebCamera côté Unity.
Cliquez ici pour un exemple de projet https://bitbucket.org/HoshiyamaTakaaki/pixelreadstest
Tout d'abord, l'implémentation côté Unity
CameraOnPost.cs
RenderTexture.active = m_TargetTexture;
m_TargetTexture2D.ReadPixels(new Rect(0, 0, m_TargetTexture.width, m_TargetTexture.height), 0, 0);
m_TargetTexture2D.Apply();
var col = m_TargetTexture2D.GetPixels32();
var handle = default(GCHandle);
try
{
handle = GCHandle.Alloc(col, GCHandleType.Pinned);
var ptr = handle.AddrOfPinnedObject();
libglutil_SetPixels(ptr.ToInt32(), m_TargetTexture.width, m_TargetTexture.height);
}
finally
{
if (handle != default(GCHandle))
handle.Free();
}
Du côté de l'iPhone, GetPixels32 d'Unity est raisonnablement rapide, donc je pense qu'il est normal d'obtenir les informations de couleur normalement du côté Unity et de passer le pointeur du côté natif. Dans le cas de RenderTexture, il est nécessaire de le déplacer une fois vers Texture2D, et il peut être nécessaire d'être prudent car cette zone devient une surcharge.
CameraOnPost.cs
m_NativePlugin.CallStatic("sendRgbaFrame", m_Context, m_TargetTexture.GetNativeTexturePtr().ToInt32(), m_TargetTexture.width, m_TargetTexture.height);
GL.InvalidateState();
Malheureusement, Android ne fonctionne pas bien avec les ReadPixels d'Unity. Et la livraison d'octet [] à Java est très lourde. C'est trop lourd à utiliser à ce stade. Ainsi, sur Android, la texture est transmise à Java telle quelle et ReadPixels est effectué du côté Java. En passant, vous pouvez passer la main à NDK si vous le faites comme vous l'avez fait sur iPhone. Il semble qu'il soit plus rapide de transférer un grand tableau d'octets vers Java via C # → NDK → JNI.
Du côté Java, utilisez la texture que vous avez reçue, dessinez la texture dans le frame buffer avec OpenGL ES et lisez-la avec glReadPixels. Mais les glReadPixels d'Android sont très lourds. C'est lourd après tout. L'utilisation de PBO (Pixel Buffer Object) le rend un peu plus rapide (et parfois plus lent), mais il reste lourd. De plus, PBO nécessite OpenGL ES3.0, et il n'est pas complet en Java, donc il marche dessus et donne des coups de pied. (Vous devez augmenter l'API SDK minimale à 24 pour terminer Java. Pouvez-vous l'augmenter ou stupide)
Afin de sauvegarder les informations RGBA acquises dans MP4, etc., il est nécessaire de les convertir davantage en YUV, et à ce stade, il est inévitable qu'il soit dans un état saccadé.
Cela peut ne pas être très utile pour le travail acharné, mais l'ajustement de la taille de RenderTexture améliorera les performances dans une certaine mesure.
De plus, Android a eu beaucoup de problèmes. J'ai également eu du mal à trouver un moyen d'inclure d'autres créés ainsi dans aar. Lorsque la version 64 bits du fichier so a été incluse, il a fallu beaucoup de temps pour résoudre le problème d'apparition d'une fenêtre contextuelle et de se terminer au moment où l'application créée avec Unity a été démarrée.
En créant cet échantillon, j'ai emprunté beaucoup d'informations à nos prédécesseurs. Et j'ai vu beaucoup de questions (cadavres) sans réponses. Tout le monde a des problèmes avec Android.
Merci beaucoup.
Recommended Posts