Merricksdad's Black Hills Tileset (First Look)

[Legacy_MerricksDad]

               

Switched to using maxscript's intersectRayEx, and getting less destruction of the mesh. Not sure how it calculates the angles. One must be wrong, if not both. IntersectRayEx also gives back a lot more error checking data, and I was able to find a better way to hammer out the shadow layers.

 

With the reduced complexity of the shadow doctoring functions, I switched back to trying the higher poly shadows again, as the lower poly shadow built from the walkmesh leaves a few noticeable lines where it differs from the visible mesh.

 

On first export I seem to have forgotten to offset the left/right/north/south pivots, causing some wrong shadows with near-zero faces, but the rest is spectacular, perfect shadowing.

 

On second export, there is no change in near-zero faces, and the rest stayed perfect. So.... now I am confused as to what I did wrong to make the near-zero faces cast shadows on themselves?

 

But first, I must locate a pizza!

 

Take a look at the perfect shadows on elevation 3

 

               
               

               
            

[Legacy_MerricksDad]

               

done! perfect! I win!

 

I'll release the maxscript shortly. I need to combine three separate scripts into one.

 

Here's what you need:

• all mesh origin z to 0, matching aurora base position z, but no lower


• all mesh verts up z by at least maximum transition stacked height (or the maximum transition offset from SEN's data). In my case that was 800, or 600 on SEN's chart, so I used 1000 anyway. I think you have up to 14000 to play with.


• separate mesh into 6 sections based on majority facing in 3-space. This is not needed, but helps a LOT in reducing the time required for the shadow detachment later. If you have a mesh built for down, delete it, Downward facing faces cannot properly cast shadows in this technique.


• offset separated meshes for north/south/east/west by x or y 250 backward from center point. This might not be needed, but I did it anyway just because I can.


• detach faces from those meshes based on if solar rays would cast a shadow on lower faces (remove the higher faces), as checked from every face's verts (thankfully intersectRayEx does not report that ray origin verts are intersected).


• repeat detach on detached faces until detachment stops (this turns out to be very few times, like 0-2 times per sub mesh)


• done

               
               

               
            

[Legacy_MerricksDad]

               

In-game shadow rendering works slightly different from the toolset rendering. Below you can see the perfect height 4 tiles again have some artifacts.

 

 

Those highlighted in pink are known and caused by the fragmentation of faces. Even faces sharing integer values will still have these.

 

Those highlighted in red are unique to the game, and do not appear in the toolset. This could be caused by one or more of the following guesses:

• Unfinished nearby tiles are stabbing into them with their faulty shadows. These tiles are at least 50 meters away, but that doesn't seem to matter with those negative shadow spikes.


• Faces pointing down in relation to the solar normal are casting negative shadows, which are not rendered the same in the toolset. Since I found out that some maxscript functions do count them, and some do not, it is highly likely a custom ray-intersect in NWN is causing the issue. I can try to locate all faces pointing down in relation to solar up, rather than world up, and see about moving them to a non-rendering mesh, or otherwise put them on their own rendering mesh and see what it does.


• My solar normal is offset by a decimal value 3-5 points below zero. I guess-timated the solar normal by mapping a shadow onto another tile offset by 1000 z and x. This allowed me to screen shot the shadow, three times, at three different day times, and in three different areas, getting the same picture each time, give or take a single pixel. In doing so, I had to take an average to get my solar normal, introducing error. Instead of using a single ray to test a single solar normal, I may use 4, reducing the error, and sealing in some of the vertical math lines, offsetting each ray target by 0.001 x/y or something similar.

Really, a few scratch marks and some dusty noise here and there is not going to kill me if it is on 4 out of 600 tiles. Not at all.

 

In the meantime, this is very much good-for-now and I am happy to move onto walkmesh detailing, and model painting.

               
               

               
            

[Legacy_MerricksDad]

               

I am very surprised at the complexity I can now achieve with shadows. The higher grade shadows I am using are at least 2x if not 4x the face count of the walkmesh. With the reduction of errors and odd shadow math, it seems I can now have more shadows with less video slowdown. I have to wonder if those testing shadows before had calculated a straight value for FPS lessening per face of shadow added? Because now I can see that some of the slowdown was, at least on my machine, hugely due to math errors. As with many programs, breaking or halting mid-function causes a lag spike. I suspect the same was happening with shadow errors. I'm not interested in running any benchmarks to test a theory on that. I just thought it was interesting. Compared to the last couple exports with the WM quality shadows and far more errors, this high poly shadow with almost no errors, runs far faster. Fascinating stuff.

               
               

               
            

[Legacy_Empyre65]

               

Surely that should have been "Yoda, find, must."

 

TR

The best Yoda-ism approximation would be "Find Yoda, I must."

               
               

               
            

[Legacy_T0r0]

               MD- looking foward to giving the shadow doctor a visit..  please provide instructions in plain english brother !


You  Rock !  nuff said.......
               
               

               
            

[Legacy_OldTimeRadio]

               

Question: How, on my machine, would I know a "math error" has occurred or track them?

 

I have to wonder if those testing shadows before had calculated a straight value for FPS lessening per face of shadow added?

 

In my testing, I mostly avoided the FPS impact entirely and looked at, generally, how many more triangles were generated with shadows on.  Because different video cards have different capabilities, FPS is subjective for a given scene.  But the number of triangles generated due to the shadows weren't.  In a given scene, the number of triangles and the number of extra triangles with environmental shadowing on are fixed things that carry over from one computer to the next.

 

Possibly trying to nail down such a thing as "how many triangles eat up one FPS" might be difficult.  An anecdote:  A few weeks ago, I took 3 models (heavy skin mesh, light skin mesh and part-based) models and added one type of them to fixed scene in the toolset, one at a time, noting the FPS drop from 158 FPS (no vsync on) with each additional instance and then compared the numbers.  While 10 beggars reduced the FPS less than 10 light skinmeshes and much less than 10 heavy skinmeshes, the actual number of FPS eaten by each type of model decreased a little bit with each additional instance.  And this phenomena was consistent, in its own way, nomatter what model I used.  (insert a look of genuine horror)  Still anecdotal, though.

               
               

               
            

[Legacy_MerricksDad]

               

Coming from a programming background, you start to see some things, even if they give no error, verbally or physically, as what they really are. I'm not talking about cats crossing a room twice, or doors appearing where they never were before...

 

The things I see most in NWN are silent divide by zero errors. They're extremely common everywhere, and even today very few people check for them on a regular basis. When 3D math goes wrong, those errors happen in GMax more than I want to discuss, so I assume anything similar related to graphics of that age is having them too. NWN doesn't usually throw such an error to the user, or if they do, they don't know why it happened so their trapping mechanisms report something else.

 

This other thing I'm seeing in the engine with the negative faces causing light interference is just another one. So many models out there with shadows turned on are not much more than an accordion of frame rate destruction, mine included. Definitely mine. Every rise and fall of the box just begging to drop a zero somewhere it should not be, or result in a nasty bottleneck of memory usage for something so simple as a tiny little mesh face.

 

I remember quite well programming my Infinity Engine clone, the Dragon Engine. One of the biggest problems (after I realized my video card at the time was only 24 bit [seriously how did I not know that already?]), was keeping frame rates high in the draw loop. I had to optimize that in such a way that no hiccup, great or small, could pause the draw loop more than a split second. (And remember this is back in the time of 32 fps on that card) One of the biggest problems was for/next looping. It doesn't seem like it is intensive, when you look at the simple words in your code, but when you understand all the calls to memory, and the validation at every single iteration (or multiple validation in the for/next definition), it really adds up. And then having to keep stacks of all the actors in a scene, and who has been drawn, and who has not. It is a wonder that NWN is even as good as it is. I seriously applaud the creators for their construction of something which most people take for granted. Yes, your horror at the frame rate loss just for having more actors is completely understandable. Thankfully NWN is mostly fluid and there is not a lot of variable checking within the draw loop.

 

I sure wish they'd let us have direct access through the scripting to the variables, instead of having to ask for them through some kind of weird proxy where functions return everything, instead of class objects.

 

If anybody is stumped on what I'm talking about, I suggest you go check out an old book: "Programming Roleplaying Games With Direct X". This came out around the time I was trying to finalize all of what I had already stolen from the Infinity Engine (including modifying the BAM format). If you understand code, and don't want to read, you can download the code that comes with the book from many places on the net. Inside you can find basic draw loops for games, even including network calls for multiplayer games. There are a lot of game programming books out there from the early 2k's with similar setups for network and draw looping. Many of them break it down in nice charts for you, and in different ways, so you can write your own loops in a way that works best for your game. I think one of them even had a low-grade directX library dumbed down so you could make one function call in the place of 7, and it was easy for "teens" to figure out. Pretty sure "teens" was in the title of the book. It really lets you see what is going on in many games out there, and what can go wrong, and why packet peeking became so prominent for Everquest and Warcraft.

               
               

               
            

[Legacy_Tarot Redhand]

               

@MD, Here in the UK there were 2 editions of that book - 2004 & 2009. To buy a new copy from Amazon will set you back £70+. Fortunately I have just ordered a used version for around about £10 (inc postage).

 

Just curious. Have you got a copy of the "gmax Bible" (link to Amazon.com - i.e. amazon USA)? It's somewhat a beast of a book at 850+ pages but appears to be a complete treatise on the subject. I have had a copy for a couple of years now. Still not made anything yet, though - it's somewhat of a dense read and not an easy tutorial.

 

TR

               
               

               
            

[Legacy_MerricksDad]

               

I don't have a copy of that one. I used to haunt the big bookstores in the Novi Michigan area. I loved walking into the computer book section, because down there it was like walking into a student bookstore, and all the giant books were at least bible-sized.

 

For GMax help, I'm basically using one of two easily accessible copies of the maxscript language reference and the forums.cgsociety.org which has a lot of good functions already constructed. Sometimes I have to convert them over from C++, but it's worth it. I even found some old comments by MDA '>

               
               

               
            

[Legacy_MerricksDad]

               

Decided I would build and export the remaining shadow equipped models. Going on an hour now, both without completion, and without crash. I guess this is good. I didn't know how long it would take to batch them all, but now I don't want to halt it to find out how it's doing.

 

I spent quite some time in the park with my boy today, looking at rock outcrops, and checking out fall foliage again. It seems like only a few months ago I took all those fall foliage pictures and released the leaf sets by species. Now I have a few to add. I also have unfinished varieties from last year I still need to package, as well as a very large list of conifer parts. I was quite busy collecting textures this spring and summer!

 

I'll be soon adding the following and updating others:

• ironwood/horn beam/blue beech


• big tooth aspen


• common witch hazel


• purple smoke bush


• common aspen/Norwegian aspen


• London plane tree


• another red maple hybrid with large full leaves

When I get around to packaging the pine and spruce foliage, what I am going to do is build a comprehensive layout for the whole tree in a single image file. I need to show the following for each species:

• New growth assortment


• Previous growth assortment (for spruce and pine, this can be kept for 2-7 years, instead of turning branch like)


• Young wood texture


• Transition wood texture


• Old Wood texture


• Dead small wood texture


• Dead large wood texture


• Knob decals assortment


• Cross section texture

I am also thinking of using my tree builder to instead create custom textures built from all this, which instead of showing the tree down to the individual leaf, I compile the assortments into a collection of pre-made branches. For rigid pines, I will probably portray these in a range of growth, having a few constructed branches for 2 to 6 years of growth each. This will substantially save on resource use in game because instead of drawing the branch down from 0 to 6 years back, I can just pop on a six year old branch in its place.

 

I'd like to package the tree builder with some species model lists in GMAX format. Something like 101 branches per species would probably do it. I can then import them by name to the main tree builder and just put them together like a kid's model car. On each of the branches, I can further create variation by including on the branch model a dummy node, which the script can pick up as a placement point for something of lesser age, calling back to the variety file to collect another. Technically, the way the tree builder is set up, I could also pick a dead sub branch to attach, and that branch can veer off at some angle predefined in the species listings I have constructed.

 

Yes, I travel outside with a protractor and ruler, because I'm weird.

 

So instead of building the tree via script at every year of growth, I'd also like to switch to pre-built tree segments, with the knob decals already on the segments. This can save me unneeded mesh vert counts, and allow me to further increase detail to the collection any time by just adding one to the list. If I see a section of tree I like in the woods, I can just go home and build that section, not rebuild the tree maker script.

 

If I complete this project in this way, which I already know will be far down the road, being that I am entering back into the geophysics program at WMU in January, I'd like to release a series of 101 finished trees for each species, providing an assortment of ages for each tree types.

 

But... for now, all I need to really think about is finishing this tileset before January rolls around, and hopefully I still have time to fix and package the rolling hills tileset I was working on just before this one. That one is pretty much done but the decals and on-tile vegetation/rocks. And now I know how to fix a few of the issues I was having with it. Now I can show those 4 different color levels of the badlands region as I wanted, and also fix the shadows.

               
               

               
            

[Legacy_MerricksDad]

               

1 hour 43 minutes to do all of them with the shadow builder, adjuster, and doctor all mixed into a single script. Maximum subdivision on any of the 6 directional submeshes looks like 5 (at only a quick glance). Now I can't wait to see how they run in the game.

               
               

               
            

[Legacy_MerricksDad]

               

Well this is somewhat unfortunate. After the time for building and then another 45 minutes for export of all that work, I see that a good majority of level 3 and level 4 combo tiles have the same in-game issues as the last image above shows. Some of them are far more distracting. I guess I will put a little more time into getting those solar-down faces separated. Last night, while in a previous sleep lacking coma, I had this idea to clone the faces and flip the clones, so that I could force the ray intersect function to see both normal-facing, and normal-not-facing polygons separately, and with different purpose. I may have to implement that easy change so I can define 4 shadow blocks for solar-down. That should take care of the majority of this mess. On some of the really steep tiles I also see the vertical line math I was thinking might be a problem, caused by using a single ray which might not be 100% accurate. I might need to go ahead and add those three more rays per check and offset them as planned. It seems two of my assumptions above are probably spot on. The third I can now disprove because even after fixing the other tiles, the same artifacts remain.

 

The really good news is that even an area using almost 50% of the tile varieties is still not bogged down by the number of shadow casting faces. Fantastic. I also can find zero shadow canceling errors (meaning that I can walk everywhere and my shadow is not destroyed). I may not sound entirely happy, but this really is something of progress.

 

I should have some time tomorrow between catching up on dishes and laundry from being couch bound.

 

I also wanted to ask you guys:

 

How important is it that your players cannot climb certain heights? And if it is important, what slope do you consider too high to NWN-walk-climb? It looks odd to climb any surface at the same speed you walk IMO, but I am kind of used to it from MMOs. With the contours of these tiles, I would only personally disallow movement over an elevation change of 3 at this point. My original intent was to disallow anything over 2, but viewing it in the game makes me change my mind a bit. What do you think? The reason I ask is that if I leave it fully open, I can continue slacking on the pathnode settings in the SET file. If I set the walkmesh material to blocking movement between any types of elevation, I need to start work back up on the pathnode autodetect maxscript, and that is just one more thing on the pile. Not that it is extremely hard, but it does take some time to adjust to these tiles.

               
               

               
            

[Legacy_OldTimeRadio]

               

IMO, over a certain steepness it just looks really odd.  But every once in a while it's good to ignore that.  For instance, I had a big rock that was really steep on 3 sides but a little gentler on the 4th (left side on this) and made that walkable up to the top, which I didn't consider too much of a stretch.

 

Anyway, let's say you wanted to have really steep walkable areas.  You could maybe help the illusion "work" a little better by using the Stone Bridge (22) surface material or making a custom one in surfacemat.2da/footstepsounds.2da.  So instead of puddles when you walk over a surface, some little emitter chunks (chunk, bounce but no splat) that roll down the walkmesh.  Looks like this.   It does not look great but maybe it can be made to look better.  I whited out the texture to more easily spot the chunks.

               
               

               
            

[Legacy_3RavensMore]

               

IMO, over a certain steepness it just looks really odd. 

 

Agree there 100%.  Just what that steepness limit is though...