z929669 Posted April 23, 2021 Posted April 23, 2021 I would look for those files in those mods and see why they are not loaded. Seems like you either have a mod(s) disabled or do not have a required mod installed that is expected by another mod. Just as likely, the mod files referenced by the plugins are not in the mod(s) ... i.e., poor housekeeping by mod author. As long as DynDOLOD finishes successfully, it may not matter at all (if they are just junk refs in the plugin(s)). sheson may have other advice, but you can check the problem mods in the meantime and look at those mods bug reports on Nexus.
sheson Posted April 23, 2021 Author Posted April 23, 2021 1 hour ago, patriklannebrink said: Having some issues using Dyndolod 3 for SSE (texgen works fine) where it says (Atleast this is how i interpret it) I'm missing files from some mods? Jedi Trees instructions said to use Texgen to generate billboards so I'm not sure what the issue is. https://pastebin.com/J8DCjReg Is this an issue or something I can ignore, because it seems like some trees do infact not have billboards (And I'm pretty sure its the Jedi Trees ones) Upload entire log files not just parts of it. Use search to find posts that might already answer questions. For example this post: "Errors typically need to be fixed. They prevent LOD generation for the mentioned stuff or in general. Warnings typically should be fixed if possible, because of good practice or because they prevent the desired outcome." Based on the posted log lines there is no issue using DynDOLOD. It seems to work as intended and reports problems in the load order. Missing meshes can cause CTD or red exclamation marks in the game. DynDOLOD reports them and then will ignore the base records and any references using them. So in case it is an object that could have had LOD, it won't. Normal textures should end in *_n.dds. This check helps to find typos or accidentally setting the diffuse as normal texture. It is highly beneficial and best practice for example for better compatibility with other mods/tools to adhere to Bethesda file naming conventions.
z929669 Posted April 23, 2021 Posted April 23, 2021 @sheson You may find this interesting. Not sure how much performance testing you have done in the past. The following is pure apples-apples compare on my system after painstakingly preparing LOD tree statics from Myrkvior. This mod has 150 trees, and many are custom in addition to full vanilla replacement. I think it makes for one of the best candidates for performance compares, particularly with respect to full vs hybrid trees. I find hybrids to be twice as tedious to create as full, and with DynDOLOD 2.xx, it was 3x more tedious, IMHO. This analysis compares full to hybrid Myrkvior with all else remaining equal. Tested on clean runs of LODGen (same terrain and occlusion, different DynDOLOD). The avg FPS is a bit low, since I am running ENB and also compared only statics (all trees for LOD4/8/16 used Level0/1/2, respectively). I also used the recommended TexGen/DDL "max size" = 256 for all textures. Each run involved me flying around 'slowly' across all regions of Tamriel using same route. Each run is 10-20 min long: FULL HYBRID My system specs are linked in my sig. Given that this is a fairly meticulous compare (all variables carefully throttled besides tree type and non-specific random factors), I am fairly confident that the same relative differences would be apparent on just about any modern PC, but there could be hardware factors that could deferentially impact performance of essentially # of NIF polygons rendered (my assumption about the brass-tax diff between full and hybrid models). This is good news, because I can create full hybrids much faster and with fewer opportunities for error. Your thoughts?
sheson Posted April 23, 2021 Author Posted April 23, 2021 1 hour ago, z929669 said: @sheson You may find this interesting. Not sure how much performance testing you have done in the past. The following is pure apples-apples compare on my system after painstakingly preparing LOD tree statics from Myrkvior. This mod has 150 trees, and many are custom in addition to full vanilla replacement. I think it makes for one of the best candidates for performance compares, particularly with respect to full vs hybrid trees. I find hybrids to be twice as tedious to create as full, and with DynDOLOD 2.xx, it was 3x more tedious, IMHO. This analysis compares full to hybrid Myrkvior with all else remaining equal. Tested on clean runs of LODGen (same terrain and occlusion, different DynDOLOD). The avg FPS is a bit low, since I am running ENB and also compared only statics (all trees for LOD4/8/16 used Level0/1/2, respectively). I also used the recommended TexGen/DDL "max size" = 256 for all textures. Each run involved me flying around 'slowly' across all regions of Tamriel using same route. Each run is 10-20 min long: FULL HYBRID My system specs are linked in my sig. Given that this is a fairly meticulous compare (all variables carefully throttled besides tree type and non-specific random factors), I am fairly confident that the same relative differences would be apparent on just about any modern PC, but there could be hardware factors that could deferentially impact performance of essentially # of NIF polygons rendered (my assumption about the brass-tax diff between full and hybrid models). This is good news, because I can create full hybrids much faster and with fewer opportunities for error. Your thoughts? The load order seems to have issues if the FPS is under 60. Use a pure and defined vanilla setup to test things, with nothing else that limits or hinders performance. With vsync disabled, obviously. The graphs do not not show GPU % usage. Obviously it is silly to use full models for all tree LOD models, especially now that creating hybrids became as simple as just saving the full model twice into trunk and crown. Every triangle saved means smaller files size, less resource usage, less memory usage, less draw calls that can be used for something else. For the few 3D tree LOD models that reveal so much (twisted) trunk and branches that they actually need 3D trunks and for Grass LOD for example. And the 8k skin and mandatory body physics...
z929669 Posted April 23, 2021 Posted April 23, 2021 Your logic makes perfect sense, particularly with respect to file size. But it is still much more work to create hybrids, IMO., Especially since *most* trunks us relatively few triangles anyway. I suppose 16 triangles is better than 50 though ... Above load order doesn't have issues. It's just modded and running ENB. I wanted to test under a (my) fully modded setup. I do see value in testing with nothing but vanilla hybrid/full trees and no mods but the minimal 'fix' and unofficial patches. Obviously no post-processing in that case.
Phlunder Posted April 27, 2021 Posted April 27, 2021 (edited) Just now got around to testing 3.0 alpha, great work! The addition of the TexGen renderer is incredible, saves so much work when using custom textures. For object LOD, this looked great so far in my testing. Tree LOD billboard creation also works flawlessly, I just ran into a small thing while playing around with it. The atlas is saved with mip-maps, which has some downsides in how those distant objects with these kind of alphas display. Especially the aspens look very "blurred" for lack of a better word, they loose a lot of detail. Resaving the atlas without mip maps fixes that. The testing was done on vanilla trees with vanilla textures. Would it be possible to add an option to save the tree LOD atlas without mip maps directly? Maybe its also an issue with alpha testing/threshold values, not sure. Edited April 27, 2021 by Phlunder
sheson Posted April 27, 2021 Author Posted April 27, 2021 2 hours ago, Phlunder said: Just now got around to testing 3.0 alpha, great work! The addition of the TexGen renderer is incredible, saves so much work when using custom textures. For object LOD, this looked great so far in my testing. Tree LOD billboard creation also works flawlessly, I just ran into a small thing while playing around with it. The atlas is saved with mip-maps, which has some downsides in how those distant objects with these kind of alphas display. Especially the aspens look very "blurred" for lack of a better word, they loose a lot of detail. Resaving the atlas without mip maps fixes that. The testing was done on vanilla trees with vanilla textures. Would it be possible to add an option to save the tree LOD atlas without mip maps directly? Maybe its also an issue with alpha testing/threshold values, not sure. TreeLODGenerateMipMaps=0 in the DynDOLOD INI 1
z929669 Posted April 27, 2021 Posted April 27, 2021 Just noticed a small UI-tooltip inconsistency: I think this should be same as:
z929669 Posted April 27, 2021 Posted April 27, 2021 Question: I know that 3D trees require modified static based upon the full model with matching CRC in the file name of the static, so any changes to the base model will 'break' pairing with the 3D static. The same is not true for billboards created by TexGen though, correct? Those match on the plugin formID, right? So if I have a mod with a custom tree with matching 3D static (obviously referenced by the mod's plugin) and I alter the base model for that tree without updating the corresponding static, DynDOLOD won't generate the corresponding 3D tree. However, TexGen 3 will still generate Billboard1/2 for the base model, and DynDOLOD will use those ... ?
sheson Posted April 27, 2021 Author Posted April 27, 2021 59 minutes ago, z929669 said: Question: I know that 3D trees require modified static based upon the full model with matching CRC in the file name of the static, so any changes to the base model will 'break' pairing with the 3D static. The same is not true for billboards created by TexGen though, correct? Those match on the plugin formID, right? So if I have a mod with a custom tree with matching 3D static (obviously referenced by the mod's plugin) and I alter the base model for that tree without updating the corresponding static, DynDOLOD won't generate the corresponding 3D tree. However, TexGen 3 will still generate Billboard1/2 for the base model, and DynDOLOD will use those ... ? TexGen generates billboards for "trees" for the current load order. See ..\DynDOLOD\docs\help\TexGen.html which explains what the criteria for a "tree" is in order for a billboard to be automatically created. Of course it creates billboards with the correct path and filename convention that is expected by xLODGen/DynDOLOD tree LOD generation, which has not changed since its inception. If users follow the instructions and run TexGen before DynDOLOD and install its output overwriting everything we can be reasonable sure the billboards are the correct ones for the tree at that time using the old system. In addition, DynDOLOD checks the full model and textures have the same CRC32 as they did when TexGen generated the billboards and prints warning messages in case they don't match anymore because the load order changed after generating the TexGen output. 1
z929669 Posted April 27, 2021 Posted April 27, 2021 I have been getting this error about half the time I run DynDOLOD lately. No additional info though so hoping you have a clue. A couple of other users have reported this error and no further error info in the logs indicated: [43:59] <Error: LODGenx64.exe failed to generate object LOD for Tamriel. LODGenx64.exe returned E0434352. Check C:\Modding\Tools\DynDOLOD-3.00\Logs\LODGen_SSE_Tamriel_log.txt> Logs.7z EDIT: Seems to happen mostly(only?) when including grass LODGen ... so longer or more intensive DynDLOLOD runs seem to produce this.
sheson Posted April 27, 2021 Author Posted April 27, 2021 1 hour ago, z929669 said: I have been getting this error about half the time I run DynDOLOD lately. No additional info though so hoping you have a clue. A couple of other users have reported this error and no further error info in the logs indicated: [43:59] <Error: LODGenx64.exe failed to generate object LOD for Tamriel. LODGenx64.exe returned E0434352. Check C:\Modding\Tools\DynDOLOD-3.00\Logs\LODGen_SSE_Tamriel_log.txt> Logs.7z 3.32 MB · 0 downloads EDIT: Seems to happen mostly(only?) when including grass LODGen ... so longer or more intensive DynDLOLOD runs seem to produce this. Start DynDOLOD in expert mode and execute LODGen for Tamriel. Bring the LODGen command prompt to the front to see if it prints more details to the console. If that does not give more detail , check the Windows event viewer for additional messages from the .NET Runtime
z929669 Posted April 27, 2021 Posted April 27, 2021 36 minutes ago, sheson said: Start DynDOLOD in expert mode and execute LODGen for Tamriel. Bring the LODGen command prompt to the front to see if it prints more details to the console. If that does not give more detail , check the Windows event viewer for additional messages from the .NET Runtime From the Event Viewer: Spoiler Log Name: Application Source: .NET Runtime Date: 4/27/2021 2:06:46 PM Event ID: 1026 Task Category: None Level: Error Keywords: Classic User: N/A Description: Application: LODGenx64.exe Framework Version: v4.0.30319 Description: The process was terminated due to an unhandled exception. Exception Info: System.ArgumentOutOfRangeException at System.ThrowHelper.ThrowArgumentOutOfRangeException(System.ExceptionArgument, System.ExceptionResource) at System.Collections.Generic.List`1[[LODGenerator.GIDFile+GrassPlacement, LODGenx64, Version=3.0.0.0, Culture=neutral, PublicKeyToken=null]].RemoveAt(Int32) at LODGenerator.GIDFile.ToStatics(System.String, Boolean, Single, LODGenerator.LogFile, Boolean) at LODGenerator.LODApp.DoLOD(LODGenerator.QuadDesc, Boolean) at LODGenerator.LODApp+<>c__DisplayClass82_1.<GenerateLOD>b__0() at System.Threading.Tasks.Task.Execute() Exception Info: System.AggregateException at System.Threading.Tasks.Task.WaitAll(System.Threading.Tasks.Task[], Int32, System.Threading.CancellationToken) at LODGenerator.LODApp.GenerateLOD(System.Collections.Generic.List`1<LODGenerator.StaticDesc>) at LODGeneratorCMD.Program.Main(System.String[]) -------------- Spoiler Log Name: Application Source: Application Error Date: 4/27/2021 2:06:47 PM Event ID: 1000 Task Category: (100) Level: Error Keywords: Classic User: N/A Description: Faulting application name: LODGenx64.exe, version: 3.0.0.0, time stamp: 0x6054b603 Faulting module name: KERNELBASE.dll, version: 10.0.19041.906, time stamp: 0x2f2f77bf Exception code: 0xe0434352 Fault offset: 0x0000000000034b59 Faulting process id: 0x22db8 Faulting application start time: 0x01d73b9443749cb3 Faulting application path: C:\Modding\Tools\DynDOLOD-3.00\Edit Scripts\LODGenx64.exe Faulting module path: C:\Windows\System32\KERNELBASE.dll Report Id: 1850ccb8-ad54-437a-8fbe-d0e2d792da4c Faulting package full name: Faulting package-relative application ID:
sheson Posted April 28, 2021 Author Posted April 28, 2021 8 hours ago, z929669 said: From the Event Viewer: Is that reproducible when executing LODGen in expert mode? If it happens to run through on second try, its fine for now
z929669 Posted April 28, 2021 Posted April 28, 2021 7 hours ago, sheson said: Is that reproducible when executing LODGen in expert mode? If it happens to run through on second try, its fine for now It occurs about half the time in expert mode with increasing chances for longer runs (generating dynamic LOD, ultra). Same two errors repeated in tandem several times over the past few days, so reproducible. Never any error output to terminal that I can see. LODGenx64.exe just quits and xEdit window remains open with error message.
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now