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

When rendering with option --save_section the rendered file names are appended with 0001, 0002, 0003 instead of the "name" attribute. #3471

Closed
ubaldot opened this issue Nov 23, 2023 · 11 comments · Fixed by #3499
Labels
new feature Enhancement specifically adding a new feature (feature request should be used for issues instead)

Comments

@ubaldot
Copy link

ubaldot commented Nov 23, 2023

I am not sure if this shall be categorized as a bug, so let me know if I have to move it elsewhere.

As per title, when rendering with option --save_section the rendered file names are appended with 0001, 0002, 0003 instead of the "name" attribute.

for example, say that iI have something like the following:

class MyScene(Scene)
    def construct(self):
          self.next_section("MyFirstSection")
          # some code
          self.next_section("Section_Two")
          # some other code

and then I render with --save-sections option‚ then the rendered files have names:

MyScene_0001.mp4
MyScene_0002.mp4

whereas it would be nicer if they inherit the section name, e.g.

MyScene_MyFirstSection.mp4
MyScene_Section_Two.mp4
@behackl
Copy link
Member

behackl commented Nov 23, 2023

Not sure I agree. The name could perhaps appear somewhere in the filename, but replacing the numbering completely leads to unsorted files in the file explorer.

@ubaldot
Copy link
Author

ubaldot commented Nov 23, 2023

The name could perhaps appear somewhere in the filename

That could be an idea!
But I am wondering, why it would be a problem to have unsorted files?
At the end, even when you have a file with multiple scenes you would have them unsorted.
For example:

class Foo(Scene):
    def construct(self):

class Bar(Scene):
    def construct(self):   

class FooBar(Scene):
    def construct(self):  

when you render all of them you would have them unsorted, no? :)

@MrDiver
Copy link
Collaborator

MrDiver commented Nov 30, 2023

Because if you read them back from disk it becomes a problem of sorting the files by name

@ubaldot
Copy link
Author

ubaldot commented Dec 1, 2023

Because if you read them back from disk it becomes a problem of sorting the files by name

This sounds more like a developer issue than a user issue.

@doaamuham
Copy link
Contributor

I would like to take on this issue

@MrDiver
Copy link
Collaborator

MrDiver commented Dec 9, 2023

This sounds more like a developer issue than a user issue.

It is still a user issue because if you drag the section files (with no numbering) into a video editor then they will appear sorted by name, because lexically sorting files is a standard in many software projects.

So by removing the numbers, you force the user to add the files one by one and sort them manually in a video editor, which is way more work than it needs to be.

Summary: It is indeed a user problem, that's why we have the numbers!

@ubaldot
Copy link
Author

ubaldot commented Dec 9, 2023

True that they are sorted by name in video software but this is in-fact very desirable.

I can make an example. Say that you are making a video to explain complex numbers. To re-use good chunk of the code you decide to use sections into a ComplexNumber Scene class. You start developing your scenes and name the sections as:

"cartesian_representation"
"polar_representation"
"conversions"

Then, at some point, you think it is a good idea and you add another section

"definition_of_i"

Then, after a while, you think that is good to write a section where you show some identities and an introduction, but at the same time you don't want to refactor the previous part because it may easily become a nightmare and also the previous section are good to go as they are. Furthermore, you don't want to create another class because you can easily re-use what has been done in the previous sections. This is not an unusual scenario I can promise you. You add a couple of sections:

"introduction"
"identities"

At the end, when you render you would have the files names as:

ComplexNumbers_cartesian_representation.mov
ComplexNumbers_polar_representation.mov
ComplexNumbers_conversions.mov
ComplexNumbers_definition_of_i.mov
ComplexNumbers_introduction.mov
ComplexNumbers_identities.mov

When I import these files into my video editor I will have exactly the same names. In my opinion this is very handy and clear and the post-production work would go like a breeze.
On the contrary, as it is now, I would have the file names named as:

ComplexNumbers_001.mov
ComplexNumbers_002.mov
ComplexNumbers_003.mov
ComplexNumbers_004.mov
ComplexNumbers_005.mov
ComplexNumbers_006.mov

which does not have the same clarity. I should remember who is who, or I have to inspect them one-by-one to find the clip I need.

Hence, I wouldn't say that the current implementation is to solve a user problem. When working in post-production is way better having the names of the clips rather than just having numbers. Adding both names and numbers could be somewhat confusing - but still way better than having just numbers and still acceptable:

ComplexNumbers_cartesian_representation_001.mov
ComplexNumbers_polar_representation_002.mov
ComplexNumbers_conversions_003.mov
ComplexNumbers_definition_of_i_004.mov
ComplexNumbers_introduction_005.mov
ComplexNumbers_identities_006.mov

To be the devil's advocate, one here could wonder: what shall be the first clip to add in the storyline? ComplexNumbers_introduction_005.mov or ComplexNumbers_cartesian_representation_001.mov? One could just ignore the appended numbers, but then why adding them in first place?

@behackl
Copy link
Member

behackl commented Dec 9, 2023

We could just do both, SceneName_num_SectionName, as @chopan050 has already suggested on the corresponding PR linked above.

As section names do not need to be valid identifiers, users will have to avoid naming their sections in a way that results in illegal characters in file names.

@ubaldot
Copy link
Author

ubaldot commented Dec 9, 2023

As section names do not need to be valid identifiers, users will have to avoid naming their sections in a way that results in illegal characters in file names.

…or do something like this perhaps?

@chopan050
Copy link
Contributor

chopan050 commented Dec 9, 2023

There are misunderstandings in mainly 2 topics, which must be clarified for this discussion to advance:

  1. The differences between a scene and a section, and when to use each one (leading to a false equivalence).
  2. Which ideas are really being argued against / in favor of, and which are not (leading to a straw man fallacy).

1. The differences between a scene and a section

why it would be a problem to have unsorted files?
At the end, even when you have a file with multiple scenes you would have them unsorted.

Apples and oranges:

  • Scenes don't have a logical/temporal order ingrained into them:
    • they aren't usually connected to each other, in the sense of: they don't depend on each other to render. You can change their order in your file, and nothing breaks.
    • Therefore, they stand on their own. That doesn't mean they must represent a whole project, like ComplexNumbers: something smaller, a subtopic like DefinitionOfI, where only the specific succession of events/animations/objects necessary to explain the number i, is needed.
  • Sections, by definition, are chronologically ordered.
    • They're based on saved states or "snapshots" at specific times during your scene.
    • Usually, what happens in a section depends on what happened in the previous section(s). If my section N° 2 only contains self.play(Rotate(square)), that only really makes sense if I previously added that square in section N° 1, maybe via self.play(FadeIn(square)).
    • Mess with the order, and you'll likely mess up your scene.
    • If a section does not depend on any of the previous sections of your scene... that's a signal for you to consider creating a new scene for it, because maybe you're unnecessarily packing your whole complex project inside a same scene.

In short:

  • Sections inside a scene are meant to represent a sequence of interdependent events. Sections depend on each other. They aren't really able to represent a "topic" on their own, they're inherently numbered fragments which need to be assembled in a specific order into something coherent.
  • Scenes are more meant to be standalone products which describe a certain topic or subtopic. They can, but don't need to, be part of a bigger project.

Therefore, they can't be really compared in this sense (false equivalence). While it is OK to have unsorted scenes (because they can function as standalone projects), we cannot really say the same about sections in the same scene.

For the layout you described:

ComplexNumbers_cartesian_representation.mov
ComplexNumbers_polar_representation.mov
ComplexNumbers_conversions.mov

those sections could've been their own scenes instead, defined in a complex_numbers.py file:

# complex_number.py
class CartesianRepresentation(Scene):
    # ...
class PolarRepresentation(Scene):
    # ...

leading to a layout like this instead:

CartesianRepresentation.mov
PolarRepresentation.mov
Conversions.mov

Because, otherwise, making a huge scene called ComplexNumbers (an enormous topic) with sections named cartesian_representation, polar_representation, etc, also huge topics by themselves which would very easily span multiple minutes, is highly impractical and unwieldly.

For reusing code between scenes, it's better to define custom classes or functions for the things we need to reuse: new Mobjects which consist of the same elements, or functions which perform the same sequence of actions. In that last case, maybe even subclassing Scene, defining a custom method, and make other scenes subclass it.

As for sections, some options for the PolarRepresentation scene could be much smaller fragments like:

show_plane_and_number
trigonometry
show_formulas
show_properties
scale_and_rotate_plane
...

Of course, doing that with every scene leads up to a huge amount of videos in your folder, and finding a specific video will get a bit harder. But the good thing is: they're sequentially ordered, they have numbers in their filenames to help identify them because of the logical, temporal order in which they were shown on scene.
Hopefully now it makes more sense to have them numbered. That does NOT mean we should not add the section name in the file: I think it's a good idea to have both of them.

2. The ideas we've been discussing

There have been 4 ideas discussed here. I'll label them as [A], [B], [C], [D]:

Label When a section has a custom name... File name format
[A] ...put only its number anyways on the file scene_num.ext
[B] ...get rid of its number and replace it with the name scene_name.ext
[C] ...use both: the number and the name, in that order scene_num_name.ext
[D] ...use both: the name and the number, in that order scene_name_num.ext

So, recapping:

  • You say that [A] is not really clear (and I agree on that statement alone).
  • But then you propose [B] instead.
  • behackl said [B] is not a good idea, and that preserving the number along with the name (instead of getting rid of the number) to keep the file sorting would be nicer (which I agree with).
    • Both [C] and [D] fit at first...
    • ...but given that a key idea is "to keep the file sorting", that leaves us with [C].
    • I totally agree with him. IMO, [C] is the best of all 4 ideas, because of what I explained above.

why it would be a problem to have unsorted files?
At the end, even when you have a file with multiple scenes you would have them unsorted.

For the same example, it would be good to have this, which fits [C]:

PolarRepresentation_0001_show_plane_and_number.mov
PolarRepresentation_0002_trigonometry.mov
PolarRepresentation_0003_show_formulas.mov
PolarRepresentation_0004_show_properties.mov
PolarRepresentation_0005_scale_and_rotate_plane.mov
  • Because sections have a much more limited scope, and they have a time order ingrained into them, it would not be good to get rid of the numbers and let [B] happen instead, because it can quickly get messy:
PolarRepresentation_scale_and_rotate_plane.mov
PolarRepresentation_show_formulas.mov
PolarRepresentation_show_plane_and_number.mov
PolarRepresentation_show_properties.mov
PolarRepresentation_trigonometry.mov
  • I do agree, however, that having only the numbers ([A]), while logically and chronologically ordered, is not clear enough:
PolarRepresentation_0001.mov
PolarRepresentation_0002.mov
PolarRepresentation_0003.mov
PolarRepresentation_0004.mov
PolarRepresentation_0005.mov

But why not both ([C])?.

MrDiver: Because if you read them back from disk it becomes a problem of sorting the files by name
ubaldot: This sounds more like a developer issue than a user issue.

True that they are sorted by name in video software but this is in-fact very desirable.

[B] is an issue for everyone and everything that wants to work with sections in any more complex manner.

Suppose that I want to develop a specific software which takes a scene as input and displays its animation timeline, and when I edit the scene code only the changed part is rerendered, letting me see my changes instantly and how they fit with the rest.

Eventually I would need to support sections. For that, it would be helpful if they were already chronologically ordered.

Removing the numbers breaks that purpose and would make it more difficult for me to find the order of the sections. I would need to find a way to map a section to its correct position in the section order. The thing is, the file numbering already does that.

Hence, I wouldn't say that the current implementation is to solve a user problem.

That's a straw man fallacy: MrDiver never said that "the current implementation is to solve an user problem". Instead, he argued that removing the numbers creates another problem.

Adding both names and numbers could be somewhat confusing - but still way better than having just numbers and still acceptable:

ComplexNumbers_cartesian_representation_001.mov
ComplexNumbers_polar_representation_002.mov
ComplexNumbers_conversions_003.mov
...

The issue is, no one has argued in favor of this idea which I labelled as [D] (everything points to [C] instead). The argument is whether to keep or not the sorting by number. [D] does not help: if the number is after the name, it doesn't affect the file order and it becomes useless for those purposes. IMO, [D] is possibly the worst of all 4 ideas.

On the other hand, [C] does keep the sorting by number, which is nice for sections, while being readable at the same time: they are chronologically sorted, but also the number part is only 4 digits long, so the users can immediately read the name of the section, be reminded of what the section was about, and still understand that it was supposed to be in that specific position. That's why I think that idea [C] is the best one.

what shall be the first clip to add in the storyline? ComplexNumbers_introduction_005.mov or ComplexNumbers_cartesian_representation_001.mov?

They should have been scenes instead of sections: Introduction and CartesianRepresentation.

@MrDiver
Copy link
Collaborator

MrDiver commented Dec 9, 2023

Let's just leave it at we will have both the number and the section name in a format that was already commented in the PR.

@ManimCommunity ManimCommunity locked and limited conversation to collaborators Dec 9, 2023
@MrDiver MrDiver added the new feature Enhancement specifically adding a new feature (feature request should be used for issues instead) label Dec 9, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
new feature Enhancement specifically adding a new feature (feature request should be used for issues instead)
Projects
Status: 🆕 New
5 participants