Author Topic: Paying attention to the little things when building matters!  (Read 966 times)

Legacy_Wall3T

  • Hero Member
  • *****
  • Posts: 748
  • Karma: +0/-0
Paying attention to the little things when building matters!
« Reply #45 on: March 17, 2013, 11:58:17 am »


               @Rolo Kipp

has anyone ever managed to get that module to work? i was never successful and wanted to know if anyone else had been
               
               

               


                     Modifié par oOKyeOo, 17 mars 2013 - 11:58 .
                     
                  


            

Legacy_s e n

  • Hero Member
  • *****
  • Posts: 654
  • Karma: +0/-0
Paying attention to the little things when building matters!
« Reply #46 on: March 17, 2013, 01:19:09 pm »


               About the lighting issues that happen between tiles: as Baba and others said one can be fixed (it depends of smoothing groups) by having the edge verts AND the verts next to that (in the adiacent column/row) of a given terrain tile share both z and x or z and y coordinates (it depends on orientation)

there is another issue that apparently cant be solved because its dependant of the tileset area orientation and lighting settings and doesnt depend of tile specific lights. this effect is a lot more evident using white terrain texure as dummy, and it increments with hieght steps (so on plain flat tiles there is no such effects, but when you start use tileset height transitions of 5 or more meters, it can really become disappointing when you use light textures)
               
               

               
            

Legacy_OldTimeRadio

  • Hero Member
  • *****
  • Posts: 2307
  • Karma: +0/-0
Paying attention to the little things when building matters!
« Reply #47 on: March 17, 2013, 05:06:20 pm »


               

s e n wrote...
there is another issue that apparently cant be solved because its dependant of the tileset area orientation and lighting settings and doesnt depend of tile specific lights. this effect is a lot more evident using white terrain texure as dummy, and it increments with hieght steps (so on plain flat tiles there is no such effects, but when you start use tileset height transitions of 5 or more meters, it can really become disappointing when you use light textures)

Does it happen with Bioware default tiles?  Can you provide a screenshot of whatever that looks like and a test area with tiles arranged to show that problem?

I also assume you're not talking about something to do with shadows but the shading (vertex lighting), correct?
               
               

               
            

Legacy_s e n

  • Hero Member
  • *****
  • Posts: 654
  • Karma: +0/-0
Paying attention to the little things when building matters!
« Reply #48 on: March 17, 2013, 07:16:05 pm »


               OTR: you're correct, I decided not to deal with shadows, so its shading issue. about ss, i havent any, but if you want you can see it clearly overriding grass texture with a white one on my terria wip hak (i should still have a dload link available, send you via pm)
               
               

               
            

Legacy_OldTimeRadio

  • Hero Member
  • *****
  • Posts: 2307
  • Karma: +0/-0
Paying attention to the little things when building matters!
« Reply #49 on: March 17, 2013, 08:49:54 pm »


               That's a really pretty concept for a tileset, SEN, and thank you for sending me material to try to reproduce the issue.  I whipped up what I think is the situation you're describing.  Are we talking about the things I've marked as A, B, both, or something else?

'Posted

FWIW, I noticed a lot of what I think technically qualify as "sparklies" on that before I replaced the grass texture.  I'm not sure how much that would have to do with things yet, though.
               
               

               
            

Legacy_s e n

  • Hero Member
  • *****
  • Posts: 654
  • Karma: +0/-0
Paying attention to the little things when building matters!
« Reply #50 on: March 17, 2013, 11:42:06 pm »


               i think you got it, cant say in point A but for sure in point B: there where should be smoothing, since the 2 meshes share the same uhmm vert normals i think its the correct term, the one thing that controls smoothing groups of a mesh, there is bad lighting.... if you use the 2nd level raise (no cliffs there) and with aabb tiles, its a lot more evident (still, it depends of area orientation, so if you dont see it try to rotate the area and it will knock at the door saying hullo!!
               
               

               
            

Legacy_s e n

  • Hero Member
  • *****
  • Posts: 654
  • Karma: +0/-0
Paying attention to the little things when building matters!
« Reply #51 on: March 17, 2013, 11:47:02 pm »


               that ss shows another thing: look at the tower windows: they both have the same meshes, with some self illumination prop applied to the trimesh, and depending on orientation.... they do look non illuminated (blue) or illuminated (orange). this thing may be linked with the other one... since both behaviors are children of the area orientation
               
               

               
            

Legacy_OldMansBeard

  • Full Member
  • ***
  • Posts: 245
  • Karma: +0/-0
Paying attention to the little things when building matters!
« Reply #52 on: March 18, 2013, 09:57:59 am »


               Hi, people. Maybe I can offer some insight ?

Smoothing groups don't carry across meshes, so they break at tile edges. The ground surface on one tile is smoothed separately from the ground on the next tile and that would still happen if you made a tile group and sliced it into individual tiles. However, all is not lost.

Smoothing groups are used when the vertex normals are precomputed when an ascii model is compiled or loaded. Then they are thrown away (!) - the smoothing group indexes are not even present in binary models, which is why they come out arbirary when the model is decompiled. They are just used to control the precomputing of the vertex normals, and it's the vertex normals that control the shading in-game. It's like a poor man's normal map.

To get nice shading between tiles, you need to contrive that the vertex normals along the edge of one tile coincide (or nearly so) with the normals along the edge of any adjacent tile. Then there's a fair chance that the light and shade will look right.

There are two ways to achieve this, both of them tricky.

One way is to meddle with the vertex normals after the model is compiled, to make them all point straight up (if that's the best direction - assuming the ground is horizontal). You could do that in a hex editor or write some special software to do it. It's possible that Bioware went down that route with their tiles but if they did, they didn't tell us about it. I thought about doing this with CM3 and got as far as adding the import code for binary models but didn't write any export code so it never got finished (and probably never will). Basically, you just need some software that reads binary models (it's okay, the format is documented), picks out vertices at x,y == +-5.000, falsifies their entries in the vertex normal array and writes it out again. And you need a code monkey to write it for you ...

The other way, developed by Lord Rozenkrantz, is to chamfer the tile edges; to extend the mesh a little way beyond the tile edge so that the vertices along +-5.000 lie in a continuous surface so they are smoothed nicely and get assigned "nice" vertex normals. The chamfers slope downwards very slightly and disappear under the edge of the adjacent tile so they are not visible in-game. Obviously, you have to do this consistently across a whole tileset. I made Lord Rozenkrantz a special version of CM3 that added the chamfers automatically and that did mostly work, although it mysteriously failed sometimes so we eventually abandoned that too. You can do it by hand in GMax, though, if you want to experiment with the idea.

Hope this helps.

OMB
               
               

               
            

Legacy_s e n

  • Hero Member
  • *****
  • Posts: 654
  • Karma: +0/-0
Paying attention to the little things when building matters!
« Reply #53 on: March 18, 2013, 10:16:43 am »


               OMB: thanks for stopping by, but we are talking about a different thing
               
               

               
            

Legacy_OldTimeRadio

  • Hero Member
  • *****
  • Posts: 2307
  • Karma: +0/-0
Paying attention to the little things when building matters!
« Reply #54 on: March 18, 2013, 03:36:42 pm »


               Sorry for not replying last night.  I have better computers but this machine I'm on now is my "favorite" and for some reason the system decided to start blue screening so I decided to call it a night.

OldMansBeard, thanks for chiming in.  From what I saw last night, and I tested it pretty extensively, what you described is the phenomena I'm seeing. 

The particular tile I chose was named sen69_g01_05.mdl and which was labeled "B" in the previous screenshot I posted.  It did not appear to have any defect to cause the issue, including a lip at the top and a lip at the bottom and the ramp portion on the sides.  To the best of my observations, the face angles on either side of sen69_g01_05.mdl appeared to match each other perfectly. All vertices on the edges seemed perfectly placed.  I tried a number of different methods to identify that this was related to smoothing groups and everything I did pointed to yes.  I used a white texture, a null texture, I even used a transparent texture which TXI-directed to gold sphere environment map (this was mostly just to help me see it more clearly) and the problem was still present (Fig 1).  With no smoothing, the join between tiles was "perfect" (Fig 2), except now the problem was pushed onto the tile itself in the form of the disparity in angles between the lip and the ramp.

Note, though, that the problem does not cause a complete seam, only a seam that manifests certain spot (or range?)  in Fig 1, above.  That spot appears to be where there's a disparity in the angle (probably over some specific threshhold) of the vertex normal.  These observations seem in line with OldMansBeard's analysis above.  Examine the screenshot below:

'Posted

Vertex A (I've circled the root to make it a little clearer) points straight up, which I'm calling the "lip vertex normal angle".  Vertices B point up at an angle, the "ramp vertex normal angle" and C is the "transition vertex normal angle".  They're all different.  While a face whose vertices (or possibly just edge vertices) match either A or B vertex normal angles will smooth across tiles, any face which contains mismatched vertex normal angles (or angles over a certain threshhold) such as the triangle which contains vertices in A & C doesn't appear to.

The above is my attempt at a thesis for why there's a partial seam, partial blending in Fig 1.

I tried what I think is an analog to the first of the two ways OldMansBeard suggested addressing the issue (but using Max) last night by using the Edit Normals modifier, selecting vertex normal A (from the screenshot above) and coping the value to all remaining vertices either along the edges or in all verts in all faces along that tile edge.  Like this(Fig 3).  The problem is, as OldMansBeard pointed out, that normal information like that isn't going to "stick".  Over the last year or maybe two I've had reason to extensively try to get changes like this to work their way into Neverwinter without any kind of success. 

I dimly recall from using IDA that during parsing of an ASCII model, NWMain.exe sometimes appeared to be looking for additional information in a line which may have never been produced by either the Bioware Max export plugin or anything else.  I'm not asserting that it would be possible to have additional vertex information parsed like this but there are things which I've gotten to work and (at least) Virusman has gotten to work which are purely derived from explorations with a disassembler.

Anyway, in vainly trying to solve this particular problem, I relied a lot on information from ThallionStellani, Wayland and Danmar from the Omnibus.  I tried all of the suggestions/"solutions" they give in the Omnibus thread "Tile Lines" as well as the chamfer technique Velmar refers to at the very end of Omnibus thread "Tiles: long polygons are bad?"  It seems very similar to the technique OldMansBeard mentions in his reply above.  It just didn't work for me on this tile and it could be chalked up to poor execution on my part.

I also tried all kinds of other things, from blending smoothing groups on a model which I'd added the extra "buffer" faces Thallion suggested, to doing the same variations with a chamfer.  I also tried rotating the faces on the ramp in such a way that their angle of incidence was reduced with the lip, soemthing which didn't appear to address the problem and tended to "walk" the problem seam down the edge of the tile.

(turns empty pockets out)

I can't code so that's about where I have to stop.  I'm not an expert in tiles but this particular tile and the problem itself seemed straight-forward enough.  Hopefully someone else might be interested in taking a crack at it.  I would really like to know what the "solution" for that specific tile is, if there is one.
               
               

               


                     Modifié par OldTimeRadio, 18 mars 2013 - 04:14 .
                     
                  


            

Legacy_s e n

  • Hero Member
  • *****
  • Posts: 654
  • Karma: +0/-0
Paying attention to the little things when building matters!
« Reply #55 on: March 18, 2013, 07:15:10 pm »


               i remember a conversation I had with _six about this issue, and we both agreed there was no solution to that, its an engine limit (six may be more exhaustive, but from what i remember he said it was because of area light, that calculates the smoothing focusing on each tile centerand not so to say, pixel by pixel... and here comes our issue). not a big deal since its hardly noticeable with textures that have at least a small amount of noise like most of the terrains do. may be more evident with a snow texture, though
               
               

               
            

Legacy_OldTimeRadio

  • Hero Member
  • *****
  • Posts: 2307
  • Karma: +0/-0
Paying attention to the little things when building matters!
« Reply #56 on: March 19, 2013, 12:21:07 am »


               @s e n - I agree it's not the worst issue in the world but it is unfortunate.  I'm so used to seeing sloppy models (some of them my own, LOL!) that when I do come across a model someone has put a lot of time into making "perfect", it's a shame NWN still has one last rug to pull out from under them. 

While I was looking at that tile, I was also examining Wayland's rolling hills and a couple of other variations I found on the Vault.  I'm not a tileset guy but I was wondering if your sloped hills were based off of an existing package on the Vault or whether you created them from scratch?  After comparing yours and a couple of others by eye, I started to get the impression that if you'd used some different geometry for your slopes, you might have been able to get around this issue altogether.  I can't say that for certain, though, because elevated tiles are one of the things I know the least about.
               
               

               
            

Legacy_s e n

  • Hero Member
  • *****
  • Posts: 654
  • Karma: +0/-0
Paying attention to the little things when building matters!
« Reply #57 on: March 19, 2013, 12:44:35 am »


               I am not sure about that, but I do think that the issue becomes visible depending on slope level, and at a certain degree it fades away (?) lets say for 3 meters height (on a 10 meters base) its almost invisible, then starts to become visible, and when the slope becomes more than lets say 100% (or more, not sure at all) (10 meters height on 10 meters base) it fades away. I havent experimented but when I 1st noticed the issue I was making those hills and cliffs (i made em from scratch). 1 thing i am sure, its it depends on the slope gradient, and on area orientation, so when testing its useful to rotate the area at least a couple of times by 90 degrees. not sure about wayland hills, but there shouldnt be much difference, they should just be way more gentle than mines (3 and 6 meters for slopes, 9 and 12 for cliffs) and maybe they miss the second vert column to keep consistent the smoothing between tiles, but looking at them with a white texture should be enough to get the issue appear, if the gradiend is high enough. sadly im not in a building phase so i cant do tests