Gamma_Metroid
-
Posts
36 -
Joined
-
Last visited
Gamma_Metroid's Achievements
Knight (6/12)
0
Reputation
-
That does fix it, thanks again!
-
Yes, it's still there. I haven't moved or changed it since I first set it up.
-
I am having some trouble with the "material names" feature again... This time, I can see in the debug log that the "sw-moss" LOD models appear to be found, but in the Object Report it is showing the default LOD model being used, and that is what ends up in the .bto files. For example 05007884 is a variant of rockL01, and the debug log shows these lines: Line 110412: [02:14] [BuildBaseRecords] <Debug: Looking for rockl01_LSC_AI_Dry for Skywind.esm _LSC_AI_DryRockL01 [STAT:05007884]> Line 110414: [02:14] [BuildBaseRecords] <Debug: Looking for rockl01_3DB38EABpassthru for Skywind.esm _LSC_AI_DryRockL01 [STAT:05007884]> Line 110415: [02:14] [BuildBaseRecords] <Debug: Looking for rockl01_3DB38EAB for Skywind.esm _LSC_AI_DryRockL01 [STAT:05007884]> Line 110416: [02:14] [BuildBaseRecords] <Debug: Looking for rockl01 for Skywind.esm _LSC_AI_DryRockL01 [STAT:05007884]> Line 110429: [02:14] [AddModel] <Debug: Meshes\morrowind\lod\landscape\rocks\rockl01_sw-moss_lod_0.nif RockL01:1 Shader Flags 1: Specular | Recieve_Shadows | Cast_Shadows | Own_Emit | Remappable_Textures | ZBuffer_Test Skywind.esm _LSC_AI_DryRockL01 [STAT:05007884]> Line 110430: [02:14] [AddModel] <Debug: Meshes\morrowind\lod\landscape\rocks\rockl01_sw-moss_lod_0.nif RockL01:1 Shader Flags 2: ZBuffer_Write | Vertex_Colors | EnvMap_Light_Fade Skywind.esm _LSC_AI_DryRockL01 [STAT:05007884]> but in the Object Report: _LSC_AI_DryRockL01 [STAT:05007884] Meshes\morrowind\landscape\rocks\rockl01.nif [CRC32:3DB38EAB] using textures\landscape\mountains\mountainslab02.dds, textures\landscape\mountains\mountainslab02_n.dds rockl01_lod_0.nif RockL01:1 = textures\landscape\mountains\mountainslab02.dds -> textures\morrowind\landscape\west coast\env3d_westcoast_rav_limestonetop_ai.dds Level0: meshes\lod\rocks\rockl01_lod_0.nif [CRC32:95177048] using textures\landscape\mountains\mountainslab02.dds, textures\landscape\mountains\mountainslab02_n.dds Mask: \ File: C:\DynDOLOD\Edit Scripts\DynDOLOD\Rules\DynDOLOD_SSE_Medium.ini LOD4: Level0 LOD8: None LOD16: None Full logs here: https://ufile.io/k5gxdda4
-
I have an object that uses a vanilla mesh (dungeons\dwemer\platforms\dweplatmid01.nif) with a Texture Set. DynDOLOD's LOD model uses a rendered LOD texture, which (unless I am missing something) does not automatically get retextured by running TexGen or during LOD Generation. What is the best way to make sure the LOD model has the correct texture? Do I need to create an alternate rendered object texture?
-
Turns out the problem was I had an ITM override on one of the MATO forms defined in the materials config file, which was preventing it from being picked up.
-
I am having some trouble getting the material names config file to work in the latest version. The check for lod models containing the "sw-moss" string only seems to be happening when the full model doesn't have a corresponding lod model supplied by vanilla skyrim or DynDOLOD. I tried reverting to the test version that worked before but had the same problem, which would seem to indicate that it's something on my end, but I can't figure out what is wrong. Here are my logs: https://ufile.io/ydz5b5n7 For example, 05101261 has the material shader applied but is not being checked for the "sw-moss" variant lod model.
-
Looks like that did the trick, thanks!
-
I believe I have it set up correctly, but it seems to be looking for files with part of the base object EDID in them as well: [00:40] [MaterialName] <Debug: Processing sw-moss 0.9.9.63_gamma.esp _LSC_Eb_DryRockTundraLand01Grass01 [STAT:05101261]> [00:40] [BuildBaseRecords] <Debug: Looking for rocktundraland01_LSC_Eb_DryGrass01_sw-moss for 0.9.9.63_gamma.esp _LSC_Eb_DryRockTundraLand01Grass01 [STAT:05101261]> [00:40] [BuildBaseRecords] <Debug: Looking for rocktundraland01_LSC_Eb_DryGrass01 for 0.9.9.63_gamma.esp _LSC_Eb_DryRockTundraLand01Grass01 [STAT:05101261]> [00:40] [BuildBaseRecords] <Debug: Looking for rocktundraland01 for 0.9.9.63_gamma.esp _LSC_Eb_DryRockTundraLand01Grass01 [STAT:05101261]> Full logs: https://ufile.io/2i16u7be I included the material names config file as well in case that helps.
-
That sounds perfect!
-
Would the name need to be specific to the individual shader? The vertex alpha makes it possible for the model to receive any LOD shader. And on a practical level, we have multiple full detail moss shaders which end up using the same LOD moss shader. Maybe something more generic like "rocktundraland01_lod_1_mato.nif" ?
-
Ah! I haven't even realized I set the vertex colors to all white. That explains that! Filename collisions are a concern I have wondered about. Generally I try to keep the filename and path as close as possible between the full model and LOD model. Is there any existing convention for when a single full model requires two different LOD models due to the directional shader?
-
Hi Sheson, I have an LOD model with vertex colors that are not being carried over into the generated LOD. I have included some log files as well as the LOD model itself and a quad of the generated LOD so you can see the result: https://ufile.io/n4yy7pab The base formID is 05101261, and an example ref is 050A0357. The corresponding shapes in the generated LOD file are blocks 158 and 164. Is there something I am missing or is this a bug?
-
Ahh I had forgotten that I needed to use empty lines to clear out the default settings. That did the trick. Thanks again!
-
Strange. I can't imagine why I would have deleted them myself.... Well, I'll let you know if it ever happens again.
-
Thanks! I was able to create the options file, and I could see in the LODGen export file that the mesh mask rules were added. However, the DynDOLOD output still does not assign objSnowHD where I want it. Running xLODGen on the same chunk does successfully give me the HD LOD shader there, so I'm sure the LOD4 model meets all the requirements. Is there still a conflict with the mesh mask settings somewhere? Here are the log files: https://ufile.io/jljd9gnz
