37 réponses à ce sujet

[Pstemarie]

I was talking with a buddy of mine today that has done some modeling work for various game companies over the past few years. During our discussion we got on the subject of NWN and changing seasons. He had an interesting premise which might be worth exploring - at least for outdoor tiles...

 

1. Create a single tile aurorabase and walkmesh.

 

2. Create the terrain geometry and link all of it to one of the tile animation loops, pulling the geometry below the Z 0 height when the animation loop is switched off.

 

3. Clone ALL of the terrain geometry, texture it for winter, then link it to another of the tile animation loops - as above the geometry would be pulled below the Z height when the animation loops is switched off.

 

In essence, when animation loop 1 is active, it's summer. When animation loop 2 is switched on, its winter. What's neat about this idea, assuming I'm not mistaken about this next bit, is that you can script the animation loops to activate based upon specific conditions - i.e. changes in season as emulated by the game clock.

 

Animation loop 3 would be left open for things such as smoke or flame emitters which are common to both seasons.

[Verilazic]

Just my novice opinion here: that sounds like genius.

 

Only concern I think of is how much would it hurt framerates to have all that geometry hiding below z0? I didn't think NWN did much occulsion culling?

[Pstemarie]

Good question. I'm thinking that the best practice would be to confine the geometry to just those objects whose textures change based upon the season. The remaining objects could just be left alone, sitting in their default positions. For example, in a scene with a house and a tree, just the ground object, the roof object, and the tree foliage object would need to be swapped out. You would never have to modify the walkmesh. To ensure that all the geometry stays at the correct Z height once moved the objects should be parented to a "dummy" node. The dummy node would be the piece that actually moves up and down. You'd need one dummy node for each animation loop (aka season).

 

There are actually some placeables in Project Q that use a similar method to swap out textured pieces depending upon the current animation state. For example, the Q Brazier, when on, has an object textured with reddish colored coals representing the "hot" coals within the brazier. When the brazier is off, the "hot coals" object is dropped below the Z 0 plane and replaced with an object that is textured with black coals.

[Fester Pot]

Make it happen!

Recent voting polls show there is high interest in such a tileset. Check the results.

If Zwerkules created a Seasonal Tileset using Animation Loop for Spring/Summer/Fall/Winter foliage, would that interest you? [YES / NO]

42 / 0

Miss u Zwerky!

FP!

[MerricksDad]

I would not worry overly much about the frame rates except on the shadow casting objects. If the shadow casting objects are same or similar on both alternates, I'd suggest having the shadows cast by a third object which stays put, and then just move the non-shadow casting meshes. As many have already found out, the engine, and most graphics cards, including my crappy one, can handle a very large quantity of geometry. The math included in casting shadows or anti-shadows is far more resources consuming. So for instance if you have shadow casting foliage, and a winter or fall version for that foliage exists, and covers the same region in shadow (like for pine species), then build a third shape for casting shadow at the same location, and set Shadow=0 on the other two meshes. In any other case, things which don't change volume, like tree stalks, but do change mesh to introduce snow-covered textures, are much easier to speculate on, because you know they will not change in their shadow cast shape.

[Pstemarie]

Shadows could be handled exactly as MerricksDad states - great call 

[PLUSH HYENA of DOOM]

OK, I'm fairly interested here...

 

Summer, winter, good, fine, great... nice, but normal... I don't do normal.

 

For some time I've been wondering precisely how to depict the "Time of Sundering" in Demoness Tales. You know, Ultimate Apocalypse sort of thing, everything in sight gets obliterated into tiny pieces.

 

I can do a lot with assorted post-apocalyptic, ruined Tilesets and Placeables that I'm hitting with bricks, but the actual cataclysm itself has been irritatingly elusive... But now I'm thinking if I can create shattered and blasted versions of all the castles, houses, towers, trees, etc in a Tileset that can be switched in by a script to replace the normal geometry, along with hideously destroyed textures for the ground etc, plus a couple of additional scripts for throwing up some ludicrously huge PHoD VFX around the PC whilst the switch occurs, then in theory, the actual moment of Sundering CAN occur on-screen, with appropriate Official Apocalypse sound effects TM (instead of just scripting a teleport to a destroyomized Area and rubbishly pretending it's the same place two seconds later).

 

Oh joy! I can blow up the world!

 

(Fetches new, extra-large brick and investigates the concept...)

[boodah83]

Good question. I'm thinking that the best practice would be to confine the geometry to just those objects whose textures change based upon the season. The remaining objects could just be left alone, sitting in their default positions. For example, in a scene with a house and a tree, just the ground object, the roof object, and the tree foliage object would need to be swapped out. You would never have to modify the walkmesh.

 

Pretty cool idea! But in your example, if you'd want to change the footstep sounds with the seasons (from grass to snow) you'd still need to modify the walkmesh (I think),

[Pstemarie]

Pretty cool idea! But in your example, if you'd want to change the footstep sounds with the seasons (from grass to snow) you'd still need to modify the walkmesh (I think),

 

Hmmm - forgot about footsteps. Since you can't have two walkmeshes, I wonder if the footstep sounds can be changed through scripting.

[boodah83]

Afaik, with SetFootstepType you can change a creature's footstep sounds, but the only terrain type available is water.

[MerricksDad]

You should be able to modify FootstepSounds.2da, and use this chart from the wiki, plus your new footstep entries. Which means it should be all scriptable.

 

http://www.nwnlexico...e=Footstep_type

[YeoldeFog]

Or make a footstep sound so generic that it -could- be snow but also everything else! Gooooh, I'm so smart these days!

[Zwerkules]

Make it happen!

Recent voting polls show there is high interest in such a tileset. Check the results.

If Zwerkules created a Seasonal Tileset using Animation Loop for Spring/Summer/Fall/Winter foliage, would that interest you? [YES / NO]

42 / 0

Miss u Zwerky!

FP!

 

I already explored this idea and abandoned it because of each tile having at least two if not three animations and lots of geometry. I changed the alpha instead of moving the geometry, but that shouldn't make any difference. It was too slow for me, so I didn't go on with it.

My Medieval City tileset is at the limit of what my computer can handle and a lot of Lord of Worm's tilesets run too slow. For those who can use LoW's tileset without problems this idea of season changing tiles could work.

[Zwerkules]

Hmmm - forgot about footsteps. Since you can't have two walkmeshes, I wonder if the footstep sounds can be changed through scripting.

It would be a lot of work and would require lots of triggers, but it is possible. It could cause lag though.

[Pstemarie]

Hence, YeoldeFog's (sorry mate) idea of a generic sound is better. Then again with the winter terrain you could always aim for something in early winter, when the grass still crunches under your feet. Even in a fantasy setting, not too many adventurers - or monsters - are going to be moving around in the deep snows of mid winter.

[OldTimeRadio]

@Verilazic - NWN does do occlusion culling based on the camera's viewing frustum and object occlusion.  However, my experience suggests that the object occlusion algorithm sometimes errs on the safe side by including material behind or under two objects (let's say, two flat grass tiles) because of a seam between them which is not noticeable to the human eye but which is "visible" to the computer.  Also, I believe a bounding box which extends into visible space may trigger inclusion.  A pet theory of mine, but something I have not looked into much, is this is one of the culprits behind why Castle Exterior, Rural can be so laggy when you have the sea cliffs going.

 

@Pstemarie - (Edit: See proof of concept here, requires animesh) Instead of multiplying the geometry, multiply the texture.  If you have four individual textures, combine them into a 2x2 image.  UV Mapping will have to be scaled down so the UV mapping matches up with the texture in the upper left hand quadrant.  For each of the additional animation sequences, simply shift the UV's to the to a different spot on the texture.  Tellingly, there already exist tools in Velstools to perform this shifting.  As Zwerkules pointed out, textured objects which need to "disappear" can have their texture replaced with pure alpha.  (Edit: Though shadows would still remain if it's shadow-casting geometry)  I believe Render can even be animated to turn on or off in the Aurora Trimesh Modifier, but I might be wrong.  

 

Other than location, position and scale of a mesh, settings on modifiers can be animated, too.  In animation mode, those settings will get red brackets next to them.  There are a very large number settings that can be animated like this.  And, of course, UV coordinates.

 

@Zwerkules - My guess is that you could probably add a crazy number of triggers before it would slow down an area.  Because a lot of things boil down just being triggers in the engine.  However, there's probably better shapes than others and I assume either a circle or a square is going to cause the least amount of calculations.

[boodah83]

Hence, Boodah's idea of a generic sound is better. Then again with the winter terrain you could always aim for something in early winter, when the grass still crunches under your feet. Even in a fantasy setting, not too many adventurers - or monsters - are going to be moving around in the deep snows of mid winter.

 

Yeoldefog's Idea

 

Hm, personally still very much like the visuals of deeply snow covered areas and it's not only useful for winter but also for far up north settings. Many an adventure to be had and monsters to slay in these climates as well.

 

This method of doing seasonal changes would be most useful for PW's, I think, but there are other ways to achieve this (like this). For SP modules, I'd prefer to just have two separate versions of a given tileset (summer/winter) tbh.

 

However, I still think it's a pretty awesome idea and could be used in ways like PhoD suggested (intact/ruined buildings, bridges, walls, etc.- in these cases with the walkmesh of the intact version and spawned-in invisible walkmesh blocker placeables for the ruined ones).

 

@MerricksDad: Hm, I'll have to try messing with the FootstepSounds.2da some time in the future then; would be pretty neat if that would work and could be also useful in combination with ground texture placeables (sand, snow, etc.) or tilemagic.

 

@OTR: That sounds pretty neat as well, might be also a good way for doing day/night windows, for example...

[Borden Haelven]

The forge my Steam machinery hak uses below Z:0 geometry on one of the anim loops so it definitely works. It is also script changable.

[Pstemarie]

The forge my Steam machinery hak uses below Z:0 geometry on one of the anim loops so it definitely works. It is also script changable.

 

Yes - you're forge is where I got the idea for the Q Brazier and the later forge placeable I did.

 

It's so great to see so many minds churning away on this - I'm certain that, given time, the Community can, as PHoD would say, "hit this problem with a brick" and solve it. There is a lot of talent here and it's just awesome to see everyone come together in a discussion in this manner.

[OldTimeRadio]

Whew, okay, here is a live proof of concept for my suggestion about just animating the UV coordinates:

 

 
Instructions: Module goes into module directory, hak into hak directory.  Open in toolset, click on the tile with the tree and right click.  Should get three animation boxes to tick:
(default) - Green leaves
Animation Loop 1 - Yellow leaves
Animation Loop 2 - Maroon leaves
Animation Loop 3 - No leaves (pure alpha a la Zwerkules' comment)
 
Note: Once the animation boxes are ticked, you have to close the dialog for the scene to update.
 
Quick observations and notes: Seems to work just fine, with the comment I made about alpha textures not affecting shadows being the only bit worth underscoring.  Required the creation of an "a" dummy node and the linking of the four foliage meshes to that.  Required the creation of animloops but don't forget to precede them with a tiledefault animation which is everything in its natural state, without any animloops running.  UVW XForm modifier's U and V offset were used to re-position the mapping with Auto Key turned on in Max (results in a red timeline) while Key Filters were set to only track Modifiers.  Each animation only has two keys, one at the start and one at the end and both are the same.  I also selected each of the four meshes and applied a single UVW XForm modifier which made things much easier during animation.  When done, I right-clicked on the modifier and made it unique, then moved each of those modifiers (on each mesh) under the Aurora Trimesh modifiers manually, just because.  Frame length for each animation was 10, starting with 0-9 and AniMesh sample length was 3 for each animation on each mesh.  These last two things were entirely arbitrary decisions on my part and can probably be tuned much better.  I also did not compile it, but the model would probably benefit from compilation and I would first attempt it with the leaked internal Bioware model compiler before trying anything else.
 

[Pstemarie]

AMAZING!!! 

 

And what leaked Bioware compiler?

[OldTimeRadio]

And what leaked Bioware compiler?

One place to get it is this Kit I put together, in the "MDL-Compiler Bioware" folder.  Found it tucked away on a Russian website some years ago and all the files in it are as I found them.  Works just like the Bioware DDS compiler, with in and out folders.  Sometimes I have to fall back on the DLA compiler, because it seems to have certain esoteric bugs related to characters fixed, but I always hit the Bioware one first.  BTW, the CleanModels in that kit is not current version but DLA compiler is fine.

[Tarot Redhand]

That demo looks great but I do have a question though. Don't you have to be careful with pure alpha textures? Isn't there a possible problem with punch-through? While I'm on the subject of punch-through is there a way to turn it off using txi files?

 

TR

[OldTimeRadio]

I don't understand the context in which you're asking the question, Tarot.  The only difference between my texture and the default Bioware texture is mine didn't include a TXI setting the alphamean to 0.595.  Both the default and mine are 32-bit.

[Frith5]

Cool stuff here, folks! Lovin' it.

I recall in NWN2 there was a useful method for creating 'deep snow' areas, where the snow lay over the terrain, matching the shape, and characters were knee deep or more in the stuff. I always liked that!
​​