Comments (4)
I think you're using the wrong SDF scale for your stamped SDF, and that's affecting the result. It's a unit sphere you scaled by 30, but you scaled its distance field by 500, which is 16 times too much. If you use the same scale 30, the issue is much less (if at all) noticeable:
Now I'm less sure about why the presence of a modifier affects it, but that might have to do with differences in gradient (one sphere is placed in an area that was already full of air so it's less prone to incorrect SDF, but the other one is placed in an area that has much closer distances so it matters more, especially since the added shape has zero-crossings in the same locations).
Here is how the SDF looks like initially (bright yellow=10, bright blue=-10):
When you use scale 500, you get this:
The right sphere doesnt end up looking bad because voxels above its surface can keep going with a "fast" gradients since there was no existing surface nearby (SDF keeps going beyond 10, the debug image doesn't show that). But the left sphere had one, so gradients go fast from the center of the sphere but suddenly have to "slow down" sharply above the surface since that's the closer values to the sphere that was originally there (the Add operation does a SDF union which uses the min
operator). I suspect that discontinuity is causing the blockyness.
You'll even notice the same problem if you chain these two, without a modifier:
voxel_tool.stamp_sdf(voxel_mesh_sdf, transform.translated(Vector3(50,0,0)), 0, 30)
voxel_tool.stamp_sdf(voxel_mesh_sdf, transform.translated(Vector3(50,0,0)), 0, 500)
But if you use scale 30, you get this:
Which is pretty much the result you expected.
from godot_voxel.
Yes, I'm aware that I'm using different scales (there are reasons why I'm doing this, but it's a bit out of scope for this issue) and why the issue happens.
Roughly speaking
With sdf scale = 1 values are:
A = [.., -2, -1, 0, 1, 2, ..]
With sdf scale = 1 values are:
B = [.., -20, -10, 0, 10, 20, ..]
Thus,
SDF_UNION(A, B) = MIN(A, B) = [.., -20, -10, 0, 1, 2, ..]
Which causes unwanted blocky look.
My main point with this report, is that, presence of modifier should not affect the result (after all, it's intended to be non-destructive preview of the mesh).
from godot_voxel.
Unfortunately this cannot be "fixed", the problem is you're expecting that using wrong SDF alongside correct SDF to behave correctly, which can't happen.
stamp_sdf
is a destructive operation, and you're using Add
, so what was there earlier will affect the result. Modifiers act like "local generator extensions", therefore they are only applied in non-edited areas, before edits. Once the area becomes edited, they are frozen on it, with your destructive edit being done on top. Even if that order was somehow reversed and the modifier was applied on top of everything, it would not solve your issue because min(a, b) == min(b, a)
.
from godot_voxel.
I should have mentioned in an initial issue, that I expected the sphere on the left to be smooth again, after moving VoxelModifier away as I thought it was applied last.
However, now knowing that modifiers are to be treated as part of terrain this behavior is to be expected.
So this is not an issue.
from godot_voxel.
Related Issues (20)
- Question: Enclosing and texturing underneath isosurface when using transvoxels HOT 2
- GDExtension API dump wrong type for enum VoxelInstancer::UpMode HOT 3
- So... quick question how would I make the noise larger? HOT 1
- VoxelMeshSDF partition_subdiv description missing info about BAKE_MODE_APPROX_FLOODFILL HOT 1
- VoxelMeshSDF get_aabb() mentions non existant margin property HOT 1
- Dummy page "2" not needed anymore HOT 1
- Assertion printed when previewing last VoxelMeshSDF layer in editor HOT 1
- VoxelModifier preview mesh has gaps with smoothness HOT 3
- Toggling visibility of VoxelModifier does nothing HOT 1
- VoxelModifierMesh changing isolevel does not update preview HOT 1
- Is the VoxelGraphGenerator usable as a base for the generation in a VoxelGenerationScript? HOT 10
- VoxelMeshSDF incorrect BAKE_MODE_ACCURATE_NAIVE description about sign calculation HOT 2
- VoxelMeshSDF BAKE_MODE_ACCURATE_PARTITIONED does not accurately bake PrismMesh HOT 3
- VoxelModifierMesh does not show up under VoxelTerrain HOT 2
- Performing edit on VoxelTerrain that hasn't loaded yet silently fails HOT 6
- Voxel Cubes not texturing. and meshes laggy and unpreforment. HOT 4
- Godot crashes when trying to add any element to the VoxelBlockyTypeLibrary HOT 2
- Error reported using '_GenerateBlock' of 'C #' HOT 3
- VoxelModifier get cutout around edited regions HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from godot_voxel.