Less features but built-in means:
It’s part of Krita natively as a brush engine or layers docker or other parts of krita, less features mean: no or almost no pose library (you have to pose everything on your own), no animations, no pose/animation retargeting - you can’t just import a your model and then grab and drop a pose/animation on it from a library, limited IK, no shapekeys support, more complicated import (technical point since user might not even know about it but it’s important from a dev point of view), no export, …
More features but as a plugin means:
It’s a Krita plugin, you have to download it and enable it in Krita, in both (2. and 3.) cases it would include some kind of a docker as usual.
It can have about anything feature wise, all the features marked as none or limited in the paragraph 2 above are possible, mostly with little work, without limits, pose library included, pose/animation retargeting functional (you can grab a model from elsewhere and as long as it uses a standard skeleton - or you can use an automatic tools to add it or add it manually in Blender for example - you can just drop any pose/animation from the pose/animaiton library in the plugin and have your model posed right away), shapekeys/animation support also makes it possible to create a customizable model - imagine a character creator from games, you could set height, fat, muscles, … - and more.
Important notes:
I’m not a Krita dev, this is also not a feature proposal from Krita dev team or me, for now it’s a research so please treat it as such
From a technically stand point it’s possible to have all the features in the built-in solution but that requires a significant amount of work and partially rewritting stuff in the framework which Krita uses as such I don’t think it’s very realistic thus I marked some stuff limited or none.
After krita moves to QT6 (framework, currently it’s QT5) it will be possible to have all the things from 3 natively but that’s still a couple of years ahead and structure of the 3d project will change so don’t pay too much attention to it please.
Don’t worry about other approaches, this thread is not to discuss them.
Anyone working or thinking about working on a 3d stuff for krita feel free to make any conclusions from this and don’t take it as a stopper for your work, there’s more than enough people excited about a possible 3d poser in krita including me
Thank you very much for participatinig in this poll!
EDIT:
I'll use this edit to answer some points which were raised in replies that seem to be worth to keep up here too for anyone:
This poll is my personal one, not related to Krita’s dev team in any way, there’s some confusion which I’ve failed to prevent so hopefully this will mitigate it at least. Don’t worry too much about technical side, I’m just standing in front of some options on my side and I wonder what you prefer, nothing else.
Android: Please don’t let this option influence your choice in the poll, currently I don’t plan support for it either way, I’ll wait until android branch gets the rework (ui, …), there are more important things for android branch that need to be resolved before I’d be suggesting adding this since this could potential bring issues which could hinder the android developers quite a bit. Eventually both options will be possible as far as I can tell from past discussions with devs but for now I won’t be focusing on android at all.
Performance: Both options have the same performance.
Can only choose 1 of 2?
Can’t provide a “both” option?
I think both can exist at the same time, they don’t conflict.
—————————————————————————————————
Also, for now I think this can be done with other software and then export the image to krita.
Using file layers, images can be re-exported in other software and displayed in krita immediately.
I say this only so that users who see this vote know of a temporary solution.
Both means double development, even a single one option is quite an amount of work.
For the other note you had, I’ve purposfully excluded an option of the file layer and blender or other app, this is a poll about plugin vs built in not a feedback or proposal thread, please I don’t want to create this discussion here right now
If it is a development priority perspective, it is indeed 2 to choose 1.
But this is just a vote.
From the practical point of view, the two have differences in ease of use for users.
So I thought maybe a “both” option should be provided.
Regarding temporary solutions.
Like I said earlier, that’s just to let the user who saw this vote know it’s okay to do so for now. (If the user who saw this poll did not know this method.)
Rather than I want to discuss temporary solutions in the polls.
Well anything right now is temporary since 3D changes in qt6 and will require changes in code anyway.
For now I’d like to avoid adding an option oh if I can do something similar already then I’ll just pick option 1, that’s why I did not include the info you can use other 3d app and kinda (not fluid) do something similar.
Both, honestly I don’t think anyone is going to develop both, in this poll the difference in drections is 180 degrees so it’s a huge investment of time to develop both since they wouldn’t be sharing the functionality or api.
I already consider it a problem that certain existing features (such as brush shortcuts) are plugins instead of first-class citizens. Especially in this case, I imagine python performance would be an issue.
Python performance is irrelevant here, it’s used just as an in between layer, the perfomance code is in c++. You can’t tell the difference between these two options performance wise
Android right now is not in a release version, until it receives UI updates and other work it’s still a test version andas far as I’m conncerned niether of the solution would be supporting it right now since that just adds extra workload on the android dev branch which could cause troubles before solving the android port altogether. This is just my personal opinion about this, if I got to it I wouldn’t be supporting android until later, both options will be eventually possible on android though, at least as far as I can tell.
I’m not sure to understand why a plugin would have more features than native Krita functionnality…
Technically, you’ll always have more possibilities by developing something native to Krita than a plugin.
For example and from my point of view, 3d stuff must be managed trhough a “3D layer” : that’s only possible through a native development, not from a plugin…
Well in this case I’d be bringing a separate 3d engine through a plugin while natively that’s a more complex issue which would also require solving lot of dependencies which also need apporval from the kde side where krita is located so it’s not as simple.
3D layer probably won’t be a thing for qutie a while anyway since adding a new layer is not a simple solution to begin with.
As I mentioned in the notes it’s not that it’s impossible, just from the practical stand point there’s lots of things to deal with.
It’s also not a one for all time solution, no one says it can’t eventually become part of krita.
I just wanted to know how people feel about this since developing it as a plugin would require a lot less work, and I mean a lot less and since time is the most valuable resource here it’s something to consider
I’ve been researching various approaches, this is just one of the questions which popped up, it’s possible to implement it in different ways, before committing too much I want to explore the options, or more like I’ve been exploring them past couple weeks and annoying devs in chat especially @tiar hehe ;0.
Natively qt-3d in qt5 just doesn’t have all the functionality which would be possible with a different solution that’s why the difference in the feature set. As I mentioned in the notes it’s technically possible since it’s all c++ and you can do it but adding all of the features would require significant amount of work building it from scratch, making lots of custom patches to qt5 and/or including new dependencies through new libraries. It’s not a simple matter and not everyone on the dev team will be happy about introducing all this.
There are other options, this poll is jsut what it is, it’s not answer deep questions or go too technical, I’ve just lately tested a pretty simple way to have a 3d in krita which also gets added to the layers stack which allows it to work with various layer stuff in krita as usual so I just want to see what people feel in general about approaches without giving away too much informaion.
Yes, both options would to the user appear about the same, it’s just the feature set in this case would differ.
To be precise, everything in both these cases happens on the canvas, it’s dynamic, both also include possibility of layer styles, alpha locks, …
Yeah, I’ve been wondering should I ask on monday or not but then I decided not to since there might be a different way, not perfect (as not any other is xD) but it would reduce the amount of work significantly so I want to first explore that as probably the last option on my research list and then evaluate the approaches so I left it for probably next week or later in the week I don’t know how life stuff will work out for me this week
So for now I’m just exploring as usual, again and again and … eghh…
Dmitry and Halla are quite experienced in estimating time and effort as well So they can help you evaluate the approaches too. And they will know better in regards to which approach would be acceptable in main Krita and which will not be.
I’m sure of that. The plugin way though doesn’t require anything from Krita so I’m almost certain it would not be an acceptable way for Krita but it cuts down the amount of work so much that I’ve decided to make a small prototype on my side to see if it’s a viable option or not.
The other options are unfortunately more work heh and some stuff would either need a lot of extra work or just not include it until qt6 since it’s just not in qt5 and needs to come from scratch or different external libs which could bloat the krita project. Well whichever way it will be eventually I’d like to move to qt6 probably - though I still prefer the plugin way right now even over qt6 ;-).
Btw for script interface (currently python plugins and pyqt5 are avilable), that would require some thinking or cut if off completely for almost everything 3d related if there’s a native 3d solution since there’s a back breaking bug in pyqt5 in the 3d part it seems. So it would for now either require someone fixing it in pyqt somehow or some custom python bindings to c++ methods to work with the 3d stuff.
