649 réponses à ce sujet

[3RavensMore]

Is there a road or perhaps a trail planned for this mountain set? 

[MerricksDad]

I want to do a road on the 0 and +1 terrain. I want to do a dirt trail on 0 to +2. Roads will only be allowed on flat tiles (0000) or tiles that rise two sequential corners by +1 (so 0011, 0111). I will also do a road split for three adjacent corner rises. I will do similar for trails going higher (so 0000, 0011, 0111, 0022, 0222).

 

For stream, I am playing with three ideas:

 

The first includes adding a stream only on tiles between 0 and +1 corners, with waterfalls from higher elevations also required to pass between those corner elevations. (0/0, 0/1, 1/2, 2/3, 3/4) This limits the stream tiles required to a reasonable level, but gives streams an ability to have two uneven banks.

 

The second includes having streams located on tile edges, reversing the meaning of crosser placement for streams. For instance, a stream crosser at the top of the tile would place a stream along the top, rather than from top to middle. While this has some drawbacks, it also allows me to place streams in the exact edges where streams would most likely be in a mountain setting, and that is at the lowest point between two higher places. This also means edge streams will only look good on edges which are the lowest two corners on a tile. It may create some confusion when three or four corners are equally the lowest, but I am trying to work out a feasible system for this reversed crosser activity, mostly because I think it can lead to a new building method.

 

Like the second idea, the third idea places streams not via normal crossers, but instead places them as a terrain, similar to shallows. Because streams need to be on the lowest section of a tile, they would only be available on level 0, just like shallow water is. Since any corner can technically be 0 for whatever height plane it is on, that allows streams to be placed anywhere that is not a upward pointing corner. Streams would then be connected via the tile diagonals, or along tile edges. Streams on edges disallows streams to turn a corner in a smooth manner, unless streams are made to turn smoothly over diagonals instead. The tiles required would be reduced if no streams could make 90 degree turns without using a diagonal tile. Having streams on corners also makes it super easy to link streams with water tiles.

 

In addition to the above, I want to include at least one of the wall types I had planned originally. I might just go with an outcrop of a different type of rock for now, at a slant to the ground plane. That way you can use it as a hogback pointing uphill, or an outcrop pointing away from the mountain center, as you would see with many faults. Like roads and paths, I would only include walls for flat areas, or small raised areas. However, a wall-type crosser could also be used to make the jagged spires I wanted for higher areas.

[MerricksDad]

Today I am working on the 2x tile variety. I'm also working on a better and faster method of turning edges to reduce downward facing polygons. Using rayintersect, I can now determine if any edge is hovering over another part of the terrain, and if so, flip it, in a loop checking again and again, until all edges that were naughty have snuffed it. One thing about this new method is that it leaves more face detail, because it prefers to flip edges to erase downward facing polygons, rather than collapsing faces.

 

The second set of tiles, similar to the first, takes the center-most vert and the connected faces out two face selection expansions. Then I flatten them and raise them to the bounding box height of the tile. This creates the diagonal bridges I needed to complete the diagonal variety I usually offer, and gives a walkable outcrop or cul du sac to tiles like 0001, while making more raised walkable area on tiles like 0111. Since the raised center matches the highest level of any given corner, this means the outcrop is going to be as high as it can, especially after noise is added. This also leaves room for more tiles to be created in the future, if I choose to make alternate tiles with the raised center equal to one of the other two heights on a 3 or 4 height tile. This leaves room for creating walkable ledges, or the ability to smooth a tile diagonally, allowing natural looking transition up 4 levels at once.

 

That also leads me to a reasonable walkable angle for this tileset, in the event that I do confine the walkmesh. If I assume that I need to walk up at least +2 elevation changes, then 1200/1000*45 degrees = 54 degrees. So I will be testing some walkmesh confinement on any face elevated over 54 degrees on an edge. Half of that being 27 might show me the face list for grass placement.

[MerricksDad]

I am not entirely sure (waiting on export) but I think this new drawing method makes things softer looking in most places. It might also increase the walkmesh complexity, which is a bad thing. One thing is sure, and that is that it is faster, has less bugs, and doesn't stutter or stammer on places where it cannot flip an edge to get rid of overhang.

 

It has also wiped out the tile edge issues with center-line verts being removed due to heavier optimize calls. This should reduce the seam visibility to near zero. Strangely, that also increased the mesh complexity of more flat tiles, which I hope gets rid of some of the occasional odd shadowing in their centers.

 

I'll report back with pics once I get to actually see the set.

[T0r0]

Haven't had a chance to DL yet but this is an instant masterpiece bro !

And the fact that it is all script based is incredible. What I'm really hoping for is to somehow put all those scripts (shadow doctor, pathnode finder, etc) to use and improve older tilesets. Will that be possible ?

[MerricksDad]

It could be some time. Right now I am fine tuning them for my own needs, but I think they will work ok on other tiles. Shadow doctor should work on any type of tile, no matter what. The pathnode finder works only on tiles named like mine and expects similar walkthrough patterns. The rest of the stuff might work on other tiles if they are not concave on the x/y plane, but not sure. Out of 1200 tiles, only one tile failed to optimize with the new edge optimizer, and it tries multiple times the first run. At least it flags those ones red it cannot do. After two more tries, it got a noise pattern it could work with and was able to complete.

 

So I'm having some trouble today. I keep running Gmax out of memory, or trying to do batch work on 2000 or more objects. Gmax is unhappy with me, so the simplest things have taken hours to complete for a batch of meshes. I was able to export about 20 tiles earlier, and found I had made a mistake in the shadow mesh, simply because I had forgotten to add a trimesh modifier and turn off render. Now all hell has broken loose because I need to manage 10000+ objects and apply that modifier, and it just doesn't want to do it in a batch, or individually by script. I also found that somewhere along the lines today, the texture on the floor and wall faces got smudged, so I need to fix that.

 

What a pain.

[Empyre65]

I wonder if you could do multiple Gmax batches using and old-fashioned DOS-style batch (.bat) file. To do this, use start /WAIT and then your Gmax command, or else it might try to run them all at the same time. It would look something like this:
 

cd \folder\path

start /WAIT gmax.exe some parameters here

start /WAIT gmax.exe parameters for the second batch

etc.

 

[CaveGnome]

<cut>So I'm having some trouble today. I keep running Gmax out of memory, or trying to do batch work on 2000 or more objects. Gmax is unhappy with me, so the simplest things have taken hours to complete for a batch of meshes. <cut>

What a pain.

 

Have you tried to expand your system virtual memory ? Allocating more hard disk drive space in the paging file can alleviate heavy program use (on XP or Win7: system, advanced tab, under performance & settings, virtual memory. Double the max limit for ex.). Another way to boost program perf is to allocate this virtual memory file only on your fastest drive (system create it by default on C:, but that's not always the best unit, specially if you own an SSD).

[MerricksDad]

This morning after making a few changes last night, the current file is not able to be lit properly. There are over 16000 objects in the scene at the moment. What I'm going to do is move the new half into a separate file and go from there. On the previous computer, there was no way I could run half that many elements in a scene and still be able to rotate my view. And on the machine before that, just having 200 trees in a scene extracted from OC Mdl files was enough to crash the viewport.

 

Hopefully this fixes it, or I will have to revert to an older file and see if something else is wrong with it. I know one of my scripts made a pile of meshes with no verts, and applying certain modifiers to that crashes gmax without notice. I cleaned those up and got some access back last night.

 

While I cannot select all the meshes I want to move to another file by name, because there is almost 600 per subset, with up to 14 child meshes, I did make the good move of separating the new set and old set by 15000cm. I'm running a delete loop on everything over 15000, and then will reverse the function on the previous file to separate the other half. That should put me back where It was yesterday morning.

 

Edit:

Wow, that worked. Now something that was taking hours is now taking 30 seconds.

 

Exporting...

[MerricksDad]

Export of the new originals shows that their polycount on the visible faces is a bit lower. I can see more faces in the sun. But, something about it is multiple times faster to export. Instead of 45 minutes, this only took 7.

 

 

I'm exporting the alternate tiles right now, and then will update the SET file with the alts. It should look more varied with 2x variety, and some of the areas will be 'fatter' and have more walking area which is flatter. This can also make the ravine shapes more tight feeling.

 

I'm also coming up with some texture options. Something more white on the rock, and something less moss and lichen covered for the ground might look more sharp and bright.

[MerricksDad]

Nobody caught that the SET file in the download was mangled? Lol! I had apparently changed the set name in the old set editor and it reset all the tile offsets to 0. This new one I am uploading right now will fix it.

 

Ok, so this next version has an updated SET file which includes 2 tiles for every possible combo. Some of the tiles are really similar, but not entirely duplicates, but most of the tiles represent an "innie and outtie" variety. The new outtie files are all suffixed by _2, and sometimes have taller knobs at high places. They also have more reasonably walkable area on knobs and at wider flat sections.

 

The walk for each is a bit less complex than the last release, but not by much. Shadows are cast with this mesh shape.

 

Visual mesh is about 1/3 less detailed from what I can see. This makes export/import and loading a little faster. The visual mesh is also less collapsed, and more rounded due to picking more edge turning and less face collapse. I'm not sure which one I like better, but this version has less errors and far less manual cleanup after running the script, so that makes it my go-to choice. In the previous version of the edge turning script, it often left 1 in 10 tiles processed with a missing or flipped face, and those were ALWAYS along the tile seam.

 

Speaking of seams, the previous version's tile seams were often off by one vertex missing per edge in about 1/2 of the tiles. That was a lot of seams. This version should have exactly the same vert count and position per tile edge from tile to tile. If you do spot a seam, let me know. One tile to watch is 0001. Certain tests are reporting it may have two ridiculous fraction verts which may hang off the edge. I don't see it yet so I'm letting it ride.

 

I set the opacity on the water texture to 50% but it didn't seem to take, or may be related to the TXI animation. I'll play with that later.

[OldTimeRadio]

Strange.  I can't login to your test module.  You know what's up?  I went ahead and made a new character and even then I couldn't login.

 

?

 

Edit: I guess I'm having the same problem that 3RavensMore is having.  (puzzled face)

 

Edit-2: I can make a new module with the haks and it works but you might want to genericize that test module so people can quickly jump in and check it out.

[kalbaern]

I've just been adding the hak to a test module of my own and it seems to work fine.

 

I really like how it looks so far. I'd like to see the grass option actually have grass though and was hoping to see some of those hoodoos shown way back in the first pages here.

[OldTimeRadio]

Feedback: I have tried to do a lot of things through automation that I eventually realized couldn't fully be done in an automated way.  Or, put another way, I could get like 80% of the way there with automation and the remaining 20% had to be done by hand.  Which led me into sort of an 80/20 "rule" paradox: Getting 80% done only took 20% of the time.  Getting the remaining 20% took 80% of the time.  After making a scratch area (looks like this) and turning the shadows on and off in the toolset I was seeing very few shadows.  But what really stood out were the smoothing discrepancies.  I understand that given the overall nature of the material itself, there are going to be "smoothing discrepancies" because it's granite and it cleaves in such and such a way and it's just going to look like that.  But the discrepancy between tiles (if you look on the right side of that pic) is really pronounced.  To take a sample tile: tmd07_0011_2.  It looks kind of wonky on the slope and the tile seams are really visible.  The part of the tile near the top of the picture looks freaking fantastic but the bottom part and the edge seams maybe deviate away from looking like granite and more just like a low poly model with not a lot of smoothing applied.  From reading upthread it looks like you might be doing an autosmooth set to 10 (?) over the whole tile. 

 

I'd just kick out two pieces of feedback which I admit are of dubious utility because I'm no tile expert:

First, would it be possible to apply a higher smoothing to faces closer to the edge and less in the middle 3/4 (or 7/8?) of the tile to make the issue I describe above "go away" while still retaining the automated nature of the process?

 

Second, I kept ticking shadows on and off and saw very few shadows appearing- it could obviously have been my choice of tiles.  However, there was a self shadowing (I think that's what it was) on one tile and another which was close to a body of water was throwing a weird shadow fragment on it.  If you had 10 "zots" to throw at the tileset between shading and shadows, my vote would be more zots in the smoothing and getting the tiles to look "just so" and not spend so many zots on the shadows, which are (I'm assuming) way more time consuming per fix.  You had sort of floated a question earlier about how many of us used shadows.  For me, if something comes with shadows I'll probably play around with them on.  But if they aren't included, no big deal.  I just don't miss them that much.  But what really stands out is the smoothing, because that's always on unless the ambient sun/moon is set so light that it blows it away.

[OldTimeRadio]

Amendment to first suggestion: Just checked out the actual tile in Max.  If tmd07_0011_2 is representative of the rest of the tiles, where the visible mesh is broken into several different meshes by material, maybe just apply a different smoothing formula to those portions of the ground mesh which are supposed to be rockier versus ones which are less rocky?  I.e., if it's got the rock texture, smooth it at 10 (or whatever) and if's got more of a ground texture, smooth it at something higher?
 
Current and with non-rock "ground" in one smoothing group.  One smoothing group might still be overkill for the texture that's being used though (raises eyebrow) a fat grassy texture in contrast with that granite could give it a look similar to the hills in the Giant's Causeway in Ireland.

[MerricksDad]

Strange.  I can't login to your test module.  You know what's up?  I went ahead and made a new character and even then I couldn't login.

 

?

 

Edit: I guess I'm having the same problem that 3RavensMore is having.  (puzzled face)

 

Edit-2: I can make a new module with the haks and it works but you might want to genericize that test module so people can quickly jump in and check it out.

I don't know what my computer is doing. Modules in the past could be used by others. This time I cloned it off twice and tried it again and it still worked for me. I may have to just build another and pile on some new mountains. Did you try the same thing 3RavensMore did? If that works for you, maybe I can do that on another machine and upload the one I got from the other machine? I'm stumped.

[OldTimeRadio]

Didn't try to reimport the area.  Since I could add the haks and make an area, I didn't pursue it further.

[MerricksDad]

Feedback: I have tried to do a lot of things through automation that I eventually realized couldn't fully be done in an automated way.  Or, put another way, I could get like 80% of the way there with automation and the remaining 20% had to be done by hand.  Which led me into sort of an 80/20 "rule" paradox: Getting 80% done only took 20% of the time.  Getting the remaining 20% took 80% of the time.  After making a scratch area (looks like this) and turning the shadows on and off in the toolset I was seeing very few shadows.  But what really stood out were the smoothing discrepancies.  I understand that given the overall nature of the material itself, there are going to be "smoothing discrepancies" because it's granite and it cleaves in such and such a way and it's just going to look like that.  But the discrepancy between tiles (if you look on the right side of that pic) is really pronounced.  To take a sample tile: tmd07_0011_2.  It looks kind of wonky on the slope and the tile seams are really visible.  The part of the tile near the top of the picture looks freaking fantastic but the bottom part and the edge seams maybe deviate away from looking like granite and more just like a low poly model with not a lot of smoothing applied.  From reading upthread it looks like you might be doing an autosmooth set to 10 (?) over the whole tile. 

 

I'd just kick out two pieces of feedback which I admit are of dubious utility because I'm no tile expert:

First, would it be possible to apply a higher smoothing to faces closer to the edge and less in the middle 3/4 (or 7/8?) of the tile to make the issue I describe above "go away" while still retaining the automated nature of the process?

 

Second, I kept ticking shadows on and off and saw very few shadows appearing- it could obviously have been my choice of tiles.  However, there was a self shadowing (I think that's what it was) on one tile and another which was close to a body of water was throwing a weird shadow fragment on it.  If you had 10 "zots" to throw at the tileset between shading and shadows, my vote would be more zots in the smoothing and getting the tiles to look "just so" and not spend so many zots on the shadows, which are (I'm assuming) way more time consuming per fix.  You had sort of floated a question earlier about how many of us used shadows.  For me, if something comes with shadows I'll probably play around with them on.  But if they aren't included, no big deal.  I just don't miss them that much.  But what really stands out is the smoothing, because that's always on unless the ambient sun/moon is set so light that it blows it away.

 

Keep in mind this is still WIP. I'm sure you did, and thanks for the feedback.

 

In comment to the shadows on/off thing. I noticed some of the times that shadows from previous models changed to another will linger in the toolset. I expect this is some kind of error in the toolset not being reported. It happens far less now than before, but still does happen. If I start a chart of which tiles do this, I can probably find a common issue and fix it.

 

In comment to the top-down picture you sent with the lack of smoothing, I specifically am using a very slow smoothing threshold because using a larger one, even as much as 15, causes the tile, which is smoothed on a curve system, to toss that curve UP on one tile, and DOWN on the adjacent one. The only way to fix that is to manually modify the edge normals, which doesn't work correctly from export of GMax to import in NWN, or to make an amount of faces at the edge of any tile which duplicate the position and angle of all potential adjacent tiles. I have a script system which does this, but it doesn't work as well as you might think. Because smoothing is based on a curve, sometimes a single face is not enough to get the wave to come near a zero point. My script went so far as to try three faces at different lengths from the true edge of the tile. None of the combinations I came up with were sufficient, as they either required a distance I was uncomfortable sacrificing from the edge of the tile, or they actually made smoothing worse in on way or another.

 

Another thing I tried, which actually worked well, even though I got lots of suggestion NOT to do it, was to let the edge mesh flow outside the tile boundary box. This let me flow the contour from one tile into the next. There was still a seam, but that let the seam be something other than straight lines. Check out very early in this thread for screen shots in the more bubbly black hills tileset. I really tried to distance myself from that method with this script, but I still have the other scripts to make those paper-doll type wrapping meshes. One big thing I think that kind of mesh will do is destroy the whole shadow mechanism. Because up to half of the tile mesh is actually outside the tile boundaries, I can't even imagine one way or another if this shadow doctor script will work on such a monster.

 

Back to the pictures you linked. The most prominent tile edge mess is visible on majority of '_2 tiles. This is because my alt tile builder raises the center vert, all faces adjacent to that, and all faces adjacent to those. That actually spans to the verts second from the tile edge on the primitive mesh I was using. The problem is then caused when the outermost group of faces is not flush with the next tile. In the case of '_2 tiles, this is much more than simply not flush. It's more like 15-30 degrees off flush, so it is quite visible. I don't much like it either, but I need to rewrite that part of the script, possibly using less faces around the center part that I raise, or somehow splitting the outermost selection faces in half before I push them up. That would leave the half of those faces nearest the edge much more flush with adjacent tiles.

 

Just to reiterate, increasing the smoothing threshold around the edge will actually make it worse, not better, unless the ring around the tile is divided into a detached element first, removing the wave-like smoothing at the edge of the rising area.

 

On shadows: if you can point me to any one tile that throws spikes, I would gladly fix those, especially if they throw negative shadow spikes outside their tile box. But I want to make sure everybody knows the long white parts on the tiles right now are not negative shadow, but instead caused by the low quality shadows I am currently creating using the walkmesh. Because the walkmesh shape sometimes goes over the visible mesh, what you get is self shading. Most of the time the walkmesh surface falls under the visible mesh, and that is where shadows are the best. When I export this using shadows created from the visible mesh, the shadows are much better, 4x as complex, and it takes a long time to export. Since I'm not really pushing that work right now, I'm repeatedly exporting with the walkmesh-grade shadows. If you'd specifically like to take a look at the higher grade shadows, I can do one up tonight and pack it so you can see the quality and bloat difference. It's quite interesting. You will however see some places where the shadow rendering stuff in the engine totally fails. Sometimes you will see a shadow mesh face which is in the same position as a visible face. Since I have no way to decide where shadow faces will be drawn when the lighting is applied, I don't know how to fix that. Another issue is that sometimes the shadow faces are detached from the rest of the shadow, and float up to 5 cm above the shape they are supposed to be parallel to. This looks really weird. Between these two really noticeable issues, I would say the last time I exported full shadows, there was one face on every 30 tiles which had a flicker-face shared position, and there were about 1/10 tiles which had misplaced shadow faces. Again, I don't know how to fix that, since I don't have access to the code which actually draws the shadows.

 

So back to smoothing. One of the biggest ways I intend to overdub the visible geometry lines is to paint decals onto sections which I pop off with another script I am working on. This script will detect verts which are higher than the faces it is attached to. It will then spread out its selection a number of times, or less if the shape of the mesh begins to curve back upward. This lets me select and detach circular and eliptical regions, clone it, place it over itself by a single cm, and then paint it with one of 10 or so decals specific to the area. Another method I was planning to hide a lot of the geometry lines is to add shrubs in places which are most angular, basically hiding the floor-located deeper lines with a bush. I know that is pretty much cheating, but I don't question it will work

 

Now another thing I do right now is separate up-facing faces from not-up-facing faces by a majority direction found in the face normal. If I change from strictly majority, to mostly majority, with a secondary setting added to the function, I may be able to select slightly more or slightly less faces at the position where slope changes faster. This will help to smooth the transition from one texture to the next. Another thing I have thought about doing is using a second part of the original splitting function to backtrack and detect "floating" faces. I think of these polygons in a geology term "xenoliths", which are rocks which separated from one body of rock as molten rock came up from underneath, encapsulating the chunk and placing it in a rock layer it shouldn't have otherwise been in. If I go back and attack these xenoliths, both upward and downward, I can place them more accurately with what type of material surrounds them. This will allow more smoothing to be had at those boundaries.

 

Back on shadows: while I am interested in finding out the exact details, I am more and more likely to turn them off myself as I work on this. I am much more happy with full quality shadows than I am with the walkmesh quality ones, but I don't know if there is EVER a "perfect" end to that endeavor. I would put money on there NOT being one.

 

Speaking of the "Causeway", I already downloaded the textures to make that place But not right now. I wanted to represent some slowly cooled basalt in the deepest section of my three underdark tilesets which are up next.

 

For grass on this tileset, I intend to use the same 3/4 human height grass I used in the pictures I put out for the High Plains/Badlands sister tileset. I'm intending to use a high gold - low green grass color, and I suspect the length will cover a great many of the tile seams.

 

As you have determined, I pretty much don't want the seams to go away on the rocky section, but I don't mind if the other texture is more smooth, I just need to do it in a different way. As you saw yourself when you smoothed the floor mesh, it looks more smooth on that tile, but adjacent to another tile it will look even more sharp-lined at the seam. Not much more because it was pretty bad to begin with on the '_2 tiles, but still more sharp tile to tile. I really need to fine tune those alt tiles more like the way the previous release was. It still had visible seams, but it was much harder to tell which seam went with which tile.

[MerricksDad]

Now that I am thinking about it, I just had this idea for the edge smoothing feature. If the bottom of a tile and the top must be at the same angle to avoid a smoothing issue, and if the sides must be equal for the same reason, but if I DON'T want a flat section at the left and right edges of the tile, only at the top/bottom, then why not have all left-leaving faces go up, and all right-leaving faces go down. If the angle that they leave is equal, and the length of the edge face on both tiles is similar, that might make it smooth near 100%. And if not, the lack of downward facing light on that area will be better at hiding the seam and highlighting it. ... that is if the upward facing seam isn't super reflective.... something to try tomorrow.

[MerricksDad]

could somebody download and try testing module v3 from the vault entry and tell me if it suffers the same lock-out problem? I'm trying to figure out if something is written to the file type format, like what version the thing is made in, or something. I'm so far lost on this bug.

[MerricksDad]

When I build a module now, this is what is in the module>module.ifo file (extracted by putting a module in the hak editor).

 

 

While I have not studied this, I think there are only two things in the file that might lock you out, and they both have to do with versioning. The first is Expansion_Pack which is set to 3 on mine. And the second is Mod_Expan_List, which is 16 for some reason. I may need to examine why this is the case, and if the GOG install is somehow different in this aspect.

 

Edit: What the heck is "examplearea" ?

 

Edit: TR already found this bug last year

 

http://forum.bioware...demigods/page-7

[MerricksDad]

Examplearea bug is fixed from here on out. See here for details

[3RavensMore]

Downloaded the latest .mod.  Still no go--but with a different error.  Now it doesn't even load the module, it just comes up--in game--with a Failed To Load, Module May Be Corrupt.  When I try it in the toolset, I get an Index Out Of Bounds 553 error when I try to view area03.  Area05 does the same thing but with 558 error.

[MerricksDad]

I think I know what it is. You have the module for the most recent release, with 1092 tiles, but you have the tiles/gamedata downloaded for the previous with only 546 tiles. It is trying to build an area for you using only the older SET file.

 

Edit: I added a complete hack package to the download page. Now you can get ALL of it in one zip file to stay up to date, instead of having to download all 4 sections. I will still do the 4 sections stuff in case I only update one part of it in the future, which I very much expect to do.

[MerricksDad]

Pretty