Usando o PhysX, como posso prever onde é necessário gerar formas de colisão de terreno procedimentais?

Nessa situação, tenho valores de altura do terreno que gero processualmente. Para renderização, uso a posição da câmera para gerar um mapa de altura de tamanho apropriado. Para colisão, no entanto, preciso ter campos de altura gerados em áreas onde os objetos podem se cruzar.

Minha solução potencial atual, que pode ser ingênua, é iterar todos os atores físicos "acordados", usar seus limites / extensões e velocidades para gerar esferas nas quais eles podem residir após uma atualização física, e gerar valores de altura para faixas que abrangem grupos agrupados de atores. Muitos desses dados provavelmente já são calculados pelo PhysX, no entanto.

Existe alguma API, talvez um conjunto de consultas, até retornos de chamada do sistema espacial, que eu possa usar para prever onde os valores de altura do terreno serão necessários?

— Sion Sheevok
fonte

Parece-me que você já codificou a melhor solução. Não tendo certeza de como o PhysX funciona, talvez você possa ter gatilhos em forma de caixa delimitadora em seus blocos de terreno e gerar as formas de colisão se algo entrar (disparar) nessa caixa. Basicamente, o que você está fazendo, mas o contrário e com a matemática de colisão PhysX.

— Aerosson 26/04

Se você estiver gerando malhas a partir de seus dados para renderização, poderá passar a malha para o PhysX como uma malha colisor. Significa que physX e seu renderizador referenciam o mesmo objeto cortando sobrecarga.

— Aquele sem-teto
fonte

Não é apropriado supor que o terreno visível é o único objeto com o qual o objeto pode colidir. O problema é identificar rapidamente com que faixa de terreno pode ser colidido, para que formas de colisão possam ser geradas sob demanda.

— precisa saber é o seguinte

pt.wikipedia.org/wiki/Octree dividindo os dados do mundo em cubos e "cortando" os dados onde quer que você tenha uma entidade colidível gratuita, você pode fazer chamadas para os dados do terreno em uma área muito pequena com muito pouco gasto adicional. Aqui está um exemplo usando quadríceps para colisão de partículas 2D, mas o conceito é o mesmo para Octrees, mas com uma dimensão extra. Isso também permitiria que objetos colidíveis livres individuais colidissem entre si. youtube.com/watch?v=fuexOsLOfl0 Você pode então gerar coletores muito pequenos a partir dos dados do terreno próximos aos objetos colidíveis gratuitos

— Aquele sem-teto

Eu estou familiarizado com octrees e particionamento espacial - o PhysX já está fazendo isso internamente. Preciso de informações do PhysX sobre seu sistema de particionamento espacial, para que eu possa gerar formas de colisão de terreno onde elas são necessárias, porque o terreno é processual.

— precisa saber é o seguinte

Você está perdendo o ponto. Estou gerando dados para o terreno. Estou amostrando esses dados para criar um campo de altura. Preciso prever onde os dados do terreno são necessários. Se houver um objeto em (-100,0, -100,0), preciso gerar terreno próximo a (-100,0, -100,0) antes de simular a física. Também preciso gerar uma região de terreno grande o suficiente, caso contrário, um objeto poderá se mover além de uma região e terminar abaixo de onde o terreno estaria se tivesse sido gerado nessa região. O PhysX já deve rastrear essas informações para prever possíveis colisões - eu preciso dessas informações. Não sei se / como fazê-lo.

— precisa saber é o seguinte

Esse é o método de solução alternativa que descrevi na minha pergunta, sim. Estou perguntando se posso obter o trabalho que o PhysX já fez, para não calcular de forma redundante os mesmos resultados. Ainda não encontrei uma maneira, mas não estou familiarizado com a API PhysX sem licenciamento.

— precisa saber é o seguinte