siebencorgie / jakar-engine Goto Github PK

Currently the engine config is created at creation time and used.
Best would be to

• Save the config of the engine as .ron file
• Create a seperate graphics configuration
• use the graphics configuration at renderer creation time

I am currently having a rather strange normal mapping issue with my TBN matrix which leads to incorrect behaviour of light and its sources. However I don't know why. It might be an input problem. I am going to investigate this as the next issue because it seriously hurts the graphical appearance.

Currently there is no nice way in Vulkano to create a pipeline from a shader file. That's why I am currently creating only one "master" shader which is used by every material. However, I want this to be changeable.

While working on #8 i found out that it would be better to have an Pipeline builder object to make the pipeline as configurable as possible.

Currently the lights can sit within a tree (together with attributes like location and rotation) but they also hold location and rotation withing the light struct.
In the future the location and rotation sent to the shader should be optained from the node attrbutes.

Coming with the next push, the engine will sort every mesh based on the distance to the player, then the farthest objects will be rendered first to get a correct blending behaviour for the transparent objects. However, this is not optimal.

I'll have to integrate flags for meshes based on their material, then only sort the transparent ones and draw them last.
reference: #19

All the textures are currently not having any mipmaps. However, since I want to be able to seamlessly import the images from the gltf format I would have to create the mipmaps on the run, maybe store them somewhere after first import, but still, they would have to be generated.

Idea: Take the image and blit it to a half sized new image several times till we reach a dimension of 1x1.

Create the vulkano::instance::ApplicationInfo struct at creation time to fill the first parameter of vulkano::instance::Instance::new() This way, at some point, drivers could better recognise the engine and its application/game

Currently only the swapchain images are recreated when the dimensions change, but we have to recreate the depth buffer image and later any other intermediate image as well.

While investigating the alignment problem (SiebenCorgie/ori-engine#16) I found out that this part:

#[derive(VulkanoShader)]
#[ty = "vertex"]
#[path = "data/test.vs"]
struct Dummy;

Actually creates all struct in the shader as Rust structs.
That's the reason why I'll move the shaders to a "One shader = one module" abroach.
The in this ways the material can, based on the pipeline send the correct, filled struct to the shader.
For instance for the directional lights a vertex_shader::directional_lights struct created from a struct definition in the shader. The struct creation might be handled by the shader itself though. I'll see.

It would be nice to load the shader at compile time to a string, analyse the "main shader" string and if a special keyword like #include is in there use the following name to replace this line with another string aka a shader part.

This way I could ensure that input structs are always the same size and the guy who writes the shader also has to write a shader just once.

However, atm the structs are set in a *.glsl file and the shader-writer has to copy them manually.

Intergrade the gltf crate to load new models and preserve scene hierarchy as well as materials and light.

One job of the manager should be to delete stuff that is no longer used. I think this could be done by counting the references of the Arc's stored in the manager, if weak and strong are both 0 it could be deleted.

Currently all buffers send to any shader are CpuAccessibleBuffer. However, most of them don't need to be read by the cpu again after creation. So after I got the clustered culling to work, I have to change them to the right type each.

At the moment I don't use any of the specialisation constants, However, with the new, dynamic pipeline creation workflow it should be easy to define them as well.
I just have to decide if it should be defined by the engine (there for the same number in every pipeline) or if it should be set on a per pipeline basis.

Currently, if you change something in the tree (like translating a node) it is done for every child at once.
It would be nice to record a Vector of things to do into a tasks field. When calling update on a tree every task will be executed. This way the system would have to "walk down" the tree only once per update, instead of several time (once per action).

API mock up:

• update(&mut self, jobs: Option<Vec<Job>>) : applies all jobs, then applies its own jobs, after that appends its own jobs to the recieved jobs and passes them down to all its children

• add_job(&mut self, new_job: Job) : Adds new_job of the enum Job to the nodes tasks field.

The only thing which could be optimized after that is some kind of "Scene Registry" which keeps a pointer to every node, sorted by their names. This way the get_node() function could become faster. But we would have to store this big registry.
We'll see if its needed when building scenes at a bigger scale.

Currently every descriptorset (except the one for the light data) is coming from Persistent descriptor sets. However I found out that it is much faster to allocate from a pool. Therefore I should implement them where needed/ appropriate.

The current asset manager is not thread save. However, it should be to make it easier for tools in other threads to access and manipulate data.
This will include to change all types to Arc<MutexT>> Types as well as implementing automated MutexGuard borrowing for the front-end functions like get_scene_manager() which should return a scene_manager::SceneManager and not a Arc<Mutex<scene_manager::SceneManager>>.
There will also be a get_scene_manager_copy() which will return the Arc<Mutex<T>> type.

Together with making it thread save there should be this implemented: SiebenCorgie/ori-engine#26

Make the frontend more "pretty".

Currently loading and adding models as well as loading and adding textures is a bit ugly but could be made nice quiet easily with some lines of code in the asset manager.

For easier sorting I'm going to add flags like "transparent" or "draw_shadow" to nodes or meshes.

At the moment the engine gets configured at run-time by some hard coded values which could be loaded nicely from a file as well.
There are several ways to handle configuration. I think the best way here would be either some "ron" file or some json files.

They could groupe the configuration into several topics like "game", "physics", "gameplay"/"runtime", "graphics".

Currently the bound of an object doesn't move with its object, however this should be.

Currently only the get_all_meshes() function can sort based on requirements. But this should be possible for all get-er functions.

The asset system currently gets updated in the rendering thread. This should be moved to a parallel approach which updates all "dirty" assets in fixed time steps.
The time steps have o be found out but I guess something around 120 times / second is a good speed. Might be configurable.

I'll have to create GUI system.
What I am currently thinking about, at least for the editor:
A GUI rendering pass which is blended with the already rendered scene.

The components of the GUI should be created in a separate, single threaded environment. Each GUI element can be described by some mathematical property (origin, width, height). An algorithms is creating the vertices setup based on them as well as based on some "theme" textures.
Most basic elements for an editor:

• Spacer
• Button (with Icon representation)
• Text field
• Notebook
• Relationship graph (maybe later, but would be good to have it for the scene graph)

However, the whole thing might be big enough to be moved into an custom crate.

Well, for some better screen effects like blur, bloom and HDR I need to add some post processing passes to the render pass, I plan to make the configurable as well (maybe with specialisation of the renderpass at vulkan context creation time). However, I need to make the renderer a little bit more modular before doing this.

Also might make it possible to create debug views like a "depth" or "normal" view. But they should be dynamic changeable.

Currently the render is ticked each frame by the main module. however, this should be changed to a rendering thread which also gets properly joined at the end of the runtime.

The title says it, the issue is primarily here to remind my self to add this feature when starting the renderer, I have no idea how at the moment tough.

I'll have to create a PBR Shader to test the light system for:

• Data correctly send
• Enough data send
• dynamic enough for applications
• capable of representing gltf models

The new winit version made the EventsLoop unsendable. Now I have to find a way to first start the Eventsloop and the renderer in parallel, then wait for the vulkan instance in the window creation and send back the window or something... have to find out the best way.