649 réponses à ce sujet

[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.

[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 ;-)

[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

[MerricksDad]

[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.

[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

[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.

[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.

[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

[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.

 

 

[MerricksDad]

Smoothing output from GMAX works on a curve system, and the game seems to interpret that just about the same. I know there are a few methods for forcing tile edges to carry a smoothing group across tiles, or at least have the appearance of doing so, but I think what I want to do is make two 1cm cuts along the edges of all tiles. Then I will build a script to force the verts from the cut regions to exactly match the position of the verts nearest them in Z value, as well as just 1.0 cm X/Y axis from the true edge. This will force the face normals at the tile edge to be much much closer to where I need them. If I can pull that off, I can increase the tile smoothing threshold to something higher. Most people on the internet seem to think 45 is perfect for just about everything. While I disagree, taking into consideration material types, I think it might be a target to shoot for. If I can do 45 across tiles without the seam showing, the set can retain at least some of its angular complexity, while also appearing very smooth after the texture is applied.

 

If I am not mistaken, the base tile size of NWN2 is subdivided by 10 squares. Maybe it was 20. Either way, this tileset matches or at least doubles that face complexity without increasing processor load.

 

Keep in mind, there is no shadow casting material yet. Even in the dark, the rises cast no shadow against the lower parts. Only the faces opposite the light source are darker. This works just fine in a well lit, or well-fogged environment, where light would not cause much of a difference. But for night-scapes and caverns, this comes across as visually odd, and the more smooth something is, the more plastic it appears.

 

At some point, a shadow casting mesh, which is lesser in complexity than the actual walkmesh, will need to be installed. Optimize functions in GMax have so far failed me in creation of shadow blocks, so I may need to make a custom un-tessellate function, which would reduce complexity only locally, rather than across multiple faces further apart, and only when edge normals are similar.

[3RavensMore]

Most of what you're talking about goes over my head, and I've been wondering what the results will be for all the effort you've spent in this project.  I'm beyond amazed though.  The landscape geometry looks real.  Not just somewhat real, but like something I'd expect to see in to Rockies.  Strike that--it looks like things I have seen in the Rockies.  Truly amazing work.

[MerricksDad]

I like the word OTR used: Organic. So many tiles in NWN look like they were stamped by a machine. I understand the need for simplicity, but at this point in time, we might as well progress at least a little. Hopefully, this set, as well as the maxscript library functions I am going to release, will be helpful to builders. I'm going to pack a library addition strictly for dealing with tile systems like this, and specifically for those who will be using Sen's tile offset data. To make use of his stuff, I actually created a few tile classes in maxscript, and then I just load all his spreadsheet data into nice object oriented thingies, and can ask it simple questions in basically english. It helped immensely while getting the TMD05 placeholder set produced. I don't think I could have done this 4 height transition without that information, and without it turned into a creature I can talk to.

[MerricksDad]

Last night I started working on an experimental tile edge adjuster. What it does it takes the tile mesh, extrudes and shrinks the thing from its edges twice, by a set value. In this case I shrink by 5 cm on each side. Then it switches back to the other edges and unshrinks them by the amount they would have moved, putting all non-edge verts right back where they started. Basically this just creates two tile edges inside the tile edge, so that the smoothing functions can make an easier flat face near the outermost edge. I then had to maximize the flatness on Z axis rises by adjusting the positions of the verts so they lined up exactly with the x or y position of the outermost edge, or there was some weird angle pointing back toward the center of the tile. If you'd like to try it on a standard tile, run this function in gmax. I'm exporting tiles now, just to see what happened with the edge details. Last night's trial was not sufficient, so hopefully this double edge and edge line hair perm will fix the deal.

 

Spoiler

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

fn contractFaceSelection obj faceList = (
	local vertList = (meshop.getVertsUsingFace obj.mesh -faceList)
	local r=-(meshop.getFacesUsingVert obj.mesh vertList)
)

undo off(
	local f1 = 10.0
	local f2 = f1*2.0
	local f = f1/2.0
	local fD = ((f*f)+(f*f))^0.5
	local f1D = fD*2


	disableSceneRedraw()
	local sel = selection as array
	for obj in sel do (
		select obj
		convertToMesh obj
		setFaceSelection obj.mesh #{1..(getNumFaces obj)}
		subobjectLevel = 3
		local m = Face_Extrude()
		modPanel.addModToSelection m ui:on
		m = XForm()
		m.gizmo.scale = [((1000.0-f1)/1000.0),((1000.0-f1)/1000.0),1]
		modPanel.addModToSelection m ui:on
		m = Face_Extrude()
		modPanel.addModToSelection m ui:on
		m = XForm()
		m.gizmo.scale = [((1000.0-f2)/(1000.0-f1)),((1000.0-f2)/(1000.0-f1)),1]
		modPanel.addModToSelection m ui:on
		convertToMesh obj
		subobjectLevel=3
		local faceList = getFaceSelection obj
		local newFaceList = (contractFaceSelection obj faceList)
		setFaceSelection obj.mesh newFaceList
		m = XForm()
		m.gizmo.scale = [(1000.0/(1000.0-f2)),(1000.0/(1000.0-f2)),1]
		modPanel.addModToSelection m ui:on
		convertToMesh obj	

		--fix edge verts
		
		local vertList = -(meshop.getVertsUsingFace obj.mesh (getFaceSelection obj.mesh))
		setVertSelection obj.mesh vertList
		in coordsys parent (
			local verts = vertList as array
			local edgeVerts = #()
			local c = verts.count
			for v = c to 1 by -1 do (
				local vert = (getVert obj.mesh verts[v])
				
				--separate tile edge verts from near edge verts
				if (vert.x==500.0 or vert.x==-500.0 or vert.y==500.0 or vert.y==-500.0) then (
					arrayPush edgeVerts verts[v]
					deleteItem verts v
					--format "%\r\n" vert
				)			
	
			)
			--format "%\r\n" edgeVerts
			
			for v in verts do (
			
				local vert = (getVert obj.mesh v)
				
				--match this vert to tile edge vert
				local notFound=true
				for ev in edgeVerts do (
					if (notFound) then (
				
						local edgeVert = (getVert obj.mesh ev)
						local dX = (abs (edgeVert.x-vert.x))
						local dY = (abs (edgeVert.y-vert.y))
						local d = (distance edgeVert vert)
						--format "%   %   %   %   % \r\n" vert edgeVert dX dY d
						
						if ((dX==f and dY==f) or (dX==f1 and dY==f1)) then (
							--don't move corners
							notFound=false
							--format ("corner\r\n")
						) else if ((dX==f and d<=fD) or (dX==f1 and d<=f1D)) then (
							notFound=false
							vert.y = edgeVert.y
							setVert obj.mesh v vert
							--format ("match\r\n")
						) else if ((dY==f and d<=fD) or (dY==f1 and d<=f1D)) then (
							notFound=false
							vert.x = edgeVert.x
							setVert obj.mesh v vert
							--format ("match\r\n")
						)
					)
					
				)
				if (notFound) then (
					--format ("*** no match ***\r\n")
				)
				
			)
		)
		
		m = AuroraTrimesh()
		m.shadow=0
		addModifier obj m
	)
	enableSceneRedraw()
)

 

Edit: while interesting, the function run with f1 set to 10, and full smooth on the tile, was not sufficient to cancel tile seams entirely. It was much better than the 2cm test from last night. I'm currently trying 25 and 50 just to see what I get, or if the overall smoothing curve is actually changed by distance. I suspect it is, but only to an extent. The longer the curve, the more horizontal the edge normal will be. There must be a really good combination of two, or an easier combination of three, which will deliver exactly what I need.

 

Edit: not exactly a lesson in futility, but getting somewhat close. Combinations of any range which total 25 or more centimeters from the edge also interfere with the geometry, making it so the walkmesh no longer lines up with the model, or creating an even worse seam or near seam obviousness.

 

I think reverting back the current release and having NO smoothing from tile to tile will be actually a better look. Feel free to play with the function above. Adding another level of face extrusion and transform does increase the smoothness at the tile edge. To further smooth the tile edge, I played into the underlying waveform of edge smoothing by only requiring the second-to-outermost edge to be adjusted on the x-y plane. I tried that from 10cm down to 4cm, with 4cm being more useful looking.

 

Anyway, abandoned and moving on. Time to play with a custom shadow box builder. This one should be far simpler to implement.

[YeoldeFog]

Wow! Very nice! Can't wait to see it with texture!

[MerricksDad]

So what was it about shadows that made them easier and more accurate? Did I have to explode them into separate meshes and then move their positions to their face center? Or something like that? What have you guys found works best?

[MerricksDad]

October Distraction

 

[ShadowM]

omg love it, got to make it a mutiple monster just to have all the eyes follow the pc or a single monster LOL. Cannot wait to get my new computer put together and going so I can get back to making nwn stuff, missing it too much. Love all the tileset work, I going to go off it when I finnally try my first tileset sometime down the line.

[MerricksDad]

http://neverwintervault.org/project/nwn1/model/merricksdads-halloween-eyeball

[MerricksDad]

I'm having some extreme difficulty building shadow blocks for the mountains. I tried a few combos:

1. lower poly mesh than the walkmesh
2. walkmesh chopped into polygons based on 15 threshold smoothing groups
3. lower poly walkmesh exploded and face positions set to face center.

The last method takes a LOT of script work, and pretty much cripples GMax, but if I export them and delete them from the file as I go, it seems to allow it. Also the last method looks the best in the game, but file bloat is highest, but again, not by that much.

 

When the shadow mesh is lower poly quality than the actual ground shape, it has a tendency to shadow parts which should be fully exposed to sunlight. Also, the shadows constructed from steep walls are not casting shadows at a distance for some reason, only upon the ground nearest them. It seems I just don't understand the bugs and purpose of tile created shadows.

 

Overall, it really looks like the set features better without a shadow system for the tiles. But you do get strange floating character shadows if you omit it.

 

I may just continue on with the explode and center method, but I might adjust the heights to clean up some flat face shadowing. We'll see.

[MerricksDad]

From what I am reading, if I sort all the faces in a shadow mesh by their primary facing (face normal), then I can separate any mesh into 6 meshes, each casting shadows in the correct direction, by placing that mesh's pivot point behind all the faces of that mesh. I don't understand this entirely, but I understand the math on how to get there. I see there is a CODI tool for doing exactly that, but it is NOT for Gmax, and is compiled, so I don't have access to the code. Perhaps I can make the same tool for Gmax? Splitting the mesh into only 6 parts, and then removing the smoothing groups, would be really easy. Making sure I have the pivots right, based on what the CODI tool does, I'm not so certain about. Worth a try.

[MerricksDad]

Hey if anybody has the time and willpower to find it, there is still one piece of SEN's spreadsheet data that is causing an issue. I suspect the issue is at level 2, as when I raise from 1-2 or 2 and beyond, something assumes there needs to be more land around under level 1. I'm not going to put a lot of time into it, since it works well enough for my purposes, but I may go back to it someday. If you do happen to find it, let me or SEN know the exact tile which is frustrated, and we'll update it on at least one of the spreadsheet releases, as well as in my Gmax scripts related to that data.
 

Edit:

 

I suspect both tiles: 0102 and 0201 need a +1 adjustment

[CaveGnome]

From what I am reading, if I sort all the faces in a shadow mesh by their primary facing (face normal), then I can separate any mesh into 6 meshes, each casting shadows in the correct direction, by placing that mesh's pivot point behind all the faces of that mesh. I don't understand this entirely, but I understand the math on how to get there. I see there is a CODI tool for doing exactly that, but it is NOT for Gmax, and is compiled, so I don't have access to the code. Perhaps I can make the same tool for Gmax? Splitting the mesh into only 6 parts, and then removing the smoothing groups, would be really easy. Making sure I have the pivots right, based on what the CODI tool does, I'm not so certain about. Worth a try.

 

 

Are you saying that you can make a GMax script for making automatic simplified correct tile shadow meshes ?

 

That would be tremendously useful !

[MerricksDad]

I think so. So far today, I have already created a script which breaks any mesh into up to 6 parts (7 if any errors occur, but have not yet done so). You get one sub mesh for every direction on a cube. Then you should be able to change the pivots of those sub meshes to a point somewhere behind every face pointing that direction. I've tried actually moving the mesh pivot, but that only makes a mess. So instead of moving the pivots, I am changing the actual mesh position and then repositioning the mesh faces back to where they were, and see if the output is different. Hope so.

 

The first three tries were so far unsuccessful with the pivot change, and almost none of the shadow appeared on the walkable surfaces. Those that did appear would not go away in the toolset when the tile model was changed, so I suspect some internal silent error there. I'm about to try without the pivot changed to see if it is different, then onto the movement of object center and face locations. Baby steps.

 

I'm also trying this on complex meshes just to see what happens, so if all else fails, I will run this on a much simpler mesh and see if that makes a difference.

[MerricksDad]

Things that don't work:

• high poly mesh cut into 6 directional meshes
• ^ with pivot points moved
• ^ no pivots moved, but whole mesh offset instead
• ^ with or without faces exploded to elements
• walkmesh cut into 6 directional meshes
• ^ with mesh offset
• ^ with or without faces exploded to elements

^^ even though the shadow checker on NwMax shows no errors

 

Things that do work:

• faces exploded into meshes with mesh position set to face center