649 réponses à ce sujet

[meaglyn]

I'd do it the other way, myself. Special cases should be the ones that have special work done to make them happen. Why make more work for the 95% of cases. I.e. all the time builders have to spend placing invisible walls for those non special cases.  If there are times the PC needs to get up those really steep ones use the climbing animations and scripts.  My 2 cents anyway...  

[CaveGnome]

I'd do it the other way, myself. Special cases should be the ones that have special work done to make them happen. Why make more work for the 95% of cases. I.e. all the time builders have to spend placing invisible walls for those non special cases. If there are times the PC needs to get up those really steep ones use the climbing animations and scripts. My 2 cents anyway...

You have a point. Things should be done for the benefit of the max of users. Personally, I prefer to choose my limits myself, even if this comes with more work in the end, but that's just me. What will be useful is more input in this subject, if possible from other module makers. Perhaps I misunderstood what MD proposed. Isn't the "height limited" option at risk of blocking the "translation up", part of the climbing animations if we where to activate it at the eventual fixed height limit ?

[MerricksDad]

Leaving the walkmesh open allows ALL possibilities going forward. Closing any of it negates that forever forward without file modification. Leaving it open lets mod makers put down those blocking decorations (visible or not). Closing it does not allow placeables to open it again for climbing (animated or not).

 

Leaving the walkmesh open allows very fast path-finding directly from point to point, but may cause units to move over the quickest path first, even if that looks ridiculous, unless blocked by module placeables. Closing it requires that path-nodes be specified for every tile in the SET file or path-finding will fail more often than not, and your character will sometimes just stand there, or double back for no reason, often refusing to go the correct way over some weird way.

 

 

Edit:

 

A third possibility exists, and that is to specify a path node in the SET file for easiest  realistic pathing from point to point, but leaving the walkmesh open so you can wander where you want, realistically or otherwise.

[MerricksDad]

well that one hour left turned into 3 or more. Hopefully that was worth it. Lets find out...

[Killmonger]

"If you see a fork in the road, Take it"      <Yogi Berra

" I will, if it is a silver one"                         <path node behavior

 

 

 

<Breathless as to the evolution of this thread, MD...>

 

If I fully understand the limitations of Nwn1,

The game engine would marshal it's resources along the existing nodes as per standard script and the Pc could wander at will. (?)

 

I vote for option 3 !!

[Tarot Redhand]

Just to add to what I said earlier. The 45 degrees I was talking about earlier is for going up the slope. Coming down on the other hand I would up the slope to, say, 60 or 70 degrees. I am basing this on personal experience of descending a steep scree slope on the Isle of Skye some years ago.

 

TR

[MerricksDad]

One would hope. It must be tried to find out I think, unless another has experience with that.

 

If I set the pathnodes to what they should be, given 3 and 4 transition changes at once should be blocked off from lower levels, it should cause the engine to move tile to tile via pathnodes, so NPCs and one-click PCs should appear to pick a more reasonable path than up-and-over any given mountain.

 

Clicking within the same tile should instantly default to localized pathfinding without pathnodes, but any click outside the tile should try pathnodes first, right?

 

It may still cut some corners which might seem unreasonable for humanoid travel, but for the majority, I think it will try straight lines through tiles it picked in the pathnode detection algorithm. I don't know if it prefers to walk from tile center to tile center, cutting corners as it goes, or if it prefers to walk tile edge to tile edge. I know it most often tries to calculate the shortest walkmesh face path from one point to another, but I don't know how it interprets tile edges.

 

Worst case scenario is actually pretty bad, because it will first get pathnodes, and then whittle the walkmesh faces down to the shortest route anyway, resulting in a straightline path as if no path nodes other than A were specified. That might register as undue strain on the engine. I don't know.

 

AHA! this batch is finally exported. Going to tinker and see if more shadow holes went away.

[MerricksDad]

Just to add to what I said earlier. The 45 degrees I was talking about earlier is for going up the slope. Coming down on the other hand I would up the slope to, say, 60 or 70 degrees. I am basing this on personal experience of descending a steep scree slope on the Isle of Skye some years ago.

 

TR

My geology teacher showed us his scar from butt sliding down an icy slope in Silverton Colorado. That stuff is all white carbonates and white jagged hydrothermal quartz with poisonous metal salts. I cannot imagine the lasting pain such a thing would have caused.

[MerricksDad]

Well, instant disappointment... but then, a spark of realization. I'm an idiot, and would have spent forever on these other large groups of faces. I offset my tiles by 1000 because I thought I was going in increments of 200, making a maximum height per tile of 800. Nope, 300x4 = 1200, so all I have to do is increase the base height of all tiles again. No problem... except I need to export again... blah. All it was is shadow from the tile behind being truncated. Derp.

 

So I guess I will try a little more variation in the solar ray tracing, and then export again. I may undo the solar down-face detection, seeing as it did absolutely nothing for the models but bloat like a summer fair italian sausage with onions and green peppers.

 

 

 

Edit:

 

Increasing solar ray "blur" distance from 5cm to 20cm. This will split more mesh, but not by much, and not anything like the division by solar direction did.

 

So now we're back to splitting by 6 directions as I did originally (instead of 6 per 4 primary solar normals, eek) and then just testing for double pass through via 16 solar normals offset from the original 4, giving quadruple coverage in the center but offering up to 20cm of mathematical mistakes to get fixed around the outside of the shadow square. This should take just under an hour to process and 15 minutes to export.

 

I also increased the under tile waste space from 1000cm to 1500cm. The tallest tile spans from +4 height at 1200 down to deep water at -300, so that should work perfectly. If I find that there is a single cm of wrong-ness in the shadows, I will increase to 2000cm waste space to fix it. I really don't like the waste space, because as was pointing out in the forums OTR linked the other day, it makes it harder to draw maps in the toolset. Not excruciatingly so, but still, very annoying. But also as was stated, there is no known way around the shadow depth limitations in relation to the tile floor level. Just don't expect this mountain set to have a true chasm terrain type anytime soon. I'll be faking it with unreachable areas made with already existing tiles.

 

Next time I do an export, I need to remember to reapply the nonexistent shadow texture to the whole range of shadow meshes before export. Their Tvert count to face count is ridiculous.

[OldTimeRadio]

@MerricksDad - Clicking within a tile will use walkmesh navigation.  Clicking x-tiles away will use pathnodes and then walkmesh as it enters each tile.

 

"I don't know if it prefers to walk from tile center to tile center, cutting corners as it goes, or if it prefers to walk tile edge to tile edge."

 

It'll totally do both, depending on what it wants to do.    I just spent a little too much time doing edge to edge walking on this basic pathnode "A" repeating tile with random-ish obscuring squares and it's not 100% but I noticed when I went from one little culvert to another, it was much more likely to not have a problem traversing along edges smoothly if I was heading east/west and was more prone to taking the "long way around" if I went north/south.  Truly odd. 

 

i really don't know if this is "a thing", though.  It could maybe not be a thing.  But it kinda looked like a thing.  Even if it is a thing, I can't imagine what kind of thing it is.  But it's there, being somewhat thingy.

[MerricksDad]

Years ago, I was trying to build a custom auto-pathing system for the Dragon Engine, but I couldn't get it to work the way I wanted. I read up on all kinds of pathing devices trying to figure out which one Infinity was using, and how. I've forgot most of it, but seeing your pictures makes me want to revisit some of that.

 

You said "as it enters each tile", so can I take that as confirmation that adding proper path nodes will let me force a unit to walk around a mountain using a single click, even if it technically can walk over by holding down the clicker as a steering device? Or do I still need to try this out and see what it actually thinks.

 

You know what, I think that book I mentioned earlier has some pathing stuff in it. I need to find a copy again.

[OldTimeRadio]

You said "as it enters each tile", so can I take that as confirmation that adding proper path nodes will let me force a unit to walk around a mountain using a single click, even if it technically can walk over by holding down the clicker as a steering device? Or do I still need to try this out and see what it actually thinks.

 

Nah, you're definitely going to have to test that.  I have worked with other pathnodes before but I do not know how much true influence (weight) they have.  My experience (admittedly subjective and limited) with them gave me the impression that they won't overrule walkable paths in favor of the pathnode, but that the pathnode and walkmesh, when on the same page, work together to do an excellent job completely getting a player/NPC from point A to point B.

 

By the way, while Stan Melax originally designed many parts of the game's pathing, it was Mark Brockington who fully matured it.  And he wrote a nice, fat whitepaper all about pathfinding in NWN:

Pawn Captures Wyvern: How Computer Chess Can Improve Your Pathfinding

[MerricksDad]

Got up this morning to find that all of the overnight exports are mangled. Not sure why, but something in the exporting went bad when some other program stole memory or something. I blame anti-virus.

 

Anyway, the main mesh is all flickery, it drags like mad, and a new shadow issue seems to have been introduced in the shallow water areas. There is now a big + symbol in the middle of every shallow water tile. Looks really weird.

 

I did find that the 1500 under tile waste was sufficient to get rid of all the other large junk, and yes it does make it really annoying in the toolset to work with. At least placeables automatically find the ground at the mouse pointer...except where there are walkmesh errors not taken care of.

 

Tiny bit more work today and then export again.

[MerricksDad]

Starting to look like the world of Svartalfheim from Thor:The Dark World

 

 

Modifications:

• walkmesh quality shadows (more holes, less time to compile/export while working on other things)
• split visible mesh into 2 parts: up-facing faces, and the rest. Up-facing faces textured to floor selection. Rest textured to dark granite.
• scripted in water planes, 50cm below base ground, for all tiles with deep or shallow water (it seems a bit bright, and is not transparent at this time)
• reduced smoothing on floor and granite to 10 threshold, down from 15, this makes it more angular, but flattens tile-edge faces a bit.

Bugs:

• For some reason selecting tiles with water and tiles with shallows and then combining the arrays unselected tiles with both water and shallows, so they didn't get processed with water planes. Strange.

[Drewskie]

this would be the perfect tileset for mini-volcanoes

[MerricksDad]

Uploaded current version to vault in new entry for granitelands tileset here.

 

If you decide to play with it now, be sure to read about why I separated it into chunks. See the example module for how I put the haks together with the mod.

[3RavensMore]

DLed it.  Unfortunatally, when I try it out, I get to the Choose Available Character screen, and after selecting a character, the Play button stays greyed out--it's not clickable.  I've never seen that happen before.  Other modules that I have still run fine.  So, what's the super secret members only handshake that I need to learn to try this out?  Do I need to sacrifice something?  Offer something to a goddess? 

[MerricksDad]

No idea. Never heard of that before. Unless I set a module thing to only allow valid characters and you are trying to use one which has been modified outside a standard module. You can always build your own module real quick and put the 4 haks in it, while I check mine.

 

Nevermind, that isn't keyed to the module, but the server when you start it up. So I still don't know

[3RavensMore]

Made a new module, imported your areas and everything works fine.

 

Oh...and it's effing brilliant.  I've been wanted to get my paws on this one for a long time.  <happy dance>

[MerricksDad]

I'll have to build a new module then. Something might be wrong with it.

[3RavensMore]

I'm seeing a seam around tile tmd07_0423 in area03.

[MerricksDad]

Many of the tiles have a temporary seam because the vertex locations are not equal. In some places the script's automatic optimize call removed a vert between two others because the edge line was the same angle. I need to write a script to put those inter-line verts back. In the meantime, you will actually see A LOT of those if you go looking. I would go so far as to say 50% of the tiles share that same seam issue.

[MerricksDad]

So one thing I was going to ask about the tileset was if you guys thought I should include 3 optional tiles for every possible combo? Right now, you are seeing a tileset with only one tile per corner combo. I am used to making at least 3, if not more for diagonals. Current diagonals only have two high sections and the middle section matches the low corners. Normally I make an option with two high corners with a bridge in between blocking the low corners.

[3RavensMore]

Are you really asking us if we'd like more tiles? 

[MerricksDad]

Ha, I had planned to do some hand-made tiles of course, but I mean basic variety tiles. I was running through stuff for about an hour last night and I think I may just do 2x variety in stead of 3x. I need to go back and wrangle all these scripts into one file now to do that. And maybe I can correct that issue with the seams at the same time.