Only those listed on the Nexus page
![Smile :)](./images/smilies/icon_e_smile.gif)
Only those listed on the Nexus page
The screenshot keybind is F8Hazelnut wrote: ↑Mon Sep 14, 2020 4:14 pm Are you putting the code up anywhere? Need to start thinking about how to make it compatible with roads.
The toggle UI command - IIRC there's already a way to disable the HUD in DFU using shift-F10. I also thought there was a screenshot function as well, but I can't recall what it is so it may be a figment of my mind.
My next focus will be cleaning up the code a bit (in terms of clean coding, my delivery can be lacking at times, as I thrive in chaos for some reason) so that I can put it up on GitHub and not feel bad for those who read it
Ah, haha - looks like I've re-invented the wheel there! I just saw a post about this feature being planned, but I suppose it must have been quite an old post then.
All future releases are gonna be for 0.10.25+, regardless of what the stable version isNystul wrote: ↑Mon Sep 14, 2020 4:36 pm hi monobelisk,
once you drop a version for dfunity 0.10.25+ I will take a look why there are compability issues with distant terrain mod (with deactivated terrain sampler of distant terrain mod via settings option)
In principle it should work together then but maybe there is something in distant terrain mod that prevents it![]()
Thank you
yeah - furthermore when distant terrain mod's improved terrain sampler is active it also alters the build-in small heightmap buffer and uses the altered values.monobelisk wrote: ↑Tue Sep 15, 2020 7:01 am 1. If I understand the Distant Terrain code properly, it reads the heights from the woods file heightmap buffer, right? Interesting Terrains also reads from that buffer, then adds new heights on top of that. So modifying the buffer won't be possible, though Interesting Terrains could possibly be modified to expose an alternative buffer that could be used instead.
Code: Select all
int width = WoodsFile.mapWidthValue;
int height = WoodsFile.mapHeightValue;
byte[] heightMapBuffer = contentReader.WoodsFileReader.Buffer.Clone() as byte[];
...
// here heightmap buffer is changed
...
contentReader.WoodsFileReader.Buffer = heightMapBuffer;
definitely a true point but may not be that bad - e.g. if you stand on a hill you should see itmonobelisk wrote: ↑Tue Sep 15, 2020 7:01 am 2. Given the peaky nature of Interesting Terrains, I fear that the distant terrain may not be of a high enough resolution to convincingly render the far away terrain.
if a custom solution works better then why not?monobelisk wrote: ↑Tue Sep 15, 2020 7:01 am Those are the reasons why I'm initially leaning towards attempting a custom solution. But I could of course be wrong (on both counts), and if you think it could work then I'd definitely rather want that to happen!
Actually, I think in my case it might be better to just store a copy of the original height buffer and use that in my compute shader, but alter the original height buffer so it's accessible by distant terrain. Otherwise I'd find myself in a dilemma, as I'd need an altered height buffer to generate the terrain, but I'd need to generate the terrain to get the altered height buffer to begin with.Nystul wrote: ↑Tue Sep 15, 2020 8:42 am I think it should be possible to modify the buffer in your mod and use your modified values in distant terrain mod later - as long as mod order is set correctly and distant terrain mod's terrain sampler is deactivated (I need to test this though, maybe something is not working as intended)
...
another measure that could be taken from us would be not to just add heights to the base height but let the base height be the average height and let your terrain generation produce positive and negative biases for it (distant terrain's terrain sampler does this) - or maybe it would be enought to shift your heights down on the y-axis by the value of maxHeight/2
I did have quite an elaborate idea of how I could pull it off without the CPU being involved at all; basically just have a static lo-res plane mesh, then pass the height values generated by the compute shader directly into the mesh material through a render texture and have the mesh material shader do distance based tessellation (that would basically be the LOD system) and then use the generated height values to displace the mesh.
you are rightmonobelisk wrote: ↑Tue Sep 15, 2020 3:01 pm Actually, I think in my case it might be better to just store a copy of the original height buffer and use that in my compute shader, but alter the original height buffer so it's accessible by distant terrain. Otherwise I'd find myself in a dilemma, as I'd need an altered height buffer to generate the terrain, but I'd need to generate the terrain to get the altered height buffer to begin with.
wow, if you can pull this off, it would be superior to what distant terrain does and much more performant as well.monobelisk wrote: ↑Tue Sep 15, 2020 3:01 pm I did have quite an elaborate idea of how I could pull it off without the CPU being involved at all; basically just have a static lo-res plane mesh, then pass the height values generated by the compute shader directly into the mesh material through a render texture and have the mesh material shader do distance based tessellation (that would basically be the LOD system) and then use the generated height values to displace the mesh.
Well, it would result in even another terrain shader that has to be maintained and kept compatible with other terrain shader mods. And a custom shader would probably be needed for the main terrain as well, in order to ensure a smooth transition. I'll give Distant Terrain a go first, and hope for the best
Thanks