Added a Material system.
It has an object name called SurfaceMaterial, and the engine only exposes the ISurfaceMaterial interface to clients.
If you pre-set shader system values, blend state, depth-stencil state, and rasterizer state values in Json format, it will read the json file and set the corresponding shaders and various render states.
Similar to Unity.. but made with json5 format instead of a self-made format.
If you make your own format, you have to create a parser and a routine for verifying the parser, which makes it more complex.
When actually building a game, Json is built into binary.
In the future, I plan to create/set json from tools rather than writing json directly. (Minimize manual work on data)
When creating a material system related to shaders, it is roughly divided into three categories like Unity or Unreal.
Shader parameter values set at the beginning of the frame
Shader parameter values set at the beginning of a pass.
Light view matrix, setting values matching the render group properties (shadow pass, lighting pass, particle pass, model pass, etc.)
And values that change for each draw.
World matrix of each object (position, rotation, scale), state value of each object (blinking when hit, darkening when poisoned, dissolving when dead)
Shader states are adjusted in this way, divided into three or four categories. This is how complex engines like D3D examples and Unreal5 ultimately handle it.
Since frequent state modifications slow down performance.. states that are similar are grouped together as much as possible to reduce changes.. this is called 'batch rendering' or 'batch processing'. Grouping and drawing.. what does this mean?
I planned to make it similar to Unity's SRP Batcher from the beginning, so I will go in a similar direction.
However, Unity is a general-purpose engine, so it has to allow a wide range of client permissions, which inevitably leads to higher memory consumption.
I designed it so that batch processing can be done by fixing a memory block and minimizing memory reallocation as much as possible, setting a maximum of 176 bytes for users to set per material.
Even then.. if you exceed 176 bytes.. it is designed to spit out error logs at the compile level and execution level.
All material files can be loaded synchronously or asynchronously.. After making an asynchronous loading call for the json material source, even if the loading is not yet complete, you can pass a json source pointer to SurfaceMaterial and apply synchronous or asynchronous loading. It's designed to automatically execute the next loading after the internal json asynchronous operation is completed.
The json parser uses yyjson, an open-source library, with a thin wrapper. yyjson is the best json parser written in C and is really fast. It even makes memory allocation within its core using mimalloc, which I wrote for CoreService of my engine's core_heap.h, making it faster than the original yyjson source.
Now that the material system has been completed in the first phase, let's solidify it once more. It needs to be stabilized and API documentation list and Material Format document need to be created.
The world is so much easier now that Claude code understands the structure of my engine and can create it automatically. In the past, I spent a lot of time making everything myself, but now it's done in minutes.. there's a huge difference in productivity.
Now that the Material system is created, it's time to create a basic UI system.
Thank you. If anyone needs the source code I've worked on so far, please send me a separate message and I'll send it to you.. I can bundle the md file I worked on with AI.. but the code is not complete yet. ㅎㅎ
