Transparency on Tiles - "Static" VS Non - "Static"

Neverwinter Nights 1 Custom Content
#1

While working on a little project of mine, I noticed something strange going on with Zwerkules’s City Interior Facelift tileset ( Neverwinter Nights facelift haks | The Neverwinter Vault).

When placing the window crosser on - for example - tiles from the House terrain, thus getting a window with transparent glass and a Vista tile (the half-spheres with outdoor scenery as textures) on the other side of the window, I wasn’t actually able to see the Vista tile through the glass.

What’s more, when placing another room right across, I was actually able to see those tiles through the window as if the Vista tile wasn’t there.

After some further testing, I noticed I couldn’t see placeables through the window either. However, placeables set to static could be seen in-game at least.

To make a long story short, after many hours of more or less useless experimenting, I found out that adding an animation to the tile containing the transparent window I could finally see the Vista tile (which also has animations) through the glass and the transparent window worked as expected.

The animation I added is as simple as:

#MAXANIM ASCII
newanim tiledefault gin02_q04_03
  length 0.0
  transtime 0.0
  animroot gin02_q04_03
  node dummy gin02_q04_03
    parent NULL
  endnode  
doneanim tiledefault gin02_q04_03

so not really containing anything.

So in conclusion, like for placeables, there seems to be a differentiation between “static” (those which do not contain animations) and non-“static” (those which do contain animations) tiles, at least where transparency (rendering things behind transparent planes/textures) is concerned.

I’m not sure if this something new with EE or if this is already common knowledge, but while searching I came up with nothing and thought I leave this post in case anyone else will come across this issue in the future.

#2

Instead of adding an animation, adding an animation node (tilename + a) and linking the transparent window parts to it should work, too. What won’t work, unless it has been changed in EE and not been documented, is adding emitters to the vista or seeing any emitters behind transparent meshes.

#3

Looks like you already did set up such an animation node for the window in question (tile is gin01_q04_03 with dummy node gin01_q04_03a to which windows01 trimesh is connected). Without the animation it does not seem to work though.

Maybe that is something that changed with EE? I read something somewhat related regarding 1.69 placeables with transparency Placeable Model TXI Transparency - Neverwinter Nights 1: EE - nwn.wiki

And you’re right, emitters still don’t show up.

#4

NWN EE broke the transparent textures and apparently it was never fixed. Before EE linking the transparent meshes to the _a node made sure they were rendered after everything else. Apparently that doesn’t work any more and they only get rendered after everything else if the _a node is also linked to the base after all the other meshes. Adding a tiledefault animation “fixes” this, but it is an unnecessary animation on lots of tiles and will only work if content gets changed. All the old content that relied on this to work doesn’t work that way any more. I haven’t checked water that doesn’t use the new water yet, but that was broken, too, and when the PC stepped into the water everything below the surface wasn’t rendered any more.

#5

So - if I understand correctly - it’s either that the rendering order of the engine changed (I think something like that happened before and led to the Q skyboxes not working as expected anymore) OR that this animation dummy node is no longer enough to make a tile qualify as having animations? Either way, this then seems like something that needs to get fixed by the devs.

In the meantime, I still wanted to go ahead with the “fix”/ work-around I described in my initial post. I checked and your Interior facelift tileset has 68 tiles that use the tin01_win01 texture. Since I also made a tni01 texture version of your facelift for my project, I have double the amount of tiles which need the work around to function as expected.

So I figured it would be more fun to write a python script that can do that for me than to actually adding this dummy animation (and adjusting the tile name each time) to all those 136 files by hand.

Going by the info you provided me with, the script checks all (decompiled) mdl files in an /in folder to see if:
a) they have a dummy animation node (e.g. “node dummy <tile_name>a”)
b) they don’t have any actual animations attached (e.g. something starting with “newanim”)

If a) and b) are true, a dummy animation as in my initial post gets added to a copy of the mdl file which is put into the /out folder.

I also wrote a script which removes such added dummy animations (if they are present and didn’t get changed in any way) in case this ever gets fixed by Beamdog (though just keeping backups of the original files is probably the way to go instead).

I think you weren’t too big on my work-around but in case you’re interested nonetheless (or anyone else is) I put the thingy up on github: link

It needs python to run though of course.