Hi Deltakosh,
I did some code searching, first time I have looked at the internals.
This file seems to be the best model I can find to work with.
Babylon.js-master/src/Rendering/edgesRenderer.ts
This already has most of the key components, as I understand it, it decides whether to draw a particular edge between two triangles based on whether the edge is judged to be “sharp” based on an angle supplied - “epsilon”
So to “morph” this file as a test bed the steps I envisage are…
- Get a reference to an eye-point in world space - the camera position.
- Instead of comparing the triangle normals with one another compare them with a vector from the eye to the midpoint of the edge - use this to determine if one triangle is facing the camera and one is facing away - draw edges for which this is true.
There are two situations which meet our criteria - one is where the backward facing triangle is infront and the other is that the forward facing triangle is infront - ( concave vs convex is all a matter of where the ‘insides’ are ) so there is a little more work to do to remove the convex edges. However the rationale of this approach is that we do not have to worry too much about self obscuration because we intend to render all triangles and non interesting edges in the background colour so we allow the GPU to do the heavy lifting there.
Even if we have a loose test that does not consider convexity - edges that pass that loose test will be automatically covered up later.
Perhaps a better way of looking at it is to say…
- Reduce the epsilon criteria as it stands to say “every edge gets drawn” - even smooth edges.
- But then add a condition which decides not to draw edges where both triangle normals point towards the eye or both point away from the eye.
- Allow GPU depth calculations to deal with obscuration.
The only problem I can see is that the ‘edge renderer’ code is currently run as a post process after the render of all the triangles - draw triangles first and then overlay edges.
The hidden line removal demands that edges and triangles are rendered at the same time, interleaved as it were - we want to do our selective edge rendering to occur at the same time as one of the parent triangles is being rendered and then allow depth testing / ordering in the GPU to cover some or all of that edge if it is fully or partially obscured by triangles other than the ones we have been considering. It does not matter if we end up rendering the edge twice because we have “forgotten” as long as we only render that edge when we are rendering one of the triangles it lies between.
In effect we want to piggy back on the depth testing of the GPU to get edge rendering correctly ordered or synchronised in the depth of field so that they can be covered up by triangles that are closer to the eye.
I am going to have a crack at it - probably will take a while since I have not yet compiled or built BabylonJS locally. I will probably start out adapting the file mentioned above to see where I get with that.
If anyone has knowledge about whether it would be possible to “morph” the given source code file so that it does not rely on a pre-render of triangles but does it on the fly along side the edges I would be grateful for a heads up. ( Babylon.js-master/src/Rendering/edgesRenderer.ts ).
I suppose a similar approach is to ask the GPU to render triangles (solid colour) and edges but to do a pre-process where only edges of interest receive a colour that is not the same as the background colour.
As mentioned in a previous post the whole thing relies on being able to render triangles in a colour with no fancy options ( reflection, emissivity etc) we want a completely flat colour #003355 say which is identical to the background colour and is invariant to lighting conditions otherwise the illusion of background colour ‘leaking’ through the interior of triangles will not work properly - but again this would require that the GPU draw edges at the same time it draws either of the triangles that share that edge.
I took a look at the existing edge functionality and for my examples it seems very fast, my models render with edges ‘on’ - without any noticeable time lag so I think at a performance level it looks perfectly possible to have real time responsive hidden line removal.
The main hurdle is probably going to be connected with getting synchronisation between edge render and triangle render so we get the desired brute force “cover up” to deal with non-local obscuration.
I think real time animation that appears to be non-shaded but instead a sketch with hidden line removal could look very cool - in a way its regressive since shaded is perhaps technically superior perhaps a little “old school” but it might have its own charm.