[et_pb_section fb_built=”1″ _builder_version=”3.7″ background_color=”#35363a”][et_pb_row custom_padding=”0|0px|0|0px|false|false” _builder_version=”3.0.48″ background_size=”initial” background_position=”top_left” background_repeat=”repeat”][et_pb_column type=”4_4″ _builder_version=”3.0.47″ parallax=”off” parallax_method=”on”][et_pb_text _builder_version=”3.0.74″ background_size=”initial” background_position=”top_left” background_repeat=”repeat”]
Result after heatwave:
The heatwave fortunately ended and it was possible to make progress. The first impovement was changing the octress so it allows higher subdivision levels than 2. The common octree has eight children which would represent a subdivision level of 2. Upon initialisation, the data structure is automaticaly adapted so it fits the subdivision level. The advantage of higher subdivision levels is the reduced overhead cost as the maximum depth is much lower so traversals and searches are much faster. However the memory requirement gradually increases with the subdivision level. A very large subdivsion level would transform the octree into a grid. Below are three examples of subdivision levels of 2,3 and 4. The texture tiling shows each block generated.
[/et_pb_text][/et_pb_column][/et_pb_row][et_pb_row custom_padding=”25.25px|0px|0|0px|false|false” _builder_version=”3.0.48″ background_size=”initial” background_position=”top_left” background_repeat=”repeat”][et_pb_column type=”4_4″ _builder_version=”3.0.47″ parallax=”off” parallax_method=”on”][et_pb_gallery gallery_ids=”1254,1252,1253″ posts_number=”3″ show_pagination=”off” _builder_version=”3.7″ title_font=”||||||||” title_text_color=”rgba(0,0,0,0)” title_font_size=”1px” custom_margin=”|||”][/et_pb_gallery][/et_pb_column][/et_pb_row][et_pb_row custom_padding=”0|0px|25.25px|0px|false|false” _builder_version=”3.0.48″ background_size=”initial” background_position=”top_left” background_repeat=”repeat”][et_pb_column type=”4_4″ _builder_version=”3.0.47″ parallax=”off” parallax_method=”on”][et_pb_text _builder_version=”3.0.74″ background_size=”initial” background_position=”top_left” background_repeat=”repeat”]
Result after heatwave:
The heatwave fortunately ended and it was possible to make progress. The first impovement was changing the octress so it allows higher subdivision levels than 2. The common octree has eight children which would represent a subdivision level of 2. Upon initialisation, the data structure is automaticaly adapted so it fits the subdivision level. The advantage of higher subdivision levels is the reduced overhead cost as the maximum depth is much lower so traversals and searches are much faster. However the memory requirement gradually increases with the subdivision level. A very large subdivsion level would transform the octree into a grid. Below are three examples of subdivision levels of 2,3 and 4. The texture tiling shows each block generated.
Allow different visual hulls:
The visual hull construction is not a part of the voxel engine and became a own component. The visual hull is an extra game object which becomes active then attached to the voxel engine as child. Currently the simple block visualisation and marching cubes are implemented. The marching cubes implementation is based on already existing source code by Scrawk which requires a point cloud as input and outputs the resulting mesh.
The algorithm requires “density” values between -1 and 1 and material becomes visible when the value is greater than 0. Therefore the whole byte range is used for evaluation and supports a range of 2-255 (0,1 are used for special cases). If a tool subtracts the value by 1, the mesh will gradualy deform untill it disappears completely. However updating the whole octress every update is very inefficient as only the region which changes should be updated. Therefore It was further adapted so the marching cubes algorithm is subdivided into regions.
Multithreading:
Further attempts have been made to allow multi core support for the marching cubes algorithm using the new unity job system. One big issue of marhcing cubes is that it takes a fixed input length but the output length is unknown. It is impossible to simply add the resulting vertices to an list as it will screw up the mesh due to race conditions. Fortunately this issue can be solved due to the fact that each cell has a maximum of 15 vertices. Therefore the output array must have a size of cellcount * 15. Another array then stores the length of each cell which is importend to build the mesh afterwards on the main thread. However the multithreaded approach works but it seems that there is not much performance gain. It seems that the reading and writing into nativearrays are the most expensive parts. The reason for this is unknown as I am not experienced enough in multithreadin.
Next Steps: VR
The next steps are about adding VR support. Therefore I need a project room in my university and a HTC-Vive as I dont have enough space at home for the VR device and the sculpting application requires enough space. Now its time to write the documentation. Therefore next weeks will be writing as in the meantime it should be possible to gain access to a project room and VR hardware.
[/et_pb_text][/et_pb_column][/et_pb_row][/et_pb_section]