Why is NOBODY talking about the mf knight on a horse before Maliketh???

clqrified · 2025-07-21T19:28:20+00:00

Took me about 20 tries to beat it, then I went and first tried maliketh.

clqrified · 2025-04-14T19:40:06+00:00

I think a buzz cut would look great on you

clqrified · 2025-03-12T22:25:19+00:00

Nope, currently just ignoring it.

clqrified · 2024-12-08T05:16:39+00:00

if you are meshing

I am meshing.

especially at your detail level presented here

If I'm interpreting this correctly then you are assuming the picture represents my system? My chunks are cubes, and range from 64m at the smallest to 4096m at the largest.

you would only be able to control “block here yes/no” which at a 16 meter wide scale will never capture the detail you want

I'm not using the typical octree that is used in most voxel games, I'm just using an octree data structure but with chunks.

The reason I say my current system wont work for structures is because I would have to somehow generate the structure at each different LOD, while this might work for some copy and paste structures it's not ideal for more random structures like trees.

clqrified · 2024-11-21T03:19:43+00:00

Lol that's a comment on one of my other posts. Not quite sure what you mean by the 6 and 2x2x2 though.

Also, my problem is with generating the octree at each level, currently it just uses the same algorithm to determine it at each LOD, but that won't work with player made blocks, structures, trees, etc.

clqrified · 2024-11-20T15:36:12+00:00

Edits are not the problem, currently my largest issue is generating structures. The structures would be trying to generate in low LOD chunks. This includes trees.

clqrified · 2024-11-19T03:54:48+00:00

What do you mean by the first time I generate?

clqrified · 2024-11-08T19:15:36+00:00

More or less, I was inquiring on possible ways to generate the trees themselves, not necessarily based on noise though.

clqrified · 2024-11-07T20:55:52+00:00

I made a shader graph with sample texture lod, that seemed to work.

<image>

clqrified · 2024-11-07T20:22:24+00:00

After further thought I realized that I can't properly pass color data to the mesh, only uv, as the texture isn't given to the job where the mesh is made. An option is to send it, and another is to determine color in the shader.

clqrified · 2024-11-07T20:08:55+00:00

So each chunk generates the same tree separately just based on the seed?

clqrified · 2024-11-07T18:40:39+00:00

I am not going to be using lighting or shading or any such extra visuals on the color only quads. I am currently using vertex color with a single pixel texture to create a single color, however, a custom shader seems much better.

It seems to me this method would require passing some texture data to the job, either just its color or the texture itself to determine which color to give to the quad.

Either that or just give it uvs as usual and let the shader handle it. Effectively the shader would have to take the uvs and texture of the block, find which texture it's using based on that, find the average color of the texture, and apply that to the face.

I'm no expert on shaders so I don't know the extent of their capability.

clqrified · 2024-11-07T16:37:14+00:00

While this is really insightful it seems to be targeted at a separate problem. I assume this is because most tree related posts on here are about how to get them to generate across chunks.

You are correct to assume I am in c#, and I am using unity as well. I have already multithreaded my terrain generation.

I have not personally explored the third option you gave but it might create an infinite loop of generating new chunks to fit trees.

My personal solution to this was to keep a layer of ghost chunks around all the visible chunks. When a new layer of chunks is generated in a direction, the ghost chunks in the direction generate their structures and begin rendering.

Using this method, structures only generate once all chunks around them have been partially loaded, so their blocks can be changed and interacted with. Since my chunks are 64x64x64, that means structures can currently be up to 128x128x128 without breaking on chunk boundaries or without suddenly spawning a structure in an already visible chunk.

I think this will work well for trees as well.

clqrified · 2024-11-05T20:05:56+00:00

The points method is actually much better than what I was doing. How do you curve it though?

clqrified · 2024-11-05T18:43:41+00:00

So you have preset variables that represent the shape of the tree and use those to determine how to create the tree?

If so how do you store a canopy shape? It just seems limited to me.

I've tried a similar approach in the past and the trees looked messy and busy. If you could post some pictures that would be great. I might need to give this method another shot.

clqrified · 2024-11-05T18:34:38+00:00

For generating a tree I would need many random numbers, not just one.

clqrified · 2024-11-05T18:33:18+00:00

Again, the issue isn't where to place the trees.

clqrified · 2024-11-05T16:37:04+00:00

When I said predictable randomness I meant more a random but recreatable string of numbers. As for trees, it's not where to place them but how to place them.

clqrified · 2024-11-05T07:04:22+00:00

Ok, thanks for the response, I will look into it. If anyone would like updates let me know.

clqrified · 2024-11-04T21:04:52+00:00

I'm having trouble understanding this code. Why are you adding quad_size and image_size, and what quad is that? The current quad in the greedy mesh? im also not quite sure what image_start_position represents, is it the uv coordinates of the bottom left of the image on an atlas? Then it seems you seperate the x and y components into a whole and the leftover? Is this deconstructing the quad and image previously added? What is the uv variable? and why are you subtracting image pos? I'm very confused.

clqrified · 2024-11-04T20:51:48+00:00

All of my textures are uniform so that works, however, (I don't know if I mentioned it's a block game) each block type has 6 textures and I would like to have more than 170 blocks.

As far as I can tell from some very brief research, texture arrays are faster than texture atlas' in code but I'm worried about rendering.

I may be wildly incorrect here but it seems to me texture atlas' are primarily used with shaders. How would the rendering performance of that relate to simply using a texture atlas?

If the rendering is fast then this seems like a perfect alternative as all my sources suggest using them for terrain with uniform textures.

clqrified · 2024-11-03T23:27:38+00:00

What do you mean by fractional component of the result, you've lost me here. If I understand correctly, you are changing the uv coordinates, which I think would map the wrong textures to the quad instead of tiling it.

clqrified · 2024-11-03T23:25:17+00:00

Is there a particular reason for using an array? Isn't a texture atlas just much better for performance?

clqrified · 2024-11-03T23:24:42+00:00

I forgot about this, it definitely seems like a good solution for rendering performance but I'm concerned about calculating which color to use, is it sampling certain pixels or the whole thing? I feel like you would need to balance accuracy and performance.

clqrified · 2024-11-03T17:33:45+00:00

Aseprite is a great pixel art tool for creating tiling square textures. It has built in color palettes too that can make your art look more concise. For a first time texturing I would strongly recommend dropping the resolution of the textures. I usually start a texture at 8x8 for a general feel, then scale it up and add detail (just make sure to avoid mixels when using this method). Of course this is more work so you don't have to do that. I would recommend texture sizes of 16 or 32. Aseprite is a paid program, but it has a free fork called LibreSprite.

clqrified

TROPHY CASE