649 réponses à ce sujet

[MerricksDad]

Well if nothing else, I figured out how to make realistic hair from extruding a bunch of stuff in the wrong direction on accident...

[Jedijax]

Wait wait wait! Does this shadow doctor thingama work on creature models and placeables and armor parts and heads?

Close

[MerricksDad]

I don't see why it won't, but the thing with non-tile shadows is that they are built differently, so it might not be beneficial. That is not to say that chopping it into 6 sub meshes won't do the same for those. I do know the character and his shadow casting parts are affected by the same solar plane at the same angle as terrain shadows, but I am not completely certain the same mechanism is being used to cast those shadow. Something to play with later.

 

If it is the same, then this will do the same on them.

[Tarot Redhand]

Must find Yoda.

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

 

TR

[MerricksDad]

Well I am trying a custom Intersect Ray script, similar to the one the max engine uses. We'll see how it works. So far it is acting strangely, but I can return a list of the exact faces which are intersected by a shadow, and I can modify it to get both faces which are hit on the normal side and on the back side. So far, I am trying it with just the normal side. What I am left with after 1-5 iterations is a mostly fragmented model mesh, and then a clump of faces it claims all cast shadow on each other. I highly doubt the math is right, because at least one of those faces, especially the lowest one, should drop off every time I run it, but it doesn't. I could just be wrong. Anyway, it it telling me to explode that remainder clump, but I am not.

 

First export results in a crash of the toolset, but I didn't check why yet. I suspect it is the naming scheme getting really long as it iterates.

 

Second export with shorter naming scheme seems to do the trick. Unfortunately, without breaking the remainder face mesh, I see zero improvement in shadow quality over previous methods on tall faced meshes. Improvement on short faced meshes is spectacular!

 

Third export with better naming scheme and remainder of faces exploded gives no improvement, is actually detrimental, showing face seams as lightly dotted lines, and gives a serious performance hit. Checking the mesh files shows some tvert errors. Next.

[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

 

[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

[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.

[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.

[Empyre65]

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

 

TR

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

[T0r0]

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

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

[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.

[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.

[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

[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

[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.

[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.

[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.

[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.

[3RavensMore]

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

 

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

[Tarot Redhand]

Not having made anything 3D I can only express this as an angle in degrees. My take on it is that anything over 45 degrees would look odd unless there is some way to trigger a climb/crawl animation.

 

TR

[MerricksDad]

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.

 

Oh, I very much like this idea I don't think most of my faces are that steep, so it might look just fine with some more chunks. Not sure. Something to try though.

[MerricksDad]

I measured the slopes at our campsite in Keystone, SD and found that the highest non-grass slope I could find and still climb while just walking/running up the surface was just over 45 degrees, so I think TR is onto something there. However, 45 in-game appears less steep than stuff in reality because of the OC camera angles. Perhaps an allowance of another 15 degrees is beneficial. If I can find my drawings again, I should be able to pinpoint the optimum walking slope for the realistic lower sections.

 

 

Today I spent some time on the alternate solar rays. For each direction where I had just one, I now use 4, each offset by 5x5cm from the target position of the previous. This is not a perfect fix, but did close in almost all the long slices on basic tiles.

 

I then figured most of the rest of the slices must be caused by faces negative to the solar normal, so I wrote a program to separate those. Unfortunately, that had ZERO effect on the visual output when they were simply separated from other faces which might interfere with that specific mesh. I may need to attempt face normal reversal on those faces to cast a shadow from them. The problem is that any face one solar normal cannot"see" should be seen by the other 3 solar normal directions when the tile is rotated. This means I need to leave both a positive and negative normal version of that face to cast all 4 potential shadows from the sun. That sounds a bit much to me. Cracking the faces down for solar negative faces already increased the fragmentation substantially, and I am not big fan of that.

 

I may first try opening up the variation on the solar normal directions. That may further close in the gaps, but not all.

 

Again, I tested to make sure this was not a math crash, which you can easily tell by walking through the unshadowed area. If you can see your shadow, it is just lack of shadow. If it cancels your shadow, there is a divide by zero error forcing paint failure of shadows in that spot. All the unshadowed spots still have nothing more than dual face pass through causing the issue.

 

Another thing I noticed about the shadow engine is that it often starts drawing shadows offset from the plane casting the shadow, as if beveled. This sometimes leaves shadow faces floating in mid air so many centimeters above the face intended to be shadowed. In one of the previous outputs, I noticed three of these shadow faces made a cave with the actual faces to be shadowed. It looked really strange. While I have had some success with putting a vertical wall on the inside edges of the tile (inside the earth), this success only attempts to hide those floating shadow polygons, but does not put them back where they need to be. This seems to be some kind of error in the shadow rendering loop in the engine, and is shared by the toolset. Adjusting the position of that shadow casting object has the effect of adjusting the location of the shadow, but is not entirely corrective. It is just weird.

 

I've got about another hour to wait for this export set. It already looks better than the previous, so I think I will release this one for viewing tonight, as long as the larger portion are not mangled.

[CaveGnome]

<cut>

 

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.

 

 

In special cases, it is handy to be able to climb to very high heights and steep angles even if it feels odd (imagine a rocky low gravity planet or magic boots...  ) . IMHO, no need to limit what you can climb. Module builders can use invisible walls or custom triggers to forbid way if needed. Slowing the PC speed by script action could improve the "hard" climbing effect.

[MerricksDad]

In special cases, it is handy to be able to climb to very high heights and steep angles even if it feels odd (imagine a rocky low gravity planet or magic boots...  ) . IMHO, no need to limit what you can climb. Module builders can use invisible walls or custom triggers to forbid way if needed. Slowing the PC speed by script action could improve the "hard" climbing effect.

 

That is very true CG. I'm thinking to leave it as is now, just by your comment alone. In one of the two final releases, it will have some walkmesh blockage where larger boulders and stuff jut out, also larger trees. In the other, no walkmesh blockage will be available on the tile, and neither will any tile decoration exist, leaving it entirely up to the builder what goes where.