Merricksdad's Black Hills Tileset (First Look)

[Legacy_MerricksDad]

               

I don't intend to stop moving, at least not until I can get my brain placed into a robot '> I just mean, at least keep active this week, instead of being mostly at the computer like a few weeks ago.

               
               

               
            

[Legacy_MerricksDad]

               

Wrote a little script this morning which examines all the edges on a mesh and determines which ones could benefit from being flipped. This basically makes the terrain more smooth, and sets up the mesh to behave better with softening and optimizing techniques.

 

This seems like it took forever, because first I had to determine if the edge indices changed after being flipped, which they don't (not exactly), and then I had to learn that even if a function reports that there is X edges, a trimesh actually has X*2 edges in reality, because faces don't technically share edges. Then I had to write scripts to figure out the edge values AFTER an edge was flipped, by first determining which verts they were going to flip to AFTER being flipped. Bah.

 

Anyway, if anybody wants the edge smooth function for gmax, I can share it on here, or you can wait until I update my library on the vault. I've got quite a few recent mesh modifying additions to put out.

 

   Spoiler
   

/*
   OPTIMIZE EDGES
   
   Usage: optimizeEdges obj
      where obj is the object node you wish to modify
      *may not function properly if the stack is not clean
*/

fn arrayPush a x = (
   l=a.count
   a[(l+1)]=x
   return a
)

fn arrayIndexOf a e = (
   if (a.count<1) then return -1
   i=1
   while (i<=a.count) do (
      if (a[i]==e) then return i
      i+=1
   )
   return -1
)

fn getPolyVertsNotSharingEdge obj edge = (
   revEdge = meshop.getEdgesReverseEdge obj.mesh edge
   faceList = meshop.getFacesUsingEdge obj.mesh (#{edge}+revEdge)
   faceVerts = meshop.getVertsUsingFace obj.mesh faceList
   edgeVerts = meshop.getVertsUsingEdge obj.mesh edge
   r = (faceVerts-edgeVerts)
)

fn getEdgesOnlyUsingVerts obj vertList = (
   edgeList = meshop.getEdgesUsingVert obj.mesh vertList
   --now subtract all the edges using other verts
   edgeList2 = meshop.getEdgesUsingVert obj.mesh -vertList
   r = (edgeList-edgeList2)
)

fn softenEdge obj edge_index = (
   verts = meshop.getVertsUsingEdge obj.mesh edge_index
   newEdges = getEdgesOnlyUsingVerts obj verts
   edgeArray = newEdges as array
   outerVerts = getPolyVertsNotSharingEdge obj edgeArray[1]
   faceList = meshop.getFacesUsingEdge obj.mesh newEdges
   faceArray = faceList as array
   v1 = getFaceNormal obj.mesh faceArray[1]
   v2 = getFaceNormal obj.mesh faceArray[2]   
   a1 = acos(dot (normalize v1) (normalize v2))
   meshop.turnEdge obj.mesh edgeArray[1]
   
   modEdges = getEdgesOnlyUsingVerts obj outerVerts
   modEdgesArray = modEdges as array
   faceList2 = meshop.getFacesUsingEdge obj.mesh modEdges
   faceArray2 = faceList2 as array
   v3 = getFaceNormal obj.mesh faceArray2[1]
   v4 = getFaceNormal obj.mesh faceArray2[2]   
   a2 = acos(dot (normalize v3) (normalize v4))
   if (a1<=a2) then (meshop.turnEdge obj.mesh modEdgesArray[1])
   
   OK
)

fn getEdgesAsVertPairs obj edgeList = (
   vertPairs = #()
   edges = edgeList as array
   for e = 1 to edges.count do (
      edge = edges[e]
      --check for twin edge
      revEdge = ((meshop.getEdgesReverseEdge obj.mesh edge) as array)[1]
      revEdgeIndex = arrayIndexOf edges revEdge
      --if this is not the reverse edge add it to the list
      if (revEdgeIndex > edge) then (
         arrayPush vertPairs (meshop.getVertsUsingEdge obj.mesh edges[e])
      )
   )
   vertPairs
)

fn optimizeEdges obj = (
   --store all edges as vert pairs
   vertPairs = getEdgesAsVertPairs obj #{1..obj.mesh.edges.count}
   --for each vert pair get the edge
   for p = 1 to vertPairs.count do (
      e = getEdgesOnlyUsingVerts obj.mesh vertPairs[p]
      e = (e as array)
      if (e.count==2) then (
         edge = e[1]
         softenEdge obj edge
      )
   )
   OK
)

 

It has one known flaw, and that is if you wanted a sharp angle, it will try to remove it. If that angle is surrounded by multiple other sharp angles, it will make a mess, and can flip a face. Multiple uses on the same object will often make such a mistake even worse.

 

I still need time to document everything, but there are already too many projects.

 

For instance, instead of running this on all the 600 tiles, I need to go take care of a city flower bed I run.

 

Edit:

 

I don't know if this is just Gmax, but this line is crashing the gmax script runner with a "system error" very often.

faceList = meshop.getFacesUsingEdge obj.mesh (#{edge}+revEdge)

If you move the compilation section to a new line and instead have code like this it has less errors.

edgeList = revEdge+(#{edge})
faceList = meshop.getFacesUsingEdge obj.mesh edgeList

That is a system error without any details, and then if I try to do something else, including closing gmax, it just crashes the program. Something about how it is handling the inline merger of two bitarrays is having issues. I'd like to see the code for gmax, but I guess that won't likely happen any time soon.

               
               

               
            

[Legacy_T0r0]

               

Flipped edges   

               
               

               
            

[Legacy_MerricksDad]

               

Let me show you with a picture or two.

 

Sorry that image is visually painful. Here is another one to lessen your pain, or for the color blind.

 

 

 

In the first image, I have highlighted a section where faces fold over each other. I could not possibly hope to create a walkmesh from this mesh because face edges reside over others in 3d space. But since all the verts are separate from each other in XY position, I could flip the edges, un-tucking those faces, and then apply a walkmesh without issue. The faces in pink are the faces of issue, and all adjacent faces. I have smoothed this by 45 degrees so you an see the offending faces are darker and unsmoothed.

 

In the second image, I have run this script one time. It unfolded the majority, but the pink area shows one tucked face, surrounded by adjacent problem area. Again, I have smoothed this by 45 degrees to highlight the tucked face, but since it is fully under another, you can only see that an edge line passes through the space of other faces. Still can't make a walkmesh from this mesh.

 

In the third image, the final offending edge was turned and the area is finally free from walkmesh error. I have smoothed it again by 45 degrees to show that the entire region is now smooth, and that no faces are tucked under another.

 

This all happens without moving a single vert. Now compare the face edges from mesh one and mesh three, and you can see other regions of the mesh were also smoothed better when other edges were turned.

               
               

               
            

[Legacy_T0r0]

               Ahh ok. Thought there was something else I had been overlooking all this time (phew ! ).  This is still about the faces tho. Albeit your way , without moving verts around is very cool. Does it actually highlight the bad faces  or was that for illustration purposes ? Does it work in 3dsmax ?
               
               

               
            

[Legacy_MerricksDad]

               

That was illustration purposes. And I don't have 3dsmax, so I cannot say, but it should, since that should have all the base functions max4 had. I included my two custom array functions just in case it would not, and in case you aren't already using my library.

 

I actually don't suggest anybody use the code above. I made some huge changes today and it works MUCH better now.

 

• I tweaked the edge checker so it now validates open edges (the ones along the tile edge) and can work with them when flipping.


• I also determined what was flipping entire faces, and found it was happening when a vert only connected to 3 or less edges, so I wrote a checker for that, disallowing flipping on such places.


• And then I realized the system exception is built into the code for their  Meshop.getEdgesReverseEdge function. It is totally fubar, so I wrote a new one.

 

No crashes now. About 5 runs of this on any 10x10 mesh and it looks wonderful compared to the original.

 

Instead of updating the function above (which still works, just not nicely), I'm going to wait and release the better one on the vault with my library.

 

If I had to change one more thing, I would check for faces which are 100% vertical when verts are snapped to integers. This current code leaves a few sharp ledges that are between 0.0 and 1.0 when you look at the distance from the edge center to the nearest vert above or below. That will probably make the walkmesh mad at that point, but I have not tried yet.

 

One question I have is whether or not the snapping of verts to integers is beneficial for anything but the outer edge of the tile mesh? If not, I won't bother. If it is just the drive space being saved by not storing the long decimal, I don't really worry about that much. But if people intend to snap my verts to integers in the future, leaving them like this is going to make a headache for somebody else down the road.

               
               

               
            

[Legacy_CaveGnome]

               Snapping verts to integers is something very useful in my case. I do a lot of manual mods to verts coordinates and it's a real pain to enter long lists of float numbers. Also it will help speed welding when you add new parts to a model, and you already mentioned the less annoying problem of outer edges decimal coords outgrowing allowed space. Disclaimer: my modeling skills are somewhat archaic... I don't understand 95% of what I do, so take this gnome opinion with a salt pinch ;-)
               
               

               
            

[Legacy_MerricksDad]

               

Your opinion is important, as is that of anybody who works on tiles. I think today I will install three more features to the function.

 

1. ability to loop until no change is detected

   
2. ability to use face collapse on faces that have no 2D surface area when viewed top down after verts are snapped to integers

   
3. ability to use face collapse on faces which have a face normal direction pointing down

               
               

               
            

[Legacy_MerricksDad]

               

               
               

               
            

[Legacy_MerricksDad]

               

Anybody know how to determine if a face is pointing down using its face normal as euler angles ? I'm researching all the existing functions in max and other programs, and I don't see a good explanation of how to find up and down in relation to a vector.

 

The closest thing I can figure out is to get the face center of any given face, the normalized face normal, and then subtract one from the other and check the Z value. Would that work?

 

Edit:

 

Nevermind, I'm an idiot. If the face normal vector has a z value which is positive, it points up. If it has a z value which is negative, it points down. Just that simple, it seems.

 

 

Edit:

 

This is time consuming, but fun, learning how to do all this face manipulation stuff.

 

So far I have one function which collapses any verts, except open edge verts, if they are connected to only three edges. This helps get rid of concave regions, as well as deep pits in the middle of nowhere caused by noise modifiers.

 

I also have two more functions, each working slightly different. The first simply takes any faces pointing down and collapses them, as per the collapseFace function in gmax, which takes the face verts and welds them to the face center.

 

The alternate version of that welds the topmost vert on the offending face with the bottommost vert. Neither option is a 100% success, but the second option seems to be more accurate in reducing concave mountain faces.

 

The third thing I listed above will have to wait til another day. I need to write a function to detect change in the mesh after a loop cycle. I don't have that energy tonight.

 

To be more clear, the tiles I am making need to have no concave verts in relation to their adjacent face set. This makes it so I can instantly make correct walkmeshes from ALL the script-built tiles. Without this, at least one tile in 100 tiles will have an issue, and finding it by hand is a maddening mess.

 

I do intend to have concave regions in the mountain tileset, but those regions will be hand made cave entrances, or stone arches, both of which will have a walkmesh which does not include those overhead mesh parts.

 

This is all just maximizing simplicity of creation and visual complexity for the first part.

               
               

               
            

[Legacy_MerricksDad]

               

I feel like I am dragging my feet at the last minute here.

 

I tried some stuff the other day and it was a complete failure, and I felt kinda bad for having wasted the time. I'm kind of in a rut now, but I want to come back out and finish this.

 

Had this severe headache this morning, which went away after I had my coffee, but after two days of real life housework, I feel mentally drained. Maybe tomorrow I can work on this.

 

I still need to:

• write a script to cycle through the mesh optimizer functions and detect when change has stopped


• update a script to paint walkmesh materials


• update a script to crack visible mesh sections into various textured meshes


• create a script to extrude certain edges, creating a grass rim where needed


• and I like this new one I have been working on:

I started work on a script which takes a walkmesh and tessellates it many times with 0 automatic relaxation between verts. This causes it to be 3-dimentionally equal to the original walkmesh, just with a ton more faces. Then I randomly pick so many verts to use as placement nodes for vegetation. I then set the base radius of the vegetation (on the vegetation placeholder I made from a dummy), collect the face area it would occupy on the tile, create a shape from the needed faces, and use that face, already adjacent to the correct walkmesh faces, and do a mesh join, creating exactly the space I need on the walkmesh to place a tree or shrub of that size. It works perfectly with the small selection of base trees I am testing it with, and on low poly meshes. On higher poly meshes it makes a mess that I have to clean up by hand, so I have to find where that complexity level line is at.

 

I know some of you prefer a set with no vegetation, that way you can add your own, but I think I will do both. One my own, and one you can tinker with, virtually

identical except walkmesh files and placed on-tile trees. No reason not to.

 

The previous tree placer I did back in 2008 simply used verts on the main walkmesh, without modification, and I used almost exclusively trees that were so thick I just had units walk through them. Placeable trees, or large tree tiles, filled in the gap where I needed something to block players.

 

There, I already feel better just telling you about that script. Thanks for listening '>

               
               

               
            

[Legacy_MerricksDad]

               

This mesh optimizer is so sick. If I run it twice, I get high poly realistic mountainscapes like 3d topo maps. I don't know if I could ever use that level of quality, but damn! In fact, applying a walkmesh to the object kills GMAX.

               
               

               
            

[Legacy_MerricksDad]

               

Maybe tomorrow morning I can show some progress shots. I finished the optimizer code this morning, with the looping change detection. Works pretty good, but it does have some bugs. It seems most of them are related to memory leaks or something. Occasionally a face is destroyed entirely instead of being collapsed, especially faces along a tile edge which where specifically told not to collapse. There are also sudden hangs, even with the use of garbage cleanup, and then I have to close and reload where I left off. So basically I am running this on 5 - 9 tiles at a time. If I detect error visually, I reload and try again. It looks like 1 in 30 makes a mistake on me, so this could take all night.

 

I think I will post a variety of this as it is in the morning to the vault for examination.

               
               

               
            

[Legacy_MerricksDad]

               

With the help of CM3, I found a few minor tweaks I would rather have directly in the NwMax exporter. Unfortunately, it took me all day to decide that I needed to just do that modification to make my life easier. I should have done that months ago (maybe years).

 

After using CM3 to do some serious fixing on simple stuff, and tell me exactly what is wrong with some things, I got the exported tiles down to a minimum size while still functioning. I hate pivot errors for NwMax. Keep in mind I'm using a modified version of 0.8b still because it has all my changes in it.

 

CM3 did a horrid number on my walkmeshes, so I had to manually figure out what was wrong with those. Mind you this is the first and second time I have seriously used that for anything like walkmeshes, so I really don't know how and why it is doing what it did to those. Somehow, it took the existing walkmeshes and made one or two points on 6 models shoot out to some random number millions of miles away from my model, or at least that is what it showed in GMax after I reloaded them when it would not work anymore. Every single log entry showed that some point was outside the model bounds, even though all verts, and model positions were snapped to correct integers, and no verts were outside the allowable mesh square area.

 

I really like the simple things CM3 does, like welding tverts and stuff. Very nice. File size went way down, and complexity did to. They load super fast now.

 

I decided to fix the WM issue to just clone off the primary trimesh and rebuild my walkmesh again, as usual, and they work fine that way. No vert spikes on the walkmesh out to space. I also modified the line of code in the old NwMax to check for pivot != local parent center. That fixed the issue of having to have world-zero pivot. Why would it need pivots on tiles to be 0 world center? Makes no sense. It should be zero local center, or technically aurorabase center. Anyway, much better now. I also put in the NwMax script to add those shadow/render 0 lines on export. Save some time in the future.

 

Appearance-wise, I was unhappy with what my script does around the edges of tiles, not smoothing from one to another. I have been trying to figure out a nice cutting algorithm to make two cuts at the edges of tiles so that it flows perfectly into the next. That will be another time. So in this colorless release, I am trying them smoothed at 15 threshold to see how they work. Although angular, I think with some very minor tessellation on the primary mesh, it would look a lot better, even if that does bloat file size. Otherwise, they work great, and I can walk the entire accurate walkmesh equal to what you see in game.

 

What I want to do next release is add some tessellation only on the primary trimesh, or build a script which chamfers the edges without making a mess. It would then pick only edges not already smooth to a threshold of 15. Hopefully a single chamfer on those edges will soften the majority to look more realistic, without being 100% smoothed. Something to try anyway. Sounds fun to teach a robot to do select chamfering. If only I could get a robot to do that with real wood, I could make a fortune.

 

Let's see... Oh I also fixed the shallows, and smoothed those a bit, as I had with the +1 and +2 rise previously.

 

I really like the noise in this one. I was afraid I was going to have to make 2-3 varieties for each tile, and I still may, but it doesn't seem required, as the variety is less on the tile and more in the builder's layout. By choosing to not make a wall the same height all the way across, the similar tiles at different elevations create the world static needed to destroy monotony.

 

Here's the current version link

               
               

               
            

[Legacy_MerricksDad]

               

I took last night's idea and ran with it. Instead of chamfers, which increased the face count far too much, and introduced math errors, I went with simple 1x face tessellation on the primary mesh. Keeping the tension level low, I was able to continue using the existing WOK files without to much foot-in-the-ground appearance. This package uses a 15 threshold auto-smooth appearance, as did the previous version, but has many more faces on the primary mesh. Frame rate seems unaffected on mine. Further tessellation, which is not in this release, substantially increases face count, and may reduce frame rates, but, using the same smoothing threshold provides a very realistic appearance, giving a combination of hard lines and smooth surfaces. This tessellation level of this release shows a bit of simple geometry, but also gives a good combination of non-geometric-looking smooth surfaces. The next level of tessellation has even less visible simple geometry. The moderate poly count increase bloats the file size of the hack to over x3 the last release. I've left the hak filename the same this time, Either override the more simple version, or change its name on export.

 

View it here.