k1 [Question] Bump-map Breaks Level Geometry Animation?

[ebmar 893]

Greetings, fellow Jedi!

I am here to ask and to report; does bump-map breaks the animation of certain level geometry?

It does occur with the m02ac_02b\Geometry\Box273 mesh on my end.

Screenshot:

• Spoiler

  

   

Update: It does working now. I had just recompiled the m02ac_02b.mdl/mdx again and strangely enough it does working on another attempt. But still I don't know what's causing the animation to stop with the aforementioned screenshot.

• Screenshot of the working bump-map:
  Spoiler

  

   

List of tools which have been used on this attempt:

• bead-v's "KOTORmax"
  Spoiler

   

• bead-v's "MDLedit"
  Spoiler

   

• ndix UR's "tga2tpc"
  Spoiler

   

• Fred Tetra's "KotOR Tool"
  Spoiler

   

Many thanks for considering this- and have a nice weekend y'all!

Edited September 15, 2018 by ebmar
Added screenshot of the working bump-map.

[DarthParametric 3,785]

All animated objects must be children of what is termed the "A" node. This is the dummy that is named "LEVELNAMEa". For example, "M01ABa" for level "M01AB". It seems in some cases that vanilla models don't always conform to this rule, but it is a requirement for any level models compiled by MDLEdit/MDLOps.

Additionally, my own recent experiments indicate enabling the tangent space flag (possibly only in conjunction with an enabled lightmapping flag) counts as animation as far as MDLEdit/MDLOps compiled level models go, so they also need to be children of the A node. This appears to be a requirement regardless of whether the model is actually truly static or not. This particular issue is currently being investigated by @ndix UR. so clarification will hopefully follow in due course.

[ebmar 893]

Many thanks for making things clear! I believe to have gained some knowledge too; very much appreciated!

10 minutes ago, DarthParametric said:

Additionally, my own recent experiments indicate enabling the tangent space flag (possibly only in conjunction with an enabled lightmapping flag) counts as animation as far as MDLEdit/MDLOps compiled level models go, so they also need to be children of the A node.

Ah-ha! Yes, I believe with the earlier attempt I had enabled the lightmapping flag [with no authentic reason- just to speculate 😁]; which leads the animation to stop, perhaps? Because with the recent attempt which is only the bump-map flag was enabled, the animation does working.

[bead-v 251]

4 hours ago, DarthParametric said:

It seems in some cases that vanilla models don't always conform to this rule, but it is a requirement for any level models compiled by MDLEdit/MDLOps.

From your wording it sounds like recompiling such a vanilla model would break it. Have you encountered anything like that?

[DarthParametric 3,785]

Wasn't that basically the issue with @Kexikus's starfields mod breaking the fire VFX on one level of the Ravager and lighting on another? Vanilla worked fine, editing it borked it.

[Kexikus 995]

I'm not 100% sure but it does sound familiar. I can't remember what the steps for fixing it were though 😕

[bead-v 251]

I checked our conversation about that issue, there's indeed a lot of bizzare stuff happening, but I'm pretty sure it all has to do with the setup of the models and not the tools themselves. Unfortunately, all the .zips with the model files are inaccessible and it seems that since the site update we can't download previous versions of mods anymore, so I barely have anything to look at. I guess I'll just try to describe what was going on...

Kexikus added the model 851nih53 to 851nih for his Backdrop Improvement mod. At first that had ignorefog off, so telos appeared completely fogged out. He originally disabled fog for the entire module to fix it. Then for v1, he hex-edited (I assume) his 851nih53 to ignore fog. Now the issue was gone so fog could be turned on for the entire module again.

BUT, now the flames in 851nih02 dissappeared. Apparently this was caused by enabling fog for the module and disabling it for 851nih53.
It was then discovered that if the walkmesh in 851nih53 was deleted, the flames would show, but now 851nih53 wouldn't show.
We now know that this is because the game doesn't render area models without a walkmesh if the .vis file is available.
So it seems that if it has to render 851nih53, in some way that breaks the flames in 851nih02.

This the structure of the model:

It was discovered that if the plane* nodes were deleted or moved under 851nih53a, the flames would show as well as the model. But apparently, moving those planes under the 851nih53a dummy caused (or at least, didn't fix) the smoke VFX in Visas' room to disappear. DP then deleted the walkmesh and moved everything under the 'a' dummy like so:

This then fixed all the issues. Apparently, under some circumstances, an area model is STILL rendered even though it doesn't have a walkmesh. @JCarter426 😮

Then there were some more problems in the other ravager module. This time something was up with the lighting. There were two area models added, 852nih13 with some ravager geometry and the reused 851nih53. The issue was fixed by applying the dummy solution to 852nih13. On the first try we forgot to move the skydome itself under the dummy, which though it caused the skydome to show, made it fogged up, and that's even though ignorefog was enabled!

This is all even more bizzare than I remember. I guess the first step in solving this would be to  figure out why 851nih53 renders without a walkmesh.

[Kexikus 995]

Well,

reading your explanation / description, I now know why I had forgotten all about those issues. They were way over my head ^^'

[JCarter426 1,215]

42 minutes ago, bead-v said:

It was then discovered that if the walkmesh in 851nih53 was deleted, the flames would show, but now 851nih53 wouldn't show.

Heeeeeeeeeeey, that sounds...

42 minutes ago, bead-v said:

We now know that this is because the game doesn't render area models without a walkmesh if the .vis file is available.

...familiar.

42 minutes ago, bead-v said:

This then fixed all the issues. Apparently, under some circumstances, an area model is STILL rendered even though it doesn't have a walkmesh.

My guess is it's thanks to the good old -a node. It seems like that's a catch-all method to have objects on an area model but behave not like an area model.

Obsidian definitely did something under the hood that changes how things are rendered. I think we discussed this away from the ears of the common soldiers already, but might as well put it on record. In K1, dynamic objects (creatures, placeables, doors) only render depending on the visibility file, just like areas. If the room they're in isn't visible from the room you're in, you won't be able to see them. You can confirm this by messing about with the camera using GLIntercept. In K2, it's different, however. All dynamic objects render all the time. This includes any area objects linked to the -a node. Here's a good visual example of it:

Spoiler

I took the screenshot when my party was in their apartment. You can see an example of a room that's visible from our apartment - the exit to the shuttle bay. You can also see that the apartment complex across from us is not visible from our apartment and therefore most of the area geometry doesn't render. However, all the dynamic objects in those rooms do render - the doors, the placeables, Harra - as well as the windows and window blockers on the room models, because they are linked to the dynamic -a node.

Why they did this, we can only guess. But as I said in my previous bug reports, I suspect the presence or absence of a walkmesh is interfering with things because Obsidian used the aabb node to differentiate between static area models and dynamic objects as some sort of prerequisite for what should be rendered. Perhaps if they hadn't done that, then all rooms would render all the time, making the visibility file pointless. The trick, it seems, is sorting out what exactly the other prerequisites are....

[ebmar 893]

Quote

I believe with the earlier attempt I had enabled the lightmapping flag [with no authentic reason- just to speculate 😁]; which leads the animation to stop....

I'd like to confirm that it wasn't the enabled lightmap flag that was causing the animation to stop. I have just checked again the working bump-map flagged vanilla m02ac_02b model which I am using now, and the lightmap flag was indeed enabled. Sorry for the commotion I've been causing, but still- I don't know what's causing the animation to stop as seen in the screenshot. 🤔

Update:

• Screenshot of the working bump-map:
  Spoiler

  

   

Edited September 15, 2018 by ebmar
Added screenshot of the working bump-map.

[bead-v 251]

2 hours ago, JCarter426 said:

The trick, it seems, is sorting out what exactly the other prerequisites are....

The question then is why the fogged out skybox in 852nih13 rendered when it wasn't under the a-dummy (everything else was though). There was no walkmesh and ignorefog was enabled...

 

2 hours ago, ebmar said:

I'd like to confirm that it wasn't the enabled lightmap flag that was causing the animation to stop. I have just checked again the bump-map flagged vanilla m02ac_02b model which I am using now, and the lightmap flag was indeed enabled. Sorry for the commotion I've been causing, but still- I don't know what's causing the animation to stop as seen in the screenshot.

Well, what else did you change when it started working?

[DarthParametric 3,785]

The issue I had in TSL was that a static mesh with tangent space and lightmap flags enabled would not properly render the lightmap (i.e. the mesh was pitch black) unless the mesh was made a child of the A node. Then the lightmap would appear correctly.

[ebmar 893]

10 hours ago, bead-v said:

Well, what else did you change when it started working?

No, I haven't change anything other than checked the bump-map flag. I have learnt not to fiddle around with anything I'm not yet to understand 😂 - for example:

• Once I fiddled around with the vanilla P_BastilaH.mdl/mdx by unknowingly checking the shadow and the lightmap flag with both the (mesh) eyeRlid and (mesh) eyeLlid which leads to this result:
  Spoiler

  

   

As seen in the screenshot, there is a straight black line that is act like shadows which it was quite noticeable in-game, ranging from Bastila's meshes to as far as it can go the way I see it. Unchecking both the lightmap flag and the shadow flag to both meshes removes the black line again.

Edited September 16, 2018 by ebmar

[DarthParametric 3,785]

That would purely be a shadow issue. The engine has trouble generating/rendering shadows from certain kinds of self-intersecting/non-watertight meshes, which classification the eyelids would definitely fall under. You can see a very clear example of this in action in M4-78: