blueskythlikesclouds / hedgegi Goto Github PK

• Scene Saving:
  Currently it is not possible for a user to save scene settings in HedgeGI, IE - scene specific Sky Intensity, etc. Being able to save your scene settings and work from them later would be a big boost for user experience.

• Omni Shadow Casting
  An option to disable shadow casting on Omnis would be useful for certain use cases.

• Lightfield Settings/Visualization
  Currently Lightfield settings do not have any way for the user to intuitively understand them. Tooltips when hovering over them would be a big help. Additionally, being able to visualize the lightfield within editor can help users understand how these values work as well.

• Lightfield Zones
  Currently HedgeGI generates lightfield across all geometry in the scene. If a user wants to only target areas where the player can interact, they must create an entirely separate stage import with only the required geometry.
  For future functionality, I believe we should have the ability for a user to designate areas where lightfield should be generated. Whether by drawing on the scene, or even through the use of simple cube volumes.

• Material Editing
  While this may be outside the scope of the project, I believe that being able to modify materials within the editor and see how the changes contribute to the would be extremely useful. One major usecase would be emissive materials and their contribution to GI.

• GIAtlas Resolution Reference
  The ability to point HedgeGI to the Render Output List generated by GIAtlas Converter would be a big help towards cutting down on rendering times.

While this makes sense in 99% of cases, it would be very useful to have the feature to toggle this on a per-mesh basis similar to Unity3d. There are certain circumstances where the user may want to have a light cast through a mesh.

Going to write this stuff down so I don't forget.

• Utilities.h needs to be split into multiple files. I kept slapping random functions there over the years and it turned into a mess. Possibly separated into files like Path.h, Math.h, BRDF.h, etc.
• Contribute all the HedgeLib style source files back to the project and remove them from HedgeGI.
• Sort the file I/O functions to be more like HedgeLib. Some of them are parsed manually, some of them are loaded directly. Bad and inconsistent.
• NEVER use PropertyBag directly for data manipulation. Use property bags only during load/save time. Should store and manipulate relevant parameters from the scene classes directly.
• Replace OpenGL with D3D11 or D3D12. Wouldn't it be funny if I used DLSS/FSR for the path traced image in the viewport?
• Game type is not stored in the scene, making handling Unleashed/Generations/Lost World shading at the same time impossible. This is going to be worse with Frontiers as it uses different PRM channels.
• Combine bake & scene parameters into a single class and pass that to the baking factory. Should make accessing certain data easier. This means getting rid of RaytracingContext.
• Could separate sample counts for light field & GI.
• Archive I/O classes that handle compression need to be grouped together.
• Material system needs to be redone completely. Path trace function is incredibly long right now and doesn't need to be. Certain shading features could be toggled by checking flags directly stored in the material instead of relying on templates like targetEngine. This will also make handling shading differences between games easier.
• All types stored in the scene class should be replaced with inline declarations instead of using unique_ptr.
• Classes like Mesh, Material, etc. should store indices to relevant objects instead of referring to them with pointers.
• Vertex class should be scrapped and deinterleaved data should be utilized instead. Even better if all the data is stored globally in the Scene class in a single collection and meshes index into them.
• Been considering grouping files into folders in the filesystem instead of VS but I'm not sure yet.
• Embed shaders and other data into the executable through other means instead of using Windows' god-awful resource API.
• Could yeet some dependencies, I don't think I need parallel hashmap anymore.
• A lot of utilities like PostRender are static classes right now, is that actually OK?
• Document class is inefficient as hell right now with all the recursive lookups, could auto-generate a shared linear array enough to store all kinds of components and gather them from there instead.