Drawing in bitmap directly in Moho

[bibendumchamalow]

Do you think the bitmap tool will be back soon?
For making traditional bitmap animations, it's more obvious to make drafts with this kind of tool because it's more like a pencil. It would be really great to have these tools back.

What do you think about it?

Here is an overview of these tools on Moho version 13 in 2019.
https://www.animestudiotutor.com/animat ... JJL5N3jVr8

[Hoptoad]

Soon? Nah.

Moho cares about users paying for upgrades. Would the average user pay for an upgrade simply for bitmap tools? I don't think so. Most people use other software for bitmap stuff and then import it, so there's no urgency for the feature.

Eventually, though, LostMarble will run out of cool, new features to justify paying for an upgrade. When they reach that point, THEN they'll add bitmap tools. And then Moho will be 100% done, and all updates will be trivial and free. For example, Moho could be upgraded to have more brushes, or a new color for bones.

That's my guess.

[Greenlaw]

Personally, while I think it would be nice to get proper bitmap drawing tools natively in Moho, right now I think it's more important to get better freehand vector drawing. The quirkiness of Moho's current Freehand and Blob Brush tools is the reason I avoid freehand drawing and FBF in Moho. If these tools were more dependable, I'd probably never open Adobe Animate or Harmony to create my FBF passes for Moho. After that, I would love to see bitmap drawing come back to Moho, but only if it's done well this time.

As for soon..? Moho 13.5.5 has only been out about 6 months, and I'm guessing it's going to take longer than that to develop the new version of Moho. That said, knowing Mike and his amazing dev team, it will be worth the wait.

[chucky]

Have to disagree with Hoptoad on this one.
Of course, people would pay for that. Itt is a crucial part of almost any pipeline.
I often pop back to 13 for those tools, but as it was an improvised feature from other developers, the core of the program had to be returned to a clean slate, which is far more stable for everyday use..

There has been no announcement regarding the feature whatsoever, so unless you hear officially, there can be no assumptions made about that.
Personally, I'm a big fan but I'm definitely biased.

[Daxel]

...it's more obvious to make drafts with this kind of tool because it's more like a pencil. It would be really great to have these tools back.

It doesn't look like they will be back so soon, and it's probably not a priority. A good implementation, whenever is ready, would be welcome. But I think (and hope) the next version will improve the vector drawing tools and then you should be able to make drafts comfortably with them.

[Greenlaw]

More on why I want a better Freehand tool in Moho...

Last week at work I had to create a series of FBF animations and I used Adobe Animate. I think the freehand vector drawing tools in that program work very nicely but as I was drawing, I found myself really missing not being able to use Moho's Magnet tool to make quick adjustments to my strokes. In fact, I started this task using Moho because it had the Magnet tool, but I soon became too frustrated with the Freehand tool and I eventually switched over to Animate to finish the task.

I guess I can start wishing for a Magnet tool appear in Adobe Animate but if I can only make one wish here, I'd rather see a better Freehand tool in Moho.

[chucky]

Oh, it's imperative that vector drawing is upgraded, you can't have better bitmap without that first as I understand.

[hayasidist]

IMO, trying to add functionally rich bitmap tools to Moho is akin to re-developing then maintaining / enhancing something that is, in lines of code, the size of the main core of Krita. Still IMO, there is no point in asking or expecting the Moho dev team to do that when there's animation stuff that would benefit from their attention.

The stuff in 13.0 worked (and I **really** loved its brush management) -- but the actual drawing part was not functionally rich and had limitations that, again speaking personally, made it not worth the effort of using it when I could readily import stuff drawn in built-for-the-task applications (Krita, PS, ...)

If **I** had a wish re bitmap drawing in Moho it would be to integrate Krita into Moho -- which can be done **NOW** in the same way as photoshop is "integrated" -- i.e. saving Krita's output as a .PSD which moho can load and dynamically update.

Going one step further, Krita is Open Source -- there are obligations should the code be re-used, but I believe there are no commercial barriers to obtaining the code **legally** and embedding it in Moho. That said, actually integrating it is probably not trivial, but IMO is a whole lot easier than building a whole bitmap package from scratch!

[chucky]

IMO, trying to add functionally rich bitmap tools to Moho is akin to re-developing then maintaining / enhancing something that is, in lines of code, the size of the main core of Krita. Still IMO, there is no point in asking or expecting the Moho dev team to do that when there's animation stuff that would benefit from their attention.

The stuff in 13.0 worked (and I **really** loved its brush management) -- but the actual drawing part was not functionally rich and had limitations that, again speaking personally, made it not worth the effort of using it when I could readily import stuff drawn in built-for-the-task applications (Krita, PS, ...)

If **I** had a wish re bitmap drawing in Moho it would be to integrate Krita into Moho -- which can be done **NOW** in the same way as photoshop is "integrated" -- i.e. saving Krita's output as a .PSD which moho can load and dynamically update.

Going one step further, Krita is Open Source -- there are obligations should the code be re-used, but I believe there are no commercial barriers to obtaining the code **legally** and embedding it in Moho. That said, actually integrating it is probably not trivial, but IMO is a whole lot easier than building a whole bitmap package from scratch!

The Krita workflow is very different, entirely FBF, no vectors or bones if you tried the combined techniques though inside Moho, it's fun, effective and fast even without the copy/paste features.
It was done once, it can be done again, doesn't really matter how.
It is not something to be expecting to suddenly appear though, I would imagine.

The likelihood is totally up to dev, it is pretty much pointless discussing it or the reasons for or against.
Regardless the feature was very useful and made for great efficiency, maybe not for all.
It's also a great drawcard if you forgive the pun.

[SimplSam]

...
Going one step further, Krita is Open Source -- there are obligations should the code be re-used, but I believe there are no commercial barriers to obtaining the code **legally** and embedding it in Moho. ..

Open source can be a bit of a nightmare. Many of the licences require that you 'share-a-like' - i.e. - LM would need to open source Moho if they chose to incorporate Krita code.

[hayasidist]

...
Going one step further, Krita is Open Source -- there are obligations should the code be re-used, but I believe there are no commercial barriers to obtaining the code **legally** and embedding it in Moho. ..

Open source can be a bit of a nightmare. Many of the licences require that you 'share-a-like' - i.e. - LM would need to open source Moho if they chose to incorporate Krita code.

I did look into that -- my reading was that you need to share anything Krita that you modify - but not stuff that was yours (and does not include the open source stuff) -- so moho core (if I'm right) is ring-fenced -- but Yeah -- due diligence and all that before leaping!

[SimplSam]

I did look into that -- my reading was that you need to share anything Krita that you modify - but not stuff that was yours (and does not include the open source stuff) -- so moho core (if I'm right) is ring-fenced -- but Yeah -- due diligence and all that before leaping!

I concluded that it was a bit of a minefield from the GNU FAQ entries below:

Can I release a nonfree program that's designed to load a GPL-covered plug-in?
If they form a single combined program then the main program must be released under the GPL or a GPL-compatible free software license, and the terms of the GPL must be followed when the main program is distributed for use with these plug-ins. However, if they are separate works then the license of the plug-in makes no requirements about the main program.

You have a GPLed program that I'd like to link with my code to build a proprietary program. Does the fact that I link with your program mean I have to GPL my program?
Not exactly. It means you must release your program under a license compatible with the GPL (more precisely, compatible with one or more GPL versions accepted by all the rest of the code in the combination that you link). The combination itself is then available under those GPL versions.

Is there any chance I could get a license of the program under the Lesser GPL?
You can ask, but most authors will stand firm and say no. The idea of the GPL is that if you want to include our code in your program, your program must also be free software. It is supposed to put pressure on you to release your program in a way that makes it part of our community.

[chucky]

I think the main danger for a commercial app working alongside and with an open source ((which is probably not that viable anyway, unless you are just an add-on appendage to the free tool), is that by doing so, one would be shining a light onto the open community, giving them free marketing and opening a door for users to wander into an increasingly effective set of free tools from which they may never return.
To beat free tools, your paid tool will have to be more appealing and offer more.

I imagine that ' in the future' perhaps as free and open apps become more popular and powerful, being an add-on may be the only way to survive in some markets.
We have seen so many smaller commercial 2d and 3d apps wither and die while the big boys monopolise, but the open source continue, unaffected by takeovers and squeezes.

Moho needs to weather the approaching open storm, I only wish it well, it has some great advantages now with a fun workflow and particular strength in 2d rigging, is it safe from Blender and Krita? Nu-uh.

[hayasidist]

Yes to both Sam and Chucky -- there are deep issues that need to be considered...

so let's take a look at this from a slightly different direction.

what does bitmap give that vector doesn't?
conversely why has Krita embraced SVG (and so offers vector graphics)?
what about .EPS / .AI vector formats?

why do I use bitmap instead of vector?

for me it's the ease of making fills that aren't just a block of solid colour; it's a more "paintbrush in hand" feeling than the click-drag-click of defining a path and then struggling to get a "textured" fill...

and now Moho has blob brush and freehand... but they're (dare I say this??) no substitute AS YET for the brush-in-hand feeling... but if I had brushes for FILL in moho that would help... if I had blend modes at shape level... if ... if ...


so maybe we stop worrying about bitmap in Moho and start thinking about making it much easier to create vector shapes that look as though they've been "painted" rather than being (neatly trimmed, carefully placed, cleverly animated) cut out shapes of coloured paper.

IOW improve blob brush and freehand to the point that bitmap becomes yesterday's technology??

[slowtiger]

That's a good direction to think about. This summer I've used just a little bit of Moho's capabilities in that range, by creating textile textures with vector brushes so they could move and deform with everything else.

Off the cuff I'd define the requirements like this:
- easier layering of strokes and fills, with better ways to select each
- an animateable stroke offset at each point (of course this can be done with a separate line as well)
- treating fill plus stroke as a default mask when adding more strokes and fills
- evaluate the way brush spacing is calculated, it's not the same number of copies between points anymore, but could be improved maybe? Plus maybe a handle at the stroke to fine-tune (animateable) brush spacing on the fly?
- something of a more intuitive control over stroke width, brush spacing, opacity etc, instead of opening and closing those many windows (goes for fills as well)
- some way to incorporate animated textures and brushes (there's a rudimentary way for brushes, but lacks control)
- a more sophisticated noise engine
- in general I'd like to get more control about frequency, like having a general setting for vector noise and animated brushes, with an override at any point so I could treat details differently. There's so much Moho could do in itself which today only works with a bunch of separately rendered plates to AFX or some other compositing tools.