Model-Loading Extensions: What is the Best Practice?

Pipeline
, , ,
1

[edit]
I’ve removed one of the questions here, as it turns out that it’s likely unrelated.

I’ll likely make a new thread for that issue soon…
[/edit]

So, for a long time I’ve been following the practice of eliding file-extensions when loading models.

A recent issue prompted me to look into the “default-model-extension” config-variable, and doing that prompted a question:

What is the current recommended practice for handling model file-extensions?

Up until now, I’ve been eliding my file-extensions. This makes sense to me, as it means that the program can use human-readable egg-files during development and binary bam-files in distributables.

But the manual seems to contradict this: in the entry for the “default-model-extension” variable, it indicates that file-extension elision is now deprecated, and that “new code should probably give the correct name for each model file they intend to load”.

However, that would seem to make development that much more awkward…

Unless, I suppose, one were to switch entirely to “gltf”-format…

So… is that the answer here? That “egg” and “bam” are likewise deprecated, with “gltf” being the recommended format going forward…?

2

There is no contradiction in the documentation, you yourself somehow connected it with the .gltf format. This variable is valid if the file extension is missing. At the moment, you cannot use .bam files without an extension, it is not very convenient for other users who have decided on the format and are not using the packaging of the application. Moreover, the extension informs you about which format is currently being used. Similarly, can also improve the situation with the implication of further modification of the API for a specific loader. In my opinion, this is a positive trend.

model = loader.assimp("plane.obj")

3

To clarify, I wasn’t saying that there was a contradiction in the manual, rather.

Rather, what I was saying was that the manual contradicts the teaching–old teaching, granted–that the usual thing to do is to elide extensions and let Panda determine what sort of file is meant.

(See for example the “Hello World” tutorial, which elides extensions.)

Specifically, the manual indicates that omitting file-extensions is now deprecated, and implies that extensions should be included when loading files.

To quote the manual:

This is primarily designed to support legacy code that used the now-deprecated implicit-extension feature of Panda’s loader; new code should probably give the correct name for each model file they intend to load.

(I gather that you mean “outside of a distributable”–bam-files, at least those converted from egg-files, seem to work perfectly well in distributables even without an extension being specified in the code.)

Based on a quick test, you can use “.bam” files without an extension, if you first set the value of “default-model-extension” to “.bam”.

(Of course, if you do so, then you can’t then use egg-files without an extension…)

Sure! But that doesn’t seem to me to speak to whether it’s best to elide file-extensions, at least outside of format-specific loaders such as the “assimp” loader that you mentioned.

On this, I do agree. :slight_smile:

4

As you yourself have noticed, the essence of skipping an extension is part of the packaging of the application, after packaging, the packer changes the extension in the configuration file, if I still remember the process correctly. This is the relationship between the .egg and .bam, which has lost its importance due to the variety of formats.

Thus, default-model-extension cannot be considered mandatory, for example, it is completely useless when developing in C++.This also provides an answer to the question of why the bam file loads perfectly - since the application packager takes care of this variable.

5

Sure, but the manual still seems to indicate that implicit extensions are not merely optional, but outright deprecated–as in, they should ideally not be used at all.

6

I think this is acceptable when using the .egg format, since Panda3D has a tool to convert the .egg format to .bam, and given that when developing in Python there is also a packager that can use it. Then you need to proceed from the combination of the above factors; there is no clear solution. This can only be discussed after removing the .egg format from Panda3D.

7

But then surely the feature isn’t deprecated until the egg and bam formats themselves are deprecated.

By the way, I bumped into a wrinkle in Panda’s support for egg- and bam- files without extensions:

It seems that, with the default settings–which presumably includes “default-model-extension” being set to “.egg”–Panda requires that “eggs” converted to “bams” be named with the extension “.egg.bam”. Files named with the extension “.bam” alone seem to not be picked up.

Now, this is of course handled automatically by the build system. I only bumped into it because I have some files that are handled separately.

8

Although this problem does not exist, if the user takes care of the required format when distributing the application, this can eliminate the model conversion step when packaging the application.

The bam format will never become obsolete; this is the internal structure of the node graph.

In fact, the effectiveness of this “feature” does not have any practical benefit, since there is a model caching system, the user must independently take care of the model format in advance at the development stage, since at the application packaging stage this stage does not lead to anything meaningful.

9

True–although that means giving up the advantages of the egg-format.

(Which, admittedly, I find I rarely use.)

That is a good point.

So, perhaps it’s just the “egg” format that’s obsolete…

I definitely find it useful while still using egg-files in development, as I don’t want to distribute in that format.

10

However, the format itself does not matter, because there is no difference whether it is outdated or not. The difference is that it makes no sense to convert files with the “.egg” extension to “.bam” at the stage of the packaging process. In fact, nothing prevents you from doing it yourself, at any moment.

The logic here is similar, that if you don’t want to, you can easily convert them in advance to .bam
It is doubtful and useless to wait until the packaging stage, since you are working in a blender for a long time, you can store the sources in the format .blend, so the .egg format is an unnecessary step - without any meaning, a waste of time.

The whole point of the .egg format is mediation, after conversion to .bam he’s useless. At the same time, you have the original model in the file .blend

11

I suppose.

But I still think that it’s worth asking what the “best practices” are–what’s recommended these days.

Plus, it occurs to me that deprecated functionality may be removed in future, which is worth knowing about.

Well, for one thing, I’m still using an old exporter that exports to the “egg” format.

And for another, it means that model-files aren’t human-readable for debugging purposes.

One can open up an egg-file and see whether it has, say, vertex colours. The same is harder to do with a bam-file.

12

You can always:

  1. Modify the exporter script so that at the end of the export it calls the egg2bam tool for the received file.

  2. Store your .egg files in parallel, if necessary, simply call the egg2bam tool through a batch processing script or through a special python script. At the same time, it remains possible to view the file with the human eye.

In practice, simple for distribution: convert to a format .bam or other independently and use the filename with the appropriate extension, it does not matter whether it is outdated or not, the main thing is that it is supported.

Postponing this stage to the application packaging stage is tantamount to creating a logical problem due to the combination of formats necessary for the application at the same time .egg, .bam, .gltf and so on.

In any case, there is no need to accumulate all the “favorite files to study” and convert them at the appointed hour and day at the stage of packaging the application in .bam.

13

It occurred to me that in order to finally eliminate the uncertainty regarding the use of the “default-model-extension” variable, you can simply refuse to convert the format in automatic mode at the packaging stage. In this case, there will be no question of the obsolescence of .egg or .bam formats.

Users will immediately identify with the necessary formats and combine them without any problems. Perhaps this feature really does not benefit and breaks logic when using other formats or the C++ language.

14

This is true, I suppose.

Well, that’s the thing: if it’s deprecated, it may be in line to stop being supported…

It’s probably fine for my current project, but it seems a question worth asking towards any future projects…

Well, not really–for the most part, at least.

I’m not using gltf right now, and eggs get automatically converted to bams. So there’s only really one format in use at any one time.

It’s only really an issue for me with this specific project because I’m doing something weird with some of my models.

(And even that’s just a matter of making sure that when I manually convert that specific sub-set of models that I use the extension “.egg.bam”, rather than just “.bam”.)

To clarify, I’m not uncertain about using the variable in question–for my current purposes I don’t have much use for setting it manually; the default is fine.

Rather, it’s the text that accompanies it in the manual that concerns me.

I suppose, but I don’t want to distribute egg-files–they’re a bit big, and in distribution one generally doesn’t want one’s files to be human-readable!

15

You’re missing the context, you can do it yourself. The essence of changing the default-model-extension is to ensure the functionality of loading models after changing the format (extension), again, this is not due to the obsolescence of the format itself. This is the logic that ensures the use of the same name in different formats, that’s all, there is no more sense.

16

Okay, sure–I misread your previous post, and thought that you were suggesting that the models not be converted at all.

That said, that seems somewhat besides the point, to my mind.

(And that is what I’m doing with the aforementioned sub-set of models.)

But it still leaves one using a feature of Panda–implicit file-extensions–that is apparently deprecated.

So, the options (for most purposes) seem to be:

  • Keep using implicit file-extensions, with Panda converting models automatically at build-time.
    • This allows one to keep the advantages of both egg and bam formats, and without worrying about the switch affecting file-names
    • But conversely, the feature in question is apparently deprecated–and which may thus be removed in future
  • Keep using implicit file-extensions, but manually convert the files
    • This seems to me to be much the same as the above, but with more work
  • Switch to a single-extension format (such as gltf)
    • This has the advantage of moving to a widely-used format, and of not requiring conversions, and of not using the implicit file-extension feature
    • But conversely, it incurs the loss of some of the advantages of the egg and bam formats
  • Stick to the egg and bam formats, but stop using implicit file-extensions
    • This would again allow one to keep the advantages of those formats–but without relying on a deprecated feature
    • Conversely, it would seem to require some additional code-support in order to switch from development code (which would use file-names with the “.egg” extension) and distributable code (which would use file-names with the “.bam” extension)

I don’t see any significant alternatives, offhand…

17

You deny the very fact that using implicit extensions is only part of ensuring automatic file conversion. When will you realize that this is the only point?

This only exists in order for the build system to convert your .egg files to .bam, then changed the default-model-extension variable to ensure that the loader searches for models.

You should understand that such a list of formats is not a requirement… I can use different formats in any number, no problem.

This only applies .egg and lazy users who want to use model converted in automatic mode, at the packaging stage of the application.

18

Correctly:

  • Keep using explicit file-extensions, but manually convert the files

This option does not contradict the meaning. Unless, of course, you prefer to shift this responsibility to the application packager(only for .egg).

Thus, the use of the extension for the .egg format is at your discretion, for other formats it is mandatory.

19

I don’t deny that–I deny that it’s the only point.

I know–I’ve never said otherwise.

And it’s for such–myself included–that I’m asking, essentially.

I don’t think that using a provided feature–even if it’s “lazy”–is necessarily a bad thing.

But, as with any feature, it seems wise to know whether that feature is still the intended way to do things, and–perhaps more importantly–whether its deprecation means that it may not remain.

Why would I want to do more work? It seems more efficient for the developer to get to leave off file-extensions.

Yes. Right now, that works well.

Hmm… Actually, I’m not sure of this: If one were using only gltf files, could one not set the value of “default-model-extension” to “.gltf” and then keep using implicit extensions?

20

You proceed from the fact of using a single format. My objections are mainly based on the fact, what to do with others? If the user wants to use ten different formats…

Look at the section, List of Build Options — Panda3D Manual, then it becomes obvious that the default-model-extension variable is relevant, and there are no prerequisites for its removal. Because there is a new list option for listing such files - bam_model_extensions

I’m not sure if this is useful, because there is no sound logic in this possibility. It’s a waste of time on logic, which is easier to implement manually by scripting, but the developers went the other way, by inflating the packaging functions of the application.