Closed acs closed 4 years ago
In a summary: CREATE (memory)->TRANSFORM (memory)->RENDER (real build).
The current build will be implemented as: create, render
Use render or show? Render semantic is much better: "to cause to be or become". We take the data from memory and make real thing with it (inside Minecraft, Minetest, Blender ...). So let's use this word (which is the natural one in computer graphics design).
The idea is simple:
Let's start implementing it for a block, then a group of blocks and then migrate all to this new system.
Probably this ticket should be: Thing pipeline.
Thinking in creating Scenes in MagicaVox I have arrived to: https://github.com/jpaver/opengametools Pretty interesting.
First Things created using the new pipeline. Pretty close to have it working in all cases.
After the refactor to use the new pipeline
class Block(Thing):
def create(self):
self.set_block(Vec3(self.position.x, self.position.y, self.position.z), self.block)
self._end_position = self.position
The same code, but implementing create instead of build. And the set_block and set_blocks API are now in Things API (more clear).
When creating a new Thing, the renderer must be provided:
self.renderer = RaspberryPi(self.MC_SEVER_HOST, self.MC_SEVER_PORT)
block = Block(pos, self.renderer)
More clear than before, when the "renderer" was created hiddenly.
Next steps:
All done except:
Ok, all is now in develop brach! And I have created a new release: 0.49.0
So, for future iterations:
Next step is to update mcthings_extra and mcthings_scenes to use the 0.49.0 version.
Ok, after the work in mcthings_scenes we need to:
All working in mcthings 0.49.3 and mcthings_extra 0.0.16.
Pending to fix all mcthings_scenes! And we will be ready.
Just pending also to fix the building because houses how overlaps. But this is quick!
And "River and line for unbuilding need the block that they removed. This must be done in the renderer."
All implemented and working for mcthings_extra (0.0.16) and mcthings_scenes with mcthings 0.49.5.
Pending:
All done, releasing the 0.50.0 version!
As final thoughts:
All done!
After thinking during sometime about the Thing lifecycle, I think the best approach is:
Following this approach for all Things (all work is done in memory until the Thing must be shown) could let McThings to optimize the full process.
So load/create data and process it (rotate, decorate ...) must be done independently of building the Thing inside the engine (Minecraft, Minetest, Blender ...).
So the Thing implementation must not be inside the build method (which is an optimized generic method to build things inside the engine from data in memory) but inside the create method. With the Thing created in memory, we can process it with rotate or scale or find_bounding_box. For example, the to_schematic method will be much easier: just write the memory. You don't need to read the Thing from the already built Thing.
Let's try to implement it. My only doubt is that we could need something that it is only known when you built the Thing. But having the blocks ids and the data, and their position, is all we need AFAIK.
Working in memory is much faster always and abstract us from the engine.