<cite>@zzuegg said:</cite> Glad you got it working. Is that the expected behaviour? I would have assumed that connected point are still connected at lower LOD.I think it is because the density at this position is smaller than the density of the corners.
<cite>@ogerlord said:</cite> Good news! Level of Detail seems to be working:
Very nice!
How does it look with a terrain?
And now we can edit Terrain (add left mouse, remove right mouse)
8 Likes
Pretty.
Thereās a glitch at #t=37 .
Not sure whether itās in the model, in the marching cubes algo, or in the shader, could be any of them.
Itās nice to see the balls generate ābridgesā when they almost touch - thatās a confirmation itās really Marching Cubes thatās going on.
Keep up the great work, ogrelord. When I get out my next multiplayer update, Iām hoping to devote a decent amount of development time on this. I think I can more easily plug this code into 3089 using the FloatGridSource (e.g. I can do all my double stuff outside of this code, and then just fill FloatGrids to build my terrain chunks).
Awesome! XD
Thx.
@phr00t
How do you texture your terrain in 3089? With TexCoords?
I think I need a proper shader that is able to do more than the triplanar texturing with three textures.
<cite>@ogerlord said:</cite> Thx.@phr00t
How do you texture your terrain in 3089? With TexCoords?
I think I need a proper shader that is able to do more than the triplanar texturing with three textures.
I donāt use TexCoordsā¦ I wrote a custom shader that uses the world position to determine texturing. I tried triplanar texturing, but meh, I ended up with a quicker approximation that causes some stretching, but nothing too bad.
Wouaw ! This project is awesome !!! Combinated with a paging system (because lod is not enough for large scale maps) <3
Any updates on this?
Really good job anyway :).
Any updates on this?
Nope, my aim was to copy the stuff the Ogre project has and I think this is mostly done, but you are free to improve the existing code yourself.
Oh cool, iāve missed the repo link 
Thanks to share it as open source 
Just as an FYI for anyone whoās having performance issues with addSphere, you will have to avoid using getValue(pos) and instead do a distance<radius check and set the value to -1 or 1. It will cause your spheres to not be smooth and have a very rough look. However, Iām planning on using it to simulate damage, so the time-save and the rough look are a good fit.
If you still want a smooth-ish sphere, then make a compromise and perform getValue(pos) on points near the surface of the sphere.
Anyways good work on this, itās been a lot of fun to play with.
Iāve been watching this for awhile and I finally got around to checking it outā¦ First off, fantastic job, man! =D thumbs up all around!
Second off: does this implementation support sharp features? I know the original algorithm does (at least it appeared that way from a quick scan of the article), but Iām not so sure if this does (I havenāt quite had enough free time allotted to check through the code busy busy). Anyways, just curious! But still, great contribution ^^ I hope I can get some more time to play around with it!
(also, amazing job with making it easy to throw into the SDK; all I had to do was get the classes and it ran great!)
is the Dual Marching Cubes algorithm also used in current projects like Cubes (the jme mincraft clone)?
No, the goal of this algorithm is making a smooth surface, that is the opposite of a minecraft like terrain.