A collection of smaller changes that are required in the /blender/source files. A lot of them are also due to variable renaming.
Details
- Reviewers
Brecht Van Lommel (brecht) Sergey Sharybin (sergey) Nils Thuerey (n_t) Georg Kohl (GeorgKohl) - Maniphest Tasks
- T59995: Mantaflow Review
- Commits
- rCdd54bf816d45: Mantaflow [Part 6]: Updates in /blender/source
rBd27ccf990c2b: Mantaflow [Part 6]: Updates in /blender/source
rB9d40d0ad2e03: Mantaflow: Smaller update for draw engine code
rB305bedc9d11f: Merge branch 'internUpdate' into sourceUpdate
rBe4cd623fefd4: Merge branch 'internUpdate' into sourceUpdate
rBf3fa0fb9b175: Mantaflow: Updates in /blender/source
Diff Detail
- Repository
- rB Blender
Event Timeline
In general have the feeling naming is a bit fuzzy again, some defines/enums/operators are using MANTA prefix,(which is a good thing), but some others still use FLUID (which is too vague and generic), and modifiers are still even using Smoke in their names…
Also, I understand that new Manta shares most of its data structure with old smoke modifier, but still, not sure it's a good idea to reuse that one (and modifier type etc. as well)… @Campbell Barton (campbellbarton) do you think we could use new DNA renaming system here?
| source/blender/blenkernel/intern/pointcache.c | ||
|---|---|---|
| 1738–1744 | Juts remove it then (also same below). | |
| source/blender/makesdna/DNA_particle_types.h | ||
| 434 | That one should probably be removed? | |
| source/blender/python/intern/bpy_app_build_options.c | ||
| 29–30 | should be removed? | |
| source/blender/python/intern/bpy_interface.c | ||
| 205–208 | This looks like a fix? Should be committed to master directly, then… | |
Regarding naming I disagree. We should not use the "mantaflow" name in the user interface or operator names much. For users that's an implementation detail, ideally we just have one fluid and smoke simulation system. Internally it's fine.
Naming concerns are for code names, not UI ones (am totally fine with generic Fluid one in UI, also there we still have some sneaking smoke too). In code, I believe keeping the underlying lib in names makes sense, it helps in case we have several systems enabled at the same time, and also when migrating from one to another (since it makes things more clear in patches etc.). This is roughly a C equivalent to the namespace concept in C++, imho that is quiet desired.
Modifiers id_name is a bit of a gray area here, but it's theoretically code info (user is supposed to see their labels, not their id_name, usually). So I’d still rather have the manta info in those.
Even for operators, I prefer the UI and operator names to match whenever possible. Just to make it easier for scripting, logs, and setting up keymaps where these names do get exposed to non-technical users.
I agree with @Brecht Van Lommel (brecht) here. Seems the naming was not addressed here?
| source/blender/editors/interface/interface_templates.c | ||
|---|---|---|
| 1822–1829 | Store ((ParticleSystemModifierData *)md)->psys->part->type in a temporary variable. No need to copy-paste it in all the lines. | |
| source/blender/makesdna/DNA_particle_types.h | ||
| 435–440 | Use anonymous enum, allowing to access values from gdb. | |
| 442–450 | PARTICLE_TYPE_FOO, not POO. | |
Couldn't we move away from manta name for filenames and types?
- eModifierType_Manta -> eModifierType_Fluid
- BKE_manta.h -> BKE_fluid.h
- DNA_manta_types.h -> DNA_fluid_types.h
- WITH_MOD_MANTA -> WITH_MOD_FLUID
| source/blender/blenkernel/intern/modifier.c | ||
|---|---|---|
| 159 | Why is this needed? (should be commented). | |
@Campbell Barton (campbellbarton) Yes, renaming is a good idea. I also got rid of the null check in the updated patch.