How do you find the edge of a mesh?

[Dal]

Is there an easy way to get all the vertices along an edge of a mesh?

[NasimiAsl]

you need array of points or Material Stuff?

[Dal]

1 minute ago, NasimiAsl said:

you need array of points or Material Stuff?

An array of points. I want to create seams for my terrain, so I need to get an array of Vector3 points that I can use to create a ribbon.

[NasimiAsl]

i have a bad algorithm in my mind but try it maybe you can make good

1. we know  each face have 3 points

2. if we have Grid struct from face on vertices so you need find  each vertex related face length

3 vertex related face count <= 3 is your edge

 

[jerome]

getting the vertices of a mesh, in general, might be far more complex than this

is your mesh just a terrain (ground) ? how is it built : pelin applied to ground ? in this case, this would be quite easier to store the heights along the terrain edge when iterating

from the line 65 : https://github.com/jbousquie/ArtilleryDuel/commit/19637fd99c7d7f55fcd83d4e0449449bd967c755#diff-85967cf6faa2faf5ac24f72dd219fc9a

[NasimiAsl]

when i look deep in my algorithm maybe it is not bad   if we add some other steps

 

[Xeonzinc]

Hi Dal,

As i mentioned before I've got a version which does this based on your continuous terrain approach.

I've quickly thrown it into a playground- http://www.babylonjs-playground.com/#CEUFD#5  (takes a few seconds to load) A slightly better version: http://www.babylonjs-playground.com/#CEUFD#6

The shading doesn't seem to be right now I've copied it out my project, but if you look at wireframe you can see the edges, and how the seams have been combined. My method for getting vertices was to loop through and define inner/outer vertices when the different segments were being built. You can see the code, but it's quite long, so ask for any more info

[Dal]

@Xeonzinc That looks interesting, although I don't really understand how you can do LOD like that... in my other one you stand in the middle of the rings and the vertices get moved up and down by the shader, so you don't really move as such, it just looks like are moving. A bit like a treadmill. In your version I don't get how you would do that bit of it.

@xeonzinc & @jerome
The idea of storing the edges when building the mesh makes sense though, I might give that a go.  I was hoping there was a method or function someone has already that does that

[Dal]

@NasimiAsl That's an interesting idea. I guess I could find vertices that only feature in <= 2 edges. Thinking about it in terms of algorithms though, I probably just need to find the lowest X value in the verts array and then find all the verts that share that value. That should be the -X edge, right?

[NasimiAsl]

i think 

 

[NasimiAsl]

i find a way in shaderbuilder but need a few days more for build

 

[NasimiAsl]

7 minutes ago, Dal said:

@NasimiAsl That's an interesting idea. I guess I could find vertices that only feature in <= 2 edges. Thinking about it in terms of algorithms though, I probably just need to find the lowest X value in the verts array and then find all the verts that share that value. That should be the -X edge, right?

this way just work on plan structer

[Dal]

24 minutes ago, NasimiAsl said:

this way just work on plan structer

Yep, but my terrain is a square... so the edge should be in a straight line. The Y is the only axis in which the verts will move from the plane.

[NasimiAsl]

so find a one x and get all line

and do it for z too

[jerome]

well, if your mesh is a ground, it is to say that you know a priori the geometry specifities, it's quite easy to find the vertices on the edge :

either you can store them when constructing the mesh, either you can guess a posteriori by evaluating the x and z values (knowing it's a planar rectangle) that should be the min and the max among all the vertices

if you know the width and height, it's even easier because you can know the minX, minZ, maxX and maxZ before starting to compare the vertex values 

here are the way x and z are computed in the geometry :  https://github.com/BabylonJS/Babylon.js/blob/master/src/Mesh/babylon.mesh.vertexData.ts#L1191

 

and for a ground built from a heightmap, here : https://github.com/BabylonJS/Babylon.js/blob/master/src/Mesh/babylon.mesh.vertexData.ts#L1191

 the same computation actually

[NasimiAsl]

@jerome always right : thanks for help us 

[jerome]

de nada, you are welcome 

[gryff]

There is some functionality in BJS that allows highlighting of mesh edges. For example:

mesh.enableEdgesRendering();
mesh.edgesWidth = 5.0;
mesh.edgesColor = new BABYLON.Color4(0, 1, 0, 1); 

Is there a way this might be used - as it must be determining what defines the edges?

cheers, gryff

[Xeonzinc]

2 hours ago, Dal said:

@Xeonzinc That looks interesting, although I don't really understand how you can do LOD like that... in my other one you stand in the middle of the rings and the vertices get moved up and down by the shader, so you don't really move as such, it just looks like are moving. A bit like a treadmill. In your version I don't get how you would do that bit of it.

@ Dal - The idea is exactly the same, you still stand in the middle and then all you need is a really simple vertex shader on top where only y-vertices are set (so really lightweight) based on a heightmap which you offset as the player 'moves'. The heightmaps themselves are passed to the shader in chunks (eventually you could have just one giant height map 10,000+ pixels in size and the code would just pull and pass the right chunks to the shader as needed). Practically all the hard work is done at build time, rather than run time which is one of the changes i was trying to add from your work.

The main limitation of this specific 'treadmill' terrain (ignoring getting everything else to work with it) is the limit of textures you can store in the shader at once, so I think your visible range is effectively limited to 2x your shader texture chunk size (probably 2k or 4k pixels). 

On the other side with a fully chunk based system you avoid this issue, but the downsides I see are much less flexibility over the LOD/graduation and higher number of draw calls (unless you can get good performance merging/unmerging as needed).

I can't see either way being perfect in all situations, so maybe we will end up with a few different systems to be used in different circumstances  ...Or perhaps eventually we will get to "The One Terrain System" and everyone's lives will be simple and carefree....

 

[Dal]

@jerome Thanks, I guess that's the best way

@gryff I took a look at that... it looks pretty complicated, I think jerome's way will be a lot easier if it works

@Xeonzinc, I basically gave up on that system when I realised its hard to page in new land once you get to the end of your current height texture and then even if you manage that you need to rewrite all the physics engines etc. to work with it. I've got a chunked approach working now but I need seams between the LOD which is why I started this thread.
I'm still not completely happy with the system though - it runs on mobile now but it's about 2x-3x slower than some other webgl terrains I found on github, and so on mobile its a bit laggy, so I need to do better!

Right now I've decided to try to implement a proper quadtree terrain meshing system rather than just cheating and using Babylon's built in heightmap function.

 

 

 

 

[Dal]

Here's a screenshot of what I wrote today... it's an infinitely chunked terrain using Babylon groundmeshes of different LOD (and you can see the seams between the LODs for now until I stitch them).

We have that at the very least, but I want to try to implement the quadtree first. 

[jerome]

nice scene !

[Dal]

With the ground mesh I can only set an LOD for an entire chunk. If I have lots of chunks this means a lot of draw calls and bad performance. If I have only a few chunks then I end up with huge parts of the chunk being too detailed and lots of it behind the camera that we can't cull.
The quadtree approach is meant to deal with that kind of problem, activating and deactivating the vertices that are needed.
I'm giving that a try, but if anyone has ideas on how to solve that problem in other ways, do let me know   

[NasimiAsl]

Dal give me  3 days i have a solution but don't know about last fps and i solve picking problem but still physics problem remine

[Dal]

6 minutes ago, NasimiAsl said:

Dal give me  3 days i have a solution but don't know about last fps and i solve picking problem but still physics problem remine

I like your approach doing it on the GPU. If it works that will be the fastest way for sure.