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

Criado em 29 jul. 2018  ·  107Comentários  ·  Fonte: godotengine/godot


Verificado esse URL, não foi encontrado nada que corresponda.

Versão Godot:

3.0.6 do Steam.
Também o mesmo problema no download recente de https://godotengine.org/
Isso também aconteceu nas versões anteriores. Isso está acontecendo há cerca de 3 meses ou mais.

Sistema operacional / dispositivo incluindo versão:

Windows 10 PRO x86_64
Versão 1803
OS build 17134.167

GPU Nvidia GTX980ti
Driver GPU 398,36

Descrição do problema:

Abrir Godot com o Steam ou download nativo leva mais de 40 segundos.
Abrir um projeto muito simples no modo de edição leva 35 segundos.
Pressionar o ícone de reprodução neste projeto em Godot leva 46 segundos antes que a janela do jogo seja aberta.

Passos para reproduzir:
Posso reproduzir isso todas as vezes apenas abrindo ou criando um projeto básico.
Tenho os mesmos problemas quando lanço um dos projetos de demonstração, como o multiplayer pong.

Projeto de reprodução mínima:

Aqui está o projeto mínimo que leva o tempo mencionado, mas eu recebo esse problema em todos os projetos.
Olá Godot.zip

Também anexei a saída das janelas cmd que são abertas quando Godot é iniciado.
cmd_output

bug 3.2 confirmed hero wanted! high priority windows porting

Comentários muito úteis

Tive esse problema há muito tempo e não está relacionado à NVIDIA. Tive um problema há algum tempo, meus drivers USB não foram instalados corretamente. Godot parece estar atrasado, mas tudo ainda está respondendo. isso aconteceria ao carregar projetos e quando eu tentasse rodar o jogo dentro do editor Godot.

Godot tenta verificar todos os dispositivos USB conectados para ver se é um teclado, controlador de jogo, fone de ouvido VR, etc. se o controlador / driver USB não estiver instalado corretamente, ele irá aguardar um minuto. Após esse minuto, ele executará o jogo de depuração ou carregará os projetos.

reinstalar seus drivers resolverá o problema. Descobri essa informação ao postar no Godot Discord alguns anos atrás. Espero que ajude. Até duas pessoas relataram esse problema na minha transmissão ao vivo. Minha informação ajudou muitos.

Quanto a projetos de monogame, sim, acontecerá qualquer coisa que verifique se há controladores de jogo ou dispositivos USB. O Monogame também verifica se há dispositivos USB.

Todos 107 comentários

NVIDIA, hein? Eu acredito que houve relatos de lançamentos lentos na NVIDIA, você pode tentar pesquisar por "NVIDIA" nos problemas. O consenso final foi que há um bug de driver.

nVidia GeForce GTX 1060 6GB / PCIe / SSE2 aqui, Godot 3.0.6 abre bem para mim (versão não-mono do site). Eu sei que Godot é um pouco mais lento em alguns casos com nVidia devido aos modos de desempenho automático ruins, mas não tão lento (como na inicialização de 30 segundos em vez de 4).

GTX 960 e 1070 relatando os mesmos problemas. Lançamento lento no windows, rápido no linux.
Eu realmente gostaria que isso pudesse ser corrigido, pois é o meu maior problema com Godot. Gosto de lançar meu jogo o tempo todo para testar pequenos ajustes, mas leva muito tempo no Windows com minhas GPUs nvidia.

Entrando no assunto com uma GTX 1070. Tentei todas as versões estáveis ​​de Godot. Também tentei em 3 versões do driver mais recente 398.98, 398.82, 398.36. Mas notei que na primeira vez (após a reinstalação do driver, reinicialização do computador), ele inicializou rapidamente. Vou brincar com algumas configurações da Nvidia quando encontrar tempo. Este é um grande problema e deve ser pesquisado um pouco mais.

Edit: Vou reconfirmar que a primeira inicialização após a reinicialização do sistema funciona normalmente. Cada inicialização subsequente leva muito tempo (40s).

https://www.nvidia.co.kr/Download/driverResults.aspx/137317/en
O driver 399.07 é lançado.
você testaria com isso?

Ei, volzhs - sim, parece que o corrigiu!
Ainda não tive tempo de fazer testes extensivos, mas acabei de abrir / editar / rodar alguns jogos e o desempenho foi ótimo.
Obrigado pelo aviso sobre o driver mais recente.

Eu não sei como isso afeta, mas a nota de versão do driver contém isso.

[GeForce GTX 1050/1070]: o driver OpenGL não libera o contexto de renderização
corretamente. [2305430]

Ótimo encontrar @volzhs , obrigado :)

@fossegutten @cimpresovec A atualização para 399.07 também corrige o problema de seus cartões?

Na verdade, recentemente fiz uma formatação completa do meu PC e o problema foi embora com o mesmo driver (398,98). Eu tentei o novo driver hoje e o problema não ocorreu. Portanto, não sei o que dizer. Mesmo driver antes e depois do formato, mas comportamento diferente. Não posso dizer o que causou o problema na instalação anterior, mas me impediu de usar Godot.

Infelizmente, isso começou a acontecer novamente para mim. Godot funciona bem por cerca de 1 hora ou mais, depois começa a ficar lento novamente.

O que é realmente estranho é que, se eu reiniciar meu PC, Godot funciona bem por um tempo novamente, mas depois começa a ficar lento.
No entanto, agora tenho quase certeza de que não é um problema de Godot. Pode tentar obter uma placa AMD e ver se isso elimina o problema para sempre.

GTX750 aqui; Achei que tinha algo a ver com https://github.com/godotengine/godot/issues/21472#issuecomment -416151678 não construir com sse2, já que eu era novo na construção, mas este problema parece ter piorado com o nas últimas semanas, com 3.1a1 tendo os tempos de carregamento mais longos.

Atualmente estou executando o driver 399.07.

Edit: Talvez não seja um problema de GPU? Percebi uso de CPU extremamente alto e baixo uso de GPU durante esses tempos de carregamento lento. Ocupando cerca de 27% da CPU (uma alocação de thread de hardware inteira na minha CPU), cai para níveis normais quando o carregamento termina.

Edit2: Não relacionado a este problema, eu apresentei outro problema.

Desculpe pela resposta tardia. Ainda muito lento, com driver 399.24 em GTX 1070 gpu.

O problema está de volta para mim. Bem, percebi isso ao desenvolver algum outro aplicativo com a biblioteca Raylib (usa GLFW por baixo). O aplicativo apresentou o mesmo comportamento de Godot. Então baixei Godot e o problema estava de volta. Percebi que, após a reinicialização do sistema, tudo funciona normalmente, mesmo após várias execuções separadas. O problema começa a ocorrer depois de algum tempo (não testei) ou depois de executar alguns jogos mais pesados ​​no sistema e, em seguida, tentar executar o Godot. O Unity, por outro lado, não foi afetado, mas não experimentei o Defold.

O que GLFW e Godot podem ter em comum?

Ambos usam OpenGL sob o capô. Assim como alguns outros programas que mencionei, que não apresentam o problema.

O problema parece ser Open GL sim. Monogame tem o mesmo comportamento com projetos OpenGL, mas não com projetos Direct X.

Hmm, se o problema existe para todas as coisas OpenGL, então provavelmente são drivers de GPU ruins.

O comportamento não é consistente em diferentes aplicativos OpenGL. Alguns funcionam bem (compilações Unity OpenGL, mecanismo Defold etc.). Provavelmente depende da versão usada, mas são apenas especulações. Infelizmente, não posso dar nenhuma ajuda concreta.

mesmo problema aqui, alguma dica?

Meu tempo de inicialização não está na faixa de 30+ segundos, mas em torno de 5 a 10 segundos. É definitivamente mais lento do que deveria ser. Eu tentei isso com um executável exportado e no motor. Isso também acontece com GLES3 e GLES2.

Estou usando uma GTX 1080 no driver 416.16
Estarei atualizando o driver momentaneamente e retornarei com uma observação sobre qualquer alteração.

Edit: O problema persiste com o driver 416.34 e (possivelmente não relacionado) parece um pouco lento para iniciar o próprio Godot, bem como abrir um projeto.

Estou no Linux e rodando os drivers NVIDIA 390.87. Realmente parecia que estava rodando em renderização de software desde o alto uso da CPU durante a rolagem, por exemplo.
Instalei os drivers da NVIDIA 410.73 e está tudo bem agora. Não sei se a NVIDIA resolveu esses problemas ou apenas reinstalar os drivers ajudou

Eu também tentei no Linux, e Godot parece funcionar muito bem. Ainda é lento no Windows.

Eu também tentei no Linux, e Godot parece funcionar muito bem. Ainda é lento no Windows.

Qual versão do Linux você está usando? E você está usando em uma VM?

Arch Linux. Sem VM.

Aqui em @JavaryGames estamos experimentando isso com todos os computadores, alguns com 1050Ti e outros com 1060. Mesmo com o driver mais recente (417).

No Linux, as mesmas máquinas funcionam bem, então é muito provável que seja um problema de driver.

Acredito que possa estar tendo esse problema também no Windows 10 godot 3.0.6

Eu tenho um AMD RX 580 embora

Adicionando meus próprios pontos de dados:

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

  1. Este problema é com 3.06-stable_win64 e 3.1-alpha5_win64. Leva de 30 segundos a 1 minuto para carregar o motor ou reproduzir uma cena.
  2. Isso pode ser corrigido reiniciando o computador, mas sempre retorna após várias execuções de cena. Pode ser conectado a falhas de motor / cena.
  3. Este problema acontece a qualquer momento [uma vez que começa após uma breve reinicialização 'cura'] a janela Godot Engine Editor (com saída de terminal) a qualquer momento "OpenGL ES [X] .0 Renderer" aparecer. Então, quando o executável começa e quando uma cena é executada.
  4. Isso não depende do driver ou da GPU. Usei um RX480 com drivers atualizados e uma GTX 1070 com drivers atualizados. O problema não mudou. Se este

Ter isso também em uma Nvidia GTX 1070

Apenas Windows, abre e funciona bem no Linux.

Estou tendo o mesmo problema, mas no linux com uma GPU AMD. Estou tendo dificuldade em rastreá-lo, pois isso começou a acontecer após uma atualização do sistema, mas o downgrade não resolveu. rebaixar godot também não teve efeito. leva mais de 30 segundos para abrir meu projeto, mais de 30 segundos para iniciá-lo e ele gagueja (às vezes congela por um tempo) sempre que um novo objeto é mostrado na tela pela primeira vez. No editor, coisas básicas como clicar em um nó ou abrir uma cena geralmente levam mais de 30 segundos.

quando as coisas estão congeladas, o som ainda é reproduzido, godot usa 100% da CPU em um núcleo e nem godot nem dmesg mostram um único erro. a princípio pensei que poderia ser da compilação de shaders e, embora usar o editor de shaders e deixá-lo compilar pode causar um congelamento de 30 segundos, parece que não ocorre depois da primeira vez que acontece.

no meu caso, parece um tanto aleatório, sendo uma falha de 10 quadros ou mais de 30 segundos sem nenhum meio-termo. quase sempre desaparece depois que algo é carregado, mas esse comportamento é redefinido quando o godot é fechado / reaberto, uma reinicialização não o afeta.

O seu Linux Mint ou Arch por acaso?

@retrotails Soa como # 24783.

@retrotails Soa como # 24783.

oh obrigado, parece que sim. Tenho apenas 18.2 em cache e ainda ocorre em 18.2, mas muito menos grave. vou tentar compilar o mesa mais recente e ver se pelo menos está consertado lá.

Para as pessoas afetadas por esse problema: você pode experimentar o Godot 3.1 beta 2 (ou posterior) e ver se ele ainda se comporta da mesma forma?

Os testes iniciais indicam que o 3.1 beta 2 corrigiu o problema para mim. Vou atualizar se começar a ficar lento novamente. Obrigado por resolver isso.

Não, 3.1 beta 2 ainda tem problemas intermitentes em meu gtx 1070. Às vezes é rápido, outras vezes é inaceitavelmente lento. Nota Não tenho problemas no meu laptop p52 também executando o Windows, com uma placa quadro p2000.

Olá,
mesmo problema aqui:
Windows 10 x64 home
cpu: AMD Ryzen 5 2600X
gpu: AMD Rx580

Depois de reiniciar o computador, Godot levará 30/40 segundos para abrir, carregar ou executar um projeto ...
Não importa a versão de Godot (2.x, 3.0.x, 3.1 alfa x ou beta x)
Depois de reiniciar o computador, tudo funciona bem, pelo que posso dizer

Tentei desabilitar o Fast Start / Boot no windows, mas o problema não foi corrigido.
Estou muito confuso, pois estava tudo bem alguns dias / semanas atrás ...

No entanto, tenho certeza de que não é um problema de Godot diretamente. Percebi, por exemplo, que o cliente STEAM tem o mesmo comportamento que Godot (e alguns jogos não funcionam) quando o problema ocorre ..

Eu de novo:

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

Agora no 3.1 Beta 2, os intervalos de ~ 30 segundos começam imediatamente, sem o período normal de lua de mel após um reinício em que as coisas estão agitadas.

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

Mesmo problema aqui, mas sem travamentos da Nvidia ou feedback no console.

O gerente de projeto demora muito para abrir quando clico em editar a mesma coisa e, se tiver sorte, mal consigo entrar no editor, onde demora muito para clicar em reproduzir e esperar que funcione corretamente.

No Gerenciador de Tarefas, descobri que Godot está usando <1% da minha CPU e o mesmo com a RAM. Não é o meu computador porque às vezes funciona como o esperado, tudo fluente e às vezes esse problema aparece.

Eu também tenho problemas com o gerente de projeto tentando carregar um png para exibir como um ícone, e fez meu Godot ficar lento novamente.

Uma pergunta totalmente não relacionada: algum de vocês com esse problema no Windows executa algum tipo de software antivírus / antimalware? Talvez algo esteja escaneando o binário quando executado.

Aqui estão outras coisas que vocês podem tentar, talvez isso esteja relacionado ao cache OpenGL, a NVidia armazena isso aqui:
C: \ Usuários \\ AppData \ Local \ NVIDIA \ GLCache

Se você excluir os arquivos aqui, ainda poderá reproduzir o problema?

Finalmente, outra coisa que encontrei nos fóruns da nvidia, você pode tentar executar o Godot manualmente enquanto define essa variável de ambiente? gostar:

__GL_SHADER_DISK_CACHE_SKIP_CLEANUP=1
godot.exe

reduz: Eu tentei isso. Não mudou nada.

@ ay200 Você tem nvidia?

@reduz Yes, 1070GTX.

Também tive uma abertura muito lenta, mas resolvo isso excluindo o arquivo: %appdata%/Godot/editor_settings-3.tres era realmente grande (~ 100 MB ou mais, não me lembro). Talvez ajude.

Eu tive o mesmo problema e, finalmente, tive em Configurações do projeto -> Depurar -> Configuração -> "Forçar FPS" definido como 1 :) Definir como 0 corrigiu o problema. Só postando aqui, pois este é o primeiro link com lagging encontrado.

Desculpe, pessoal, tenho a sensação de que esse problema se tornou uma salada de problemas diferentes.

Arquivo de configuração grande:

Se algum de vocês for afetado pela lentidão para abrir o GERENTE E EDITOR DE PROJETOS e, por acaso, seu
% appdata% / Godot / editor_settings-3.tres é enorme, FAÇA O ZIP E ENVIE-O PARA que possamos aprender por que esse arquivo é enorme. Se isso por algum motivo contiver informações privadas, edite-as primeiro para removê-las (embora eu realmente não ache que salve para talvez caminhos para seus projetos).

Lento para iniciar o jogo

Se o seu GAME demora para iniciar, mas o gerente de projeto e o editor estão OK. Descreva o seu hardware, incluindo sistema operacional, GPU e versão do driver.

Lento para iniciar o jogo

Se o seu GAME demora para iniciar, mas o gerente de projeto e o editor estão OK. Descreva o seu hardware, incluindo sistema operacional, GPU e versão do driver.

De acordo com o # 23986 semelhante, parece estar corrigido no driver Nvidia mais recente (419,17 no Windows 10). Alguns de vocês podem confirmar isso?

Eu tenho esse mesmo problema.

Demora cerca de 41 segundos para o lançamento inicial, abertura do projeto e execução (eu cronometrei cada um individualmente e eles estavam todos dentro de 1 segundo um do outro).
Reiniciar corrigiu isso.

Tentei a v3.0.6 tanto não mono quanto mono e tive o mesmo problema com os dois. Isso também acontece com o projeto de tutorial super básico "instanciar".

Especificações:
Windows 10 (64 bits)
AMD Radeon HD 6700 (v15.201.1151.1008)
16 GB de RAM

EDIT: Estou começando a usar o 3.1 beta e parece ter corrigido, mas o tempo dirá. Vou atualizar isso se ele voltar.

Tive esse problema do nada agora ... então lembrei que acabei de atualizar meus drivers NVidia e esqueci de desativar a telemetria ( https://github.com/NateShoffner/Disable-Nvidia-Telemetry ) depois de fazer isso e reiniciar, Godot começou muito bem. Isso é muito interessante realmente ... (Windows 10 x64 v1809)

Alguém tentou isso talvez? Estou pensando que tem algo a ver com essas coisas de telemetria. Também estou usando os drivers Nvidia mais recentes:
image

Eu ainda tenho o mesmo problema.

Demora muito para lançar inicialmente e depois abrir o projeto. A única vez que funcionou bem foi quando fiz o download do Godot, mas depois que o problema dos longos tempos de carregamento começa, não há como fazê-lo funcionar novamente.

Acontece em Godot v3.1 e v3.1.1 (ambos não mono)

Tentei todas as sugestões aqui e não ajuda.

Especificações:
Windows 10 (64 bits)
Nvidia RTX 2070 (v430.39)
16 GB de RAM

Seguir a sugestão do teihoo ao desativar a telemetria faz com que funcione após a reinicialização. Mas, uma vez que você reinicia novamente, fica lento novamente. Reativar a telemetria e, em seguida, desativá-la não resolve o problema novamente. Limpei instalei meu driver da Nvidia v430.39 e ele faz o mesmo funcionando uma vez após a reinicialização, mas não funciona após a segunda reinicialização. Mudei para o driver do criador da Nvidia em vez do driver pronto para o jogo e ainda assim o problema persiste. Tentei a versão Steam apenas para ter certeza de que o problema ainda está presente. Eu realmente espero que esse problema possa ser corrigido.

Eu me pergunto por que o título da edição foi alterado ..? Uma vez que parece não ser um problema exclusivo da Nvidia.

O problema ainda está lá para mim (AMD RX580 - Versão de configurações Radeon: 2019.0326.2353.42986 - Versão OpenGL: 25.20.15000.13547 - Versão API OpenGL: 4.6)

O problema ainda está presente para mim. Agora no driver Nvidia v430.64. Ainda não funciona.

Definitivamente um problema de OpenGL e não específico de Godot, ou Nvidia ou AMD para esse assunto. Mesmo um projeto MonoGame em branco leva muito tempo para abrir.

Olá!
Tudo estava funcionando bem e então atualizei meus drivers da nvidia para 430.64.

Desde então, quando eu iniciei o jogo via F5 / F6, ele ficou muito lento para iniciar (quase um minuto).

Esta é minha configuração:
Windows 10 Pro 64 bits
16go DDR4
Geforce GTX1060 6Gb
Executando em um SSD

Preciso executar o dual boot com o Ubuntu apenas para trabalhar com Godot de maneira eficiente. Só uma dica para os outros lutadores!

Oi pessoal, estou com problema parecido, mas só acontece com 3.1.1, outra versão está bem.

Esta é a minha especificação de batata:
Windows 10
GPU: nVidia GeForce GT 520M
Versão do driver: 391.35 (estou preso com esta versão, nenhum driver mais recente disponível para 520M)

Sim, não é uma máquina poderosa, mas é bastante decente. Posso executar o Unity sem problemas, até mesmo posso jogar jogos portados para ps3 no Steam com FPS completo. Portanto, dirigir Godot deve ser uma brisa.

Quando eu uso o 3.1.1 Depois de jogar o jogo no editor, meu laptop fica lento. Essa condição persiste mesmo depois que eu fecho o Godot.
É uma lentidão muito grande que torna meu laptop inutilizável. Se eu forçar a usá-lo, eventualmente, ele fica pior e a tela fica preta e um artefato na minha tela (por vários minutos). Estou com muito medo, me dá arrepios.
A única maneira de consertar é reiniciando o Windows.

Então agora eu uso o 3.1 e ele funciona bem, um pequeno soluço acontece quando eu jogo o jogo no editor, mas é quase imperceptível.

Isso é tudo. Espero que ajude a corrigir esse problema.

Oi de novo,

Acabei de formatar o computador e acabei de instalar o Godot. A versão mais recente 3.1.1 x64. E quando o abri pela primeira vez, esse problema simplesmente aconteceu comigo.

Especificações do PC:
GPU: Nvidia 1060 3 GB [com novos drivers limpos instalados]
CPU: Intel i5-4460
RAM: 16 GB DDR3
OS: WIN10

Eu olhei para o arquivo .tres e ele tinha apenas 5 KB.
E o console diz "Renderizador OpenGL ES 3.0: GeForce GTX 1060 3GB / PCIe / SSE2."

Tive esse problema há muito tempo e não está relacionado à NVIDIA. Tive um problema há algum tempo, meus drivers USB não foram instalados corretamente. Godot parece estar atrasado, mas tudo ainda está respondendo. isso aconteceria ao carregar projetos e quando eu tentasse rodar o jogo dentro do editor Godot.

Godot tenta verificar todos os dispositivos USB conectados para ver se é um teclado, controlador de jogo, fone de ouvido VR, etc. se o controlador / driver USB não estiver instalado corretamente, ele irá aguardar um minuto. Após esse minuto, ele executará o jogo de depuração ou carregará os projetos.

reinstalar seus drivers resolverá o problema. Descobri essa informação ao postar no Godot Discord alguns anos atrás. Espero que ajude. Até duas pessoas relataram esse problema na minha transmissão ao vivo. Minha informação ajudou muitos.

Quanto a projetos de monogame, sim, acontecerá qualquer coisa que verifique se há controladores de jogo ou dispositivos USB. O Monogame também verifica se há dispositivos USB.

Eu tive o mesmo problema que outras pessoas mencionaram. Na inicialização do Windows, Godot 3.1.1 funcionaria bem no início, mas depois de algum tempo iniciando o Godot, carregar projetos e reproduzi-los levaria cerca de 30 segundos.

Para mim, também foi por causa de um dispositivo USB (como disse shmellyorc). Esse dispositivo usb era um hub usb, que conectava meu M&K ao meu pc. Não instalei nenhum driver, apenas conectei diretamente meu M&K ao meu pc. Isso corrigiu todos os atrasos (não precisei nem reiniciar Godot ou meu pc).

Posso confirmar que tenho o mesmo problema. Tenho um PC recém-instalado, reinstalado em maio, com apenas alguns programas instalados e obtenho o mesmo início lento do Godot, abrindo Projetos e reproduzindo cenas do editor.

Meus projetos são MINÚSCULOS, pois acabei de iniciar o curso Descobrindo Godot na Udemy e até agora imprimindo texto no console de Saída em Godot.

Meu% appdata% / Godot / editor_settings-3.tres tem apenas 8 KB, então eu não diria que é enorme.

Tentei desabilitar a Telemetria Nvidia, reiniciei meu PC e tudo é rápido e legal.

Win 10, versão 1903, compilação 18362.10005
GFX: MSI 970GTX, o driver Nvidia mais recente
RAM: 16 GB
CPU: i7-4790
USB: Corsair KB e mouse, placa de som Focusrite Scarletti, controle do Xbox, dongle iLok

Também estou executando a mesma versão do Godot em um antigo Thinkpad T420 com Win10 e provavelmente em uma placa de vídeo Intel interna. Lá ele funciona perfeitamente.

Eu tenho um problema semelhante, mas eu não chamaria isso de lentidão, mas na verdade travando, enquanto a CPU sobe 80%. Então não tenho certeza se meu problema é o mesmo, pois não tenho NVIDIA, e o godot trava para ações bem específicas e só até certo ponto, como explicarei a seguir, e apenas no GLES3 e apenas em 3D . Depois disso, tudo parece bom e tranquilo. O lançamento de um jogo é instantâneo com um projeto vazio.

Primeiro, estou usando Godot 3.1.1 estável e meu sistema é:
Windows 7
ATI Radeon HD série 4800 (1 GB de memória, iirc)
Intel Core Duo 2,13 Ghz (dois núcleos, com OC a 3,6 GHz)
2 GB de RAM

Eu tive esse problema desde o lançamento do 3.0. Eu perguntei e fui levado a acreditar que meu cartão gfx pode não suportar GLES3. Acabei de lançar o GLView agora e em GL Report ele lista várias versões 3.x em 100% . Talvez alguém possa me confirmar que isso significa que GLES3 é totalmente compatível com minha placa?

Então, sobre as coisas penduradas, é assim:

        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.

O fato é que os tempos de suspensão são os mesmos toda vez que tento fazer isso, mais ou menos um segundo, nem mais nem menos - é quase exato. Percebi uma exceção estranha: se o segundo nó diferente que coloco for Sprite3D ele é colocado instantaneamente, mas o terceiro e o quarto nós que coloco tomam os mesmos tempos que o segundo e o terceiro acima.

Outra coisa que notei, é que depois de colocar a raiz Spatial, posso colocar Spatials tudo que eu quiser sem nenhuma suspensão. É quando coloco um nó 3D diferente que ele trava mais uma vez. O mesmo é verdade para cada nó específico que eu coloco em seguida, independentemente de qual eu escolher: então, se o próximo que eu escolher for um CSGBox, ele trava 54 segundos e então posso colocar CSGBoxes para o conteúdo do meu coração sem parar ... até Eu coloco o terceiro nó diferente.

(EDITAR: e aliás, se estou lidando com cenas que já construí antes, simplesmente selecionar os nós após a inicialização trava o motor no mesmo padrão)

A remoção do ambiente padrão trava godot por 72 segundos na primeira vez. Então posso colocá-lo de volta e retirá-lo sem problemas. Mudar da visualização 2D de volta para a visualização 3D também demora um pouco na primeira vez (não foi o tempo).

No GLES2, o godot leva cerca de 11 segundos para inicializar e tudo é suave e instantâneo a partir daí, incluindo a remoção do def. env. (embora ainda seja consideravelmente mais lento do que Godot 2, como mencionei em # 27230).

Além disso, recebo todos esses erros no stdout na inicialização (isso é listado muito rapidamente, só então ele trava aparentemente inativo por 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

(Os últimos erros WASAPI são provavelmente porque não tenho placa de som.)

@Skaruts Godot não usa OpenGL ES em plataformas de desktop. Em vez disso, ele usa OpenGL 3.3 diretamente (ou OpenGL 2.1 ao usar o backend GLES2).

As placas de vídeo AMD antigas são muito ruins em termos de suporte a OpenGL, que é a causa de erros como ERROR: initialize: Directional shadow framebuffer status invalid (https://github.com/godotengine/godot/issues/27572).

Tive esse problema há muito tempo e não está relacionado à NVIDIA. Tive um problema há algum tempo, meus drivers USB não foram instalados corretamente. Godot parece estar atrasado, mas tudo ainda está respondendo. isso aconteceria ao carregar projetos e quando eu tentasse rodar o jogo dentro do editor Godot.

Godot tenta verificar todos os dispositivos USB conectados para ver se é um teclado, controlador de jogo, fone de ouvido VR, etc. se o controlador / driver USB não estiver instalado corretamente, ele irá aguardar um minuto. Após esse minuto, ele executará o jogo de depuração ou carregará os projetos.

reinstalar seus drivers resolverá o problema. Descobri essa informação ao postar no Godot Discord alguns anos atrás. Espero que ajude. Até duas pessoas relataram esse problema na minha transmissão ao vivo. Minha informação ajudou muitos.

Quanto a projetos de monogame, sim, acontecerá qualquer coisa que verifique se há controladores de jogo ou dispositivos USB. O Monogame também verifica se há dispositivos USB.

Obrigado, eu confirmei que o problema em computadores Windows é de drivers USB não instalados corretamente. Eu instalei um novo hub de extensão USB em meu computador e desligá-lo resolveu meu problema.

Confirmei que desconectar o hub USB também corrigiu o problema para mim.

Também posso confirmar que esse problema está relacionado a algumas das minhas portas USB2 (desconectar meu controlador USB ou apenas conectá-lo a outra porta USB3 resolve o problema).
obrigado a todos por apontar isso.

Eu tive exatamente o mesmo problema e resolvi-o desconectando o segundo cabo USB do meu teclado, que era para as duas portas USB integradas. Em algum momento, se eu realmente planejar usar essas portas, posso tentar reinstalar seus drivers e conectá-los novamente.

Eu me pergunto se é possível definir algum sinalizador no Godot para que os gamepads sejam atualizados manualmente (por solicitação explícita do código)? Não é muito legal pedir a todos os jogadores afetados para (des) instalarem drivers usb para o jogo que na verdade não se preocupa com drivers usb.

Acabei de instalar Godot v3.1.2.stable.official (do 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

O lançamento do Godot leva 35 segundos. Depois de aberto, o lançamento de um "aplicativo HelloWorld" (nada além de um único Node) leva 30 segundos. Tentei todas as sugestões feitas por comentaristas anteriores sem sucesso. Tentei a versão autônoma e vi o mesmo resultado.

NOTA: pode ser útil preceder cada uma dessas linhas por um carimbo de data / hora:


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 Já que você parece ter um laptop Optimus, isso acontece se você forçar Godot a rodar com gráficos integrados? Isso pode ser feito clicando com o botão direito do mouse no executável e escolhendo a GPU.

NOTA: pode ser útil preceder cada uma dessas linhas por um carimbo de data / hora:

Não vejo um caso de uso real em adicionar isso - não ajudaria a resolver o problema em questão aqui. Utilitários de registro geralmente adicionam carimbos de data / hora por conta própria de qualquer maneira: ligeiramente_smiling_face:

@Calinou Eu era um engenheiro sênior na equipe do Visual Studio na MS e na equipe do Xcode na Apple. Usar carimbos de data / hora liberalmente não prejudica nada. ;-)

E, a propósito, o atraso de 35-40 segundos que estou vendo ocorre em cada lançamento do meu aplicativo simples (não apenas no lançamento de Godot). Isso significa que Godot é inutilizável neste estado.

Ah ... você editou seu comentário. Estou usando um MSI GS75 Stealth 479 . Executar com gráficos integrados resulta nos mesmos atrasos.

Eu encontrei uma solução alternativa:

Inicialmente, meu laptop foi conectado a um monitor de jogos Alienware 1900R 34.1 ", Curved Gaming via Thunderbolt 3. Se eu iniciar o Godot _sem_ o monitor conectado, tudo funcionará conforme o esperado.

Portanto, minha solução alternativa é:

  1. Desconecte meu monitor
  2. Lançar Godot
  3. Conectar meu monitor

Após essas etapas, o exe Godot é iniciado sem demora e os lançamentos subsequentes do meu projeto de exemplo também funcionam conforme o esperado.

Como outros notaram, Godot está usando CPU zero durante o "travamento", então é mais provável que uma única chamada esteja travada. Informe-nos se houver uma maneira de iniciar o Godot com telemetria / registro estendido, pois deve ser muito fácil isolar o problema. (Novamente, escrevi o mecanismo de instrumentação original para o criador de perfil do Visual Studio, então estou muito familiarizado com esses tipos de problemas).

Inicialmente, meu laptop foi conectado a um monitor de jogos Alienware 1900R 34.1 ", Curved Gaming Monitor via Thunderbolt 3. Se eu iniciar o Godot sem o monitor conectado, tudo funcionará como esperado.

O monitor inclui um hub USB? Nesse caso, esse pode ser o motivo.

Informe-nos se houver uma maneira de iniciar o Godot com telemetria / registro estendido, pois deve ser muito fácil isolar o problema.

Há um argumento de linha de comando --verbose , mas até onde eu sei, ele não imprime nada sobre digitalização de dispositivo USB.

Sim, meu monitor tem um hub USB (que monitor moderno não tem?). E você está correto, --verbose não é útil. Estou baixando o código fonte do Godot agora e informarei se posso identificar o problema.

Para mim foi uma USB DAC (placa de som) da marca FiiO. Desconectar isso corrige o lançamento lento. Ele até causou os lançamentos lentos enquanto desligado (modo de carregamento).

Para os afetados, esse problema também torna os jogos exportados mais lentos ou apenas o editor?

Alguém afetado pode tentar construir Godot a partir do código-fonte e usar um depurador para descobrir o que ele está fazendo quando essa desaceleração acontece? Normalmente, você deve conseguir interromper a execução durante uma desaceleração e ver no depurador qual é o stacktrace atual.

Eu tive o mesmo problema, ou pelo menos os mesmos sintomas. Tentei desconectar vários dispositivos USB e descobri que o culpado era meu Massdrop O2 + ODAC, também conhecido como "ODAC-revB USB DAC".

Depois de alguma pesquisa, me deparei com esta postagem StackOverflow , que continha a solução final para o problema.

Acontece que por algum motivo, o DAC adiciona um dispositivo extra a "Dispositivos de interface humana" que aparece com o nome genérico "Dispositivo de entrada USB". Não tenho ideia do que ele faz, mas desativá-lo no gerenciador de dispositivos não parece afetar a funcionalidade de áudio (para que um dispositivo de áudio precisaria de um dispositivo de entrada afinal?) E corrige o problema de Godot e alguns jogos (Dark Souls e Sekiro vem à mente) experimentando longos congelamentos durante a inicialização.

Para identificar o "dispositivo de entrada USB" correto (eu tinha um monte deles, a maioria não relacionado ao DAC), o ID do seu dispositivo pode ser comparado ao do dispositivo de áudio real.
No meu caso, o dispositivo de áudio era USB \ VID_262A & PID_1048 & MI_01 \ 7 & 12634547 & 0 & 0001 e o dispositivo de entrada era USB \ VID_262A & PID_1048 & MI_00 \ 7 & 12634547 & 0 & 0000. Observe que eles são iguais, exceto para o MI_xx e o último número.

Adicionar à 'coisa USB fez Godot lento para carregar e reproduzir as vozes do projeto'. Liguei meu novo teclado RGB Corsair K55 hoje e carreguei Godot. Demorou cerca de 40 segundos para carregar a lista de projetos e outros 30 para carregar o projeto: um projeto de tutorial de uma cena com um script quase vazio anexado a um nó de sprite (sim, eu tenho um longo caminho pela frente!). A execução do projeto demorou cerca de um minuto para a janela aparecer. Desliguei Godot, desconectei o teclado e Godot carregou em 3 segundos, como eu esperava. Conecte o teclado de volta e Godot continuará a carregar e reproduzir as cenas normalmente. Não tenho certeza se vou precisar desconectar e reconectar meu teclado toda vez que quiser usar Godot. Vou ver como corre e atualizar este post.

Edit: Eu atualizei o firmware do teclado através do software iCUE da Corsair e isso corrigiu o problema. Eu chego à lista de projetos em 2-3 segundos e em um projeto em cerca de 3, ou seja, normalmente. antes de conectar um novo teclado hoje.

Posso confirmar que atualizar meu firmware de teclado corsair K55 por meio do software ICUE corrigiu o bug de enumeração de dispositivo lento de entrada direta, conforme mostrado aqui: https://stackoverflow.com/questions/10967795/directinput8-enumdevices-sometimes-painfully-slow

Meu teclado Corsair K70 RGB estava no firmware v 2.05. Acabei de atualizá-lo para 3.08, que presumo que resolverá o problema.

Gostaria de acrescentar que vi exatamente o mesmo problema em um aplicativo totalmente diferente outro dia: o jogo de luta Skullgirls 2nd Encore. O jogo iria travar no lançamento e eu não conseguia entender por quê. Tentei iniciar o Godot e ele teve o antigo problema de carregamento novamente, então reiniciei meu PC (provavelmente deveria ter apenas reinserido o teclado), e os dois aplicativos funcionaram bem. Se eu vir algum problema novamente após a atualização, irei verificar novamente aqui, mas

IMO, este problema está mais relacionado a hardware / drivers / firmware ruins do que um bug com Godot. Dada a simplicidade da solução alternativa (atualize o firmware do seu dispositivo USB ou reinsira-o), não tenho certeza se isso justifica uma correção.

IMO, este problema está mais relacionado a hardware / drivers / firmware ruins do que um bug com Godot. Dada a simplicidade da solução alternativa (atualize o firmware do seu dispositivo USB ou reinsira-o), não tenho certeza se isso justifica uma correção.

Muitos jogadores iniciantes desistem do jogo, em vez de mergulhar fundo na solução de problemas do sistema para descobrir o problema do driver, presumindo que eles tenham esse conhecimento. A suposição será que o jogo tem bugs e não pode ser reproduzido.

Se houver uma maneira de contornar isso, vale a pena fazer.

Posso ter perdido o comentário, mas achei que era um problema apenas do editor. Se isso afeta os jogos também, então sim, provavelmente deve ser consertado.

Posso ter perdido o comentário, mas achei que era um problema apenas do editor. Se isso afeta os jogos também, então sim, provavelmente deve ser consertado.

Se não for muito difícil de fazer, você seria capaz de reverter seus drivers para recriar o travamento do editor e tentar recriá-lo em um projeto exportado?

Nunca fui capaz de reproduzir o problema de forma confiável, mesmo antes de atualizar o firmware do meu teclado. Eu não acho que o software que faz a atualização realmente suporte o downgrade de firmware.

O melhor que posso pensar é comprar um novo teclado (o meu não está disponível no Amazon) e torcer para que ele tenha um firmware antigo, então usá-lo por semanas / meses até que o bug ocorra aleatoriamente novamente.

Isso acontece uma vez por mês para mim. Mas tão chato, ter que reiniciar o computador para consertar depois de ter iniciado todas as minhas coisas de desenvolvimento.

Tendo este problema também, + 30 segundos cada para:

  • abrir seleção de projeto
  • projeto aberto
  • cena de corrida.

Rastreei até meu teclado RGB Corsair K95. Minha solução alternativa no momento é alternar a taxa de pesquisa / chave de BIOS no próprio teclado, o que basicamente faz a mesma coisa que reinserir o cabo USB. Godot funciona normalmente depois disso.
iCue versão 3.27.68. Firmware 3.08v.

Notei que no iCUE também marquei "Ativar SDK". Eu também desmarquei por agora. Encontrei um link anterior que pode ser a causa.

Godot V3.2.1, mas tive problemas com versões anteriores.

@landgrafa Você consegue reproduzir o problema com um projeto construído?

A "correção" USB para desconectar e reconectar funciona para mim.

Atualizar o firmware no meu teclado K55 Corsair através do iCUE também funcionou.

Ainda é o teclado com melhor valor para tamanho / peso, mas cara, esse era um problema idiota de se ter.

Pista interessante para esse bug de Ryan Gordon, já que o SDL parece sofrer de um problema semelhante: https://mobile.twitter.com/icculus/status/1256845560763551744

Na verdade, pode ser nosso código de verificação do joypad que causa o travamento. Poderíamos talvez forçar o salto de dispositivos que levam mais de alguns segundos para responder e lançar um aviso para que os usuários também possam identificar dispositivos USB que precisam de uma atualização de firmware.

Eu daria um passo adiante e lembraria do dispositivo ignorado (pelo menos até Godot ser reiniciado) para que você possa continuar ignorando-o em vez de esperar 2 segundos e importunar o usuário todas as vezes. Digo isso porque, quando eu tinha o problema, ele se manifestava toda vez que eu começava a depurar.

Ou mover a descoberta de dispositivo para um segmento diferente, talvez?

Para mim, o problema era YETI Microphone on USB quando plugado no GODOT leva 30s para começar, quando eu o desconecto é super rápido.

O problema para mim era o fone de ouvido Razer Kraken USB . Desconectar o fone de ouvido me levou de 20 segundos a 2 segundos.

Se alguém afetado souber como usar um depurador no Windows, poderíamos realmente usar um rastreamento de pilha que mostra onde exatamente o mecanismo está travado durante esta longa etapa de inicialização:

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

Dado o problema semelhante no SDL, eu suporia que está em algum lugar em platform/windows/joypad_windows.cpp , mas saber onde exatamente ajudaria a saber onde abortar ou colocar na lista negra dispositivos problemáticos.

Compilei a versão 3.2, mas não consegui fazer o depurador rodar no VS.

@sungvzer Não tenho muita experiência com isso, mas se você tiver mais detalhes, posso tentar ajudar. Não foi iniciado sozinho ou você está tendo problemas para anexá-lo?

Recebi uma atualização sobre o problema, depois de mover o fone de ouvido para um hub USB, entre outros dispositivos, isso parou de acontecer. Os horários de carregamento e início são muito mais rápidos.

Usuário Corsair K70 aqui. Atualizar o firmware corrigiu o problema para sempre.

Outras coisas USB que conectei que não eram o problema:
HyperX Cloud USB Dongle, mouse Rival 300, placa de som Line6 GX, webcam Logitech, ventilador USB.

Bug interessante.

Parece que a Corsair é o terreno comum notável com muitos casos relatados aqui.
Eu estava tendo o mesmo problema (Windows 10, enquanto no meu Arch Linux Godot é muito rápido) com um headset Corsair HS60 e consertei a lentidão seguindo a sugestão principal de instalar o software proprietário CUE e os drivers apropriados.
Para ser preciso, instalei o CUE uma vez meses atrás apenas para ter os drivers essenciais, depois desinstalei aquela porcaria de 1,5 GB. Depois de ler isso, acabei de reinstalar o software (sem executá-lo e atualizar os drivers) e o desempenho de Godot já está estável.

Atualização: Reinicializei meu PC e o problema voltou novamente, mas com certeza é algo ligado ao fone de ouvido.
Se eu puxar o cabo USB do meu fone de ouvido (é o único dispositivo de saída de áudio em meu sistema), tudo ficará bem novamente.
Colocar o cabo USB novamente não comprometerá o desempenho até a próxima reinicialização do sistema.

A melhor solução que encontrei é desinstalar meu dispositivo de fone de ouvido do painel de controle e puxar o cabo USB e inseri-lo novamente. Os novos drivers instalados (com ICUE ativado) não me causam nenhum problema.
Pode ser um conflito entre os drivers antigos instalados sem ICUE, que podem ser selecionados primeiro em vez dos novos atualizados?

Tive esse problema há muito tempo e não está relacionado à NVIDIA. Tive um problema há algum tempo, meus drivers USB não foram instalados corretamente. Godot parece estar atrasado, mas tudo ainda está respondendo. isso aconteceria ao carregar projetos e quando eu tentasse rodar o jogo dentro do editor Godot.

Godot tenta verificar todos os dispositivos USB conectados para ver se é um teclado, controlador de jogo, fone de ouvido VR, etc. se o controlador / driver USB não estiver instalado corretamente, ele irá aguardar um minuto. Após esse minuto, ele executará o jogo de depuração ou carregará os projetos.

reinstalar seus drivers resolverá o problema. Descobri essa informação ao postar no Godot Discord alguns anos atrás. Espero que ajude. Até duas pessoas relataram esse problema na minha transmissão ao vivo. Minha informação ajudou muitos.

Quanto a projetos de monogame, sim, acontecerá qualquer coisa que verifique se há controladores de jogo ou dispositivos USB. O Monogame também verifica se há dispositivos USB.

O problema foi descrito aqui (lembrete)!

Eu tive o mesmo problema, ou pelo menos os mesmos sintomas. Tentei desconectar vários dispositivos USB e descobri que o culpado era meu Massdrop O2 + ODAC, também conhecido como "ODAC-revB USB DAC".

Depois de alguma pesquisa, me deparei com esta postagem StackOverflow , que continha a solução final para o problema.

Acontece que por algum motivo, o DAC adiciona um dispositivo extra a "Dispositivos de interface humana" que aparece com o nome genérico "Dispositivo de entrada USB". Não tenho ideia do que ele faz, mas desativá-lo no gerenciador de dispositivos não parece afetar a funcionalidade de áudio (para que um dispositivo de áudio precisaria de um dispositivo de entrada afinal?) E corrige o problema de Godot e alguns jogos (Dark Souls e Sekiro vem à mente) experimentando longos congelamentos durante a inicialização.

Para identificar o "dispositivo de entrada USB" correto (eu tinha um monte deles, a maioria não relacionado ao DAC), o ID do seu dispositivo pode ser comparado ao do dispositivo de áudio real.
No meu caso, o dispositivo de áudio era USB \ VID_262A & PID_1048 & MI_01 \ 7 & 12634547 & 0 & 0001 e o dispositivo de entrada era USB \ VID_262A & PID_1048 & MI_00 \ 7 & 12634547 & 0 & 0000. Observe que eles são iguais, exceto para o MI_xx e o último número.

Isso resolveu o problema para mim, eu tenho o Topping MX3 que é de uma marca diferente e tentei atualizar os drivers mas o Windows diz que já está atualizado, gostaria de saber se os chips de entrada USB são semelhantes entre eles. Ainda bem que encontrei essa correção, pois tive que clicar em carregar mais comentários algumas vezes, não tenho certeza se eu poderia ter sofrido ao esperar 30 segundos para que o thread desbloqueie cada iteração em um projeto ou sem áudio.

Alguém perguntou no início do tópico, eu acho, mas isso também acontece com uma construção exportada também, não sei com que frequência essa lentidão ocorreria durante um jogo finalizado, mas provavelmente não teria tentado solucionar o problema com um jogo finalizado e apenas suponha que seja bugado.

Windows 10 Pro x64
Version 20H2
OS build 19042.572

GPU Nvidia RTX2070 Super
GPU driver 457.09

Confirmar que o problema ainda está presente; O tempo de inicialização do editor e do programa exportado é normalmente inferior a um segundo no meu computador, mas quando o problema surge, pode levar de 30 a 40 segundos para iniciar. Isso também afeta a depuração no editor, que pode levar mais de um minuto para iniciar e conectar.

O problema sempre se corrige após uma reinicialização, mas voltará após algum tempo. Não consegui identificar um gatilho, mas suspeito que ele pode ser afetado pela execução de qualquer aplicativo de tela inteira.

Eu tentei consertar o USB mencionado acima, mas não encontrei nenhum dispositivo que fizesse qualquer alteração perceptível.

Confirmar que o problema ainda está presente; editor e lançamento do programa exportado

Obrigado pela confirmação. Portanto, também afeta as versões exportadas. Isso é preocupante.

Esta página foi útil?
0 / 5 - 0 avaliações

Questões relacionadas

n-pigeon picture n-pigeon  ·  3Comentários

bojidar-bg picture bojidar-bg  ·  3Comentários

Spooner picture Spooner  ·  3Comentários

mefihl picture mefihl  ·  3Comentários

nunodonato picture nunodonato  ·  3Comentários