Godot: Godot lento para abrir, lento para editar, lento para iniciar un juego simple [Windows, causado por periféricos USB específicos]

NVIDIA, ¿eh? Creo que hubo informes de lanzamientos lentos en NVIDIA, podría intentar buscar "NVIDIA" en los problemas. El consenso final fue que hay un error de controlador.

nVidia GeForce GTX 1060 6GB / PCIe / SSE2 aquí, Godot 3.0.6 se abre bien para mí (versión del sitio web no mono). Sé que Godot es un poco más lento en algunos casos con nVidia debido a los malos modos de rendimiento automático, pero no tan lento (como en el lanzamiento de 30 segundos en lugar de 4).

GTX 960 y 1070 informan con los mismos problemas. Lanzamiento lento en Windows, rápido en Linux.
Realmente desearía que esto pudiera solucionarse, ya que es mi mayor problema con Godot. Me gusta lanzar mi juego todo el tiempo para probar pequeños ajustes, pero toma demasiado tiempo en Windows con mis GPU nvidia.

Uniéndose al problema con una GTX 1070. Probé todas las versiones estables de Godot. También probé en 3 versiones del último controlador 398.98, 398.82, 398.36. Pero noté que la primera vez (después de reinstalar el controlador, reiniciar la computadora) se inició rápidamente. Jugaré con algunas configuraciones de Nvidia cuando encuentre el tiempo. Este es un gran problema y debería investigarse un poco más.

Editar: Volveré a confirmar que el primer inicio después de un reinicio del sistema funciona normalmente. Cada inicio posterior lleva mucho tiempo (40 s).

https://www.nvidia.co.kr/Download/driverResults.aspx/137317/en
Se libera el controlador 399.07.
¿Probarías con él?

Hola volzhs, ¡sí, eso parece haberlo solucionado!
Todavía no he tenido tiempo de hacer pruebas exhaustivas, pero solo abrí / edité / ejecuté algunos juegos y el rendimiento fue excelente.
Gracias por avisarnos del último controlador.

No sé cómo afecta, pero la nota de la versión del controlador contiene esto.

[GeForce GTX 1050/1070]: el controlador OpenGL no libera el contexto de renderizado
correctamente. [2305430]

Gran hallazgo @volzhs , gracias :)

@fossegutten @cimpresovec ¿La actualización a 399.07 también soluciona el problema de sus tarjetas?

De hecho, recientemente hice un formateo completo de mi PC y el problema desapareció con el mismo controlador (398.98). Probé el nuevo controlador hoy y el problema no ocurrió. Entonces no sé qué decir. El mismo controlador antes y después del formato pero con un comportamiento diferente. No puedo decir qué causó el problema en la instalación anterior, pero me disuadió de usar Godot.

Desafortunadamente, esto ha comenzado a sucederme nuevamente. Godot funciona bien durante aproximadamente 1 hora, luego comienza a funcionar lento nuevamente.

Lo realmente extraño es que si reinicio mi PC, Godot vuelve a funcionar bien por un tiempo, pero luego comienza a ir lento.
Sin embargo, ahora estoy bastante seguro de que no es un problema de Godot. Podría intentar conseguir una tarjeta AMD y ver si eso elimina el problema para siempre.

GTX750 aquí; Pensé que tenía algo que ver con https://github.com/godotengine/godot/issues/21472#issuecomment -416151678 no construyendo con sse2, ya que era nuevo en la construcción, pero este problema parece haber empeorado con el las últimas semanas, con 3.1a1 teniendo los tiempos de carga más largos hasta ahora.

Actualmente estoy ejecutando el controlador 399.07.

Editar: ¿Quizás no sea un problema de GPU? Se notó un uso de CPU extremadamente alto y un uso bajo de GPU durante estos tiempos de carga lentos. Tomando alrededor del 27% de CPU (la asignación de un subproceso de hardware completo en mi CPU), cae a niveles normales una vez que finaliza la carga.

Edit2: No relacionado con este problema, he presentado otro problema.

Perdón por la respuesta tardía. Sigue siendo muy lento, con el controlador 399.24 en GTX 1070 gpu.

El problema ha vuelto para mí. Bueno, lo noté al desarrollar alguna otra aplicación con la biblioteca Raylib (usa GLFW debajo). La aplicación mostró el mismo comportamiento que Godot. Luego descargué Godot y el problema volvió. Me di cuenta de que después de reiniciar el sistema, todo funciona normalmente, incluso después de varias ejecuciones independientes. El problema comienza a ocurrir después de un tiempo (no se probó) o después de ejecutar algunos juegos más pesados ​​en el sistema y luego intentar ejecutar Godot. Unity, por otro lado, no se ve afectado, pero no he probado Defold.

¿Qué podrían tener GLFW y Godot en común?

Ambos usan OpenGL debajo del capó. Al igual que algunos otros programas que mencioné que no presentan el problema.

El problema parece ser Open GL, sí. Monogame tiene el mismo comportamiento con los proyectos OpenGL, pero no con los proyectos Direct X.

Hmm, si el problema existe para todas las cosas de OpenGL, entonces probablemente sean controladores de GPU malos.

El comportamiento no es consistente en diferentes aplicaciones OpenGL. Algunos funcionan bien (compilaciones Unity OpenGL, motor Defold, etc.). Probablemente dependa de la versión utilizada, pero eso es solo pura especulación. Lamentablemente, no puedo dar ninguna ayuda concreta.

mismo problema aquí, algún consejo?

Mi tiempo de inicio no está en el rango de más de 30 segundos, sino entre 5 y 10 segundos. Definitivamente es más lento de lo que debería ser. Intenté esto con un ejecutable exportado y en el motor. También ocurre con GLES3 y GLES2.

Estoy usando una GTX 1080 en el controlador 416.16
Actualizaré el controlador momentáneamente y regresaré con una nota sobre cualquier cambio.

Editar: el problema persiste con el controlador 416.34 y (posiblemente no relacionado) parece un poco lento iniciar Godot, así como abrir un proyecto.

Estoy en Linux y estaba ejecutando controladores NVIDIA 390.87. Realmente parecía que se estaba ejecutando en la renderización de software debido al alto uso de la CPU durante el desplazamiento, por ejemplo.
Instalé los controladores de NVIDIA 410.73 y todo está bien ahora. No sé si NVIDIA resolvió este problema o simplemente reinstaló los controladores.

También probé en Linux, y Godot parece funcionar muy bien. Todavía es lento en Windows.

También probé en Linux, y Godot parece funcionar muy bien. Todavía es lento en Windows.

¿Qué versión de Linux estás usando? ¿Y lo estás usando en una VM?

Arch Linux. Sin VM.

Aquí en @JavaryGames estamos experimentando esto con todas las computadoras, algunas con 1050Ti y otras con 1060. Incluso con el controlador más reciente (417).

En Linux, las mismas máquinas funcionan bien, por lo que es muy probable que sea un problema de controladores.

Creo que podría estar experimentando este problema también en Windows 10 godot 3.0.6

Aunque tengo un AMD RX 580

Añadiendo mis propios puntos de datos:

CPU Intel i7-3770K
16 GB de RAM
Windows 7

1. Este problema es con 3.06-stable_win64 y 3.1-alpha5_win64. Se tarda entre 30 segundos y 1 minuto en cargar el motor o reproducir una escena.
2. Esto se puede corregir reiniciando la computadora, pero siempre regresa después de que se reproduzcan varias escenas. Puede estar relacionado con choques de motor / escena.
3. Este problema ocurre en cualquier momento [una vez que comienza después de un breve reinicio 'cura'] la ventana del editor de Godot Engine (con salida de terminal) en cualquier momento que aparezca "OpenGL ES [X] .0 Renderer". Entonces, cuando se inicia el ejecutable y cuando se ejecuta una escena.
4. Esto no depende del controlador ni de la GPU. Usé una RX480 con controladores actualizados y una GTX 1070 con controladores actualizados. El problema no cambió. Si esto

Tener esto también en una Nvidia GTX 1070

Solo Windows, se abre y funciona bien en Linux.

Tengo el mismo problema, pero en Linux con una GPU AMD. Estoy teniendo dificultades para rastrearlo, ya que esto comenzó a suceder después de una actualización del sistema, pero la degradación no lo solucionó. degradar a Godot tampoco tuvo ningún efecto. se necesitan más de 30 segundos para abrir mi proyecto, más de 30 segundos para iniciarlo, y tartamudea (a veces se congela por un tiempo) cada vez que se muestra un nuevo objeto en la pantalla por primera vez. en el editor, las cosas básicas como hacer clic en un nodo o abrir una escena suelen tardar más de 30 segundos.

cuando las cosas están congeladas, el sonido aún se reproduce, godot usa el 100% de la CPU en un núcleo, y ni godot ni dmesg muestran un solo error. Al principio pensé que podría deberse a la compilación de sombreadores, y aunque usar el editor de sombreadores y dejar que se compile puede causar una congelación de 30 segundos, no parece hacerlo después de la primera vez que sucede.

en mi caso, parece algo aleatorio, ya sea con un tartamudeo de 10 cuadros o más de 30 segundos sin intermedio. casi siempre desaparece después de que se carga una cosa, pero este comportamiento se restablece cuando godot se cierra / vuelve a abrir, un reinicio no lo afecta.

¿Es su Linux Mint o Arch por casualidad?

@retrotails Suena como # 24783.

@retrotails Suena como # 24783.

oh gracias, lo parece. Solo tengo 18.2 en caché, y todavía ocurre en 18.2 pero mucho menos severo. intentar compilar la última mesa y ver si al menos está arreglado allí.

Para aquellos afectados por este problema: ¿pueden probar Godot 3.1 beta 2 (o posterior) y ver si todavía se comporta igual?

Las pruebas iniciales indican que 3.1 beta 2 me ha solucionado el problema. Actualizaré si comienza a funcionar lento nuevamente. Gracias por solucionar esto.

No, 3.1 beta 2 todavía tiene problemas intermitentes en mi gtx 1070. A veces es rápido, otras veces es inaceptablemente lento. Tenga en cuenta que no tengo problemas en mi computadora portátil p52 que también ejecuta Windows, con una tarjeta quadro p2000.

Hola,
mismo problema aquí:
Inicio de Windows 10 x64
CPU: AMD Ryzen 5 2600X
gpu: AMD Rx580

Después de un nuevo inicio de la computadora, Godot tardará 30/40 segundos en abrir, cargar o ejecutar un proyecto ...
No importa la versión de Godot (2.x, 3.0.x, 3.1 alpha x o beta x)
Después de reiniciar la computadora, todo funciona bien, por lo que puedo decir

Intenté deshabilitar el inicio rápido / arranque en Windows, pero el problema no se solucionó.
Estoy realmente confundido ya que todo estuvo bien hace algunos días / semanas ...

Sin embargo, estoy bastante seguro de que no es directamente un problema de Godot. Noté, por ejemplo, que el cliente STEAM tiene el mismo comportamiento que Godot (y algunos juegos no se ejecutan en absoluto) cuando ocurre el problema.

Yo otra vez:

CPU Intel i7-3770K
16 GB de RAM
Windows 7

Ahora en 3.1 Beta 2, los intervalos de ~ 30 segundos comienzan inmediatamente, sin el período normal de luna de miel después de un reinicio en el que las cosas van bien.

Hola, _ [Godot v3.0.6 - WIN 10 - GTX 1060 3GB - 16GB RAM DDR3 - Intel i5-4460] _

El mismo problema aquí, pero sin fallas de Nvidia o comentarios en la consola.

El administrador del proyecto tarda mucho en abrirse cuando hago clic en editar lo mismo, y si tengo suerte, apenas puedo ingresar al editor, donde se necesitan años para hacer clic en reproducir y esperar que funcione correctamente.

En el Administrador de tareas, descubro que Godot está usando <1% de mi CPU y lo mismo con la RAM. No es mi computadora porque a veces funciona como se esperaba, todo fluido y, a veces, aparece este problema.

También tengo problemas con el gerente del proyecto al intentar cargar un png para mostrarlo como un ícono, e hice que mi Godot se volviera lento.

Pregunta completamente no relacionada, ¿alguno de ustedes que tiene este problema en Windows ejecuta algún tipo de software antivirus / antimalware? Quizás algo esté escaneando el binario cuando se ejecuta.

Aquí hay otras cosas que pueden probar, tal vez esto esté relacionado con la caché de OpenGL, NVidia almacena esto aquí:
C: \ Usuarios \\ AppData \ Local \ NVIDIA \ GLCache

Si elimina los archivos aquí, ¿aún puede reproducir el problema?

Finalmente, algo más que encontré en los foros de nvidia, ¿puedes intentar ejecutar Godot manualmente mientras configuras esta variable de entorno? me gusta:

__GL_SHADER_DISK_CACHE_SKIP_CLEANUP=1
godot.exe

reduz: Lo intenté. No cambió nada.

@ ay200 ¿Tienes nvidia?

@reduz Sí, 1070GTX.

También tuve una apertura muy lenta, pero solucioné esto eliminando el archivo: %appdata%/Godot/editor_settings-3.tres era realmente grande (~ 100 MB o más, no lo recuerdo). Quizás ayude.

Tuve el mismo problema, y ​​finalmente lo tuve en Configuración del proyecto -> Depurar -> Configuración -> "Forzar FPS" establecido en 1 :) Establecerlo en 0 solucionó el problema. Solo publico aquí, porque este es el primer enlace con retraso encontrado.

Lo siento chicos, tengo la sensación de que este problema se ha convertido en una ensalada de diferentes problemas.

Archivo de configuración grande:

Si alguno de ustedes se ve afectado por la lentitud de abrir PROJECT MANAGER AND EDITOR y por casualidad su
% appdata% / Godot / editor_settings-3.tres es enorme, POR FAVOR ENVIÉRELO Y ENVIARLO para que podamos saber por qué este archivo es enorme. Si esto por alguna razón contiene información privada, edítelo primero para eliminarlo (aunque realmente no creo que se guarde para tal vez rutas a sus proyectos).

Lento para iniciar el juego

Si tu JUEGO tarda en iniciarse, pero el director del proyecto y el editor están bien. Describa su hardware, incluido el sistema operativo, la GPU y la versión del controlador.

Lento para iniciar el juego

Si tu JUEGO tarda en iniciarse, pero el director del proyecto y el editor están bien. Describa su hardware, incluido el sistema operativo, la GPU y la versión del controlador.

Según el similar # 23986, parece estar arreglado en el último controlador de Nvidia (419.17 en Windows 10). ¿Pueden algunos de ustedes confirmar eso?

Tengo este mismo problema.

Toma ~ 41 segundos para el lanzamiento inicial, el proyecto de apertura y la ejecución (cronometré cada uno individualmente y todos estaban dentro de 1 segundo entre sí).
Reiniciar lo solucionó.

Probé v3.0.6 tanto no mono como mono y el mismo problema con ambos. Esto también es con el proyecto tutorial súper básico "creación de instancias".

Especificaciones:
Windows 10 (64 bits)
AMD Radeon HD 6700 (v15.201.1151.1008)
16 GB de RAM

EDITAR: Estoy empezando a usar la versión 3.1 beta y parece haberlo solucionado, pero el tiempo lo dirá. Actualizaré esto si vuelve.

Acabo de tener este problema de la nada ahora ... luego recordé que acabo de actualizar mis controladores de NVidia y olvidé deshabilitar la telemetría ( https://github.com/NateShoffner/Disable-Nvidia-Telemetry ) después de hacer eso y reiniciar, Godot comenzó bien. Eso es muy interesante realmente ... (Windows 10 x64 v1809)

¿Alguien intentó esto tal vez? Creo que tiene algo que ver con estas cosas de telemetría. También estoy usando los últimos controladores de Nvidia:

Todavía tengo el mismo problema.

Se tarda mucho en lanzar inicialmente y luego en abrir el proyecto. La única vez que funcionó bien fue cuando descargué Godot por primera vez, pero una vez que comienza el problema de los tiempos de carga largos, no hay forma de que vuelva a funcionar.

Ocurre tanto en Godot v3.1 como en v3.1.1 (ambos no mono)

Probé todas las sugerencias aquí y no ayuda.

Especificaciones:
Windows 10 (64 bits)
Nvidia RTX 2070 (v430.39)
16 GB de RAM

Seguir la sugerencia de teihoo al deshabilitar la telemetría hace que funcione después de reiniciar. Pero una vez que reinicia de nuevo, vuelve a ser lento. Volver a habilitar la telemetría y luego deshabilitarla no resuelve el problema nuevamente. Hice una instalación limpia de mi controlador Nvidia v430.39 y hace lo mismo funcionando una vez después del reinicio, pero luego no funciona después del segundo reinicio. Cambié al controlador del creador de Nvidia en lugar del controlador listo para el juego y el problema persiste. Probé la versión de Steam solo para asegurarme y el problema sigue presente. Realmente espero que este problema se pueda solucionar.

Me pregunto por qué se ha cambiado el título del número ... Dado que parece no ser un problema exclusivo de Nvidia.

El problema sigue ahí para mí (AMD RX580 - Versión de configuración de Radeon: 2019.0326.2353.42986 - Versión de OpenGL: 25.20.15000.13547 - Versión de API de OpenGL: 4.6)

El problema todavía está presente para mí. Ahora en Nvidia Driver v430.64. Sigue sin funcionar.

Definitivamente un problema de OpenGL y no específico de Godot, o Nvidia o AMD para el caso. Incluso un proyecto de MonoGame en blanco tarda mucho en abrirse.

¡Hola!
Todo estaba funcionando bien y luego actualicé mis controladores nvidia a 430.64.

Desde entonces, cuando lanzo el juego a través de F5 / F6, es muy lento para comenzar (casi un minuto).

Aquí está mi configuración:
Windows 10 Pro de 64 bits
16go DDR4
Geforce GTX1060 de 6 Gb
Ejecutando en un SSD

Necesito ejecutar un arranque dual con Ubuntu solo para trabajar con Godot de manera eficiente. ¡Solo un consejo para los otros luchadores!

Hola chicos, tengo un problema similar, pero solo sucede con 3.1.1, otra versión está bien.

Esta es mi especificación de papa:
Windows 10
Procesador gráfico: nVidia GeForce GT 520M
Versión del controlador: 391.35 (estoy atascado con esta versión, no hay un controlador más nuevo disponible para 520M)

Sí, no es una máquina potente, pero es bastante decente. Puedo ejecutar Unity sin problemas, incluso puedo jugar juegos portados para ps3 desde Steam con FPS completo. Entonces, ejecutar Godot debería ser muy sencillo.

Cuando uso 3.1.1 Después de jugar el juego desde el editor, mi computadora portátil se ralentizó, esta condición persiste incluso después de cerrar Godot.
Es una ralentización muy importante que hace que mi computadora portátil sea inutilizable. Si lo obligo a usarlo, eventualmente empeora y la pantalla se vuelve negra y aparece un artefacto en mi pantalla (durante varios minutos). Estoy muy asustado, me pone la piel de gallina.
La única forma de solucionarlo es reiniciando Windows.

Así que ahora uso 3.1 funciona bien, ocurre un pequeño contratiempo cuando juego desde el editor, pero apenas se nota.

Eso es todo. Espero que ayude a solucionar este problema.

Hola de nuevo,

Acabo de formatear la computadora y acabo de instalar Godot. La última versión 3.1.1 x64. Y cuando lo abrí por primera vez, este problema simplemente me sucedió.

Especificaciones de la PC:
GPU: Nvidia 1060 3GB [con nuevos controladores limpios instalados]
CPU: Intel i5-4460
RAM: 16 GB DDR3
SO: WIN10

Miré el archivo .tres y solo tenía 5 KB.
Y la consola dice "OpenGL ES 3.0 Renderer: GeForce GTX 1060 3GB / PCIe / SSE2".

Tuve este problema hace mucho tiempo y no está relacionado con NVIDIA. Hace un tiempo tuve un problema, mis controladores USB no estaban instalados correctamente. Godot parece estar retrasado, pero todo sigue respondiendo. sucedería al cargar proyectos y cuando intentaría ejecutar el juego dentro del editor Godot.

Godot intenta verificar todos los dispositivos USB conectados para ver si se trata de un teclado, controlador de juego, casco de realidad virtual, etc. si el controlador / controlador USB no está instalado correctamente, esperará hasta un minuto. Después de ese minuto, ejecutará el juego de depuración o cargará proyectos.

reinstalar los controladores solucionará el problema. Encontré esta información cuando publiqué en godot discord hace unos años. Espero eso ayude. Incluso dos personas también informaron este problema en mi transmisión en vivo. Mi información ayudó a muchos.

En cuanto a los proyectos de monojuegos, sí, ocurrirá cualquier cosa que busque controladores de juegos o dispositivos USB. Monogame también busca dispositivos USB.

Tuve el mismo problema que mencionaron otras personas. En el inicio de Windows, Godot 3.1.1 funcionaría bien al principio, pero después de un tiempo al iniciar Godot, cargar proyectos y reproducirlos tardaría unos 30 segundos.

Para mí también fue por un dispositivo USB (como dijo shmellyorc). Ese dispositivo USB era un concentrador USB, que conectaba mi M&K a mi PC. Sin embargo, no reinstalé ningún controlador, simplemente conecté directamente mi M&K a mi PC. Eso solucionó todas las ralentizaciones (ni siquiera necesitaba reiniciar Godot o mi PC).

Puedo confirmar que tengo el mismo problema. Tengo una PC bastante nueva, reinstalada en mayo, con solo algunos programas instalados y obtengo el mismo inicio lento de Godot, apertura de proyectos y reproducción de escenas desde el editor.

Mis proyectos son PEQUEÑOS, ya que acabo de comenzar el curso Discovering Godot en Udemy y hasta ahora solo he estado imprimiendo texto en la consola de salida en Godot.

Mi% appdata% / Godot / editor_settings-3.tres es solo 8Kb, así que no lo llamaría enorme.

Intenté desactivar la telemetría de Nvidia, reinicié mi PC y todo fue rápido y agradable.

Win 10, versión 1903, compilación 18362.10005
GFX: MSI 970GTX, el controlador más nuevo de Nvidia
RAM: 16 GB
CPU: i7-4790
USB: Corsair KB & Mouse, tarjeta de sonido Focusrite Scarletti, controlador Xbox, dongle iLok

También estoy ejecutando la misma versión de Godot en un viejo Thinkpad T420 con Win10 y probablemente en la tarjeta gráfica interna de Intel. Allí funciona a la perfección.

Tengo un problema similar, pero no lo llamaría ralentización, pero en realidad cuelga, mientras que la CPU sube al 80%. Entonces no estoy seguro de que mi problema sea el mismo, porque no tengo una NVIDIA, y godot se cuelga para acciones muy específicas y solo hasta cierto punto, como explicaré a continuación, y solo en GLES3 y solo en 3D . Después de eso, todo parece agradable y fluido. Lanzar un juego es instantáneo con un proyecto vacío.

Primero, estoy usando Godot 3.1.1 estable y mi sistema es:
Windows 7
Serie ATI Radeon HD 4800 (memoria de 1 GB, iirc)
Intel Core Duo 2.13Ghz (dos núcleos, con OC a 3.6Ghz)
2 GB de RAM

Tuve este problema desde que salió 3.0. Pregunté y me hicieron creer que mi tarjeta gfx podría no ser compatible con GLES3. Acabo de lanzar GLView ahora, y debajo de GL Report enumera varias versiones 3.x en 100% . ¿Quizás alguien pueda confirmarme que esto significa que GLES3 es totalmente compatible con mi tarjeta?

Entonces, sobre las cosas para colgar, es así:

        hanging times

launching godot                   - 38 seconds
placing the root Spatial          - 54 seconds
placing a 2nd different node      - 54 seconds
placing a 3rd different node      - 18 seconds
placing every next random node    - instantaneous. From now on all seems smooth.

La cuestión es que los tiempos de espera son los mismos cada vez que intento esto, más o menos un segundo, ni más ni menos, es casi exacto. Noté una extraña excepción: si el segundo nodo diferente que coloco es un Sprite3D , se coloca instantáneamente, pero luego el tercer y cuarto nodo que coloco toman los mismos tiempos que el segundo y el tercero anteriores.

Otra cosa que noté es que después de colocar el Spatial raíz, puedo colocar Spatials todo lo que quiera sin ningún tipo de tapiz. Es cuando coloco un nodo 3D diferente que se cuelga una vez más. Lo mismo es cierto para cada nodo específico que coloco a continuación, independientemente de cuál elija: así que si el siguiente que elijo es un CSGBox, se cuelga 54 segundos, y luego puedo colocar CSGBoxes al contenido de mi corazón sin colgar ... hasta Coloco el tercer nodo diferente.

(EDITAR: y por cierto, si estoy tratando con escenas que ya construí antes, simplemente seleccionar los nodos después del inicio cuelga el motor en el mismo patrón)

La eliminación del entorno predeterminado cuelga godot durante 72 segundos la primera vez. Entonces puedo volver a ponerlo y sacarlo sin problema. El cambio de la vista 2D a la vista 3D también lleva bastante tiempo la primera vez (no lo cronometramos).

En GLES2, godot me toma ~ 11 segundos para iniciar, y todo es fluido e instantáneo desde allí, incluida la eliminación de def. env. (aunque sigue siendo considerablemente más lento que Godot 2, como mencioné en el # 27230).

Además, obtengo todos estos errores en la salida estándar al inicio (esto se enumera bastante rápido, solo entonces se cuelga aparentemente inactivo durante 38 segundos):

OpenGL ES 3.0 Renderer: ATI Radeon HD 4800 Series
ERROR: initialize: Condition ' status != 0x8CD5 ' is true. Continuing..:
   At: drivers/gles3/rasterizer_scene_gles3.cpp:5037

 [... same error 29 more times ...........]

ERROR: initialize: Directional shadow framebuffer status invalid
   At: drivers/gles3/rasterizer_scene_gles3.cpp:5062
ERROR: audio_device_init: Condition ' hr != ((HRESULT)0x00000000) ' is true. returned: ERR_CANT_OPEN
   At: drivers/wasapi/audio_driver_wasapi.cpp:217
ERROR: init: WASAPI: init_render_device error
   At: drivers/wasapi/audio_driver_wasapi.cpp:404

(Los últimos errores de WASAPI probablemente se deben a que no tengo tarjeta de sonido).

@Skaruts Godot no usa OpenGL ES en plataformas de escritorio. En su lugar, usa OpenGL 3.3 directamente (o OpenGL 2.1 cuando se usa el backend GLES2).

Las viejas tarjetas gráficas AMD son bastante malas en términos de compatibilidad con OpenGL, que es la causa de errores como ERROR: initialize: Directional shadow framebuffer status invalid (https://github.com/godotengine/godot/issues/27572).

Tuve este problema hace mucho tiempo y no está relacionado con NVIDIA. Hace un tiempo tuve un problema, mis controladores USB no estaban instalados correctamente. Godot parece estar retrasado, pero todo sigue respondiendo. sucedería al cargar proyectos y cuando intentaría ejecutar el juego dentro del editor Godot.

Godot intenta verificar todos los dispositivos USB conectados para ver si se trata de un teclado, controlador de juego, casco de realidad virtual, etc. si el controlador / controlador USB no está instalado correctamente, esperará hasta un minuto. Después de ese minuto, ejecutará el juego de depuración o cargará proyectos.

reinstalar los controladores solucionará el problema. Encontré esta información cuando publiqué en godot discord hace unos años. Espero eso ayude. Incluso dos personas también informaron este problema en mi transmisión en vivo. Mi información ayudó a muchos.

En cuanto a los proyectos de monojuegos, sí, ocurrirá cualquier cosa que busque controladores de juegos o dispositivos USB. Monogame también busca dispositivos USB.

Gracias, he confirmado que el problema en las computadoras con Windows es que los controladores USB no están instalados correctamente, he instalado un nuevo concentrador de extensión USB en mi computadora y apagarlo resolvió mi problema.

Confirmé que desconectar el concentrador USB me solucionó el problema también.

También puedo confirmar que este problema está relacionado con algunos de mis puertos USB2 (desconectar mi controlador USB o simplemente conectarlo a otro puerto USB3 resuelve el problema).
gracias a todos por señalar eso.

Tuve exactamente el mismo problema y lo resolví desconectando el segundo cable USB de mi teclado, que era para los dos puertos USB que tiene incorporados. En algún momento, si alguna vez planeo usar esos puertos, puedo intentar reinstalar sus controladores y volver a conectarlos.

Me pregunto si es posible establecer alguna bandera en Godot para que los gamepads se actualicen manualmente (mediante una solicitud explícita del código). No es muy bueno pedir a todos los jugadores afectados que (desinstalen) los controladores USB para el juego que en realidad no se preocupa por los controladores USB.

Acabo de instalar Godot v3.1.2.stable.official (de Steam).

Win 10, version 1903, build 18362.535
GFX: NVIDIA GeForce RTX 2080 Max-Q (driver 441.66)
RAM: 32GB
CPU: i7-9750
USB: Corsair Keyboard and Razer Mamba mouse

Lanzar Godot tarda 35 segundos. Una vez abierta, el lanzamiento de una "aplicación HelloWorld" (nada más que un solo nodo) toma 30 segundos. Probé todas las sugerencias hechas por comentaristas anteriores sin éxito. Probé la versión independiente y veo el mismo resultado.

NOTA: Puede resultar útil preceder cada una de estas líneas con una marca de tiempo:

Godot Engine v3.1.2.stable.official - https://godotengine.org
OpenGL ES 3.0 Renderer: GeForce RTX 2080 with Max-Q Design/PCIe/SSE2
Editing project: C:/Users/reed/dev/Godot/HelloGodot (C:::Users::reed::dev::Godot::HelloGodot)
Godot Engine v3.1.2.stable.official - https://godotengine.org
OpenGL ES 3.0 Renderer: GeForce RTX 2080 with Max-Q Design/PCIe/SSE2
erasing D:\SteamGames\Steam\steamapps\common\Godot Engine/editor_data/projects/HelloGodot-fa02d82fa570fbe2be598d4aa480ceae/filesystem_update4

@rmangino Dado que parece tener una computadora portátil Optimus, ¿esto sucede si obliga a Godot a ejecutar gráficos integrados? Esto se puede hacer haciendo clic con el botón derecho en el ejecutable y eligiendo la GPU.

NOTA: Puede resultar útil preceder cada una de estas líneas con una marca de tiempo:

No veo un caso de uso real al agregar eso; no ayudaría a resolver el problema en cuestión aquí. Las utilidades de registro generalmente agregan marcas de tiempo por sí mismas de todos modos: mild_smiling_face:

@Calinou Fui ingeniero senior tanto en el equipo de Visual Studio en MS como en el equipo de Xcode en Apple. Usar marcas de tiempo generosamente no hace daño a nada. ;-)

Y, por cierto, el retraso de 35 a 40 segundos que veo ocurre en cada lanzamiento de mi aplicación simple (no solo en el lanzamiento de Godot). Esto significa que Godot es inutilizable en este estado.

Ah ... editaste tu comentario. Estoy usando un MSI GS75 Stealth 479 . La ejecución con gráficos integrados genera los mismos retrasos.

Encontré una solución:

Inicialmente tenía mi computadora portátil conectada a un monitor curvo para juegos Alienware 1900R de 34.1 "a través de Thunderbolt 3. Si lanzo Godot _sin_ el monitor conectado, todo funciona como se esperaba.

Por lo tanto, mi solución es:

1. Desconecta mi monitor
2. Lanzamiento Godot
3. Conectar mi monitor

Después de esos pasos, el exe de Godot se inicia sin demora y los lanzamientos posteriores de mi proyecto de ejemplo también funcionan como se esperaba.

Como han señalado otros, Godot está usando cero CPU durante el "bloqueo", por lo que lo más probable es que sea una sola llamada la que se cuelga. Por favor, avíseme si hay una manera de iniciar Godot con telemetría / registro extendido, ya que debería ser bastante fácil aislar el problema. (Nuevamente, escribí el motor de instrumentación original para el generador de perfiles de Visual Studio, así que estoy muy familiarizado con este tipo de problemas).

Inicialmente, tenía mi computadora portátil conectada a un monitor curvo para juegos Alienware 1900R de 34.1 "a través de Thunderbolt 3. Si ejecuto Godot sin el monitor conectado, todo funciona como se esperaba.

¿El monitor incluye un concentrador USB? Si es así, esa podría ser la razón.

Por favor, avíseme si hay una manera de iniciar Godot con telemetría / registro extendido, ya que debería ser bastante fácil aislar el problema.

Hay un argumento de línea de comandos --verbose , pero hasta donde yo sé, no imprime nada sobre el escaneo de dispositivos USB.

Sí, mi monitor tiene un concentrador USB (¿qué monitor moderno no tiene?). Y tienes razón, --verbose no es útil. Estoy descargando la fuente de Godot ahora y les haré saber si puedo identificar el problema.

Para mí era una DAC (tarjeta de sonido) USB de la marca FiiO. Desenchufar esto corrige el inicio lento. Incluso causó los lanzamientos lentos mientras estaba apagado (modo de carga).

Para los afectados, ¿este problema también ralentiza los juegos exportados o solo el editor?

¿Alguien afectado puede intentar construir Godot desde la fuente y usar un depurador para averiguar qué está haciendo cuando ocurre esta desaceleración? Por lo general, debería poder interrumpir la ejecución durante una desaceleración y ver en el depurador cuál es el seguimiento de pila actual.

Tuve el mismo problema, o al menos los mismos síntomas. Intenté desconectar varios dispositivos USB y descubrí que el culpable era mi Massdrop O2 + ODAC, también conocido como "ODAC-revB USB DAC".

Después de buscar, encontré esta publicación de StackOverflow , que contenía la solución final al problema.

Resulta que, por alguna razón, el DAC agrega un dispositivo adicional a los "Dispositivos de interfaz humana" que aparece con el nombre genérico "Dispositivo de entrada USB". No tengo idea de lo que hace, pero deshabilitarlo en el administrador de dispositivos no parece afectar la funcionalidad de audio (¿para qué necesitaría un dispositivo de audio un dispositivo de entrada de todos modos?) Y soluciona el problema de Godot y ciertos juegos (Dark Souls y Sekiro viene a la mente) experimentando congelaciones prolongadas durante el inicio.

Para identificar el "Dispositivo de entrada USB" correcto (tenía un montón de ellos, la mayoría no relacionados con el DAC), su ID de dispositivo se puede comparar con el del dispositivo de audio real.
En mi caso, el dispositivo de audio era USB \ VID_262A & PID_1048 & MI_01 \ 7 & 12634547 & 0 & 0001 y el dispositivo de entrada era USB \ VID_262A & PID_1048 & MI_00 \ 7 & 12634547 & 0 & 0000. Observe que son iguales, excepto por MI_xx y el último número.

La adición de 'USB hizo que Godot fuera lento para cargar y reproducir las voces del proyecto'. Conecté mi nuevo teclado Corsair K55 RGB hoy y cargué Godot. Tomó alrededor de 40 segundos cargar la lista de proyectos y otros 30 para cargar el proyecto: un proyecto de tutorial de una escena con un script casi vacío adjunto a un nodo de sprite (sí, ¡tengo un largo camino por recorrer!). La reproducción del proyecto tardó alrededor de un minuto en aparecer su ventana. Apagué Godot, desconecté el teclado y Godot se cargó en 3 segundos como era de esperar. Al volver a conectar el teclado, Godot continúa cargando y reproduciendo escenas como de costumbre. No estoy seguro de si tendré que desconectar y volver a conectar mi teclado cada vez que quiera usar Godot. Veré cómo va y actualizaré esta publicación.

Editar: Actualicé el firmware del teclado a través del software iCUE de Corsair y eso solucionó el problema. Llego a la lista de proyectos en 2-3 segundos y en un proyecto en aproximadamente 3, como es normal, es decir. antes de conectar un nuevo teclado hoy.

Puedo confirmar que la actualización del firmware de mi teclado corsair K55 a través del software ICUE solucionó el error de enumeración de dispositivo lento de entrada directa como se muestra aquí: https://stackoverflow.com/questions/10967795/directinput8-enumdevices-sometimes-painfully-slow

Mi teclado Corsair K70 RGB tenía el firmware v 2.05. Acabo de actualizarlo a 3.08, que supongo que resolverá el problema.

Quiero agregar que vi exactamente este mismo problema en una aplicación completamente diferente el otro día: el juego de lucha Skullgirls 2nd Encore. El juego se quedaba colgado en el lanzamiento y no podía entender por qué. Intenté iniciar Godot y volví a tener el antiguo problema de carga, así que reinicié mi PC (probablemente debería haber reinsertado el teclado), y ambas aplicaciones estaban bien. Si vuelvo a ver algún problema después de la actualización, volveré a consultar aquí, pero @saulpalv agradece la respuesta, ya que la edición del comentarista anterior nunca llegó a mi bandeja de entrada.

En mi opinión, este problema está más relacionado con un hardware / controladores / firmware defectuoso que un error con Godot. Dada la simplicidad de la solución alternativa (actualice el firmware de su dispositivo USB o vuelva a insertarlo), no estoy seguro de que justifique una solución.

En mi opinión, este problema está más relacionado con un hardware / controladores / firmware defectuoso que un error con Godot. Dada la simplicidad de la solución alternativa (actualice el firmware de su dispositivo USB o vuelva a insertarlo), no estoy seguro de que justifique una solución.

Muchos de los jugadores novatos se darán por vencidos en el juego, en lugar de sumergirse profundamente en la resolución de problemas de su sistema para descubrir el problema del controlador, asumiendo que tienen este conocimiento. La suposición será que el juego tiene errores y no se puede jugar.

Si hay una forma de solucionarlo, valdría la pena hacerlo.

Puede que me haya perdido el comentario, pero pensé que se trataba de un problema exclusivo del editor. Si también afecta a los juegos, entonces sí, probablemente debería arreglarse.

Puede que me haya perdido el comentario, pero pensé que se trataba de un problema exclusivo del editor. Si también afecta a los juegos, entonces sí, probablemente debería arreglarse.

Si no es demasiado problemático, ¿podría revertir los controladores para recrear el bloqueo del editor e intentar recrearlo en un proyecto exportado?

Nunca pude reproducir el problema de manera confiable, incluso antes de actualizar el firmware de mi teclado. No creo que el software que realiza la actualización sea compatible con la degradación del firmware.

Lo mejor que se me ocurre es comprar un teclado nuevo (el mío no está disponible actualmente en Amazon) y esperar que tenga un firmware antiguo, luego usarlo durante semanas / meses hasta que el error vuelva a ocurrir al azar.

Esto sucede como una vez al mes para mí. Pero es tan molesto, tener que reiniciar la computadora para arreglarlo después de haber iniciado todas mis cosas de desarrollo.

Al tener este problema también, + 30 segundos cada uno para:

• selección de proyecto abierto
• proyecto abierto
• ejecutar la escena.

Lo rastreé hasta mi teclado Corsair K95 RGB. Mi solución alternativa en este momento es alternar el interruptor de tasa de sondeo / BIOS en el teclado, que hace básicamente lo mismo que reinsertar el cable USB. Godot funciona normalmente después.
iCue versión 3.27.68. Firmware 3.08v.

Acabo de notar que en iCUE también tenía la marca de verificación "Habilitar SDK". También lo he deseleccionado por ahora. Encontré un enlace antes que esa podría ser la causa.

Godot V3.2.1, pero he tenido problemas con versiones anteriores.

@landgrafa ¿Puedes reproducir el problema con un proyecto construido?

La "reparación" de desconectar y volver a conectar USB funciona para mí.

La actualización del firmware en mi teclado K55 Corsair a través de iCUE también funcionó.

Sigue siendo el teclado de mejor valor por tamaño / peso, pero hombre, este era un problema tonto.

Una pista interesante para este error de Ryan Gordon, ya que SDL parece sufrir un problema similar: https://mobile.twitter.com/icculus/status/1256845560763551744

De hecho, podría ser nuestro código de prueba de joypad el que causa el bloqueo. Quizás podríamos forzar la omisión de dispositivos que tardan más de un par de segundos en responder, y lanzar una advertencia para que los usuarios también puedan identificar los dispositivos USB que necesitan una actualización de firmware.

Daría un paso más y recordaría el dispositivo omitido (al menos hasta que Godot se reinicie) para que pueda seguir saltándolo en lugar de esperar 2 segundos y regañar al usuario cada vez. Digo esto porque cuando tenía el problema, se manifestaba cada vez que comenzaba a depurar.

¿O quizás trasladar el descubrimiento de dispositivos a un hilo diferente?

Para mí, el problema fue YETI Microphone on USB cuando GODOT se conecta, tarda 30 segundos en iniciarse, cuando lo desenchufo es súper rápido.

El problema para mí fue el auricular Razer Kraken USB . Desenchufar los auriculares me llevó de 20 segundos a 2 segundos.

Si alguien afectado sabe cómo usar un depurador en Windows, realmente podríamos usar un seguimiento de pila que muestre dónde está atascado exactamente el motor durante este largo paso de inicio:

https://github.com/godotengine/godot/issues/20566#issuecomment -577056589

Dado el problema similar en SDL, asumiría que está en algún lugar en platform/windows/joypad_windows.cpp , pero saber dónde exactamente ayudaría a saber dónde abortar o poner en lista negra los dispositivos problemáticos.

Me puse a compilar la versión 3.2 pero no pude hacer que el depurador se ejecutara desde VS.

@sungvzer No tengo

Recibí una actualización sobre el problema, después de mover el auricular a un concentrador USB, entre otros dispositivos, dejó de suceder. Los tiempos de carga y de inicio son mucho más rápidos.

Usuario de Corsair K70 aquí. La actualización del firmware lo solucionó para siempre.

Otras cosas USB que he conectado que no fueron el problema:
HyperX Cloud USB Dongle, mouse Rival 300, tarjeta de sonido Line6 GX, cámara web Logitech, ventilador USB.

Error interesante.

Parece que Corsair es un terreno común notable con muchos casos reportados aquí.
Estaba teniendo el mismo problema (Windows 10, mientras que en mi Arch Linux Godot es increíblemente rápido) con un auricular Corsair HS60 y solucioné la ralentización siguiendo la sugerencia principal de instalar el software propietario CUE y los controladores apropiados.
Para ser precisos, instalé CUE una vez hace meses solo para tener los controladores esenciales, luego desinstalé esa basura de 1,5 GB. Después de leer esto, acabo de reinstalar el software (sin ejecutarlo y sin actualizar los controladores) y el rendimiento de Godot ya es estable.

Actualización: reinicié mi PC y el problema volvió a aparecer, pero seguro que es algo relacionado con los auriculares.
Si saco el cable USB de mis auriculares (es el único dispositivo de salida de audio en mi sistema), todo vuelve a estar bien.
Volver a poner el cable USB no comprometerá el rendimiento hasta el próximo reinicio del sistema.

La mejor solución que he encontrado es desinstalar mi dispositivo de auriculares del panel de control, sacar el cable USB y volver a insertarlo. Los nuevos controladores instalados (con ICUE activado) no me dan ningún problema.
¿Podría ser un conflicto entre los controladores antiguos instalados sin ICUE, que pueden seleccionarse primero en lugar de los nuevos actualizados?

Tuve este problema hace mucho tiempo y no está relacionado con NVIDIA. Hace un tiempo tuve un problema, mis controladores USB no estaban instalados correctamente. Godot parece estar retrasado, pero todo sigue respondiendo. sucedería al cargar proyectos y cuando intentaría ejecutar el juego dentro del editor Godot.

Godot intenta verificar todos los dispositivos USB conectados para ver si se trata de un teclado, controlador de juego, casco de realidad virtual, etc. si el controlador / controlador USB no está instalado correctamente, esperará hasta un minuto. Después de ese minuto, ejecutará el juego de depuración o cargará proyectos.

reinstalar los controladores solucionará el problema. Encontré esta información cuando publiqué en godot discord hace unos años. Espero eso ayude. Incluso dos personas también informaron este problema en mi transmisión en vivo. Mi información ayudó a muchos.

En cuanto a los proyectos de monojuegos, sí, ocurrirá cualquier cosa que busque controladores de juegos o dispositivos USB. Monogame también busca dispositivos USB.

El problema se ha descrito aquí (recordatorio).

Tuve el mismo problema, o al menos los mismos síntomas. Intenté desconectar varios dispositivos USB y descubrí que el culpable era mi Massdrop O2 + ODAC, también conocido como "ODAC-revB USB DAC".

Después de buscar, encontré esta publicación de StackOverflow , que contenía la solución final al problema.

Resulta que, por alguna razón, el DAC agrega un dispositivo adicional a los "Dispositivos de interfaz humana" que aparece con el nombre genérico "Dispositivo de entrada USB". No tengo idea de lo que hace, pero deshabilitarlo en el administrador de dispositivos no parece afectar la funcionalidad de audio (¿para qué necesitaría un dispositivo de audio un dispositivo de entrada de todos modos?) Y soluciona el problema de Godot y ciertos juegos (Dark Souls y Sekiro viene a la mente) experimentando congelaciones prolongadas durante el inicio.

Para identificar el "Dispositivo de entrada USB" correcto (tenía un montón de ellos, la mayoría no relacionados con el DAC), su ID de dispositivo se puede comparar con el del dispositivo de audio real.
En mi caso, el dispositivo de audio era USB \ VID_262A & PID_1048 & MI_01 \ 7 & 12634547 & 0 & 0001 y el dispositivo de entrada era USB \ VID_262A & PID_1048 & MI_00 \ 7 & 12634547 & 0 & 0000. Observe que son iguales, excepto por MI_xx y el último número.

Esto solucionó el problema para mí, tengo el Topping MX3 que es de una marca diferente e intenté actualizar los controladores, pero Windows dice que ya está actualizado, me pregunto si los chips de entrada USB son similares entre ellos. Me alegro de haber encontrado esta solución porque tuve que hacer clic en cargar más comentarios varias veces, no estoy seguro de haber sufrido esperando 30 segundos para que el hilo desbloqueara cada iteración en un proyecto o sin audio.

Alguien preguntó anteriormente en el hilo, creo, pero esto también sucede con una compilación exportada, no sé con qué frecuencia ocurriría esta desaceleración durante un juego terminado, pero probablemente no hubiera intentado solucionarlo con un juego terminado y lo haría simplemente asuma que tiene errores.

Windows 10 Pro x64
Version 20H2
OS build 19042.572

GPU Nvidia RTX2070 Super
GPU driver 457.09

Confirmando que el problema aún está presente; Los tiempos de ejecución del editor y del programa exportado son normalmente inferiores a un segundo en mi computadora, pero cuando surge el problema, puede tardar entre 30 y 40 segundos en iniciarse. Esto también afecta la depuración en el editor, que puede tardar más de un minuto en iniciarse y conectarse.

El problema siempre se corrige solo después de un reinicio, pero volverá después de un tiempo. No he podido identificar un disparador, pero sospecho que podría verse afectado por la ejecución de aplicaciones de pantalla completa.

Intenté la corrección USB mencionada anteriormente, pero no encontré ningún dispositivo que hiciera cambios notables.

Confirmando que el problema aún está presente; lanzamiento del editor y programa exportado

Gracias por la confirmación. Por tanto, también afecta a las versiones exportadas. Eso es preocupante.