Jump to content

J Montes

Registrados
  • Content Count

    119
  • Joined

  • Last visited

  • Days Won

    12

J Montes last won the day on April 29

J Montes had the most liked content!

Community Reputation

55 Excellent

About J Montes

  • Rank
    Asiduo

Profile Information

  • Especialidad
    Otros

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. De todas formas, el último error no indica ya problemas de codificación. Parece que hay un problema con las opciones de red al abrir el socket... esto podría ser por falta de permisos en Android (quizá te falte algún permiso en el manifest). ¿No dice nada más el log?. Si la conexión que estás haciendo es segura (SSL), aunque no lo parece por la cadena de conexión), podría tratarse de un problema de certificados. El cliente necesita aceptar el certificado del servidor (o de su autoridad certificadora). Creo que veríamos otro error diferente en ese caso. El permiso que necesitas en Android para abrir sockets al exterior es: <uses-permission android:name="android.permission.INTERNET" /> Esto tienes que añadirlo a tu manifest, pero como Unity combina los manifests al generar el proyecto, el sitio donde tienes que ponerlo es uno específico. La documentacion aquí: https://docs.unity3d.com/Manual/android-manifest.html Por otra parte, estaba dando por hecho que lo habrás contemplado pero como dice @francoe1 nunca debes permitir que usuarios ajenos se conecten a tus bases de datos directamente. Si es una aplicación personal, o para una pequeña organización, los usuarios/permisos de MySQL pueden ser suficientes. Pero en términos generales, siempre deberías tener un servicio intermedio que autentique a los usuarios y haga las operaciones en la base de datos.
  2. El último error que pones es diferente (¿sabes leer esas trazas, o "stack dumps"? - es importante). Este error ¿ha cambiado después de añadir las DLLS? sería bueno saber si las DLLs solucionaron el error anterior y ahora estamos viendo otro. El error ahora aparece al llamar a Socket.GetSocketOption, y es una excepción de tipo "Invalid Arguments". Esto sugiere que quizá estabas sin conexión de red, la base de datos estaba caída, o el hostname / ip / puerto están incorrectamente definidos. Como todo esto está dentro del constructor de la conexión, al igual que antes, ahora me surge la duda ahora de si la codificación se establece antes o se negocia con el servidor. Lo último que se me ocurre es que mires también la configuración del servidor MySQL, ya que cada base de datos (o incluso cada tabla y columna) puede tener una codificación diferente. Asegúrate de que tu base de datos es UTF8: select default_character_set_name, schema_name from information_schema.schemata
  3. A ver... pero entonces no necesitas una WebCamTexture yo creo. Primero, no traduzcas cosas como "privado xmgMagicFaceBridge" porque el código no se traduce. Es "private". Y yo preferiría las fuentes en inglés y el enlace, pero ya lo he buscado por ahí. Lo que te están diciendo es que no uses la captura nativa de esta biblioteca (que soporta móviles y/o WebCamTexture en el escritorio). De esta forma, el componente XZIMG deja de gestionar la entrada de video y tendrás que alimentarla tú con imágenes de tu video. Así que tenemos varias partes: 1) sacar imágenes de tu video 2) ponerlas en un formato que XZIMG pueda entender 3) dárselas a XZIMG. 1) No nos has dicho qué formato de video tienes ni cómo lo estás leyendo. Nunca he usado video en Unity pero por lo que veo hay una cosa llamada VideoPlayer que nos permite acceder a las imágenes de cada frame (https://docs.unity3d.com/ScriptReference/Video.VideoPlayer-texture.html), en formato Texture. Al parecer esto en realidad es una RenderTexture y puedes obtener la imagen de ahí así como su dirección de memoria. Observa que tendrás que suscribirte a una serie de eventos para saber cuándo la texture presenta datos nuevos, etc. Hay información imprescindible en: https://stackoverflow.com/questions/42747285/get-current-frame-texture-from-videoplayer . Observa que es costoso hacer esto y que quizá más adelante necesites considerar procesar el video de otra manera y no cada frame con este mecanismo, depende mucho de tu caso de uso. 2) Vamos a suponer que el formato no es un problema por ahora. 3) Te dicen que prepares una imagen para contener los datos que la biblioteca procesará. A mí me surge la duda de si esta biblioteca necesita que se le actualice la imagen cada vez que cambia o hay que pasarle la dirección de memoria y ya "ella se apaña". Como lo segundo sería raro, vamos a suponer lo primero para ir probando. Primero, declara una variable para la imagen que la bibiloteca procesará: private xmgMagicFaceBridge.xmgImage m_image; Después comienza el reconocimiento. xmgMagicFaceBridge.xzimgMagicFaceTrackNonRigidFaces(ref m_image,...) Cada vez que tengas un frame nuevo en el video (lo sabrás por los eventos del VideoPlayer), tendrás que preparar la imagen nueva y dársela a la biblioteca (o quizá cada 2, 3 ó N frames si quieres diezmar la tasa de entrada). En cualquier caso, cada nueva imagen a despachar debes dársela a a XZIMG usando: xmgMagicFaceBridge.PrepareImage(ref m_image, captureWidth, captureHeight, 4, m_myWebCamEngine.m_PixelsHandle.AddrOfPinnedObject()); Aquí, el primer parámetro es la imagen que has creado y es siempre la misma. El ancho y el alto son los del video y te dicen que deben coincidir con los que hayas usado al inicializar la biblioteca (xmgInitParams.m_processingWidth, and xmgInitParams.m_processingHeight). No sé qué significa el 4 y no encuentro la documentación de este método (que sería bastante útil tener). El último parámetro es el quid de la cuestión: entiendo que es la dirección de memoria de los bytes de la imagen y que (por el nombre "pinned") nos sugiere que no deben cambiar durante un rato o incluso hasta que vuelvas a llamar a PrepareImage. Esto creo que descartaría usar directamente la dirección de memoria del RenderTexture, si bien no estoy seguro... Aquí me surgen dudas también. Tendrás que probar a coger los pixels de la RenderTexture y usar la dirección de memoria aquí (que sería el RenderTexture.colorBuffer.GetNativeRenderBufferPtr() ) (https://docs.unity3d.com/ScriptReference/RenderBuffer.GetNativeRenderBufferPtr.html), pero insisto que este buffer quizá cambie concurrentemente. Así que si esto no funcionase bien, supongo que tendrías que copiar la imagen de ese buffer a otra textura y utilizar la dirección de memoria de esa copia en este parámetro. Hay un ejemplo de como copiar efectivamente los pixeles de la RenderTexture en la pregunta de StackOverflow que enlacé más arriba. De todas formas nunca he hecho esto. Ya contarás, ¡ánimo!.
  4. Me ha gustao mucho. La primera fáse me pareció muy difícil perdí mil veces. La segunda tardé un ratin en darme cuenta de la mecánica y tenía un montón de bichos encima (fueron muriendo en cuanto encontŕe a mini y lo sacrifiqué unas pocas veces). La historia y la ambientación geniales. Sonido un poco repetitivo, eso sí, faltaŕia algo de música y más variedad de efectos. Muy bien la historia, me encantó la madre, estaría bien ver a dónde iba eso a parar. Y que el gameplay cambie un poco reaprovechando la mecánica de la linterna, muy bien también.
  5. Buscando el error aparece una referencia en: https://answers.unity.com/questions/42955/codepage-1252-not-supported-works-in-editor-but-no.html?_ga=2.247957831.1540783762.1588396663-1855270041.1569288163 En resumen, la página de códigos usada por ese cliente está en una DLL que no está disponible en el player, pero sí en el editor. Se trata de I18N.dll and I18N.West.dll, y parece que puedes copiarlas a tu proyecto para que se incluyan (mala solución). Alternativamente, utiliza una versión de la bibilioteca cliente de MySQL que esté construida para usar UTF-8 por defecto. Porque en general, me parece mala idea usar como transporte una codificación que no sea UTF-8 (no sé por qué alguien usaría 1252 por defecto hoy en día, igual es la de tu sistema Android o no sé). O alternativamente, y lo que te recomiendo buscar, es asegúrate de usar UTF-8 en tu propio código, así evitarás sorpresas en función del dispositivo en el que te ejecutes. No sé si es posible hacer esto con la biblioteca MySQL que usas, porque tu cadena de conexión ya indica utf8, quizá (a ver si hay suerte) prueba a añadir el punto y coma que falta tras "CharSet=utf8": conString = "Server=server;" + "Database=dataBaseName;" + "User ID=username;" + "Password=password;" + "pooling=false;" + "CharSet=utf8;"; Aunque yo no creo que eso debiera ser el problema. Tampoco me convence ese "pooling" ahí en medio, y según la documentación, (https://dev.mysql.com/doc/connector-net/en/connector-net-connections-string.html) ese "User ID" debería ser simplemente "uid". Tampoco sé si las mayúsculas / minúsculas importan, he encontrado ejemplos en ambos formatos. A ver si te sirve algo. Ya comentarás. Y por curiosidad, ese "databasename", "username" o "password" ¿tienen acentos o caracteres no-ASCII?.
  6. No lo he probado pero no puedes usar: m_webcamTexture.GetPixels32(m_data); Porque GetPixels32(int) pertenece a Texture2D. Usa: m_data = m_webcamTexture.GetPixels32(); Donde m_data debería ser de tipo Color32[] .
  7. Hola. De acuerdo con la documentación, no puedes hacer un "Texture2D.GetPixels32()" sobre una WebCamTexture, ya que ésta hereda de "Texture" y no de "Texture2D". El método a usar es "WebCamTexture.GetPixels()" o "WebCamTexture.GetPixels32()", pero pertenecen a la clase WebCamTexture. Fíjate que la firma del método es diferente, los parámetros formales no incluyen el "mipLevel" (ya que, entiendo yo, la textura generada por la cámara no tiene miplevels, que son diferentes resoluciones de la misma textura usadas durante el rendering). Si sigues con problemas, pega el código que estés usando y dinos qué intentas hacer.
  8. ¡Ole ole! (Parece un buen momento para cambiar la password entonces...)
  9. ¡No! Si haces esto impides a la pipeline de rendering batchear ("dibujar en un único lote") todos esos meshes (subirán tus draw calls), y obligas a la tarjeta gráfica a hacer un cambio de estado innecesario entre meshes (no muy grave, porque no cambias la textura sino sólo su parametrización, pero no sé si Unity es TAN listo y lo importante son las draw calls de todas formas). Lo que se hace es aplicar coordenadas UV en el software de modelado. Con ellas controlas cómo se muestran las texturas en cada cara de tus modelos. Cada vértice tiene unas coordenadas en 2D que indican qué coordenada de la textura se aplica ahí (las llamamos UV). Cada triángulo "sabe" qué porción de textura se le aplica. Las coordenadas UV van de 0 a 1 representando la superficie de la textura, pero si en un vértice pones coordenadas (0, y) y en otro (10.5, y), representas que la textura debe repetirse 10 veces y media en ese eje. De nuevo, esto no se hace a mano, el software de modelado te da herramientas para disponer las texturas a tu antojo (pero es un tostón). Evidentemente tu programa de modelado tendrá que tener la textura configurada con el mismo tiling que luego usarás en el material en Unity (si es que Unity no importa el material, o si lo modificas). Si no, verás una cosa en el modelador y otra en Unity. Configura el material primero en tu programa de modelado, y asigna coordenadas UV adecuadas a cada vértice (suelen tener herramientas para hacer esto). Si lo haces así, al cargar luego el modelo en Unity aparecerá bien texturizado.
  10. Sólo si los hijos no tienen Rigidbody kinemáticos. Cuando no los tienen, el collider del padre es la suma de los colliders de los hijos (fácil de olvidar, Compound Colliders), Si quieres que detecten las colisiones individualmente, tienen que tener sus propios Rigidbody (kinemático, puesto que si no deberías usar Joints supongo). Si necesitas distinguir los OnTrigger (lo recibirán ambos) tendrás que chequear en el código (por ejemplo usando tags, el componente que tienen, o el nombre, o lo que sea). Fuente: https://stackoverflow.com/questions/37991042/do-child-trigger-runs-parent-trigger-also
  11. El mouse es el mouse (o la pantalla táctil). Los ejes de los joysticks (y pueden tener muchos) van numerados igual que los botones. En "Preferences > Input" defines todos los ejes que quieres usar. Duplica los ejes "Horizontal" y "Vertical" (boton derecho > duplicar) y renómbralos a "CameraH" y "CameraV" por ejemplo. Luego cambia el eje que quieras usar. En función del driver de tu joystick, la numeración puede cambiar (por ejemplo, no suele coincidir entre Windows / Linux) así que siempre debes proporcionar un mecanismo para que el usuario defina sus controles. Para un joystick: En type pon "Joystick Axis". En axis el número (serán posiblemente 3 y 4). En joy num pon "Get Motion from all Joysticks". Luego, desde el código, lees el valor como habitualmente usando GetAxis: float cameraH = Input.GetAxis("CameraH"); float cameraV = Input.GetAxis("CameraV"); Ten en cuenta que, si tu joystick tiene conmutador "analógico / digital", verás que la numeración es diferente en función de si ese modo está o no activado. También es peculiar a veces el tratamiento del POV / Pad digital: en algunos drivers, los botones del control digital (izquierda / derecha / arriba / abajo) se ven como dos ejes más (esto es lo normal), pero en algunos joysticks aparecen como botones (es raro, pero avisado quedas). En cualquier caso los joysticks analógicos siempre aparecen como "ejes". Respecto a los ejes del mouse, que por defecto se llaman "Mouse X" y "Mouse Y", si lo miras verás que está configurado como "type Mouse". Una nota: es bastante fácil confundirse al editar estas settings, ya que después de pulsar una tecla a menudo pulsamos otra antes de cambiar el foco. El editor además borra todos los nombres de botones incorrectos. Te recomiendo, tras configurar, revisar la configuración que has puesto.
  12. Buaahh ❤️❤️ Te tupiría a likes si no lo tuvierais desactivado.
UnitySpain © Todos los derechos reservados 2020
×
×
  • Create New...