Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement polygon-based tools #376

Open
Poikilos opened this issue Mar 17, 2020 · 0 comments
Open

Implement polygon-based tools #376

Poikilos opened this issue Mar 17, 2020 · 0 comments
Labels
bucket_game formerly Bucket_Game enhancement

Comments

@Poikilos
Copy link
Owner

Poikilos commented Mar 17, 2020

The current system of generating tools creates a ridiculous number of polygons for a tool that is 64x64 or more (the number of polygons in a 32x32 tool is also very high). Ironically, making a mesh for each tool would use far fewer polygons.

Example:

  • a rod that is 20x20 pixels diagonally (such as for a tool) and about 3 pixels wide
    • polygon count:
      • front & back: 20*3 + 20*3
      • right & left (with stairstepping since diagonal, so multiply height by 2): 20*2 + 20*2
      • bottom: 3
      • subtotal: 203, but Multiply ALL by 2 due to converting quads to tris
      • TOTAL: 406
  • For contrast, a 3d modeler could produce a mesh like that in 30 seconds that has only 20 tris!
    image

Possible solutions:

  • Add a feature to Bucket_Game to use a mesh for a tool, if that is backward-compatible (does not require an engine change). If not, then:
  • Add a "smart" 3D object generator to the engine (This is definitely backward-compatible, but the improvement will only be visible in clients that have the feature [I guess]). A tracing function (as opposed to the current function which is a voxelizer) can generate the 3D model that is far more efficient. Intelligently choosing which parts to make smooth or sharp on the edge is possible--basically, any extension that has a continuous thickness can become a shaft. Basing the model on an extruded rectangle (put implemented as making a "hill") would be much easier to program and still have the same savings or more. This would change the style from voxel-style to a smooth style, so it should be optional. Customizing and using an existing heightmap generator is possible if the code is changed to: 1. convert color to grayscale (lighter if farther from edge, calibrated by farthest as 100% aka white) 2. account for alpha (change to A>255 black but retain A, trim parts of the model where alpha is below a threshold or even just delete all points on the outer edge). Here is a list of heightmap projects with detail optimization:
    • hmm (C++11, MIT License)
    • tin-terrain (C++, MIT License; needs certain changes since caters to GeoTIFF)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bucket_game formerly Bucket_Game enhancement
Projects
None yet
Development

No branches or pull requests

1 participant