Animated Emitters in Room Models

[WildKarrde 116]

Is there any special trick to animating the parameters of emitters in room models for TSL?  I’m experimenting with modifying the Peragus medical bay (101per2a.mdl), and whenever I try linking an emitter to the node 101PER2aa for animation, that immediately breaks the emitter, even without adding animation keyframes.  I know it must be doable because the fountain in the Dantooine enclave sublevel (610dan_01.mdl) has all of its water splash emitters attached to its -a node (610DAN_01a), and the Harbinger’s medical bay (152har36.mdl) also has one with animated parameters in Sion’s kolto tank.  But I haven’t yet figured out what makes mine different from theirs.  I am using Blender 4.0 with the latest version of KotorBlender (3.10.3).

To test if I can get them to work at all, I’ve tried adding a water splash emitter (copied from 152har36 with the keyframes removed) right in front of the Exile’s kolto tank and directly linked to the model base node.  I have also made copies of it and the kolto bubble emitter and linked them to 101PER2aa.  As you can see in the screenshots below, the ones linked to the base node work while the ones linked to 101PER2aa do not, even though their properties are otherwise identical.  Re-importing the exported model shows that the emitters are present, they just don’t work in-game.  Has anyone run into this before?  I have attached my edited model in case anyone would like to take a look.

Screenshots:
Emitter layout in Blender.  The two white squares to the right of the tank are the emitters linked to 101PER2aa.

Spoiler

In-game screenshot.  As you can see, the emitters on the left produce bubbles and water ripples like they should, but the ones on the right do not.

Spoiler

 

Sample Edited 101per2a.zip

[DarthParametric 3,782]

Yeah emitters don't need to go under the A node. Although I'm surprised that putting them there kills them. I don't recall encountering that before. Here's an example hierarchy from my edit of the Taris Upper City South med center:

The VFX nodes (xxx_Bubbles) are a couple of levels deep, but ultimately under the base not the A node.

That said, I know there are vanilla models where emitters are under the A node. Like birds in skyboxes, for example. Try making your test emitters children of a dummy and then make the dummy a child of the A node.

[WildKarrde 116]

20 hours ago, DarthParametric said:

Try making your test emitters children of a dummy and then make the dummy a child of the A node.

Thanks for the suggestion.  Unfortunately, attaching the emitters to a dummy produces the same effect—The emitters are visible if the dummy is linked to the base but invisible if it’s linked to the -a node.  After some more research and experimentation, I have made an interesting discovery:  The emitters magically start working if I remove 101PERza from the module layout or replace it with a different room model.

 

Spoiler

Removing 101PERza is obviously not a long-term solution, but I’ll investigate that model next to see if I can determine what about it is causing the problem.  @DarthParametric, I saw on this thread that you and bead-v were once able to help fix an issue with Kexikus’ TSL Backdrop Improvements mod where the edits to the Ravager somehow also broke the fire emitters in the boarding zone.  Do you happen to remember the details of how that fix worked?  The thread mentions something to do with the walkmesh?

[DarthParametric 3,782]

24 minutes ago, WildKarrde said:

The emitters are visible if the dummy is linked to the base but invisible if it’s linked to the -a node

So my question is, does that matter? Why do you need them in the A node?

24 minutes ago, WildKarrde said:

edits to the Ravager somehow also broke the fire emitters in the boarding zone

The solution in that case was deleting the walkmesh that was floating out in space as I recall. Not sure if that ever got resolved properly, or what happens these days with KBlender.

[WildKarrde 116]

53 minutes ago, DarthParametric said:

So my question is, does that matter? Why do you need them in the A node?

I'm experimenting with adding a water column that drops as the player slumps in their kolto tank during the opening "waking up" sequence.  As part of that, I'm trying to make the tank bubbles turn off as the water drains, and I believe I need to have it linked to the -a node to animate the emitter parameters.  I'm also thinking of adding a moving water splash emitter at the top of the water where the player model breaks the surface.  (The emitters in the screenshots do not remotely reflect the final setup, I'm still just trying to see if I can get anything to cooperate.)  I know I can skip these emitters entirely if I have to, but I'd like to figure it out if I can.

1 hour ago, DarthParametric said:

The solution in that case was deleting the walkmesh that was floating out in space as I recall. Not sure if that ever got resolved properly, or what happens these days with KBlender.

Got it, thanks for the info.  I don't think deleting the walkmesh will work in this case, but maybe I can swap in and modify a walkmesh from another model that does play nicely with the module.  I'll report back if I do manage to narrow it down any further.

[DarthParametric 3,782]

I suppose if all else fails you could always make it as a placeable.

[WildKarrde 116]

Well, after more experimentation, I think what I’ve stumbled across is some sort of strange bug with TSL’s room visibility system.  For some reason, I think the engine is getting confused and treating any emitters attached to the 101PER2aa node as being part of 101PERza from a visibility standpoint, and it hides them when the VIS file says not to draw 101PERza.  I added 101PERza to 101PER2a’s visibility list, and voila—the emitters start working as soon as I walked into the medbay.  So if anyone else runs into this in a different module, see if you can isolate a room that your emitters may be getting confused with, and try editing the VIS so that both rooms are drawn together.

On 4/7/2024 at 8:16 PM, DarthParametric said:

I suppose if all else fails you could always make it as a placeable.

Good point, thanks for the suggestion.  That might be the better approach from a mod compatibility standpoint if I ever do release this in some form.

Some further random observations which may help anyone who tries to deal with this in the future:

• This bug only affects emitters.  Meshes attached to the -a nodes always appeared in-game like they were supposed to.
• It doesn’t seem to be related with room count.  Editing the LYT (without editing the VIS) to remove the 25 or so rooms before 101PERza had no effect, but removing only 101PERza made the emitters work.
• I was also able to make the emitters appear by deleting four meshes from 101PERza: mesh476, mesh480, mesh481, and mesh482.  However, deleting all of the room’s meshes except those four also worked, so it doesn’t seem to be an inherent issue with those meshes.
• Attaching those same meshes to node 101PERzaa also fixed the issue.  Interestingly, meshes attached to -a nodes seem to be always drawn, even when the VIS would say otherwise.  (When I edited the VIS so that no room was visible from any other room, the other rooms’ static meshes all disappeared, but I could still see their animated meshes like the docked Harbinger.)  Maybe linking them to the -a node removed them from interacting with the visibility code and therefore circumvented the bug?
• It doesn’t seem to be related to mesh count or poly count (at least, not entirely) because deleting four different meshes with higher total poly counts didn’t bring the emitters back.
• When I tried adding an emitter to the -a node of a different room in the same module, that emitter remained broken even after I added 101PERza to its visibility list.  However, it did start working when I walked a few rooms away and looked back, so I suspect that it was linked to the visibility of a different room.  My guess is that a given room’s animated emitters become entangled with a unique room, rather than every room’s emitters being linked to the same room.

[DarthParametric 3,782]

Curious. It would probably require investigation into the exe to see what is going on. Alas, @ndix UR who has undertaken such code spelunking in the past isn't around these days.