- Home /
Soft edges between two separate meshes - Possible?
So I am working on a procedural object that is made up of several separate Gameobjects/meshes of equal dimensions (10x10 planes, in essence). I could have made it one large mesh, but due to processing and rendering constraints I have decided to break it down into "chunks". Though I haven't gotten to working on texturing, etc., I imagine that there is going to be a noticeable lighting difference between bordering faces on each chunk. Is there any way around this? Perhaps some fancy shaders? Or is there perhaps a different approach to breaking up a mesh?
~Cheers
Answer by Owen-Reynolds · Nov 27, 2011 at 06:10 PM
That's pretty much the way terrains are drawn now -- a 512x512 array is used to generate lots of adjacent 16x16 meshes. It's likely you will never see a problem. The main point is, say you have side-by-side chunks A B. Do everything exactly the same for verts on the right side of A as the left-side of B: position, normals, tex-coords, textures ... everything. The shader won't know the difference (normals control lighting -- if you use the same on each edge, smooth lighting happens.)
Be sure to use exactly the same data. Copying from the same source is fine. Doing math that should give the same result for each, that will make little holes and discontinuities as rounding errors creep in. Can try an example with Unity planes (they are 10x10 verts.) Lining up two will look fine. But, as you get odd scales/tile-sizes, the ends tend not to match up, even when your math is correct.
For some background: clearly, drawing A with a bumpmap and B without, is going to make a visible seam. What the pros do is make A B C. A has a bump map (or whatever,) B fades it out, and C has none. Making a "fading-out bumpmap" shader is a pain. Likewise, if you want 10x10 near, but 5x5 (twice as large squares) in the distance, B is a special mesh with 10 on the left and 5 on the right, so each pair can share exact vert data on their edge. If you select wireFrame, you can see Unity doing this on terrain -- looks like 16x16 pieces.
In general, two meshes can't have soft edges, since they won't fit the rule. Placing an Inn on a platform, say. You would need to retesselate the platform to create verts matching the bottom of the inn (or snap the Inn to the platform verts) and then copy that data to the bottom Inn verts, also use the platform texture when you draw the Inn and vice-versa.
Okay thanks for the tip on the math. Not only is it procedural, but it is also dynamically changing and growing, so yeah I have been encountering creeping discrepancies between the meshes. Right now the array data is local to each individual chunk. I'll go back and make some sort of manager class that generates the whole array, updates it, and distributes it among the meshes. It ought to be a bit more efficient. However, your answer in regards to smoothing still perplexes me. from my understanding of smooth shading, it depends on knowing all of the angles heading into a vertex. Since the vertex on the left side of $$anonymous$$esh B doesn't know what happens to the left of it (because all of that data is known only by $$anonymous$$esh A) won't the shading/lighting not change as $$anonymous$$esh A's verts near $$anonymous$$esh B move?
Alright it makes a bit more sense now as a static mesh, but a dynamically changing array would leave seams unless I did a RecalculateNorms() every frame... right? Or are you saying that the 512x512 array could also carry fully updated mesh info, and not just the vertex/triangle positions?
No matter how you draw it, even one piece, if you move verts around, you'll have to recalc the local normals, and save them somewhere.
For lighting, think of an edge. Both pieces share data for both verts, so normals along each edge are the same. So each piece shades towards the same edge values and will match (well, as much as any other edge.)
Good point on the RecalcNorms() thing -- don't know where my $$anonymous$$d was. Okay so... here's the next step that I can't decide on and would like some further advice: Would you recommend that I have the overarching, unifying, "512 x 512" array just simply a Vector3 array with simple Vector3's for each vertex --- Orrrr should I take it a bit further and generate a large (but unrendered) mesh based on the main array, then distribute that full mesh info to the rendered "chunks"? Thanks for your tips so far, and I think you've answered the question, so a check mark for you! :D
For terrain say, the TRI array is the exact same for each 10x10 chunk. If you copy these 121 (11x11) verts into v.vertex, then numbers 0,1 and 11 always make the upper-left tri. All you need is the vert/normal data (often the shader computes the UV coord from position.)
The only difference between a "mesh" and a list of verts is the tri array. If the tris aren't made by a formula, you're pretty much stuck going though for each piece to grab tris using only those verts. There's no quick way to say these verts use these tris.
You could take a look at various papers, etc... about building terrain. Lots of them go over the various problems.
Answer by Mox.du · Nov 27, 2011 at 04:41 AM
Even if this is possible to solve with shader it is not good approach. You will have overlapping geometry with extra vertices which is not advisable in a sense of performance impact and unpredictable behavior. I think that you should make these meshes procedurally. Take a look at this
Your answer
Follow this Question
Related Questions
Normals on procedural mesh 0 Answers
Calculate Rotation based on mesh normals 1 Answer
Procedural mesh's normals are reversed (Solved) 2 Answers
Correcting normals along chunk edges 1 Answer
Procedural mesh generation - problem with normals. 2 Answers