Em jogos de corrida 3D muito simples, como são tratadas as colisões?

Fiquei me perguntando como são feitas colisões em alguns jogos simples de corrida de carros em 3D (especialmente em jogos como Outrun 2 / Motoracer).

Nos jogos clássicos de corrida de carros com ambiente complexo (mundo aberto), acho que isso é feito com uma caixa básica (para o carro) para colisão de avião (para pista, construções e outras coisas). A coisa toda seria otimizada usando algumas caixas delimitadoras (é assim que a colisão é feita em muitos jogos).

Em um jogo como Outrun 2 / Motoracer, a jogabilidade é tão simples que os desenvolvedores talvez não precisem disso e tudo poderia ter sido muito simplificado. Para quem nunca toca, aqui está o que é tão específico:

• O carro / bicicleta está sempre colado na estrada.
• A estrada é sempre do mesmo tamanho e tem uma forma muito simples.
• As únicas possibilidades são seguir essa estrada, não é possível sair da estrada ou entrar em colisão com outra coisa (exceto outros carros / motos, mas não nos importamos).
• Quando você colide com a estrada, uma colisão de arcada muito básica é feita (o carro é simplesmente empurrado para longe dela)

Aqui está como eu acho que a colisão (poderia) ter sido feita:

A pista inteira poderia ser considerada como uma curva gigante em 3D. A partir dessa curva, os polígonos da estrada podem ser gerados (usando os vetores frontal, esquerdo e superior gerados a partir da curva). Outros elementos (como casas, árvores, ...) também podem ser colocados e alinhados usando esse método.

Em seguida, para lidar com as colisões (e desenhar carro):

1) Encontre a posição mais próxima na curva 3d da posição 3d atual do carro. Em outras palavras, transforme a posição do carro 3d na posição da curva mais bege. Cada posição 3d na estrada pode ser considerada um deslocamento ao longo da curva 3d ( t) + deslocamento lateral ( d). Verifique a imagem abaixo se ela não estiver clara (este é um exemplo 2d, mas isso se aplica a 3d facilmente).

quando t = 0 carro estiver no início da seção da pista, quando t = 1 carro estiver no final. quando d = -1 ou 1 carro está na fronteira da pista, quando d = 0 carro está no meio da estrada

2) alinhe o carro à estrada usando te d(muito simples: para qualquer valor te deu posso obter uma posição 3d + vetores para cima / frente / esquerda). o carro agora está colado na estrada

3) verifique o deslocamento lateral ddo carro. se o valor for muito grande (d > 1)ou se o (d < -1)carro estiver baixo , estiver fora da pista. basta prendê-lo para colocar o carro no lugar correto.

Isso também torna o abate em 3D muito simples, basta desenhar a pista da tposição atual do carro para t + some_big_enough_value_to_avoid_visible_clipping.

Ou talvez eu esteja completamente errado: teria sido muito mais rápido e mais simples verificar a colisão do carro (uma caixa delimitadora) e um conjunto muito simplificado de polígonos que representam a pista (sem os prédios e outros). O mundo 3d (e o modelo de colisão resultante) teria sido simplesmente gerado antes, usando alguma ferramenta de terceiros (sem mais curvas 3d ao executar o jogo, apenas um monte de polígonos).

Eu trabalhei em alguns jogos comerciais semelhantes aos que você descreve.

Em cada um desses jogos, na verdade tínhamos polígonos criando uma "parede" invisível ao longo dos lados da pista e realizamos testes de colisão tradicionais contra essas paredes. Isso significava que poderíamos ter alguns perigos colidíveis adicionais ao lado da estrada, dentro das paredes invisíveis, e também permitiríamos variar a largura da estrada mais rapidamente do que você normalmente pode com uma abordagem de spline.

Mas com isso dito, também fizemos o que você listou na seção Como eu acho que a colisão funcionaria para se proteger contra túneis / falhas de colisão, e esse sistema também foi muito usado para competir com a lógica da IA. Também o usamos para determinar quais carros estavam na liderança, para que pudéssemos exibir um indicador "1º / 2º / 3º / etc" no HUD. Às vezes, esses dados também eram usados ​​para reaparecer um carro após um acidente grave.

Uma parte que você perdeu na forma como acho que a colisão funcionaria é que, quando você está trabalhando com splines como esse, normalmente dá costelas aos splines. Costelas são bits de dados que expressam a distância que a trilha se estende lateralmente em cada direção a partir do spline. Portanto, para um spline de 100 metros de comprimento, você pode ter 50 nervuras, fornecendo a largura da trilha a cada dois metros ao longo de seu comprimento. Isso permite que sua faixa mude de largura ao longo de sua extensão. Nos jogos em que trabalhei, essas costelas também distinguiram entre "superfície da pista" e "área dirigível". Então, você teria um conjunto de larguras de estrada informando a que distância do meio do spline você tem um bom asfalto e, em seguida, outra largura dizendo a que distância a areia / grama / o que quer que esteja fora disso. Isso permite que os jogadores consigam percorrer uma distância razoável fora da pista, mas ainda assim a IA sabe onde estava a verdadeira superfície da estrada.

Muitos jogos em que trabalhei também armazenaram outros dados nas costelas; um jogo incluiu informações de iluminação nas costelas, para calcular facilmente se uma área estava ou não na sombra (que foi usada para a renderização do carro, para decidir se desenha ou não o reflexo da lente e outros efeitos). Outra informação foi divulgada sobre quais posicionamentos de câmeras cinematográficas poderiam ver essa parte do spline; portanto, não tivemos que fazer cálculos de linha de visão durante repetições. Outra ainda incluía informações sobre quantas faixas havia no spline, em qual direção elas foram e o deslocamento horizontal em que cada pista estava localizada. Isso nos permitiu incluir carros de trânsito que pudessem dirigir corretamente em faixas de rodovia. As nervuras são fantásticas para armazenar qualquer tipo de dados variados que você possa precisar sobre a superfície de sua estrada.

As nervuras são normalmente armazenadas em uma matriz associada ao spline. Por motivos de velocidade, uma implementação normal terá nervuras espaçadas uniformemente. Assim que você souber a distância de um objeto ao longo do spline, poderá calcular o índice de nervuras mais próximo na matriz dividindo a distância ao longo do spline pela distância entre as nervuras. Caso contrário, você estará preso fazendo pesquisas binárias na matriz de nervuras para encontrar os dados corretos de largura da estrada.

Sua descrição de seleção fornece uma boa descrição básica de como a abordagem de spline pode ser usada, mas na verdade é um pouco mais complicada do que você sugere - se você usar splines para seleção dessa maneira, longas voltas em gancho de cabelo geralmente não atrairão o lado oposto do turno, uma vez que, quando medido pela distância ao longo da pista, o lado oposto do turno pode estar muito distante, mesmo que a apenas alguns metros, quando o corvo voa. Além disso, as distâncias nas quais a geometria do mundo pode ser vista são tipicamente diferentes daquelas nas quais a malha da trilha pode ser vista, de modo que elas também não se encaixam nesse sistema. Minha experiência é que, na maioria dos casos, é melhor não confiar na lógica de acompanhamento de trilhas para determinar se um modelo deve ser desenhado; é muito mais confiável e faz com que menos falhas usem o teste padrão de frustum da câmera para isso.

No meu piloto OpenGL, eu comecei usando dois círculos para definir as bordas da pista, mas parecia um incômodo demais. Eu apenas uso glReadPixel para ler a cor do pixel. Se o carro do jogador estiver sobre um pixel verde (colorido na grama), o movimento será ainda mais limitado. Há muito pouco efeito no desempenho.