Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFC]: 3D models, lighting, and glTF #2543

Open
1 task done
bobbens opened this issue Feb 3, 2024 · 1 comment
Open
1 task done

[RFC]: 3D models, lighting, and glTF #2543

bobbens opened this issue Feb 3, 2024 · 1 comment
Labels
Type-Enhancement Issue refers to a vector of improvement for Naev.

Comments

@bobbens
Copy link
Member

bobbens commented Feb 3, 2024

Suggestion

Naev 3D Models Proposal

This is a proposal to add flexible 3D models to Naev using Physical-Based Rendering (PBR).
Main format will be glTF which is open source and meets the demands of the project with lots of tools to manipulate and work with them.
The main idea of the proposal is to apply to ships in Naev, but it should be able to extend to space objects, munitions, and other things when applicable.

In-game Usage

Models will be loaded once with meshes and textures shared by URI when possible.
Shaders will use some hard-coded camera and view transforms, with different vertex shaders for store / comm / etc.
Should be API to override this or allow access to a more general shader that requires manual set-up.
There will also be Lua API to load, render, and manipulate different parts of the 3D rendering system.

Space Lighting

  1. Use ambient + 3 point lights for default lighting.
  2. Allow changing ambient lighting to simulate scattering in Nebula / Haze / Plasma Storm / etc...
  3. Allow having up to 3 extra point lights that can be controlled by scripts. This would allow the "stars" in the background in the different systems to also affect the ship model and give better effects.
  4. Variational Shadow Maps will be used for all light sources when applicable.

glTF Specification

The idea is to use a minimum number of extensions, and try to make most of the base glTF format.
glTF files for use in game should be able to be generated from a recent version of blender

  1. Each glTF file will require a single scene, but additional scenes can be used to give more advanced effects.
    1. base: will contain the base model. This is what will be rendered by default and also used by the collision polygon creation system.
    2. engine (optional): will contain the base model + engine glow.
    3. lod_base (optional): a lower polygon version of base that will be for rendering small ships in space.
    4. lod_engine (optional): similar to engine, but low polygon.
    5. shield (optional): used to show flickering of a shield over the ship.
    6. collision (optional): used to create collision polygons if applicable.
  2. Do not allow extra lights per scene, for extra lighting such as blinking lights, have blender "bake" it into textures, and use animations to make it work. Blinking lights should be able to be implemented in this way.
  3. Materials can define "NAEV_noShadows": true' extras property to have the object neither receive nor emit shadows. This would mainly be used for the engine glow parts. This is supported as a custom property in blender.
  4. Animations will be supported when possible. Will probably have to support KHR_animation_pointer (not official yet, but close, KHR_animation_pointer KhronosGroup/glTF#2147 )

Other Notes

  1. We'll probably need some source of simple subsurface scattering for Soromid bioships, although I'm not certain on what yet. Maybe support KHR_materials_sss, although that seems like a pretty early stage draft.
  2. Models need a lot of fixing and work, there will be a separate issue for this.
  3. Animations and shields are not currently implemented yet, with animations likely depending on blender getting KHR_animation pointer support.
  4. It's not clear how to do the fade in/out with engine now, although doing two renders and interpolating the resulting images would be a possibility at the cost of extra computation cost.
  5. If we modify the models to have the concept of primary (and secondary colour), that could be an RGB value that multiplies the texture, it would allow us to let the player colourize the ships too, which would be really cool.

Code of Conduct

  • I agree to follow this project's Code of Conduct
@bobbens bobbens added the Type-Enhancement Issue refers to a vector of improvement for Naev. label Feb 3, 2024
@bobbens
Copy link
Member Author

bobbens commented Feb 4, 2024

Edited to mention adding primary / secondary colour to ships.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type-Enhancement Issue refers to a vector of improvement for Naev.
Projects
None yet
Development

No branches or pull requests

1 participant