Moho 13 Bitmaps - Option to Embed internally

[SimplSam]

I would love to see an option to embed the Bitmap Image layers created in MH13 internally within the Moho file, rather than creating and linking to an external file.

At the moment I find the save to filesystem option messy.

I also recognise that there are benefits to having the image files stored externally - like having the ability to process the image panes by tools outside of Moho, so some may prefer that at times.

p.s. Also the option to create Duplicate Image Layers that do not use the same binary file/source.

[hayasidist]

Fully support this idea.

The .moho is really only a .zip, so adding assets that are "private" to the actual .mohoproj ought to be a breeze. (I actually requested this back in the "dark ages" - not just images but brushes, layerscripts ... that are only used in the given project ought to be in the project container -- a variation on "gather media").

Having them in the .moho container doesn't preclude being able to access them by programs other than Moho - so, even if there's stuff inside the .moho an inverse of "Gather" (e.g. "expose media") could present them in a way (similar to "open custom content") that they can be opened by other programs. Last part of this would be some way to mark each individual asset as "private / shared" (i.e. stored internal or external to the .moho container).

[Greenlaw]

I agree that Moho's content directory management is messy and easy to break. Most animation programs I work with allow me to assign a specific directory for a given production, which works much better. This way, even if when the entire production is move to a completely different drive, so long as the hierarchy is preserved within that content directory, all I need to do is re-point the program to that content directory and everything load as before. It doesn't matter if the content directory is nested at a different level or that the path is using a different drive letter because the path is relative.

I'm not so keen on having all the assets embedded within a project file. That could easily bloat the file sizes because of duplication and increase the file size of an entire production by many unnecessary gigabytes or even terabytes. Having files embedded also makes it difficult up universally update shared assets. This can be a nightmare on productions with dozens or hundreds of Project files. Even my 'small' personal animations may have dozens of Moho Project files. If this method of asset management was added, I'd probably never use it, so yes I agree that it should be made optional.

Moho has the next best thing with Gather Media. The collects copies of all the files in use and dumps them into a folder. All directory original structure is lost, but Moho knows where the files are and it's easy to .zip this up and send it away when the intention is to have somebody 'offline' work on it. Of course, when it comes back, you have the problem of re-linking everything to conform to your network structure, so it's not necessarily ideal for collaboration.

In my experience, the user defined and managed content directory is what works most reliably and efficiently, even when I need to work away and then return to my studio. In this case, I have a synced copy of my production's content directory on a portable drive. With most programs I use, I just point to that content folder and everything is the same. When I return home, I just resync the mobile drive and my NAS, and pick up where I left off with my desktop. With Moho it's a little more complicated than that because expects the drive letter to be exactly the same, which means I need to change my drive letter to match what I use at home or at work--not always possible or practical. We really need a place in Moho's Project Settings where we can point to a preferred Content Directory for that project, and a similar setting in the Preferences to assign the preferred Content Directory path to new project files.

As a bonus, it would be nice if Moho kept track of the most recently used paths, which is useful, for example, when multiple productions in progress. Not absolutely necessary, but convenient.

[chucky]

I agree with Denns (Greenlaw) on this one.
Gather media is great, the way Moho 13 saved bitmaps contradicted that well establishes folder structure.
Yes Moho can be challenged when it comes to links to images but I do love how the missing file name is clearly identified by Moho on those occasions where you have to relink.
I can't think of any time when I've permanently broken a project using the external images...
Also those external images are safe from any corruption during saving, which is the dangerous time, the longer it takes to save, the more chance there is for it to go wrong.

Having said all that if you get the option to save internally, I can see how that could be really useful.
Choices are good, maybe the option to do either would be ideal, just a s Sam has proposed.

[Greenlaw]

Sorry, I just remembered that Moho switched to relative paths a while ago so it's not quite as bad as described, but it's still kind of messy and easy to break compared to other programs where I can assign the current content directory.

BTW, I manage potential drive letter conflicts using a handy utility called Dive Letter Changer. With dChanger, I can quickly change the drive letter of the portable drive for my mobile computer, to the same drive letter for working in Moho or to a different one for syncing. You can get it here:

https://www.sordum.org/8501/drive-letter-changer-v1-4/

[hayasidist]

I'm not so keen on having all the assets embedded within a project file. That could easily bloat the file sizes because of duplication and increase the file size of an entire production by many unnecessary gigabytes or even terabytes. Having files embedded also makes it difficult up universally update shared assets. This can be a nightmare on productions with dozens or hundreds of Project files. Even my 'small' personal animations may have dozens of Moho Project files. If this method of asset management was added, I'd probably never use it, so yes I agree that it should be made optional...

the idea was that only those _local_ to the .moho file get packed in the moho container (optionally!!) - so shared assets always stay outside.

I can see that in some circumstances there are only shared assets -- but equally there are times when there's a variant (image / script / brush / whatever...) that is just for the given .moho file and I really do think it's better to have it kept with the .mohoproj that needs it -- also it isn't a once-and-for-all-time decision - stuff can always be made shared or private as its usage evolves.

[chucky]

Ahh Yes, Brushes.
There is a very good example, and a very small file.

That IS something that I've got lost, a preference for brushes and textures to be saved with file, separate to images, audio and video would be great!

[synthsin75]

The .moho is really only a .zip, so adding assets that are "private" to the actual .mohoproj ought to be a breeze.

This.

[Lukas]

Sorry, I just remembered that Moho switched to relative paths a while ago so it's not quite as bad as described, but it's still kind of messy and easy to break compared to other programs where I can assign the current content directory.

I'd like to note that the relative paths are not truly relative.
Paths are only relative as long as a file is in the same folder or sub-folder of the moho file.
If you have a project organized like this:

Code: Select all

/server/projects/coolmovietitle/shots/intro.moho
/server/projects/coolmovietitle/resources/images/beautifulpixels.jpg

The moho file will save the path to the jpg as an absolute path.

It should save it either as a relative path:

Code: Select all

/../resources/images/beautifulpixels.jpg

Or Moho should get a new feature where you can manage project locations.
For example in this case you would want to map the project like so:

Code: Select all

"Cool Movie Title" = "/server/projects/coolmovietitle/"

Different animators could map it differently, so it wouldn't matter if you're hiring a remote animator that is working on a mac syncing a project through some cloud client or a Windows user that's hooked into the project server through a vpn for example.

Gathering media is nice for a quick and dirty solution, but getting a remote file back into a structured project is a terrible and unnecessary waste of time.

[Greenlaw]

I'd like to note that the relative paths are not truly relative.
Paths are only relative as long as a file is in the same folder or sub-folder of the moho file...

Thanks for the additional input, Lukas! I settled for 'it's still kind of messy' in my post because, TBH, I'm not always sure why it breaks. Your explanation helps makes the reasons clearer.

Or Moho should get a new feature where you can manage project locations.

Yes! I've been wanting something like that for a long time.

Some programs I use have very detailed windows for this. It's typically called something like Project Folder or Content Directory. For example, one program I use has a window that looks like this...

At the top, there's a field for Content Directory, which is tells the program where to start looking for files. This is usually a level or two above where the project file is but it can be any directory. I usually set this to the current production's main directory. Next to that path is a pop up list of recently used paths, which is typically other productions I might need to switch to, since it's not unusual for me to be working on multiple productions at the same time.

Below this is a check box to enable Custom Paths, which lets me enable paths for project files, objects, images, animation curves, particle data, output directory, etc. I don't normally need to enable any of these because the program is usually smart enough to work relatively from the path I set at the top and save this data in the project file. In other words, if the project's assets are located anywhere inside the specified production's folder (not the projects) then it can and will be found.

There's one other feature that's kinda cool: Auto-Detect. This helps the program determine if the content directory has changed, and the program asks if I need to switch. This could be because a drive letter has changed, or the production's folder has been moved. It would nice to have this in Moho too...but I would be very happy to have just the ability to set the content folder for a project.

[jmartins]

We actually toyed with the idea of adding image data inside the Moho file. We ended up using the prototype code to store the bitmap brushes stamp data, so the functionality is sort of there.
The bigger problem is regarding user experience. Even though it's very handy to be able to just drag around a file to get the full output, bigger scale productions can get cluttered with files really fast, pushing the mohoproj file (which is essentially metadata at this stage) into a huge mess that can take ages processing without some careful development.
I think studios (and this is a trend on any sort of animation/vfx production in my experience) will always prefer to have separate assets for both ease of storage/transfer but also for version controlling (assume updating the the image data for a rig, which in most cases won't obligate to update the rig, so you actually only need to update one file, instead of updating the whole capacity of files). Shotgun for instance likes stuff like this.

The only option I can think of is on a project basis, to be able to set that assets are stored in file or as directories. But then again that's the sort of solution that can lead a product UX in a rupture state, I'm personally not a fan.

All in all, I think having the option is good, but if I was advising a user that has both options, I would advise to have them organized as separate files, and it might be good for Moho in the long term to enforce that sort of behavior on the users.

[hayasidist]

Hey João!! Nice to see you're still around!

We actually toyed with the idea of adding image data inside the Moho file. We ended up using the prototype code to store the bitmap brushes stamp data, so the functionality is sort of there.
The bigger problem is regarding user experience. Even though it's very handy to be able to just drag around a file to get the full output, bigger scale productions can get cluttered with files really fast, pushing the mohoproj file (which is essentially metadata at this stage) into a huge mess that can take ages processing without some careful development.

For sure there it makes no sense whatsoever to keep resources that are intended to be shared / sharable locked up in a moho file with, as you and others have pointed out, all the attendant problems of asset management that it involves. And I certainly don't advocate having images stored in the .mohoproj...

But I'd be keen to see the .moho container (rather than the .mohoproj) as a candidate for storing assets that are local to a project - with the option to manage the content, in effect, just as any other .zip.

[slowtiger]

I tend to not include too much stuff within the file, maybe because of my bad experience with loading time in the past (all software). Three reasons:

1. If you want to implement this function, I recommend to make it reversable as well. Why? Because people (me included) tend to click a button, followed by longer cursing "aaaaaah! Now the file's enormously large and doesn't open anymore!" So it also needs a button "Un-Embed image files", with a dialogue asking for a folder (or creating one).

2. Also embedding possibly will make it more complicated to update image files on the fly, which I do all the time.

3. Bigger productions will share a lot of images over several project files. Shared images need to be updated as well - how would you handle this if many project files have embedded these images? (One of my last studio jobs had 11 GB of image texture files per episode. Imagine this multiplied by the number of scenes!)

[Greenlaw]

I tend to not include too much stuff within the file, maybe because of my bad experience with loading time in the past (all software)...Now the file's enormously large and doesn't open anymore!" So it also needs a button "Un-Embed image files", with a dialogue asking for a folder (or creating one).

Ugh...yes, that can happen even with the beefy computer systems I use at work. In my experience, it's just a bad idea except for maybe simpler projects...in which case, why bother?

...Also embedding possibly will make it more complicated to update image files on the fly, which I do all the time.

Yes, I need to update images all the time. Imbedding makes this inconvenient.

...Bigger productions will share a lot of images over several project files. Shared images need to be updated as well - how would you handle this if many project files have embedded these images? (One of my last studio jobs had 11 GB of image texture files per episode. Imagine this multiplied by the number of scenes!)

That's my concern too. The other day, I was revisiting the files from my first Moho short Scareplane from seven years ago. This was a small indie production, but there are over 20 shots and many of the Moho project files share about 6.5 GB of bitmap images for backgrounds and props. I was able to animate this short on a modestly powered laptop (4GB RAM) because Moho let me work efficiently with the assets. Back then, I would not have had enough storage available if every project had embedded bitmaps.

So, yeah, bitmap embedding should definitely be optional, if it's done at all.