Thanks crash. Yes the only noise type used at the moment is opensimplex. Am gradually adding ridged, billowed, etc. 
1 Like
hello hello,
busy two week it’s been so I haven’t had as much time to spend on this as I would’ve liked but… gradually improving. I think -_-
cracks are gone 
and more noise variety is no now in. At the moment I am just playing with noise merging, etc, to get a feel of the kind of terrain they can create in real time. All this to hopefully pave the say to more “physical” vertex properties coming in from the procedural server-side bits (elements, compounds, tectonic level of activity, etc.)
Ticking at between 0.0 (wasm vertex buffer) and ~5-6ms, I think there is till plenty of intra-frame time left for improvements, especially in a worker (at the moment in all runs on the main thread).
a little video:
and a little capture with long(er) shadows cast by a basic shadowcaster with self.receiveShadows = true;
the crust in this example is fairly chaotic and would work well with chtonian/archaean planet types.
Hope you will like it!
It looks like our moon 
Do you keep the low resolution because of being in the main thread? I wonder how it would look with maybe x4 the resolution 
How do you handle the shadow frustum, do you render shadows only close to the camera? I am not sure how it would scale to a planet by default ^^
it looks like our moon because the vertices are coloured from elevation
but craters i still have not idea how to do. Perhaps a mix between vertex elevation/displacement and texturing for the finer details?
at 4x resolution, this will slow to a crawl. ie, 15-20ms per tick, which I’d rather avoid. I can of course try and improve the internal perf, etc
shadows are very basic, it’s just a normal shadowcaster with no dynamic follow-up or change:
const shadowGenerator = new BABYLON.ShadowGenerator(2048, light, true);
shadowGenerator.useExponentialShadowMap = true;
shadowGenerator.bias = 0.1;
shadowGenerator.useKernelBlur = true;
shadowGenerator.normalBias = 0.05;
shadowGenerator.useBlurExponentialShadowMap = true;
shadowGenerator.forceBackFacesOnly = true;
//shadowGenerator.enableSoftTransparentShadow = true;
shadowGenerator.blurKernel = 16;
shadowGenerator.useCloseExponentialShadowMap = true;
shadowGenerator.depthScale = 50;
shadowGenerator.filteringQuality = BABYLON.ShadowGenerator.QUALITY_HIGH;
shadowGenerator.autoCalcDepthBounds = true;
shadowGenerator.addShadowCaster(sphere);
I have been thinking to use some voronoise for that like something like this Shader - Shadertoy BETA
Ah yeah that would be an issue ^^’ We you offload the generation to a worker that will become easier I guess
shadowGenerator.autoCalcDepthBounds = true;
I am a bit skeptical about this one, because with a 2048x2048 shadow map, you probably have less than one pixel per meter squared on the planet. On the video you shared, I am not sure I see any shadows being rendered, you can probably get the same result by regular shading alone
Blimey these craters are nice
re workers; yes definitely. I am starting to wonder if having several workers would make sense (for triangles processing, chunking LODs, etc). But then again that would imply the use of a SharedArrayBuffer, which is I believe quite slow compared to a fully contained wasm (?).
re shadows; yes, I turned them off and not much change, tbh. Not a major issue a I intend to use specific shaders for materials, which probably means implementing shadows there. But that will come later!
some improvements are in (imho anyway :P):
a little bug by me for the laughs
that vertex clearly loved the camera and ran towards it!
I think more workers can be beneficial, especially if you have more cores in your cpu (there is navigator.hardwareConcurrency that gives you an estimation of how much workers can work in parallel in the browser).
I don’t have experience with ROAM so I don’t know how much it can be parallelized though
haha I knew it 
Having a custom implementation in shaders makes sense ^^ Thinking about this issue, another option could be to keep the camera inside a constant shadow frustum that would move alongside the camera
Not sure what you changed but it does look better
It do be like that some days Bugs in computer graphics have the quality of being interesting to watch at least haha