Code Monkey home page Code Monkey logo

cubos's Introduction

Cubos Engine

Cubos Engine logo

Voxel based engine

Cubos aims to be a simple, but powerful game engine for PC, where everything is made out of voxels.

It is open source and free to use for any purpose. Written in modern C++ (20) and with data-oriented design in mind, its goal is to be both performant and highly flexible.

Learn more

Check out the project's website which contains the documentation, guides and examples on how to use the engine.

Who is making this engine

Cubos is developed by a team at GameDev Técnico, a student group at Instituto Superior Técnico who makes games. Our goal is to build a game engine from the ground up and have fun doing it.

Join us

If you're interested in joining us or learning more about the project, join our discord server!

cubos's People

Contributors

dacops avatar dannyisyog avatar darkerqueensara avatar diogomendonc-a avatar diogomsmiranda avatar edswordsmith avatar fallenatlas avatar joaomanita avatar joaopat98 avatar josegraca96256 avatar luishfonseca avatar ratuspro avatar riscadoa avatar roby2014 avatar rsubtil avatar scarface1809 avatar tomas7770 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar

cubos's Issues

Window/Input Manager

  • Create windows
  • Input Bindings
    Hardware that is connected to specific actions (WASD, Spacebar, left joystick, etc.)
  • Input Actions
    Specific actions that result from a player's input (move, jump, etc.)

Support compressed streams

Implement the Stream interface for a compressed stream.
The usage should be similar to this:

Stream& originalStream = ...;
CompressedStream compressedStream = CompressedStream(originalStream);

Such that when any data written to/read from the compressed stream is first compressed and then written to the original stream/read from the original stream and then decompressed.

The Zlib library may be used to implement the compression/decompression.
This feature will be useful for implementing compressed archives for loading engine resources.

Restructure Build Targets

The building pipeline should be able to generate:

  • cubos-core (library) - includes all the core modules of the engine that will be used by the systems. This should be easily testable
  • cubos (executable) - links cubos-core with an entrypoint that is responsible to load all assets into a game. Also includes all the systems necessary to execute the game (e.g. rendering, input, etc...)
  • cubos-editor (executable) - a standalone application that links cubos-core and helps creating assets that will then be loaded by cubos

Decide Window implementation at runtime

As it is, the Window class isn't abstract and the implementation is chosen using macros. This should be changed to having an abstract Window, and another class GLFWWindow which implements the previous one.

This way we can switch between different window implementations (eg.: GLFW vs WinApi) at runtime which would also allow us to easily switch from OpenGL to DirectX, without recompiling the engine.

Renderer prototype

  • 3D Grid representation
  • Triangulate 3D grid
  • Draw Object
  • Camera Implementation

Renderer

  • Utility function for sending vertex data to GPU (for testing).
  • Function to register models, should return an identifier so that the rendering of the model can later be requested.
  • #87
  • #88
  • #89
  • #90

Add cmake alternatives for game engine and testing

Use an option to determine the executable being generated.
By default the engine should be run as the game engine: invoking entry.cpp's main function.
In the other cases, it should run the test executable.

Abstract render device (gl wrapper)

  • class RenderDevice
  • class ShaderStage
  • class ShaderPipeline
  • class ShaderBindingPoint
  • class ConstantBuffer
  • class Texture1D
  • class Texture2D
  • class Texture3D
  • class CubeMap
  • class Sampler
  • class VertexBuffer
  • class VertexArray
  • class IndexBuffer
  • class RasterState
  • class DepthStencilState
  • class BlendState
  • class RenderTexture
  • class DepthStencilTexture
  • class Framebuffer

Define voxel data structures

Properties for each voxel in a model will be defined using a palette.
Palettes can use different index sizes (8-bit, 16, 32) depending on how many materials are needed for the model.
Palettes can be shared between models.

First Implementation of voxel structures:

  • Simple 3d grid (Array)
  • each slot in the grid contains index of the material within the model's palette (first index (0) will be considered as empty)

(IDEA)
2 Different palette types:

  • Gpu Only: data sent to shaders (only properties needed to draw the model)
  • Engine: Contains other properties of the voxels, such as physics info, metadata, etc.

Restructure directories to accommodate systems

Since we'll start working on the engine systems, we now need to separate the core sources from the engine sources.
The current src and include folders should be moved to a core folder.
A new engine folder should be created which contains the engine sources.

With this change it makes sense to also move the samples and tests folders to the core folder.

Shadow Mapping

  • Spot Lights
  • Directional Lights (CSM)
  • Point Lights (Cubemaps)

Debugger/Logger

  • Log on request
  • Logging levels (Critical, Warning, Error, Info, Debug)
  • Error Reporting
  • Directing logging output

Consider SPDLOG

OpenGL 3.3 render device implementation

This issue is a follow up of #9
A OpenGL implementation of cubos::gl::RenderDevice will be provided on includes/gl/ogl_render_device.hpp.
The targeted OpenGL version will be 3.3, since it has wide support.

  • class RenderDevice
  • class ShaderStage
  • class ShaderPipeline
  • class ShaderBindingPoint
  • class ConstantBuffer
  • class Texture1D
  • class Texture2D
  • class Texture3D
  • class CubeMap
  • class Sampler
  • class VertexBuffer
  • class VertexArray
  • class IndexBuffer
  • class RasterState
  • class DepthStencilState
  • class BlendState
  • class Framebuffer

Support compressed archives

We should provide an implementation of Archive for mounting compressed files/directories to the virtual filesystem. This would require adding an external dependency such as zlib.

Improve Settings

The settings functionality needs to be enhanced:

  • other settings types should be added (ints, doubles, booleans).
  • make it so that there are both a global settings object and local settings instances.

Allowing local setting instances will be useful for reading/storing settings separately for the engine and the game.

Settings

- [ ] Parse Settings File

  • Retrieve Settings on request with required defaults
  • Update Settings values

Add contribution guidelines to README.md

The README.md file is missing the contribution guidelines:

  • pull requests should have a clear description of what they add
  • code must be formatted using clang format
  • camelCase is used for functions, methods, local variables and fields (no underscore prefixing on private fields)
  • PascalCase is used for class names
  • UPPER_CASE is used for macros
  • snake_case is used for namespaces, folders and files
  • each file should have an #ifndefinclude guard
  • when closing a namespace the namespace name should be added as a comment, the same goes for if macros (#ifdef, ...)
  • namespaces should match the directory structure, except namespace impl, which can be used to hide implementation details (check cubos::gl::impl)
  • everything should be well documented (/// style, check already existing files)

There should also be a mention to the gh page with documentation.

Octree Testing

  • Octree memory implementation
  • Analyse Compile time / Runtime drawbacks/advantages of octree
  • Triangulate Octree
  • Draw Octree object

CMake dependency search enhancement

Instead of having options for using submodules or not, we can use find_package by default. If find_package fails, the submodule is used as a fallback.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.