Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Broken Camera #36

Open
kdru opened this issue Aug 17, 2020 · 3 comments
Open

Broken Camera #36

kdru opened this issue Aug 17, 2020 · 3 comments

Comments

@kdru
Copy link

kdru commented Aug 17, 2020

I've downloaded new version of miritore and tried to export camera for alliance stardust, it was completely broken
5
camera with new tool
2
camera with old one

@hozuki
Copy link
Member

hozuki commented Aug 17, 2020

Looks like 67ab036 broke the camera function (d038fb9 works, 0.3.0.71). I'll fix this asap.

@kdru
Copy link
Author

kdru commented Aug 17, 2020

But meanwhile, Fermata in Rapsodia camera works fine o: better than in old version

@hozuki
Copy link
Member

hozuki commented Aug 22, 2020

I finally found the cause. The bug was introduced in 145c092 (not 67ab036).

Starting from this commit, the new motion asset searching flow is:

  1. Test asset name.
    • Is this motion for default (no appeal), special appeal, another appeal, or gorgeous appeal? If so, add it to the result collection.
  2. Are all 4 motions found? If so, return early.
  3. Are there any more motions? If so, go to step 1; otherwise return.

In contrast with the new flow, the previous flow only searches for 3 appeals (no gorgeous appeal). For now, most of the motion bundles do not have a gorgeous appeal; only the 39-person version of Thank You! has it. So most of the time, all of the motions in a motion bundle will be read.

So, how to determine the appeal that the motion belongs to? By looking at its ending. For example, if it ends with _cam, it should be the one for default.

Unfortunately, some MVs use more than one camera. アライアンス・スターダスト (Alliance Stardust) is one of them. It has two default camera files: cam_alstar_01_cam and cam_alstar_02_cam (so that there are several split screens in the MV). Using the old flow, cam_alstar_02_cam will never be read because all appeal motions will be found before it. However, with the new flow, both of them will be read (since they both end in _cam). And guess which one is returned? cam_alstar_02_cam because it appears after cam_alstar_01_cam and the former gets replaced! Therefore, in the end, the camera animation exported is the one for secondary camera, not the main camera.

How to solve this problem? My solution will be adding a "camera number" dropdown so you can select one if it exists.

But, since I'll be occupied in the next two or three weeks, I can't make commits of major changes in this period. Please use build number 0.3.0.71 as a temporary solution, if camera or dance animations go wrong like this. That version does not support appeals but the camera logic is okay (i.e. always exporting the default animation). This problem will be fixed eventually.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants