Re: [Bf-committers] Wiki Account
How does that work? Do I just open a new task? Thanks. On Mon, Oct 26, 2020 at 3:45 AM Dalai Felinto via Bf-committers < bf-committers@blender.org> wrote: > Hi Joe, > > Can you use developer.blender.org instead? It is easier to aggregate > feedback, see what changed, ... we reserve the wiki for final designs > mostly. > > -Dalai- > > Dalai Felinto - da...@blender.org - www.blender.org > Blender Development Coordinator > Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands > > Em dom., 25 de out. de 2020 às 02:52, Joe Eagar via Bf-committers > escreveu: > > > > Hi all. I'm just about ready to submit my final proposal for improving > > DynTopo performance. Could someone set me up with a wiki account so I > can > > write a design document? Thanks. > > > > Best, > > Joe > > ___ > > Bf-committers mailing list > > Bf-committers@blender.org > > https://lists.blender.org/mailman/listinfo/bf-committers > ___ > Bf-committers mailing list > Bf-committers@blender.org > https://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Wiki Account
Hi all. I'm just about ready to submit my final proposal for improving DynTopo performance. Could someone set me up with a wiki account so I can write a design document? Thanks. Best, Joe ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] It's time to get rid of cloth
Brecht, you can avoid the worst numerical instability issues of CCD by adding a small repulsion force when cloth is in close proximity with geometry. IIRC most commercial cloth sims do this. Ton, I'm sorry I blew up. Cloth collision is something of a special nightmare for me. Sergej, that's fair. Sebastian, sounds like you're doing good work, just remember that robust collisions are important :) ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] It's time to get rid of cloth
So, ten years ago I wrote several continuous collision detection systems for cloth/hair, one of which I tried to push into trunk: https://www.youtube.com/watch?v=QBM3TBKO9w8 And, here's how the cloth sim performs today: https://www.youtube.com/watch?v=5462m9yEkU8&feature=youtu.be If the cloth development process is this dysfunctional (this patch actually passed review? https://developer.blender.org/rB0666ece2e2f96571200d693d9d7bee1ca72d026f ) then I propose we eliminate the cloth code entirely and go with a third party lib (Bullet?). Joe ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Sculpt Work
Greetings. Recently I've found myself sucked into the sculpt code. I heard talk of removing DynTopo--a tool I absolutely could not live without, and since the problems in the DynTopo code are partly my fault for not properly documenting the design limitations of BMesh I thought I'd help fix it. While I'm at it I'm also going to finally fix some multires bugs I've been meaning to fix for an embarrassing number of years. For those who don't know I headed the BMesh refactor back in the day along with Geoffrey Bantle who wrote the core BMesh api. The two of us never intended for BMesh to be used for anything like high-res sculpting, but unfortunately we never actually wrote that down anywhere in the codebase. This has led to a bit of a mess in the DynTopo code. Anyway, as I see it DynTopo needs two things: * Rip out BMesh. This has actually mostly happened already; DynTopo strictly forces faces to be triangles and reuses very little of the BMesh API opting for its own implementation of topology operations. I've already done this in a branch. * Refactor PBVH/sculpt code to be more maintainable, given the presence of DynTopo. I get the impression that this is a major concern for the sculpt dev team. I plan to make a few proposals here. I'm also going to try and profile CPU cache and branch prediction misses, since this seems to be a problem. Unfortunately I wasn't able to get blender to run in valgrind in a VM, but luckily I have a Linux machine in the house I can set up for the task. Cheers, Joe Eagar ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Commit access for branch
Fun fact, Geoffry designed the mempool library out of a desire to get something that was more like the Mesh structure. Anyway, I'm not terribly wedded to a dedicated trimesh library (it's very basic code with an API based off BMesh). The important non-trimesh-related changes seem to be: 1. Don't set pbvh->leaf_limit too low. 2. Change active sculpt vertex "index" from an int to a generic intptr_t. That drastically cuts down the usage of BMesh element tables, which is a huge performance boost. 3. Attach pointer arrays to PBVHNode->bm_unique_verts, bm_other_verts, to avoid iterating over GHashes. Alternatively, inline the GHash iterators. 4. Support dynamically joining PBVH nodes. 5. Don't use BMLog to cache original vertex/normal data. On Fri, Oct 16, 2020 at 9:33 AM Brecht Van Lommel via Bf-committers < bf-committers@blender.org> wrote: > It's not clear to me that being triangle based only is a good thing about > dynamic topology. It would be better if it preserved ngons and only > triangulated parts of the mesh where actual changes are being made. And > also did not lose vertex colors and UV maps. > > Maybe it's possible to use MVert and MPoly, and find a way to dynamically > grow/shrink the arrays? Then there would be one less special case in the > sculpt code. > > On Wed, Oct 14, 2020 at 10:55 PM Joe Eagar via Bf-committers < > bf-committers@blender.org> wrote: > > > I’ve actually copied the existing DynTopo code for a base, but with a > > triangle mesh lib (with a BMesh like API) instead of BMesh. I’m modifying > > it from there, design is contingent on further profiling (for example, > I’m > > not sure we’ll end up needing the topology update to be multithreaded, so > > far most performance bugs have been cache related). > > > > > > > > On Wed, Oct 14, 2020 at 9:12 AM Dalai Felinto wrote: > > > > > Hi Joe, > > > > > > By the way, could you please put together a design document before you > > > go on with the branch development? This way we can get the design > > > cleared out before you spend your time coding it. > > > > > > Thank you, > > > -Dalai- > > > > > > Dalai Felinto - da...@blender.org - www.blender.org > > > Blender Development Coordinator > > > Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands > > > < > > > https://www.google.com/maps/search/Buikslotermeerplein+161,+1025+ET+Amsterdam,+the+Netherlands?entry=gmail&source=g > > > > > > > > > Em qua., 14 de out. de 2020 às 15:11, Dalai Felinto > > > escreveu: > > > > > > > > Hi Joe, > > > > > > > > It is worth taking a look at this refresh course: > > > > https://wiki.blender.org/wiki/Developer_Intro/Committer > > > > > > > > It goes over format style, branches, test builds, ... > > > > > > > > And welcome back :) > > > > -Dalai- > > > > > > > > Dalai Felinto - da...@blender.org - www.blender.org > > > > Blender Development Coordinator > > > > Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands > > > > > > > > Em qua., 14 de out. de 2020 às 04:10, Joe Eagar via Bf-committers > > > > escreveu: > > > > > > > > > > Thanks, I got it to work. I was just confused. > > > > > > > > > > On Tue, Oct 13, 2020 at 6:11 PM Julian Eisel via Bf-committers < > > > > > bf-committers@blender.org> wrote: > > > > > > > > > > > Hey, > > > > > > > > > > > > People who had commit rights with SVN still have in the Git > > > repository. So > > > > > > you should already/still have them. > > > > > > Nowadays, giving commit rights means adding someone as member to > > the > > > BF > > > > > > Blender project on developer.blender.org < > > > http://developer.blender.org/> > > > > > > -- which you are: > > > > > > > > > > > > https://developer.blender.org/project/?member=PHID-USER-dh5md27jh3dxb57kokls > > > > > > < > > > > > > > > > > > > https://developer.blender.org/project/?member=PHID-USER-dh5md27jh3dxb57kokls > > > > > > >. > > > > >
Re: [Bf-committers] Commit access for branch
I’ve actually copied the existing DynTopo code for a base, but with a triangle mesh lib (with a BMesh like API) instead of BMesh. I’m modifying it from there, design is contingent on further profiling (for example, I’m not sure we’ll end up needing the topology update to be multithreaded, so far most performance bugs have been cache related). On Wed, Oct 14, 2020 at 9:12 AM Dalai Felinto wrote: > Hi Joe, > > By the way, could you please put together a design document before you > go on with the branch development? This way we can get the design > cleared out before you spend your time coding it. > > Thank you, > -Dalai- > > Dalai Felinto - da...@blender.org - www.blender.org > Blender Development Coordinator > Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands > <https://www.google.com/maps/search/Buikslotermeerplein+161,+1025+ET+Amsterdam,+the+Netherlands?entry=gmail&source=g> > > Em qua., 14 de out. de 2020 às 15:11, Dalai Felinto > escreveu: > > > > Hi Joe, > > > > It is worth taking a look at this refresh course: > > https://wiki.blender.org/wiki/Developer_Intro/Committer > > > > It goes over format style, branches, test builds, ... > > > > And welcome back :) > > -Dalai- > > > > Dalai Felinto - da...@blender.org - www.blender.org > > Blender Development Coordinator > > Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands > > > > Em qua., 14 de out. de 2020 às 04:10, Joe Eagar via Bf-committers > > escreveu: > > > > > > Thanks, I got it to work. I was just confused. > > > > > > On Tue, Oct 13, 2020 at 6:11 PM Julian Eisel via Bf-committers < > > > bf-committers@blender.org> wrote: > > > > > > > Hey, > > > > > > > > People who had commit rights with SVN still have in the Git > repository. So > > > > you should already/still have them. > > > > Nowadays, giving commit rights means adding someone as member to the > BF > > > > Blender project on developer.blender.org < > http://developer.blender.org/> > > > > -- which you are: > > > > > https://developer.blender.org/project/?member=PHID-USER-dh5md27jh3dxb57kokls > > > > < > > > > > https://developer.blender.org/project/?member=PHID-USER-dh5md27jh3dxb57kokls > > > > >. > > > > > > > > Cheers, > > > > - Julian - > > > > > > > > > -- > > > > Julian Eisel - jul...@blender.org - www.blender.org > > > > Software Developer > > > > > > > > > On 14. Oct 2020, at 01:25, Joe Eagar via Bf-committers < > > > > bf-committers@blender.org> wrote: > > > > > > > > > > > > > > > Hi. I've been working on the DynTopo code a bit and I'd like a > branch to > > > > > commit my work. Can I get whatever account permissions are needed > for > > > > > this? I promise I won't commit to master. :P > > > > > > > > > > Best, > > > > > Joe Eagar > > > > > ___ > > > > > Bf-committers mailing list > > > > > Bf-committers@blender.org > > > > > https://lists.blender.org/mailman/listinfo/bf-committers > > > > > > > > ___ > > > > Bf-committers mailing list > > > > Bf-committers@blender.org > > > > https://lists.blender.org/mailman/listinfo/bf-committers > > > > > > > ___ > > > Bf-committers mailing list > > > Bf-committers@blender.org > > > https://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Commit access for branch
Thanks, I got it to work. I was just confused. On Tue, Oct 13, 2020 at 6:11 PM Julian Eisel via Bf-committers < bf-committers@blender.org> wrote: > Hey, > > People who had commit rights with SVN still have in the Git repository. So > you should already/still have them. > Nowadays, giving commit rights means adding someone as member to the BF > Blender project on developer.blender.org <http://developer.blender.org/> > -- which you are: > https://developer.blender.org/project/?member=PHID-USER-dh5md27jh3dxb57kokls > < > https://developer.blender.org/project/?member=PHID-USER-dh5md27jh3dxb57kokls > >. > > Cheers, > - Julian - > > -- > Julian Eisel - jul...@blender.org - www.blender.org > Software Developer > > > On 14. Oct 2020, at 01:25, Joe Eagar via Bf-committers < > bf-committers@blender.org> wrote: > > > > > > Hi. I've been working on the DynTopo code a bit and I'd like a branch to > > commit my work. Can I get whatever account permissions are needed for > > this? I promise I won't commit to master. :P > > > > Best, > > Joe Eagar > > ___ > > Bf-committers mailing list > > Bf-committers@blender.org > > https://lists.blender.org/mailman/listinfo/bf-committers > > ___ > Bf-committers mailing list > Bf-committers@blender.org > https://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Commit access for branch
Hi. I've been working on the DynTopo code a bit and I'd like a branch to commit my work. Can I get whatever account permissions are needed for this? I promise I won't commit to master. :P Best, Joe Eagar ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] 2.8 3D Manipulator Design
Ah, these *user* interfaces, I mean. 3D user interface design isn't a skill many people have. Joe On Tue, Aug 23, 2016 at 8:40 AM, Joe Eagar wrote: > Right. I'm rather bad at designing these interfaces myself. That's the > hard part. > > Joe > > On Tue, Aug 23, 2016 at 2:35 AM, Ton Roosendaal wrote: > >> Hi, >> >> Aside of some details, this is what Antony and Julian already have been >> working on. >> The basics is simple, the implications and implementation not - >> especially to achieve top level (and pleasant) interaction. >> >> -Ton- >> >> >> Ton Roosendaal - t...@blender.org - www.blender.org >> Chairman Blender Foundation, Producer Blender Institute >> Support us - join blender.cloud or Blender Dev Fund. >> >> > On 23 Aug 2016, at 10:29, Joe Eagar wrote: >> > >> > Hi all. I had a rather panicky reaction on pursing Autodesk Fusion 360 >> > videos: >> > >> > http://www.autodesk.com/products/fusion-360 >> > >> > Here's a direct link to one of the videos: >> > >> > https://www.youtube.com/embed/KZyjLwKWyOw?rel=0 >> > >> > So! 3D widget interfaces on steroids. I've dome similar stuff in the >> > past, so I thought I'd write up how I went about designing a 3D widget >> API >> > (to fit inside my Blender-derived application architecture). >> > >> > The basic concept is pretty simple, and is a lot like a 2D user >> interface >> > API. You have shapes that live in the 3D viewport (and participate in >> the >> > dependency graph). These shapes have event callbacks (and an "am I >> still >> > alive" method) and can contain other shapes. They also participate in >> the >> > dependency graph. >> > >> > Shapes never store direct pointers to data. References to scene objects >> > and the like are stored as RNA paths. >> > >> > In my implementation shape widgets could not go modal. Instead they >> would >> > invoke modal tool operators, and if necessary insert a temporary DAG >> node >> > to update themselves interactively. For example, a translate >> manipulator >> > widget has a DAG reference to the active object. When it invokes >> > transform, the widget automatically moves as the user expects. >> > >> > One final point. 3D widget user interfaces are remarkably difficult to >> > design, and I don't have a lot of talent for that myself. Before any >> > coding happens, we should solicit proposals from people with 3D UI >> design >> > talent. >> > >> > Anyway, cheers! >> > >> > Joe >> > ___ >> > Bf-committers mailing list >> > Bf-committers@blender.org >> > https://lists.blender.org/mailman/listinfo/bf-committers >> >> ___ >> Bf-committers mailing list >> Bf-committers@blender.org >> https://lists.blender.org/mailman/listinfo/bf-committers >> > > ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] 2.8 3D Manipulator Design
Right. I'm rather bad at designing these interfaces myself. That's the hard part. Joe On Tue, Aug 23, 2016 at 2:35 AM, Ton Roosendaal wrote: > Hi, > > Aside of some details, this is what Antony and Julian already have been > working on. > The basics is simple, the implications and implementation not - especially > to achieve top level (and pleasant) interaction. > > -Ton- > > > Ton Roosendaal - t...@blender.org - www.blender.org > Chairman Blender Foundation, Producer Blender Institute > Support us - join blender.cloud or Blender Dev Fund. > > > On 23 Aug 2016, at 10:29, Joe Eagar wrote: > > > > Hi all. I had a rather panicky reaction on pursing Autodesk Fusion 360 > > videos: > > > > http://www.autodesk.com/products/fusion-360 > > > > Here's a direct link to one of the videos: > > > > https://www.youtube.com/embed/KZyjLwKWyOw?rel=0 > > > > So! 3D widget interfaces on steroids. I've dome similar stuff in the > > past, so I thought I'd write up how I went about designing a 3D widget > API > > (to fit inside my Blender-derived application architecture). > > > > The basic concept is pretty simple, and is a lot like a 2D user interface > > API. You have shapes that live in the 3D viewport (and participate in > the > > dependency graph). These shapes have event callbacks (and an "am I still > > alive" method) and can contain other shapes. They also participate in > the > > dependency graph. > > > > Shapes never store direct pointers to data. References to scene objects > > and the like are stored as RNA paths. > > > > In my implementation shape widgets could not go modal. Instead they > would > > invoke modal tool operators, and if necessary insert a temporary DAG node > > to update themselves interactively. For example, a translate manipulator > > widget has a DAG reference to the active object. When it invokes > > transform, the widget automatically moves as the user expects. > > > > One final point. 3D widget user interfaces are remarkably difficult to > > design, and I don't have a lot of talent for that myself. Before any > > coding happens, we should solicit proposals from people with 3D UI design > > talent. > > > > Anyway, cheers! > > > > Joe > > ___ > > Bf-committers mailing list > > Bf-committers@blender.org > > https://lists.blender.org/mailman/listinfo/bf-committers > > ___ > Bf-committers mailing list > Bf-committers@blender.org > https://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] 2.8 3D Manipulator Design
Hi all. I had a rather panicky reaction on pursing Autodesk Fusion 360 videos: http://www.autodesk.com/products/fusion-360 Here's a direct link to one of the videos: https://www.youtube.com/embed/KZyjLwKWyOw?rel=0 So! 3D widget interfaces on steroids. I've dome similar stuff in the past, so I thought I'd write up how I went about designing a 3D widget API (to fit inside my Blender-derived application architecture). The basic concept is pretty simple, and is a lot like a 2D user interface API. You have shapes that live in the 3D viewport (and participate in the dependency graph). These shapes have event callbacks (and an "am I still alive" method) and can contain other shapes. They also participate in the dependency graph. Shapes never store direct pointers to data. References to scene objects and the like are stored as RNA paths. In my implementation shape widgets could not go modal. Instead they would invoke modal tool operators, and if necessary insert a temporary DAG node to update themselves interactively. For example, a translate manipulator widget has a DAG reference to the active object. When it invokes transform, the widget automatically moves as the user expects. One final point. 3D widget user interfaces are remarkably difficult to design, and I don't have a lot of talent for that myself. Before any coding happens, we should solicit proposals from people with 3D UI design talent. Anyway, cheers! Joe ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Current state of Blender's user experience (Ton Roosendaal) (Sybren A. St?vel) (Ton Roosendaal)
> I often get mails from professionals who say "nice job on Blender, but..." > and then come with a list of favourite Maya or Max features. This might be > an acceptable consumer attitude towards commercial software, but it's very > not helpful for a public open source project. Dynamics here work > differently, it's not based on market shares or consumer satisfaction, it's > based one time and energy - contributions. Oh really? Care to explain? I find such feedback incredibly helpful. I think you're making the mistake of thinking that if a user wants something, he should get it now. That's just silly. I'm perfectly happy to take a commercial user's input, and factor it into my medium and long-term thinking. An example of that is superknife, which I designed as a hybrid of two different commercial package's knife tools. It took years for BMesh to reach a state where I could implement it. Geoffrey Bantle thought the same way, which is why the BMesh data structure he designed is so flexible and yet simple to work with; it's meant to cover all an enormous number of use cases (except cad, which requires holes in polygons; both of us were too intimidated to attempt it at the time). We loved getting ideas from commercial software and the users of that software. Of course, given the human tendency to turn every public conversation into a flame war over "which is normatively better, my tribe--erm, I mean app--or yours?", most of these conversations happened semi-privately on IRC or through email, and occasionally the main developers list. I love feedback. Feedback is wonderful. Software development is an incredibly complicated constrained optimization process. Feedback helps you prioritize goals. It doesn't have to be implemented immediately; in fact it can take years, and I think that's okay. I'd much rather have knowledge I cannot act on now, then live in ignorance until I have the means to implement said knowledge. When I finally do implement it, I'll have had years to think about it. Cheers, Joe On Tue, Apr 26, 2016 at 6:34 AM, Thomas Dinges wrote: > It's Ton, not Tom. ;) > > Am 26.04.2016 um 15:23 schrieb David Ballesteros: >> Hi Sybren, >> >> It's simply crossed to me as a too much white & black answer, nothing else. >> I just read Tom new answer and I understand his original answer. >> So all is good. >> >>> You don't appear like an avid hater, so why do you feel he is addressing >> you? >>> Cheers, >>> -- >>> Sybren A. St?vel >> - >> Hi Tom, >> >> Thanks for the welcome and the answer. >> Now I understand much better your points. >> >> I'm very glad to read you're open to suggestions form "commercial" software >> users. >> >> A simple argument can be used to those users that want feature X in Blender >> is asking them how many features suggested by them got implemented on their >> commercial X software. ;) I know several of mine were completly ignored in >> LW and Modo :D >> >>> My expectation was that we could use the dynamics of the 2.8 project to >> include that target. >>> But I'm still not convinced we are ready for it now. The project is too >> complicated, with too >>> many inactive stakeholders and not enough active contributors. But we >> make progress here... >> >> I read the document you attached yesterday, and I'm very glad to see where >> is going, and I guess you mean it was for the 2.8 branch and still under >> disscusion if it oges or not?. >> >> I liked the consolidation explained area by area, that will really >> streamline Blender and make it even better. >> >> I still have a lot to read on Blender internals to even know where to start >> to touch without breaking anything :) I'll try to do my best. >> >> To the OP (Daniel): >> I read that reddit thread, and I think better ignore it. Too much energy >> spent in a discussion that doesn't take anywhere. >> >> Cheers >> David. >> >> Message: 6 >>> Date: Tue, 26 Apr 2016 11:17:51 +0200 >>> From: Ton Roosendaal >>> Subject: Re: [Bf-committers] Current state of Blender's user >>> experience (Ton Roosendaal) >>> To: bf-blender developers >>> Message-ID: <667e96f1-d629-4e04-9389-774609ed1...@blender.org> >>> Content-Type: text/plain; charset=us-ascii >>> >>> Hi David, >>> >>> Thanks for sharing, I just addressed the Blender haters out there, not >>> users of other 3d tools. >>> >>> It is great that there are so many people involved with our projects who >>> used (or still use) commercial 3d software as well. We can learn from them, >>> especially because they were curious enough to invest time to figure out >>> how to use Blender, or what makes Blender good (enough to use) as well. >>> >>> So please feel welcome to hangout, help developers with their work or >>> contribute code. >>> >>> I often get mails from professionals who say "nice job on Blender, but..." >>> and then come with a list of favourite Maya or Max f
Re: [Bf-committers] Google Summer Of Code: UV - Tools
I had an embarrassing moment last year when trying to help a coworker
find a feature in Blender's UV editor. It. . .no longer existed. We
definitely need some work done here. One thing that absolutely drove
her insane was the inability to hide UV islands without altering the
mesh selection state. That was a big deal for her.
It might be worth concentrating on improving the UI workflow and not
spend too much time on new unwrapping features.
Best,
Joe
On Mon, Mar 21, 2016 at 10:28 AM, Phil Gosch wrote:
> Hey again!
>
> I just submitted/shared my proposal via the GSOC form and would love to get
> some feedback from possible mentors, seasoned devs and Ton of course. As
> usual I'm also available via IRC.
>
> I'd especially be interested in what specific improvements to the Unwrap
> algorithm ("Improved automatic UV Layout") the mentors had in mind when
> writing the ideas page as well as general feedback regarding the proposal.
>
> Thanks in advance and best wishes,
> Phil
>
>
>
> Am 13.03.2016 um 12:49 schrieb Phil Gosch:
>> Hey everybody!
>>
>> My name is Phil Gosch, I'm from Graz University of Technology and I'm
>> interested in the "UV Editing Tools" GSOC project.
>> I'd be very happy to realize this project and wanted to get some
>> help/tipps or hints beforehand, that's why I'm writing this mail.
>>
>> About me: I'm a long time Blender user and active member of the Blender
>> community. Besides university I'm working as a 3D/Technical Artist
>> freelancer, where I'm mostly doing illustrations, visualizations
>> including custom tool development and gameart/gamedev. You can have a
>> look at my portfolio at my homepage [0] or at my Blender Network profile
>> [1].
>>
>> As someone who uses Blender as his main tool on a daily basis I know the
>> UV Editor (and its shortcomings) and because of that fact I not only
>> think I'm fitting for this project but I also have a great personal
>> interest in improving these tools. I'm no complete stranger to Blender
>> core coding, I already had some of my patches applied to trunk a few
>> years ago. Of course the codebase is changing all the time, that's why
>> I'm already getting familiar with the codebase again. I already compiled
>> the newest Blender version and I'm spending my free time reading
>> uvedit_*.c files. ;)
>>
>> I think the outline presented at the ideas page [2] makes sense, however
>> while writing my proposal I found that I liked the idea of trying to
>> convert some of the useful UV python scripts I'm using to C code (I'm
>> sure people have lots of scripts they use which I don't even know
>> about). So if you use a python addon for the UV tools and would like me
>> to consider it for inclusion into my proposal, please let me know by
>> answering to this mail. :)
>>
>> If any of the potential mentors (Bastien, Campbell, Howard) have some
>> useful input I'd be very thankful! Also if anyone could have a look at
>> my proposal before submitting that would be great! It's not finished
>> yet, but you can poke me anytime on IRC/blendercoders, I'm always
>> lurking there. My IRC nick is "saphires".
>>
>> Best wishes,
>> Phil
>>
>> [0] http://www.saphirestudio.at/
>> [1] https://www.blendernetwork.org/phil-gosch
>> [2] http://wiki.blender.org/index.php/Dev:Ref/GoogleSummerOfCode/2016/Ideas
>>
>> PS: Sorry if this mail shows up twice, there was an error when I first
>> tried sending it
>>
>
> --
> pixel-pusher at saphirestudio.at
>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] GSoC 2016 Preliminary proposal to optimize the memory usage of mesh undo
Editmode undo is different than global undo, remember. This, people, is an awesome idea. I've used Blender's tool operator in three major projects (one of which is commercial) and I made exactly this modification. Why should the transform tool copy the whole mesh? Or the select tool? It's not necessary. Here's the source code for my design: https://github.com/joeedh/fairmotion/blob/master/src/core/toolops_api.js Here's one of the comments in that file: /* basic design of tool ops: inspired by Blender's tool system. each tool has a list of parameters, and are also passed a Context struct (a sort of bundle of common tool parameters). The main difference is that undo is implemented on top of this system. Tools that do not implement undo callbacks will trigger a complete copy of the data state. This is to get new tools up and running quickly; all tools should eventually get their own, faster callbacks (or at least inherit from super-classes with faster defaults, like SelectOpAbstract). Note that for some tools, serializing the app state prior to undo is unavoidable. RULES: 1. Tools must store all (non-undo) state data in slots. 2. Tools cannot access ANYTHING RELATED TO THE UI within exec. This is to ensure tool repeatability, and maintain the integrity of the undostack (which doesn't store things like viewport pans). 3. ToolProperty subclassess MUST NOT STORE REFERENCES (except to basic types like strings, ints, etc). Rather, they must store a value to lookup an object: * DataRef structures for DataBlocks (ASObject/Mesh/Scene/etc) * integers for Mesh element subtypes (Vertex/Edge/Loops/Face). */ On Sat, Mar 5, 2016 at 8:27 PM, Campbell Barton wrote: > On Sat, Mar 5, 2016 at 8:19 PM, Ounan Ding wrote: >> Hi, >> >> I am Ounan Ding(IRC: TheBusyTypist). >> I am interested in Blender and willing to contribute to our community in >> the coming GSoC 2016. >> >> Here is my preliminary proposal to optimize the memory usage of mesh undo: >> >> >> https://github.com/thebusytypist/gsoc-2016-doc/raw/master/proposals/mesh-undo-memory/mesh-undo-memory.pdf > > Checked over the document, one thing which isn't quite correct is the > statement that... > > "The current strategy is that the whole mesh data get duplicated and > restored > on the undo command" > > ... in fact each chunk of memory is compared and only stored if there > are differences, > though this is inefficient when making destructive changes to the mesh > (subdivision for example), > it does mean changing selection won't have to store UV's, weights, > shape-keys etc. > > One possible optimization would be to implement binary diffing, so > minor differences to large allocates don't have to store the entire > block each time. > >> (and I put it on wiki.blender.org as well: >> http://wiki.blender.org/index.php/User:TheBusyTypist/GSoC2016-Mesh-Undo-Memory >> But I suggest to read above pdf version since it has better typesetting) >> >> I have a review of current implementation here: >> http://blender.linearconstraints.net/2016/02/28/notes-on-undo.html >> It helps me form this proposal. >> >> I also have some notes and practice on the Blender Operator system: >> http://blender.linearconstraints.net/2015/03/28/write-first-blender-operator.html >> http://blender.linearconstraints.net/2015/04/01/analyze-primitive-cube-add-operator.html >> which lead me to the design in my proposal. >> >> Currently I am still working on more strategies for specific Operators. >> I am also looking forward to commends and critiques from you. >> >> Thank you. >> ___ >> Bf-committers mailing list >> Bf-committers@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers > > > > -- > - Campbell > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
