<div class="gmail_quote">On Thu, Sep 24, 2009 at 10:44 PM, Moritz Moeller <span dir="ltr"><<a href="mailto:realritz@virtualritz.com">realritz@virtualritz.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On 09/20/2009 08:48 PM, Boudewijn Rempt wrote:<br>
> On Saturday 19 September 2009, Moritz Moeller wrote:<br>
><br>
>> There is another few posts of mine, in the archives (from 2007, I<br>
>> think), where I already tried advertising these approaches. Might help<br>
>> digging the resp. thread out, to understand better where I'm coming from.<br>
>> :)<br>
><br>
> The big problem with this is that it would be a wonderful project, but going<br>
> this way simply means starting completely from scratch. Nothing in the current<br>
> krita codebase will be at all useful (well, maybe some color selectors...).<br>
<br>
</div>I think "from scratch" is exaggerating greatly. I made two propsals. One<br>
is for a node based core.<br>
The other was for procedural bushes.<br>
Neither requires the other to be implemented. Procedural brushes bring<br>
many advances, even w/o a node-based core.<br></blockquote><div><br>I think the "from scratch" was targeted at you reyes proposal.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
As for the latter. This would indeed mean replacing the core with a node<br>
system. I don't know how well abstracted interaction of the core is, for<br>
any part of Krita making use of it.<br>
But if it was abstraced sufficiently, replacing the core and providing<br>
backwards compatibility to keep a big chunk of the exisiting code that<br>
is non-core, should be possible.<br>
Because a layer baed system can easily be expressed in a node-based system.<br>
The reverse is btw not true. Photosop tries hard these days, having now<br>
smart-objects and cascaded layer groups. But this is still far from the<br>
flexibility of a node based system.<br><div class="im"></div></blockquote><div><br>It's always the question how much you want expose the node system to the user. Some users might be overwhelmed by it.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">
> And I know that I lack the skills to setup such a project and get it anywhere<br>
> meaningful :-(<br>
<br>
</div>Which one? Node-based core or procedural brushes. I can help out with<br>
how to implement these. I am really sorry that I don't have more time, I<br>
would love to write a reference implememtation of procedural brushes at<br>
least.<br>
<br>
I can also assure you that neither is any harder to implement than<br>
anything Krita does currently. :)<br>
A node based core is cretainly a lot of work. Really a lot. Procedural<br>
brushes aren't<br></blockquote></div><br>Editing draw strokes might be nice if you do it like MyPaint only for the last stroke. It gets more complicated to use if you want to modify single path points, just try to modify a calligraphy stroke in Karbon.<br>
<br>Saving the path would get a possible maintainance problem as future paintops have to work in the same way to keep the image looking the same. If you send someone a picture he needs all the paintops you used to create your image, so you would have to included the whole image as fallback.<br>