New v0.3 restructure

[chirpxiv]

v0.3 Restructure

Full rewrite and restructuring of Ktisis which implements a framework for scene editing and object manipulation.

As mentioned previously, the main branch is not accepting PRs until this is complete.

This does not currently have full feature parity with the v0.3 branch it's replacing - it will be open as a draft until it is done. A rebase may be required for this to merge cleanly.

Remaining work for ongoing service refactor:

• [x] Posing
• [x] Chara models
• [x] Weapons (+ other child objects)

Remaining ports for feature parity with v0.3-rework:

These are mostly already complete as prototyped code; they just need to fit into the restructured codebase.

• [x] Selection overlay
• [x] Transform/edit window
• [x] Localization
• [x] History
• [x] Input/hotkey handler
• [x] Configuration manager

To consider:

Dalamud provides its own Localization service for plugins to make use of. Do we want to switch over to making use of this, or continue using our own bespoke library for it? The latter, I believe, may be better suited to how we store and implement string translations, but I am admittedly unfamiliar with how the other works.

[Fayti1703]

Dalamud provides its own Localization service for plugins to make use of. Do we want to switch over to making use of this, or continue using our own bespoke library for it?

It's worth noting here that Dalamud's Localization doesn't appear to support parameters in the localization strings, which we already have an implementation for. Similarly, the API contract doesn't allow locale-specific quantity rules, which is something I've been planning to implement -- though I'm not sure which strategy to use yet.

A rebase may be required for this to merge cleanly.

I would personally recommend replacing the branch with the new history, possibly archiving the old one elsewhere; though for merging with main we should still rebase the new history onto there.
But we should probably worry about that once we have a mergable state.

[chirpxiv]

Marking Selection overlay as completed per 0c267eb.

[chirpxiv]

Marking the following as completed:

• Weapons per 53cb728
• Posing per e76b321, 057abbe and 83a4b61

PoseEditor has been reworked into a static class which I have not pushed yet.

Will be implementing separate editing modes for objects and skeletons to simplify things both visually and programmatically. I may remove the IManipulable interface from Bone in favour of a higher-level class that specifically handles it (likely relating to the aforementioned modes); would save us from having to read the same shit hundreds of times.

[chirpxiv]

Will be implementing separate editing modes for objects and skeletons to simplify things both visually and programmatically.

Done implementing this with ObjectMode and PoseMode - both inherit from ModeHandler, and are responsible for 1) retrieving the current active transform of the selected objects, and 2) manipulating the transforms of those objects.

UI code should interface directly with these and avoid carrying out transformations themselves. GuiOverlay implements a RendererBase class responsible for taking info from those respective handlers and drawing it on screen. This should make it easier to implement transforms in cases where the gizmo isn't being used.

With the logic for posing mostly in place, and I must say I'm extremely happy with it, I believe that's most of the hardest parts done! Looking forward to where this goes from here.

[chirpxiv]

Done implementing this with ObjectMode and PoseMode - both inherit from ModeHandler, and are responsible for 1) retrieving the current active transform of the selected objects, and 2) manipulating the transforms of those objects.

Something really interesting here - I put these in place to avoid complicating things by trying to mix transforms for objects and bones in tandem, but the end result actually made it extremely easy to do that if we wanted to. So I'll restructure things a bit to support this, particularly by finding a way to move the logic for GetTransformTarget higher up into SceneEditor somehow.

[chirpxiv]

With GetTransformTarget being mentioned I'd also like to note down that I want to look into changing this a bit for bones - I think it would be a good idea to find the common parent of each selection and treat that as the transform origin. It would probably be a bit more convenient.

[chirpxiv]

Marking transform editor as completed per f635366.

[chirpxiv]

@Fayti1703 I'm going to look at bringing i18n in soon, is there any particular branch you'd like me to pull it in from?

feature/extend-i18n, for example.

[Fayti1703]

feature/extend-i18n is the most recent one, so that'd be a good place to merge/cherry-pick over from.

You'll likely need to redo approximately the entire data file; plus I meant to make it use Assembly->GetManifestResourceStream(Type, string) instead of the (string) overload but couldn't because of folder name/namespacing issues.

[chirpxiv]

Marking configuration manager as completed per 5b62dea...eba02cd, pending UI for editing config.

[chirpxiv]

Did some more cleanup of the main workspace window, I believe this will be the final layout. Included toggle buttons for editing windows, Transform Editor is currently the only implemented one, Camera Editor and Environment Editor are stubs. The Other button will open a submenu for settings as well as the aforementioned toggles. TransformWindow will now draw in a disabled state if no valid selection is active, and the logic for opening it has been delegated to PluginGui.

SceneTree has also been rewritten to instead implement TreeNode functionality into Selectables due to problematic behaviour with ImGui; the previous nodes could not be used as DragDropSources due to the overlapping content. The drawing of context buttons is now much cleaner as well, though I need to improve click detection on the caret icons, and reimplement dimming for items the current editing mode isn't applicable to.

Having support for DragDropSource/DragDropTarget now means that I can implement: 1) Reorganising items within the tree. 2) Attachments.

[chirpxiv]

Marking localization as completed per 44e2df2, 03cba43...0ac6ed6.

[chirpxiv]

Marking input/hotkeys as completed per ecd66fc...15bdd1e

[chirpxiv]

Implemented HistoryService on my local branch, will do some cleanup then push. Chara models shouldn't take long after that.

Should be ready to merge once that's done, although I'll probably try to get actor editing/spawning in beforehand.

[chirpxiv]

Adding onto the previous comment to note that I'll be doing another small refactor of object transforms as well - primarily to take a snapshot of an object's transform on selection, which then gets passed to the gizmo. This serves two purposes:

• Small changes when moving objects won't fling it into the stratosphere.
• Allows bone groups to render as the mean of each transform within it, rather than that of any individual bone.

[chirpxiv]

Will revisit this draft when Dalamud stabilizes again - API 9 work currently takes priority.

[Fayti1703]

Are we planning to have this done before API 10? Asking because of a change to the Logger abstraction that will be necessary before 10 drops.

[chirpxiv]

I believe we have until January/February for API 10 so no rush on that, but would be good to get it done anyway.

[chirpxiv]

Marking this as ready to merge.

[chirpxiv]

Noting down that this pose file implementation will use local space to store transforms, as opposed to model space.

This makes it easier to apply standalone parts of a pose, but will require a version bump and conversion handling.

[chirpxiv]

Noting down that this pose file implementation will use local space to store transforms, as opposed to model space.

This makes it easier to apply standalone parts of a pose, but will require a version bump and conversion handling.

Rolling this back in favour of calculating the rotation delta of root bones in partial skeletons.

[chirpxiv]

Environment editing strings are not final and should not be localized until after testing. Pushing it either tonight or tomorrow morning after cleaning up the UI.

[chirpxiv]

AppearanceModule hooks will conflict with Penumbra and Glamourer depending on load order, might need to communicate with Otter about implementing an IPC to handle that

[chirpxiv]

Also not personally a fan of this solution, but trying to write to the customize array on creation will just result in Penumbra not loading collections, and Glamourer not applying designs. I'll continue to play around with it.

[chirpxiv]

How close is this to being rebased? @Fayti1703

[chirpxiv]

Doing some minor cleanup, moving everything from SceneCreateMenu into their respective IEntityBuilder implementations.

[Fayti1703]

Manually landed on the v0.3/main branch with 6ad454fdfeaa010e198ff419a416c37a4046206a.