HeightFieldShape resolution power of 2 #400
-
|
There is something i'm a bit confused on regarding HeightFieldShapes. The comments state "inSampleCount: inSampleCount / mBlockSize must be a power of 2 and minimally 2.". I was thinking that the sample count would need to be (inSampleCount-1) / mBlocksize as a power of 2 so that it would always be an odd number of points for subdividing up the heightmap. (Ex. with a blocksize of 2 and a resolution of 65x65 I would expect to get (65-1)/2 = 32 which is a power of 2 and would give me a field of 64x64 squares.) Am I misunderstanding something or is it not possible for me to generate a HeightFieldShape object that would represent the space of 64x64 squares and contain a resolution of 65x65? The comment gives me the impression that I would need to create a HeightFieldShape with a resolution of 64x64 which would yield me a grid of 63x63 squares. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 4 replies
-
|
The number of samples needs to be a power of 2, so if you create a heightmap of 64x64 samples this gives you 63x63 squares. Note that you can apply any scale to the heightmap, so you if you want it to span 64x64 meters you can do so. The reason for this is that the heightmap in our case is also used on GPU as a texture so must be a power of 2 and we stretch it so that it fills a power of 2 meters. |
Beta Was this translation helpful? Give feedback.
-
|
My issue is that I would want heightmaps that I can equally subdivide for when I generate my LODs.
As always thank you very much for your help. 😄 |
Beta Was this translation helpful? Give feedback.
-
|
I was thinking more about this last night and working on it. I suppose I can subdivide my terrain differently other than the usual half subdivision to account for the 2^n sample count size requirement. I know you had mentioned that in your case a texture is used for the heightmap which is why the requirement was there for the power of 2. Does this need to be enforced on the Jolt physics side of things? |
Beta Was this translation helpful? Give feedback.
-
|
Yes the texture is specific to our game indeed, you won't find any traces of it in Jolt. Unfortunately at this moment it needs to be a power of 2 for Jolt too because the data is block compressed and the acceleration structure built around it (an implicit quad tree) assumes a power of 2 too. B.t.w. In my experience, LODing a terrain comes with a lot of problems. If there's something lying on the terrain while it switches LOD it may fall through (because the height at a particular point may change) and there's usually issues with seams at the boundary between low and high LOD that cause objects to fall through the terrain / raycasts to miss the terrain. B.t.w. 2: You could give the right column and bottom row of your lower LOD the cNoCollisionValue value (which effectively disables that row/column). That way you can make them effectively the same size as the combined higher lods (which share 1 row/column). |
Beta Was this translation helpful? Give feedback.
-
|
Awesome, thanks so much! Also, I just meant generating LODs in regards to the vertex/index buffers I am using when I render the terrain. I didn't plan on changing anything with the physics shape heightmap, but I wanted the vertices to match up for the highest level of detail mesh of course. I had considered that cNoCollisionValue solution as well to disable rows/columns, but I was just thinking it felt a little hacky so I wanted to try to find an alternative. |
Beta Was this translation helpful? Give feedback.
The number of samples needs to be a power of 2, so if you create a heightmap of 64x64 samples this gives you 63x63 squares. Note that you can apply any scale to the heightmap, so you if you want it to span 64x64 meters you can do so.
The reason for this is that the heightmap in our case is also used on GPU as a texture so must be a power of 2 and we stretch it so that it fills a power of 2 meters.