Various thoughts:
- Ideally block types would be entities. This would allow them to have components to define their attributes which could be readily expanded on by mods, and allow the concept of health or hardness to be ripped out of engine. Currently they are sort of at a half-way point where they have both their own class and an entity, but it is a mess. I may clean this up a bit as part of integrating the new asset framework (since they way blocks are handled currently isn't a good fit for the framework) but it won't go all the way, at least in the first pass (because I want to get the framework in sooner rather than later).
That is what I would prefer as well. I was hoping that Block's were just another 'global' entity that you could put components on, though I noticed the entityref, which I am guessing was for that purpose in a round-about kind of way?
- Similarly block families would also be entities.
Likewise, everything should be an entity.
- I had some thoughts around blocks types being queried during chunk mesh generation for exactly which mesh to use based on their immediately surrounding 26 blocks, which would help avoid the need to quite so many block types (e.g. fences having a block type for each connection configuration). This wouldn't make sense for all blocks (stairs would still need multiple block types as their direction is independent of their surrounds). What this would look like, not sure - I guess an event sent to the block type entity ultimately.
That is precisely the kind of situation my changes are supposed to handle the, the BlockMeshGenerator subclasses should handle caching of meshes, choosing which mesh to do based on surrounding data, fluid level height decisions, etc... In my mod, for my ores for example, I will be choosing different overlay's to render on my blocks based on various ore data, density, and such.
- I think rather than having custom rendering code, chunk meshes should be rendered via entities with mesh components, same as everything else. This may require mesh components having some additional settings around rendering priority. This would eliminate the need for a special class for mesh generation for different aspects of block rendering - mods can just declare systems that generate a mesh and add it to mesh components.
That could potentially create a lot of new meshes just to render a couple of blocks. What I think would be nice (by programming style, unsure of speed without testing) would be systems that listen to a component on the base block type and a rendering call as normal, something like this (pseudo-code):
Code:
// In some System subclass
@ReceiveEvent(components = {MyMeshType.class})
void handleChunkRender(ChunkRenderEvent event, EntityRef block) {
// Handle your custom rendering here
}
This would have the effect of being able to render multiple things for a single block based on what components are on the block. I would also want the ChunkMesh to, instead of just having 4 'mesh' types internally, would want it to have a variable amount, each that can have different (or same) rendering flags. Reason I would really like that is to allow me to be able to put a group of blocks (think MC redstone) on its own 'mesh' array so I can update it far faster then re-rendering an entire chunk, but not so slow as to rendering each individually via a world Entity. This issue right here was the main reason that MC would become extremely laggy and 'delayed' in its chunk rendering with a lot of updates to blocks.
On the light leaking - that is an artifact of vertex lighting, I believe. I assume all the corners and edges of the house are exposed to light on the outside, so the light fades over the transition from the lit vertices to the internal vertices. A simple fix would be for the light of a side to be purely based on the adjacent position's light level. This would mean no smooth transition across blocks though. A further fix would to do the fading by checking lighting positions surrounding the side. Anyway, I believe either way the underlying lighting model is correct, but the application of it to vertices is wrong. Please feel free to correct this. Or there may just be an issue with the direction light is sampled from in the tessellator.
If vertex rendering is what it is doing then are vertexes being combined? That is the only way I could see them leaking is if corners on different faces are being combined, they would need to be kept on separate indexes so they have unique vertex colors per face. As for the lighting model on the vertices the vertices for each face need to be separate and they need to be aware of 'corner' blocks to know when light is blocking.
A question back, but where you say renderer do you just mean custom mesh generation for how a block generated into the chunk mesh, or do you mean something else? I probably wouldn't use the word renderer if it is not part of the rendering pipeline.
Sorry, I mean mesh generation, I will try to keep it separate.
I believe the event system is pretty efficient. It uses a dynamically generated byte code so that calling the event method be close to a direct method call. There is a some overhead in determining which systems are relevant for a given entity the event is called on though. I'ld say start with that, and if it isn't efficient enough we can optimise. Or at least do some metrics gathering and make an informed decision
. You will also need to decide if rendering is per block, or per block type - if it is per block type perhaps a fusion of the two techniques would work, with the event system used to fetch a rendering chain for each block type once at start up. If it is per block you pretty much have to do the events method as a block could change settings and components.
What I was thinking for the ultimate style would be for:
- Blocks to be entities
- During chunk rendering either do:
- Loop over each block like it is now and then send a mesh generation event to a World Block Entity if it exists, then send a mesh generation event to the base block entity that represents all blocks of that type in world.
- For each chunk, not each block, send a mesh generation event based on the chunk, then things listening to it would gather all block locations in that chunk (an iterator given by the Chunk for blocks) for components that are either on the block itself or on a world entity for that block that have a given component(s) then it would render all of the given blocks that use that component at once. This has a higher gathering cost to determine which blocks have given components, but the Chunk class itself could cache that information by seeing which components the systems ask for and recording when those blocks have those components added or removed over the game from then on into a map, this should fix the overall initial speed problem, and with being able to generate many at once then a lot of things can be done to speed that up too. This would be the more substantial change of course, but would be the most 'component-system style'.
Also note that if individual blocks have advanced rendering requirements such as animation, this can be done by not trying to render them in the chunk mesh at all but instead giving them their own mesh/skeletalmesh component, particle effect components, etc.
Yep, *many* of my blocks will have fairly complicated and large rendering requirements that are not animated. In MC I render those to the static world chunk mesh and that is fine, if I rendered them individually, well, there could be, quite literally, hundreds of thousands within chunkloading distance, so that would be infeasible. Animated blocks of course would have to be custom-rendered, but honestly those should not be rendered individually but since those are World Entities there should be a System for a given component that takes all that are currently 'renderable' in world and handles their rendering, that way they can do custom distance checks or other criteria, can batch them up all at once (a great speed boon in many cases!) and more.
P.S. Please excuse spelling/grammar, currently am out and about instead of programming.
