Page MenuHome

Mantaflow [Part 6]: Updates in /blender/source
Needs ReviewPublic

Authored by Sebastián Barschkis (sebbas) on Oct 29 2018, 5:29 PM.

Diff Detail

Repository
rB Blender
Branch
sourceUpdate (branched from master)
Build Status
Buildable 3296
Build 3296: arc lint + arc unit

Event Timeline

Update manta files after merge with master.

Harbormaster completed remote builds in B3296: Diff 14647.

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
1560–1562

Juts remove it then (also same below).

source/blender/makesdna/DNA_particle_types.h
436

That one should probably be removed?

source/blender/python/intern/bpy_app_build_options.c
53

should be removed?

source/blender/python/intern/bpy_interface.c
201–204

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.