Overlapping walkable walkmesh faces

[Legacy_s e n]

               A couple of weeks ago Ive been playing a bit with woks, trying to see if I was able to replicate what I have seen in MDA's  youtube video. In the end, I've been able to replicate it, and I came to a few conclusions that may help modellers, if they decide to go for it:

1.the engine handles the movement in 2 different ways, if you target with mouse or if you move with arrows. there is no way to get overlapping faces in a wok to work with the arrow movement: lets say the wok has just 2 faces overlapping ( a total of 4 so), and they share xy values in all 4 verts couples (lets say you make a square, you clone it, move it up the z axis and build a path connecting the 2 squares, thats what i did to experiment) there will be a square that will allow free, unbugged movement, and another that will aloow just the movement by target mouse click, and its good if the char doesnt end its movement standing over that square, because if it does, there is a chance it gets "ported" to the other square...

2. it is possible to decide which one of the 2 squares will work ok, and by consequence which one will only half work by detaching and reattacking the squares to the wok. this way we can switch the priority of the faces in the mesh, from what i got the engine gives priority in this way.

3.using arrows in the bugged face makes the char get stuck on the "exit" edge, not the one where it enters the overlap, nor the diagonal one. in fact, the 1st edge it doesnt seem to cause issues. issues comes when it walks over the diagonal one. this doesnt block movement but causes porting. the exit vert, completely blocks movement in thet direction. this using arrows. using target click it is possible to avoid port and movement blocking, just by clicking beyond the exit vert. thats safe.

4. this is something i havent tried because of lazyness, but there is a chance it can work: by using a third party wok (a placeable, or a door), that takes the place of the unbugged square, maybe exactly matching its geometry, should cause the engine to be fooled, recalculating the path and giving access to arrow movement to the bugged square. basically, an or switch.

5.the core of the problems are the edges, thats where the bugs come from: when walking over a bugged (lets call it secondary) square and meeting the projection of the edge of the primary (unbugged) square. its all about the edges.

6.I remember Helvene's walkable placeable beds: maybe thats the same principle, have the edges match the wok under the placeable (and with match i mean exactly snapped values of the verts) to fool the engine
               
               

               
            

[Legacy_OldTimeRadio]

               Giving this a Sunday bump!  I don't have much to contribute except thanks for posting your findings.

But a couple of questions:
1. Did these modifications cause any problems for you in the toolset?
2. Were the changes you describe made after the AABB modifier had been applied?  Do you know if it chokes otherwise?

I only have any kind of real experience with the "third party" walkmesh you bring up in points 4 & 6- the placeable "hole".  But some time ago, I contacted the person who wrote the AABB code for Bioware to find out how important the difference was between the real AABB routine used in the Bioware .dlm plugin and the AABB code found in NWMax and elsewhere.  He indicated that  anyone's AABB code would probably suffice but my takeaway in the context of your post is that (if you or someone else) really wants it bad enough, they might be able to hand-modify AABB node parents/leaves in the ASCII model to tweak the behavior a little more in your favor.  Or modify the existing AABB code to be friendlier to the process you use- if it isn't already.
               
               

               
            

[Legacy_s e n]

               Actually i use mdl suite tools to create walkmeshes, not nwmax stuff (im not even able to use nwmax aura stuff to make aabbs). mdl suite is much more intuitive from my perspective, and it works great. i dont think there is difference in the output though, maybe it doesnt allow some new wok material added later by bioware, but thats it... if someone explains me how to create and modify woks using aura nwnmax plugin id be grateful lol

to answer:
1.no issue in the toolset
2.the aabb/wok modifier is applied at the end of the detach/reattach/weld verts thing, also because with mdl suite it collapses modifier, and i think with aura is the same: from what i get wok material is assigned using face numbers in the mesh hierarchy, so if you add faces, remove faces from the mesh, it will change hierarchy and the aabb will address materials to wrong faces, so its good to apply the modifier and recreate the wok at the end of the process
               
               

               
            

[Legacy_s e n]

               Well if its in your skills to ascii tweak the engine code to allow minor wok retouch I am in to give councils and test out the results!
               
               

               
            

[Legacy_OldTimeRadio]

               

s e n wrote...
Well if its in your skills to ascii tweak the engine code to allow minor wok retouch I am in to give councils and test out the results!

I'm a bit behind on some commitments I made so I couldn't participate until they're done.  What I'm thinking of wouldn't be much different than the  technique (search down to "nailed it") I used to add grass to non-grass walkmesh triangles by adding extra faces in the ASCII model, though.  ATM I am foggy on how the AABB correlates to individual triangles on the walkmesh so anyone attempting such a thing would want to be clear about that first then, I think, dupe a portion of them like you do and see if you can add that info into the ASCII file under the AABB node.  Something like that.  Hierarchal placement in the ASCII text under the AABB node might my important as well.
               
               

               

                     Modifié par OldTimeRadio, 23 septembre 2012 - 06:48 .
                     
                  

            

[Legacy_Bannor Bloodfist]

               There are a couple things that confuse me about this whole idea, and please take this a true questions, not an attack on the idea or the folks with this idea:

1) Why do you need it?  Seriously, what are you going to gain that makes such a special feature worth the bugs already mentioned in how movement is handled in game?

2) How are you going to perfectly align a smaller placeable on top of a specific section of tile?  
2b) If you as the designer has issues with this alignment, consider that 98% of NWN builders won't havfe the time/skills to make that alignment.
2c) If you are planning on making a full sized placeable (10x10 meters) to overlay the entire tile, why not just add the additional full tile to the set as a feature?

3) Seriously, what can you possibly gain that is worth all of this extra required effort?  Manually editing AABB data is a recipe for disaster.  You have to do it twice, actually 3 times.  Twice per .mdl file and once for the .wok.  Some folks seem to think that editing the seperate .wok is all you need, but in fact, the .wok only gets used in a server envirronment and it will overwrite all the edits in the .mdl file regardless of how you edit the .mdl.  On SP side, the .wok gets completely ignored, and is built from the data in the .mdl file on the fly when the area loads.  It is a quirk in how the two engines were designed and how MP owners wanted protection from folks hacking into their own local copy of a given tileset to allow access to areas that should be blocked.

That is a serious amount of work, and a huge chance of serious issues when used.  so, again, why?  What do you really gain?
               
               

               
            

[Legacy_s e n]

               I try to answer at least from my perspective '>:

1. I dont need it, but for minor things itd be a nice add (im not thinking of building rooms above rooms, but just using it for small intersections like streams under the bridges and stuff like that, really a 2 faces overlap like in my tests) also, testing this will be fun!

2. alignment depends of what you need. if you use the switch, it can be done automatically by using door nodes, so a door instead of a placeable, that snaps so no toolset placement issue,
if you use placeables, like helvene's beds or otr holes, i think its tricky, 1st you need to match the tile geometry to fit the placeable one. so if you want to make a walkable table, 1x2, you need to make in the tile a geometry that fits this, so yes, its easier to make tiles instead... if we dont find a way to fool the engine!

2b. agreed

2c. agreed

3. for me, more of the overlapping thing, that i dont think it can be fooled, no matter how we try, we can just use that placeable/door thing to get a switch, and that also needs tests because i havent done them...  I was saying, more of that, Id be interested in seeing if we can tweak the code to modify some materials, and get for example, the chance to use different grass types. thatd be a great improvement, and I dont think it would bring bugs with him. its just material substitution, if it can be done...