Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Editor: Transient land shape editing #2520
New version of #2167 to make reviewing easier. The previous PR had terrain selection changes included in the changelog.
Terrain editing feature limits the edits to the range of ESM file format. This PR now also implements a feature that highlights the broken land heights as red whenever the edit is about to go out of range.
Planning/feedback needed for:
https://youtu.be/B1FCAOFqy-M (new video, demonstrating the features of the editmode. Note that after this video was made, if slope steepness limiting fails, it won't be applied to data any more.)
Work for other PR's
For the editor side, I think this is ready for review and testing. Feature is fully functional, and I've tested the crap out of it on Linux.
Cons: Real-time terrain limiting is not yet implemented, and it's debatable whether using forced red in vertex colors is good for signaling slopes that are too steep. These can be further developed before or after merging. There are also some terrain selection related things one could work on, but I'm trying not to touch terrain selection in this PR (any more than I already did...)
For the changes made to components/esmterrain/storage.cpp and components/esmterrain/storage.hpp, someone familiar with them should probably have a glance.
Sorry for extra CI- and appveyor builds.
Great job @unelsson! I played around with this for several minutes. Didn't get any crashes, tools seem to do what I would expect them to. Glad that we have both height drag and paint! One suggestion would be to have a hotkey switch between up and down when painting so you don't have to switch through the menu.
Only two real problems that I noticed, one major, one minor. Major one is that if you leave the terrain edit tool and then come back to it, the UI switches to the default settings, but the tool remembers what you set it to previously. Basically if you were editing with circle at 10 radius with height paint, then switch to instance editing mode by clicking on that icon, then switch back to terrain editing, the UI resets to point with 1 radius and height drag, but will actually edit with the circle at 10 radius and paint. Each of these will only be reflected by the UI once they've been changed.
The minor problem I noticed is that when changing height (at least with the drag tool) I expect the terrain to still be very smooth, just stretched up. Instead, some of the vertices don't seem to travel in a smooth arc upward and some of it turns out rather jagged, forcing me to use the smooth tool, which also changes the height somewhat. Not ideal if I'm trying to make precise adjustments. The left click feature where it highlights the vertices allows you to see this if you click before and then again after the edit. Certainly not the worst thing, but figured it was worth pointing out.
The left click to highlight radius and vertices is a pretty cool feature. Wondering what the intended use for it is though? Just to check how your edit compares to the previous morphology? Same with the green highlighting at cell edges. That's especially nice to know you've messed with another cell.
Only other suggestions would be to show the tool outline at all times, or maybe only if you hold down a certain hotkey. Although come to think of it, I'd rather have it shown at all times with a hotkey to turn it off. Might be helpful to have a second radius shown to indicate strength, but not sure how useful that would really be.
So awesome to have someone working on major editor features! Let me know if I need to clarify or post pics/videos etc.
Thanks for testing @rhtucker !
Did you test this in Windows btw? It's really nice to have this just ran through different platforms before merging.
Circle tool was using int for distance calculation, which resulted in rough terrain. I now changed this to float to have smoother shapes.
Also removed the deactivation code in order to hold tool options in memory while changing modes. Alternative would be to also delete all tool options from memory, but I suppose it's better to keep these in memory.
Hotkey between modes is a good idea, but I'm cutting that out of this PR. This is a big feature already, so I'm trying not to change the code of the keyboard settings / controls right now. It's better not to touch too many places all at once, and surely hotkeys can be implemented later.
This is the terrain vertex selection. The basis for it was already implemented in already-merged terrain selection PR, but this PR kind of enables it. Currently it's just the very basics of this feature. Just being able to draw the vertex lines highlighted can be useful at times. This feature can be improved in many ways, and uses for it implemented later. You might e.g. use it for defining custom tool shapes, similar as texture editing. Copy-pasting terrain height might also be possible, but not in the scope of this PR.
Definitely! I've been thinking of drawing a circle around the editing area for all edit modes, but currently the way for drawing the selection has optimization problems, so implementing this takes a bit of thought. So, out of the scope of this PR.
Which os? The latest version? I've tested builds after almost all commits and havent had the same, but maybe something changed during latest code changes.
edit: I tested this again with the latest, but can't reproduce the shifting of the cursor. How would you reproduce this?
edit2: The coordinates for editing are set in
Thanks, great find! I'm not sure exactly which point the glitch happens though, and I have zero knowledge of QT's environment variables. Google search gives some ideas that it might be possible to change it with qputenv https://doc.qt.io/qt-5/qtglobal.html#qputenv . I can't think of better right now than to check if it's 1, and if so, force it to something which works.