projectbraf/braf
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs(repo): expand Arma 3 development guide
Deploy DEV Workshop / deploy-dev-workshop (push) Successful in 47s
Details

Browse Source
This commit is contained in:
Rodrigo Arantes
2026-08-02 18:23:50 -03:00
parent 3d2edb64c4
commit 6324a368de
1 changed files with 136 additions and 50 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+136 -50
View File
@@ -211,71 +211,157 @@ Consulte a referência oficial de [Event Handlers](https://community.bohemia.net
## Modelos, LODs e Object Builder
O BRAF usa modelos `.p3d`, materiais `.rvmat`, texturas `.paa` e animações `.rtm`. A geometria visual não substitui automaticamente as geometrias de colisão, visão, balística, física ou navegação.
O BRAF usa modelos `.p3d`, materiais `.rvmat`, texturas `.paa` e animações `.rtm`. Um modelo não é apenas a malha visível: os LODs determinam renderização, visão, colisão, penetração, PhysX, flutuação, navegação, sombras e pontos de integração com a configuração. Uma malha que parece correta pode continuar sem colisão, deixar a IA enxergar através dela, tornar a tripulação invulnerável ou falhar na água.
O [Object Builder](https://community.bohemia.net/wiki/Object_Builder) faz parte do Arma 3 Tools e é utilizado para editar modelos, configurar LODs, propriedades nomeadas, materiais e visualizar o resultado com Buldozer.
O [Object Builder](https://community.bohemia.net/wiki/Object_Builder) é parte do Arma 3 Tools, sucessor do Oxygen 2, e cria, edita e grava P3D **não binarizado (MLOD)**. Ele não é uma ferramenta para editar um P3D binarizado de release. No BRAF, modelos, texturas, materiais e animações existentes continuam protegidos: esta documentação explica o fluxo, mas não autoriza substituir, recriar ou sobrescrever um binário sem escopo explícito.
### LODs principais
### Contrato entre P3D, `model.cfg` e `config.cpp`
| LOD | Função | Cuidados principais |
| Camada | Define | Deve coincidir com |
|---|---|---|
| Resolution | Geometria visível em diferentes distâncias | Use LODs realmente diferentes e remova detalhes pequenos progressivamente; cópias idênticas não trazem ganho |
| View Pilot | Visão de piloto ou motorista | Deve refletir o que o ocupante realmente vê |
| View Gunner | Visão do atirador | Verifique torre, óptica, arma e animações relacionadas |
| View Commander | Visão do comandante | Verifique posição, escotilhas e instrumentos |
| View Cargo | Visão de passageiros | Verifique proxies e visibilidade dos ocupantes |
| Geometry | Colisão geral e interação com objetos sem PhysX | Componentes fechados, convexos e simples; a massa e o centro de massa importam |
| Fire Geometry | Colisão com projéteis e foguetes | Use geometria simplificada, materiais de penetração e proxies necessários para ocupantes |
| View Geometry | Oclusão e linha de visão | Deve bloquear corretamente visão do jogador e percepção da IA |
| Geometry PhysX | Colisão e simulação física de veículos | Mantenha simples; massa e distribuição de massa afetam diretamente o comportamento |
| Geometry Buoyancy | Volume de deslocamento de objetos flutuantes | Componentes convexos, simples e não intersectados; requer teste em água |
| Roadway | Superfície onde unidades caminham ou ficam | Não sobreponha Geometry; use superfície compatível e divida objetos muito grandes |
| Memory | Pontos de controle | Inclui armas, faróis, fumaça, escapamento, luzes, eixos e pivôs |
| LandContact | Pontos de contato com o solo | Essencial para veículos e comportamento de contato |
| Hit-points | Pontos de partes destrutíveis | Deve corresponder aos hitpoints declarados na configuração |
| Paths | Navegação da IA em interiores | Use pontos e seleções adequados ao espaço navegável |
| Shadow Volume | Sombra dedicada | Mantenha fechado, triangulado e separado por complexidade adequada |
| Wreck | Modelo ou geometria após destruição | Deve corresponder à propriedade de dano e à configuração do objeto |
| `.p3d` | LODs, seleções nomeadas, eixos, proxies, materiais, pontos do Memory LOD e geometria | nomes usados por `model.cfg`, `hiddenSelections[]`, `memoryPoint*`, torres, hitpoints e efeitos |
| `model.cfg` | `CfgSkeletons`, `CfgModels`, seções, ossos e animações do modelo | nome do P3D sem extensão, seleções, eixos e controladores reais |
| `config.cpp` / `.hpp` | `model =`, classe de veículo, `AnimationSources`, `hiddenSelections[]`, posições de entrada, turrets, hitpoints, efeitos e User Actions | caminhos, seleção, ponto de memória e fonte de animação existentes no modelo |
| `.rvmat` / `.paa` | material e aparência visual; material de dano no Fire Geometry | faces e seleções do LOD correto, além de caminhos com capitalização real |
A documentação oficial de [LOD](https://community.bohemia.net/wiki/LOD) descreve os tipos, limitações e fallback entre LODs. Os valores abaixo são orientações de trabalho, não substituem validação:
`CfgModels` é a interface entre o P3D e a engine: a classe deve usar o nome do arquivo do modelo sem `.p3d`, declarar suas `sections[]`, associar o `skeletonName` e conter as `Animations`. `CfgSkeletons` descreve cada osso e sua relação pai/filho. Já `AnimationSources` pertence à classe do objeto em `config.cpp`: ela fornece controladores nativos ou fontes `user` para as animações declaradas no `model.cfg`. A referência oficial de [Model Config](https://community.bohemia.net/wiki/CfgModels) detalha essa separação entre trabalho de arte e configuração.
- mantenha um único UV map quando a ferramenta e o asset exigirem isso;
- não trate `decimate = 0.5` como regra universal: preserve a silhueta e a função de cada LOD;
- use componentes `ComponentXX` fechados e convexos onde a engine exige geometria válida;
- a massa e a distribuição da massa são importantes para objetos PhysX;
- Fire Geometry precisa de material de dano/penetração apropriado;
- proxies de ocupantes devem existir nos LODs relevantes para evitar ocupantes invulneráveis ou invisíveis à IA;
- não presuma que Geometry, View Geometry e Fire Geometry podem compartilhar exatamente a mesma malha;
- valide o modelo no Object Builder/Buldozer e depois no jogo.
O repositório aplica esse contrato em várias famílias — `braf_air`, `braf_air2`, `braf_armored`, `braf_boat`, `braf_ships` e `source\braf_tracked` têm `model.cfg`. Um exemplo pequeno e útil é `braf_boat\BRAF_VLPV`: o `model.cfg` define esqueleto, `propeller`, `rudder`, `drivewheel` e `hatch`; `VLPV_base.hpp` declara a fonte `openhatch`, as seleções de textura e os pontos de água, motor, carga e entrada. Use-o para entender o vínculo entre os arquivos, não para copiar nomes ou propriedades para outro veículo.
### Named Properties
### Fluxo seguro no Object Builder
Named Properties são configuradas no Object Builder e normalmente devem ser escritas em minúsculas; a documentação de [Arma 3 Named Properties](https://community.bohemia.net/wiki/Arma_3%3A_Named_Properties) explica o comportamento da ferramenta e do binarizador.
1. Confirme que abriu a fonte MLOD correta e identifique o addon proprietário, o `model.cfg`, a classe de veículo e todos os consumidores antes de alterar qualquer seleção.
2. Trabalhe por LOD. Não use a Resolution LOD como substituta automática para Geometry, Fire Geometry, View Geometry, PhysX, Buoyancy ou Roadway.
3. Crie e mantenha seleções nomeadas para partes móveis, retexturáveis, hitpoints, proxies e eixos. Trate o nome como contrato: preserve grafia e capitalização já usadas pelo modelo e pela configuração.
4. Em LODs físicos, valide topologia antes de adicionar proxies: `Structure > Topology > Find Non-Closed`, `Close`, `Structure > Convexities > Find Non-Convexities` e `Component Convex Hull`; depois use `Structure > Check Faces` para localizar faces ou texturas inválidas. A referência de [Validating Geometries](https://community.bohemia.net/wiki/Validating_Geometries) descreve essas verificações.
5. Revise massa e distribuição de massa no Geometry LOD; em objetos PhysX elas afetam inércia, contato e estabilidade.
6. Use Buldozer como prévia visual de LODs, materiais, proxies e animações. Ele é configurado pelo Arma 3 Tools/P drive; a documentação oficial registra que iniciar o Object Builder diretamente pela Steam pode impedir a conexão com Buldozer.
7. Teste no jogo cada comportamento físico e de gameplay. Um P3D abrir no Object Builder ou renderizar no Buldozer não prova colisão, dano, PhysX, flutuação, Roadway, IA ou multiplayer.
Propriedades comuns incluem:
O Object Builder aceita P3D MLOD e outros formatos de importação, mas sua saída é P3D não binarizado. Não use isso como atalho para editar um asset de runtime, nem use packing ou binarização como teste de comportamento neste projeto.
- `lodnoshadow` para controlar sombra em LODs de resolução;
- `canocclude` e `canbeoccluded` para oclusão;
- `sbsource` para a fonte de sombra;
- `autocenter` e `reversed` quando o asset realmente precisa dessas propriedades;
- `aicovers` quando o objeto deve ser considerado cobertura pela IA;
- `buoyancy = 1` no Geometry LOD de objetos flutuantes.
### LODs de visualização e interior
Não adicione propriedades apenas por copiar outro modelo. Uma propriedade como `autocenter`, especialmente em veículos aquáticos, pode alterar o comportamento físico. O resultado só é considerado validado após teste do modelo no jogo.
O valor numérico de uma Resolution LOD não escolhe uma distância fixa no Arma 3. A engine seleciona LODs conforme distância, qualidade gráfica, carga e outras condições. Portanto, forneça níveis com complexidade realmente decrescente; cópias idênticas aumentam tamanho, memória e carregamento sem ganho. Proxies precisam existir em cada Resolution LOD onde devam aparecer, e uma seleção vazia usada por animação ou pela engine pode causar falha quando o LOD se torna ativo. Consulte [LOD](https://community.bohemia.net/wiki/LOD) para o comportamento de seleção.
### Geometry Buoyancy, Roadway e navios
| LOD | Responsabilidade | Verificação obrigatória |
|---|---|---|
| Resolution | Modelo externo visível; a Resolution LOD de maior detalhe deve preservar silhueta, materiais, seleções e proxies necessários | detalhe cai progressivamente, não há cópias idênticas, UV/material e proxies permanecem válidos |
| View Pilot | Interior visto por piloto/motorista | painel, visibilidade, mãos/controles, portas e partes ocultas não invadem a câmera |
| View Gunner | Interior e partes vistas pelo atirador | torre, arma, óptica, miras e eixos acompanham a posição do gunner |
| View Commander | Interior da posição do comandante | escotilhas, ópticas e instrumentos respeitam a câmera e a animação |
| View Cargo | Interior visto por passageiros | proxies de carga, posições, abertura de portas e visibilidade por assento |
| View Pilot/Gunner/Commander/Cargo Geometry e Fire Geometry | Geometria específica das posições internas quando a proteção, oclusão ou dano diferir por ocupante | teste primeiro pessoa, dano recebido e linha de visão em cada assento afetado |
| Shadow Volume / Shadow Buffer | Sombra dedicada nas resoluções próprias | não duplique LODs de mesma resolução, mantenha a forma simples e revise artefatos em luz forte |
| Wreck | representação após destruição, quando a classe/configuração a usar | modelo, material, hitpoints e transição de dano correspondem ao comportamento configurado |
Para embarcações e veículos anfíbios:
`LodNoShadow = 1` é a propriedade documentada para Resolution LODs. Para transparências que recebam sombras ambientais de modo incorreto, a BIKI indica `Forcenotalpha = 1` no Geometry LOD — nunca como correção automática para qualquer material alfa. Use a grafia da propriedade documentada ou já empregada pelo asset; não normalize propriedades por estética.
- o Geometry LOD deve conter a propriedade `buoyancy = 1` quando o objeto deve flutuar;
- o Geometry Buoyancy deve ser simples, convexo e sem interseções entre componentes;
- a massa do Geometry e a configuração do veículo devem ser coerentes;
- o PhysX Geometry e o Roadway devem ser testados separadamente;
- o Roadway não deve atravessar o Geometry de forma a causar tremores;
- navios longos podem precisar ser divididos em segmentos ou child P3Ds, cada um com geometria e roadway válidos;
- proxies visuais não substituem automaticamente a geometria física do objeto principal.
### LODs físicos, dano e visibilidade
Use as [Ships Config Guidelines](https://community.bohemia.net/wiki/Arma_3%3A_Ships_Config_Guidelines) junto com a inspeção dos P3Ds reais. Packing ou binarização não provam que flutuação, colisão, roadway ou ocupantes estão corretos.
| LOD | Responsabilidade | Regras práticas e riscos |
|---|---|---|
| Geometry | Colisão quando pelo menos um objeto não é PhysX; por exemplo, contato soldado-veículo | use `ComponentXX` consecutivos, componentes fechados e convexos, massa válida e espessura física suficiente; a engine usa massa e distribuição para inércia |
| Geometry PhysX | Malha de simulação física do veículo | mantenha muito simples, triangulada e coerente com o centro de massa; não a trate como cópia de alta fidelidade do visual |
| Geometry Buoyancy | Volume de deslocamento para embarcações e anfíbios | poucos componentes convexos, fechados, triangulados e sem interseções; volume e posição alteram a flutuação |
| Fire Geometry | Impacto de balas, foguetes e penetração | componentes fechados/convexos, material de dano/penetração aplicado, complexidade baixa; se ausente, a engine recorre a View Geometry e depois Geometry |
| View Geometry | Oclusão visual e linha de visão da IA | deve representar volumes que realmente bloqueiam visão; se ausente, Geometry é usada como fallback |
| Hit-points | vértices nomeados não conectados que localizam partes destruíveis | nomes, posição e espaçamento devem corresponder a `HitPoints` da classe e ao Fire Geometry |
| LandContact | vértices únicos de contato com solo | cada ponto precisa apoiar o veículo conforme sua simulação; não confunda com flutuação naval |
Para Geometry e Fire Geometry, a validação de convexidade não é opcional. O Object Builder pode gerar `ComponentXX` por `Structure > Topology > Find Components`; valide antes de inserir proxies. A BIKI também recomenda manter o Geometry LOD dentro do limite de tamanho: a referência histórica aponta instabilidade em torno de 50–60 m a partir da origem para a geometria, com variação por contexto. Não use esse número como limite garantido; trate-o como gatilho para testar e, quando necessário, dividir a composição.
Fire Geometry requer atenção adicional:
- inclua proxies de motorista e passageiros nesse LOD quando a tripulação deve receber dano; sem eles, ocupantes podem se tornar invulneráveis;
- aplique material físico de dano/penetração, não apenas o `.rvmat` visual;
- mantenha faces e componentes simples; a referência BIKI cita menos de 3.500 pontos como orientação;
- evite placas de Fire Geometry quase sobrepostas: o passo de simulação do projétil pode ignorar a segunda camada.
View Geometry não é decoração. Ela impede jogador e IA de enxergarem através do objeto. `canocclude` e `canbeoccluded` são propriedades de Geometry/View Geometry para casos específicos de oclusão; use-as somente quando a forma de oclusão não representar a forma visível, como vegetação perfurada. A página de [Named Properties](https://community.bohemia.net/wiki/Arma_3%3A_Named_Properties) deve prevalecer sobre valores copiados de outro modelo.
### Memory, Roadway, Paths e proxies
| LOD/elemento | Uso | Contrato de integração |
|---|---|---|
| Memory | pontos de arma, escapamento, fumaça, luz, efeito de água, entrada/saída, carga, câmera, PIP, eixo e ação | o texto em `memoryPoint*`, `memoryPoints*`, posição de User Action, torre ou efeito deve ser o nome da seleção do Memory LOD |
| Eixo no Memory | dois vértices com uma seleção nomeada formam eixo de rotação/translação | `axis =` de `model.cfg` deve apontar para essa seleção quando `memory = 1`; com `memory = 0`, o eixo pertence ao LOD do modelo |
| Roadway | superfície onde unidades ficam em pé e caminham | não pode sobrepor Geometry, ou o personagem oscila; é necessário abaixo de pontos de escada; textura da superfície também influencia o efeito sonoro de passos |
| Paths | rede de navegação de IA em interiores/estruturas | malha conectada, `posXX` para paradas e `inXX` para entradas; deixe folga de paredes e mantenha os caminhos cerca de 10 cm acima da superfície caminhável |
| Proxy | referência a outro P3D, ocupante, arma ou acessório | inclua-o nos LODs visuais em que deve aparecer e nos LODs físicos que realmente exigem sua presença; proxy visual não garante colisão, Roadway, dano ou PhysX |
O Roadway torna uma superfície caminhável para unidades. Não deixe Roadway e Geometry ocuparem o mesmo volume; isso causa oscilação. A BIKI relata instabilidade para componentes do Roadway a aproximadamente 36 m da origem, variando com mapa/célula, e limite menor quando o Roadway contém elementos animados. Para plataformas, pontes e navios extensos, teste cada segmento e prefira uma composição de P3Ds menores quando a superfície exceder esse comportamento estável.
Memory LOD é também a origem de muitas falhas aparentemente "de configuração". No BRAF, a classe de VLPV, por exemplo, aponta para pontos de efeito de água e motor, carga sling e entrada de piloto/carga. Um nome ausente ou em outra grafia resulta em efeito, entrada ou interação ausente. Partículas e certos pontos de arma podem ignorar deslocamento animado e usar a posição padrão do Memory LOD; confirme no jogo, não apenas no Buldozer.
### `model.cfg`, esqueleto e animações
| Elemento | Papel |
|---|---|
| `CfgSkeletons` | declara ossos e hierarquia pai/filho em `skeletonBones[]`; o filho acompanha a transformação do pai |
| `CfgModels` | associa o modelo ao `skeletonName`, declara `sections[]`/`sectionsInherit` e contém `class Animations` |
| `selection` | parte móvel ou osso/seleção existente no P3D |
| `axis`, `begin` e `end` | eixo local ou pontos que definem direção da animação; normalmente um eixo de dois pontos no Memory LOD |
| `source` | controlador nativo ou fonte declarada em `AnimationSources` no `config.cpp` |
| `memory` | informa se o eixo está no Memory LOD; o padrão documentado é verdadeiro |
| `minValue`, `maxValue`, `angle0`, `angle1` | mapeiam entrada do controlador para fase, rotação ou deslocamento |
| `sourceAddress` | define como entrada fora do intervalo é tratada, como loop, clamp ou espelhamento |
Os tipos usuais são `rotation`, `rotationX/Y/Z`, `translation`, `translationX/Y/Z`, `hide` e `direct`. Para uma porta, torre, leme, hélice ou trem de pouso, confirme na sequência: seleção existe no LOD visível; a seleção física acompanha a animação quando necessário; eixo está no lugar e orientação corretos; `model.cfg` aponta para ambos; a fonte existe em `AnimationSources` ou é um controlador nativo; a ação, script ou sistema do veículo altera a mesma fonte.
Se uma animação muda colisão ou proteção, copie a seleção para os LODs físicos atingidos, especialmente Geometry e Fire Geometry. Para animações de personagem, não trate `model.cfg` como substituto de `.rtm`, `CfgMoves` e `CfgGestures`: a referência de [Animations – Arma 3](https://community.bohemia.net/wiki/Arma_3%3A_Animations) separa animações simples de modelo das animações de estado de personagens.
### Propriedades nomeadas
Named Properties pertencem ao LOD, não à classe de veículo. Adicione somente uma propriedade com comportamento conhecido e aplicável ao tipo de asset.
| Propriedade | LOD usual | Uso correto |
|---|---|---|
| `LodNoShadow = 1` | Resolution | controla contribuição de sombra da Resolution LOD; não pertence a Shadow Volume |
| `Forcenotalpha = 1` | Geometry | correção específica para artefato de sombra ambiente através de material alfa |
| `canocclude` / `canbeoccluded` | Geometry e View Geometry | ajusta participação na oclusão; útil apenas para formas cuja oclusão não representa o objeto visível |
| `buoyancy = 1` | **Geometry**, não Geometry Buoyancy | habilita o uso de Geometry Buoyancy para barcos e anfíbios |
| `autocenter` | Geometry, quando o tipo de modelo exigir | altera referência/origem física; nunca defina `0` ou `1` por cópia, nem use como solução genérica de flutuação |
| `aicovers`, `sbsource`, `reversed` e outras | somente no LOD e caso documentados para o asset | mantenha a semântica existente e confirme na BIKI/vanilla antes de introduzir |
Não existe conjunto universal de properties para todos os modelos. Em especial, propriedades de origem e massa podem ter efeitos opostos entre acessórios, veículos terrestres, aeronaves, barcos e estruturas. Uma alteração de `autocenter`, `buoyancy`, material físico ou componentes de Geometry exige inspeção do P3D real e teste no jogo.
### Embarcações, anfíbios e navios
Para `braf_boat`, `braf_ships` e qualquer veículo anfíbio:
- coloque `buoyancy = 1` no **Geometry LOD**, não no Geometry Buoyancy;
- modele Geometry Buoyancy com poucas faces, componentes convexos e fechados, triangulação válida e sem volumes internos, interseções ou contatos desnecessários entre componentes submersos;
- faça a forma e o volume do LOD de buoyancy se aproximarem do casco que desloca água; massa e centro de massa do Geometry precisam ser coerentes com esse deslocamento;
- mantenha Geometry PhysX separado da geometria visual e teste massa, estabilidade, contato, inclinação e dano em água;
- mantenha efeitos de motor abaixo da linha d'água quando a configuração do veículo assim exigir; pontos de água, propulsão e esteira também são Memory points que precisam coincidir com a configuração;
- não use LandContact como evidência de que o navio flutua: o comportamento na água depende de Geometry, PhysX e Buoyancy;
- trate cada seção de uma embarcação modular como unidade física própria. Proxies podem resolver a aparência, mas não substituem Geometry, Fire Geometry, View Geometry ou Roadway válidos em cada área onde esses comportamentos são necessários.
A documentação de [Ships Config Guidelines](https://community.bohemia.net/wiki/Arma_3%3A_Ships_Config_Guidelines) alerta que navios grandes pressionam limites de tamanho, vértices, luzes, PhysX e Roadway. Como orientação, uma embarcação acima de aproximadamente 100 m pode exigir divisão em P3Ds/componentes menores. Isso não é uma licença para fragmentar qualquer modelo: primeiro defina a responsabilidade de cada seção, suas origens, LODs físicos e critérios de teste. Nunca conclua que uma composição funciona apenas porque o visual aparece.
### Diagnóstico por sintoma
| Sintoma | Camada a investigar primeiro |
|---|---|
| modelo aparece, mas pessoa atravessa ou colide de forma errada | Geometry, componentes convexos, massa, Geometry PhysX e tamanho/origem |
| bala atravessa blindagem ou ocupante não recebe dano | Fire Geometry, material de penetração, proxies de ocupante, Hit-points e configuração de dano |
| jogador ou IA enxerga através do objeto | View Geometry, `canocclude`/`canbeoccluded` e LOD de visão da posição afetada |
| personagem cai, vibra ou não caminha no convés | Roadway, sobreposição com Geometry, distância da origem, escadas e Paths |
| porta, torre, leme ou hélice não anima corretamente | seleção, eixo, `memory`, `CfgSkeletons`, `CfgModels`, `AnimationSources` e fonte usada pela classe |
| luz, fumaça, entrada, arma ou efeito de água está ausente | seleção no Memory LOD e string exata da propriedade `memoryPoint*`/`memoryPoints*` |
| barco afunda, inclina ou muda comportamento após dano | `buoyancy = 1`, Geometry Buoyancy, massa/distribuição, Geometry PhysX, volumes intersectados e configuração naval |
| textura variante não troca | seleção no P3D, `sections[]` do `model.cfg`, `hiddenSelections[]`, material e caminho real do asset |
### Validação mínima antes de considerar um modelo pronto
1. **Mapa de contratos:** confirme caminho do P3D, classe `CfgModels`, `skeletonName`, seções, seleções, eixos, proxies, `AnimationSources`, `memoryPoint*`, hitpoints e materiais.
2. **Object Builder:** revise LOD por LOD, named properties, massa, componentes, faces e topologia. Valide Geometry e Fire Geometry antes de inserir proxies.
3. **Buldozer:** percorra Resolution, todas as câmeras internas, sombras, materiais, proxies e cada fase de animação.
4. **Jogo:** teste colisão soldado/veículo, impacto e dano da tripulação, linha de visão da IA, assentos, torres, portas, efeitos, hitpoints, Roadway, Paths e, quando aplicável, PhysX, água e flutuação.
5. **Relato honesto:** diferencie checagem textual, validação estrutural no Object Builder, prévia no Buldozer e evidência no jogo. Binarização, packing ou geração de PBO não provam nenhum desses comportamentos — e não são executados como validação neste repositório.
Referências oficiais: [Object Builder](https://community.bohemia.net/wiki/Object_Builder), [LOD](https://community.bohemia.net/wiki/LOD), [LOD resolutions](https://community.bohemia.net/wiki/LOD_resolutions), [Model Config](https://community.bohemia.net/wiki/CfgModels), [Animations – Arma 3](https://community.bohemia.net/wiki/Arma_3%3A_Animations), [Named Properties – Arma 3](https://community.bohemia.net/wiki/Arma_3%3A_Named_Properties), [Validating Geometries](https://community.bohemia.net/wiki/Validating_Geometries) e [Ships Config Guidelines](https://community.bohemia.net/wiki/Arma_3%3A_Ships_Config_Guidelines).
## Texturas, materiais, sons e caminhos