Re: [Bf-committers] Wiki Account

[Joe Eagar via Bf-committers]

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

[Joe Eagar via Bf-committers]

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

[Joe Eagar via Bf-committers]

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

[Joe Eagar via Bf-committers]

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=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

[Joe Eagar via Bf-committers]

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

[Joe Eagar via Bf-committers]

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=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
> > > > > > >.
> > > > > >
> > > > > &g

Re: [Bf-committers] Commit access for branch

[Joe Eagar via Bf-committers]

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=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

[Joe Eagar via Bf-committers]

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

[Joe Eagar via Bf-committers]

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

[Joe Eagar]

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 <joe...@gmail.com> 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 <t...@blender.org> 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 <joe...@gmail.com> 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

[Joe Eagar]

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 <t...@blender.org> 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 <joe...@gmail.com> 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

[Joe Eagar]

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)

[Joe Eagar]

> 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 <blen...@dingto.org> 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 <t...@blender.org>
>>> Subject: Re: [Bf-committers] Current state of Blender's user
>>> experience (Ton Roosendaal)
>>> To: bf-blender developers <bf-committers@blender.org>
>>> 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
>>&g

Re: [Bf-committers] Google Summer Of Code: UV - Tools

[Joe Eagar]

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 <p...@saphirestudio.at> 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

[Joe Eagar]

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

Re: [Bf-committers] [Bf-blender-cvs] [bfea087] master: Alternate fix for offscreen render w/o npot

[joe]

Thanks for doing this properly.  Screen space AO still doesn't quite
work right; I've opened a bug report for it:

https://developer.blender.org/T46105

Joe
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Lack of coordination and communication in Blender development

[joe]

On Sat, Aug 15, 2015 at 12:49 PM, Kai Kostack kaikost...@gmx.net wrote:
 Hello Martijn, hello Antony,

 I'd like to emphasize that I have great respect for every person involved 
 with Blender development. I'm following the mailing lists more or less since 
 2004 and I remember often core redesign took place only within a small group 
 of people and not so much in public.

This isn't always a bad thing, though. As developers, it's our job to
do what the wider Blender community *needs*, and sometimes that
conflicts with what it *wants*.  The mesh refactor and the debate over
ngons was a perfect case of this: a lot of people were disturbed by
the idea of supporting ngons in Blender.  This never bothered me, nor
did it bother other senior developers. We knew the users would come
around in the end, so we simply went ahead and did it anyway.

I do agree that Blender needs a better way to coordinate tasks between
developers, but I don't think a big open process is the answer.
That's what nearly killed Gimp.  Part of this is Blender's lack of
modularization compared to other 3D software, which is what the
current redesign effort is aimed at.  A more modular/graph-based
design will make it a lot easier to implement features without
stepping on other people's toes.


 Scorpion81 and me will take care of a list of the requirements. We don't even 
 expect guarantees, we only would like to make sure our interests are not 
 overlooked this time and at least being considered.

This tends to be a time constraint problem more than anything else.
The best thing to do is to keep reminding people you exist, so they'll
keep you in mind.


 Above that I really think the interaction between core devs, hobby devs and 
 users could use improvement in this regard.

 Thank you so far.


Best,
Joe
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Implicit Surface Nodes

[joe]

Hi all.  I've been working on a pynode proof-of-concept for an
implicit surface node system (basically, node-based metaball
surfaces).

This network:
http://www.pasteall.org/pic/91966

Produced this surface:
http://www.pasteall.org/pic/91967

It's a little hard to read the network since I've not finished group
nodes yet (which I plan on using to implement higher-level, more
artist-friendly nodes).  Basically, all it's doing is calculating a
(crude) metaball cube, using perlin noise to warp the domain space.
The nodes are designed to form extremely simple symbolic expression
trees, the idea being to generate code for a GPU marching cubes
tessellator.  These trees are designed to be symbolically
differentiated; you can see a 'Scalar Derivative' node in that
network, it does not use finite differences.

I'll be publishing the code soon (everything is done in python as an
add-on).  I still need to work out the details of how these nodes will
be tied to scene objects, and I don't have a working implementation
yet of the fancy marching cubes algorithm (dual grid) you use for
hard-edged objects ( :( ).  Anyway, I just thought I'd share.

Best,
Joe
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Is anyone working on the UV editor?

[joe]

Hi, is anyone working on the UV editor?  If not, I might take a crack at
it.  One of my coworkers was having a hard time with it (I think we've had
some regressions here). I'm going to try and put together a workflow
improvement document, try and work out some usability problems she ran into.

I haven't gotten approval to do this as a work project, so I'll be working
on this at home, for now.

Thanks,
Joe
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender developers meeting notes - August 2, 2015

[joe]

Who's doing the viewport optimization work?  I have some experience here.
The key thing is to limit OpenGL commands, and also the data sent per-frame
to the GPU.  It might also be a good idea to move the simpler deform
modifiers into vertex shaders (and make sure to use a node system--it's
actually easier to use a DAG system than to try and code all the edge cases
by hand).



On Sun, Aug 2, 2015 at 9:16 AM, Ton Roosendaal t...@blender.org wrote:

 Hi all,

 Here are the notes from today's meeting in irc.freenode.net
 #blendercoders.

 1) Upcoming 2.76 release

 - OpenSubdiv: an essential fix was made by the Pixar team, we we can move
 on. (3.0.1 will be out soon).
 Unfortunately 3.0 has no UV texture support yet, will be in 3.1 later this
 year.

 For that reason Sergey will add it as optional choice, mainly for
 animation editing and playback
 in viewport.

 - Still waiting for a short document outlining the viewport Mesh
 performance work.

 - Reminder: anyone who wants to add something that affects users or other
 developers (APIs):
 always make a nice doc! *Before the commit* Even when you think it's not
 interesting (like optimizing).
 Blender work is interesting to share by default! :)

 - Due to holidays (2+ weeks absence of several core devs) we also extend
 the 2.76 with two weeks.

 - Current projects and planning:
 http://wiki.blender.org/index.php/Dev:Doc/Projects

 - Splash: suggested is to do a public contest in BA forums again. Still
 need a proposal for
 who will do the judging... and would we do a theme again? Tradition is to
 have the previous
 team/panel who selected a splash appoint the next. I'll ask the artists
 here to propose something.

 - Kevin Dietrich: OpenVDB patch is still waiting for review. There are
 also two (small) Cycles
 features using OpenVDB ready. The platform maintainers have to check on
 inclusion of new libs though.

 Check this:
 http://wiki.blender.org/index.php/User:Kevindietrich/OpenVDBRendering
 And this:
 http://wiki.blender.org/index.php/User:Kevindietrich/OpenVDBSmokeExport

 Laters,

 -Ton-

 
 Ton Roosendaal  -  t...@blender.org   -   www.blender.org
 Chairman Blender Foundation - Producer Blender Institute
 Entrepotdok 57A  -  1018AD Amsterdam  -  The Netherlands



 ___
 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] Blender 2.8 - the Workflow release

[joe]

I've used blender design concepts in three projects now; the All-Shape
WebGL modeller I demoed at SIGGRAPH a year or two back, a proprietary
product my company hired me to write, as well as, perhaps ironically, a 2D
vector graphics project of mine (https://github.com/joeedh/fairmotion).

I've put together a few notes on what I've learned:

1. Tool operators

I used Blender's tool operator system as a starting point in three large
projects.  The big change I made was making tool operators responsible for
undo.  This isn't as terrible as it sounds; most tools inherit their
handlers from parent classes.  The root tool operator class has a crude
implementation itself (it saves the entire application state), so there is
no danger of a tool missing undo callbacks.

2. RNA pointers

I ended up using full RNA paths instead of using something like the
PointerRNA struct.  I use RNA paths a lot; in JavaScript it's important to
avoid hanging references (it leaks memory), and RNA paths are a handy way
to store a reference to an object without actually referencing it.

3. Library block system

Interestingly, I found that Blender's Library block architecture is even
more suited for dynamic, garbage collected languages like JS than C.  The
kind of bugs it is designed to prevent do not produce crashes in JS; no no
no, they merely corrupt the application state in a fundamental, but
insidiously invisible manner.  Things seem perfectly fine and dandy, until
you try saving the file or executing an undo.

4. 3D manipulator objects / DAG Actors

Combining the Actor model with a DAG dependency graph is great for 3D
manipulator widgets.  It really opens a lot of cool 3D UI possibilities.
The basic idea that one has special, temporary DAG nodes, that insert
themselves into the scene in the right contexts (e.g. a move array if an
object is selected) then remove themselves when they are no longer needed
(or if they scene objects they refer to no longer exist).

5. Material Nodes

5.1 Multi channel mix node

I found this incredibly useful.  The basic idea is to have a mix node with
multiple channels, where you can add/remove/sort the channels.  It made my
shaders a lot simpler.

5.2 B-spline curve nodes

I found B-splines were much easier to work with than the normal piecewise
bezier splines.  It is a bit more complicated, since you have to compile
optimized GLSL code at runtime (de Boor's formula can be incredibly slow if
one implements it naively).



Anyway, I hope some of this is useful.
Best,

Joe
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] An easy to use damped spline

[joe]

Do you have a link to a paper?
On Sep 28, 2014 10:45 AM, Fred f.hartho...@ziggo.nl wrote:

 Hi Campbell Barton,

 The amount of interpolation dots is 2^i, at the start of the demo  i =
 4(16 dots)
 if you change i = 7 (the limit in the demo) than there are 128
 interpolation dots.

 if I had set the limit in the demo to 10 then 1024 interpolation dots
 was possible.

 If the spline is used in a 3 dimensional space,
 to compute an interpolated dot position takes:  dim * 10  clock cycles =
 30 clock cycles.
 I hope that it is fast enough.

 If you like to have a curve to the last plotted dot you have to put two
 dots on each other at the end.
 You will see that it is symmetrical again.

 Please change the number to 7 in the demo and you see a curved line in
 stead of dots.

 Much more is possible with this spline because the first, second and
 third derivative (parameterized ) of the curve
 is available in real time.

 I think that much more can be invented with this spline technique.
 I think that with some research tangent handles can be constructed as
 well (if you like them?).
 What I did in the demo was the most simple way of using it.

 The essence is: a 3th degree curve in two (x,y) or more directions is
 differentiated three times, and then again integrated 3 times.
 With floating point this is impossible , because it is not exact, the
 curve runs away.
 But with integer computing it is exact and the spline exact a 3th degree
 curve.

 It can also be used in ten or more directions, but more then 3
 dimensions (x,y,z) is not  practical.

 Fred.
 --
 Fred schreef op 28-9-2014 om 18:30:
  That is in the demo the case, because I programmed that  the first plot
  point is actually two points.
  the spline uses 4 points p0, p1, p2, p3  and the interpolation is
  between p1 and p2.
 
  Campbell Barton schreef op 28-9-2014 om 17:42:
  Checked the test application, and not sure if this is intended but a
  simple triangle has uneven distribution.
 
  see: http://www.graphicall.org/ftp/ideasman42/fred_curve.png
 
  On Mon, Sep 29, 2014 at 1:32 AM, Dan McGrath danmcgrath...@gmail.com
 wrote:
  Cool, got them. Will take a look later. o/
 
  Dan
 
  On Sun, Sep 28, 2014 at 11:28 AM, Fred f.hartho...@ziggo.nl wrote:
 
  Ok, It is uploaded to the directory incoming
 
  Dan schreef op 28-9-2014 om 17:15:
  You could always upload it to our anonymous ftp via
 download.blender.org
  (or ftp.blender.org) and put it into the incoming directory (use
 passive
  mode). From there was can fetch the files via
  http://download.blender.org/ftp/incoming/
 
  Dan
 
  On Sun, Sep 28, 2014 at 11:05 AM, Fred f.hartho...@ziggo.nl wrote:
 
  Campbell Barton
 
  I have tried to send it but it is rejected. So send me an addres for
  upload.
 
  fred
 
 
  Campbell Barton schreef op 28-9-2014 om 16:51:
  Could the project files be posted to a public URL?, Id like to be
 able
  to look into this. but probably wont have time over the coming
 weeks.
 
  The main source file compiles for me with minor edits on
  Linux/FreePascal, but the demo relies on `Window` unit, which I
 assume
  is provided by delphi/windows.
 
  On Mon, Sep 29, 2014 at 12:36 AM, Dan McGrath 
 danmcgrath...@gmail.com
  wrote:
  Hey,
 
  Just save out the delphi project and zip it up and email it to me
  direct
  via email I guess (the mailing list wouldn't allow such a large
  attachement). I was attempting to compile it on linux, so the
 compiled
  dll's wouldn't be of much use to me unfortunately.
 
  Thanks!
 
 
  Dan
 
  On Sun, Sep 28, 2014 at 10:06 AM, Fred f.hartho...@ziggo.nl
 wrote:
 
  Hi Dan,
 
  Of course I can  send you the project.
  I have made two versions:
  1) The spline is embedded in de demo:
  2) The spline is an external .dll, de demo calls PSpline.dll
 
  Which one do you prefer?
 
  Fred.
  
 
 
 
  Dan McGrath schreef op 28-9-2014 om 15:42:
  So is/was Turbo Pascal (limited in features; eg: objects but no
  classes)
  and FreePascal+Lazarus (supports almost everything Delphi does
  still?
  http://wiki.freepascal.org/Lazarus_For_Delphi_Users).
 
  Anyway, just thought it was neat to see code in pascal (an
 elegant
  language, imho). Curious though, why not just give the whole
 delphi
  project
  and resource files so your forms can be built etc.? The code
 seems
  to
  compile with some modifications here, but without the {$R *.DFM}
  (*.lfm
  in
  fp), one would have to manually rebuild the form :(
 
 
 
  On Sun, Sep 28, 2014 at 8:55 AM, Fred f.hartho...@ziggo.nl
 wrote:
 
  It's true, but Delphi is object oriented.
 
  Dan McGrath schreef op 28-9-2014 om 14:53:
  Standard Pascal, Turbo Pascal, Freepascal, Delphi; same
 language,
  different
  dialect :)
 
  On Sun, Sep 28, 2014 at 8:43 AM, Fred f.hartho...@ziggo.nl
  wrote:
  Actually it is Delphi
 
 
  Dan McGrath schreef op 28-9-2014 om 14:35:
  Pascal, with inline assembler to boot! \o/ :)
 
  On Sun, Sep 28, 2014 at 6:46 AM, Ton 

[Bf-committers] ID Pointer ID Properties

[joe]

The original design for ID Properties had a special ID pointer type, the
idea being that one can have custom properties that point to library
datablocks.  I've found myself needing this recently, when writing a UI for
a custom render interface that stores image textures in materials directly,
not in separate texture blocks.

What do people think?

Joe
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Node link swapping

[joe]

I agree, but I think maybe we should bring it back until the new
implementation. Though it shouldn't be too hard, just an extra flag per
node.
On Apr 14, 2014 3:56 PM, Daniel Salazar - patazstudio.com 
zan...@gmail.com wrote:

 The old behavior was too broad and intrusive, maybe swapping could be
 implemented just in the few cases where it actually makes sense like
 in mix nodes
 Daniel Salazar
 patazstudio.com


 On Mon, Apr 14, 2014 at 4:53 PM, gandalf3 zzyx...@gmail.com wrote:
  I have missed the node connection usability feature which was removed in
  r61178, and I'm convinced that my node workflow is slightly slower than
  it was before.
 
  I have written up a wiki page/request explaining why I think the old
  behavior was faster in most cases. You can find it here:
 
 http://wiki.blender.org/index.php/Dev_talk:Ref/Proposals/UI/Socket_Swapping
 
  And I just want to say how awesome Blender is, and also thanks, for
  keeping Blender going :)
 
  --
  -gandalf3
 
  ___
  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

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Gooseberry VCS?

[joe]

A simple diff tool is certainly possible. In fact, you could probably do it
through py/RNA alone. Of course, patches would be a bit more complicated to
support, but could be doable (through RNA, you couldnt do it by patching
the DNA data itself, not even in a text form, because there is no such
thing as a robust .blend validator)
On Dec 2, 2013 11:42 PM, Nicholas Rishel rishel.n...@gmail.com wrote:

 There used to be a page on blender.org that covered the .blend file
 format.
 Unfortunately it did not make the
 transition
 http://www.blender.org/development/architecture/blender-file-format/to
 the new site and I haven't had the time to check if it exists in the
 wiki. But if my memory serves right it was implied that current design
 would not be hard to translate to readable text - mentioning possible
 benefits of using conventional VCS.

 A working example of this exists with Unity3d which can save .scene files
 as either binary or forced text. I have found this very helpful due to the
 relation between objects in a scene and their associated scripts being kept
 in sync between branches, but I'm not sure whether an analogue for this
 exists in animation pipelines.


 On Mon, Dec 2, 2013 at 8:16 PM, Gavin Howard gavin.d.how...@gmail.com
 wrote:

   Hey all,
 
   Right now, I'm listening to the Blender Podcast Episode 27, talking
  about the upcoming Gooseberry project, with its distributed studio
  requirements. With those requirements in mind, I thought I would again
  bring up a suggestion I made a long time ago.
 
   This suggestion is based on the fact (or myth, whichever is the
 case)
  that blend files are merely a binary dump. Because Gooseberry will
  require coordination with studios across the globe, I think that
  implementing an internal version control system specifically for blend
  files would make it MUCH easier to manage all of Gooseberry's assets.
 
   In my mind (twisted as it may be), I see it using Git-like
 algorithms.
  Because blend files are binary dumps (which as I understand it, means
 that
  each section, or property in the file is separate from the others), it
  would generate diffs based on different sections. For example, say we
 have
  a blend file with a model and a material. The artist takes the file,
  changes the material, and recommits the file. The diff would show that
 only
  the material changed.
 
   Obviously, artists make a lot of changes between uploading, so that
  may not be entirely feasible. However, if we were to add the concept of
  micro-diffs, that might help. In my mind, a micro-diff is ONE change
  only, and a diff would be a list of micro-diffs. (This actually could
 also
  help clean up the undo/redo system too.)
 
   Of course, I have a lot more in mind than I'm saying, but before I
 say
  more, I want to hear devs' opinions. If this is really not feasible, I'm
  fine with that. I know that I don't understand even a sliver of what goes
  on (as demonstrated when I failed this summer in GSoC). But I wanted to
 at
  least get it out there and see what real devs think. Thanks!
 
   Gavin Howard
  ___
  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

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Regarding sticky coordinates removal from blender

[Tai Joe]

I would vote for that we remove it.In my opinion using the UV Project modifier 
is a better workflow.As for the more click argument,  you can use the copy 
attribute menu addon to copy selected modifier. So it actually require fewer 
click.

As for compatibility, people can always download an older build of blender to 
open their file. I know it sound rude. But to me, not to remove a dated feature 
just because many people know how to use it through a dated tutorial doesn't 
make much sense. There are also tutorials out there that teach how to do camera 
mapping using the UV project modifier. So the new user should be fine.

 From: p_boel...@msn.com
 To: bf-committers@blender.org
 Date: Sat, 22 Sep 2012 01:23:52 +0200
 Subject: Re: [Bf-committers] Regarding sticky coordinates removal from blender
 
 
 I agree. If people still use the feature and all removing it does is taking 
 that away and breaking old-file compatibility, I vote we keep it.
 
 -Patrick
 
  Date: Sat, 22 Sep 2012 09:09:38 +1000
  From: mfoxd...@gmail.com
  To: bf-committers@blender.org
  Subject: Re: [Bf-committers] Regarding sticky coordinates removal from  
  blender
  
  My vote is for putting them back, since its clear they are being used, 
  so as long as BI is still being used sticky should remain, just not on 
  bugs associated with it that the feature is no longer developed and will 
  not be fixed. Not to mention its very late in the cycle to be doing this
  
  On 22/09/12 08:34, Campbell Barton wrote:
   @Lockal,
  
   Cameras really shouldn't be scaled - when you scale a camera it won't
   render scaled, so UV project is correct in this case.
  
   On Sat, Sep 22, 2012 at 5:12 AM, Lockal S lockals...@gmail.com wrote:
   Project from view ignores the scale and aspect of camera. Additional
   uv tweaking is needed to match the scale of original image.
  
   The other potential replacement could be adding and applying UvProject
   modifier on the special uv layer, however it distorts uvs in
   perspective mode.
   Can you expand on this? - not sure what you mean.
  
 Also it doesn't take image aspect into account
   (default aspect is (1, 1)). And even after fixing distortion in
   uvproject modifier there are still problems:
   The aspect is 1:1 but its a setting that can be modified. Adding an
   option to use the scenes aspect can be done easily, though it does
   create a tricky dependency (changing scene aspect would need to update
   modifiers).
  
   1) No replacement in do_versions provided
   Since this has been hidden for so long, my assumption was that users
   were not accessing.
  
   2) No changes in documentation and release notes
   Yep. this needs doing.
  
   3) Even then Spacebar menu - Add sticky is easier than going to
   modifiers panel, adding Uv project modifier, setting image, setting
   aspect, setting camera and clicking apply after each geometry change.
   I see your point but dont think its an argument for keeping sticky -
   such a tool can be added as an operator accessible from C, or a macro
   / py script.
   eg - http://www.graphicall.org/ftp/ideasman42/uv_project_apply.py
  
   On Fri, Sep 21, 2012 at 9:32 PM, Nate Wiebe natewieb...@gmail.com 
   wrote:
   Unless I'm missing out on something, using project from view uvs is a
   better solution and works with cycles.
   ___
   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
 
 ___
 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] could this be useful for blender ? opensubdiv

[joe]

I'm not sure I trust the FSF on this; it has a history of exaggerating the
restrictiveness of the GPL.  If we want this library, we should consult a
lawyer to be sure.

This site from 2008, http://www.opensourcelegal.org/?page_id=532 ,
apparently thinks MS-pl is compatible with GPL v3, which I believe would
cover our code (since we have the or any later versions GPL clause).
However, that was written in 2008, and the link to the FSF's website is
dead; not what I would call a reliable source.

Joe

On Tue, Aug 7, 2012 at 1:01 AM, Davis Sorenson davis.soren...@gmail.comwrote:

 According to Wikipedia: (

 http://en.wikipedia.org/wiki/Shared_source#Microsoft_Public_License_.28Ms-PL.29
 )
 According to the Free Software Foundation, it is a free software license
 but not compatible with the GNU GPL. [1]

 So of all the MS shared-source licenses it's the least bad, but still GPL
 incompatible. It looks very cool, apparently it's what Pixar uses in
 production so I imagine it is quite good. :) I noticed this quote from them
 on the project site:
 Feel free to use it and let us know what you think through the github
 site. [2]
 Maybe it would be worth a try to contact them and ask them about using a
 different license?

 [1] http://www.gnu.org/licenses/license-list.html#ms-pl
 [2] http://graphics.pixar.com/opensubdiv

 Davis

 On Tue, Aug 7, 2012 at 1:48 AM, rsaave...@ono.com rsaave...@ono.com
 wrote:

  Hi!,
I have just seen that pixar has released a parallel subdivision
  lib as open software and I was wondering if it would be interesting
  to use it in blender.
 
http://graphics.pixar.com/opensubdiv
 
It is
  released under Microsoft Public License, I haven't read the clausules
  of that license and if it is compatible with GPL, I can guess that it
  is not, but if somebody can ilustrate us ...
 
  --
  Rafael Rios
  ___
  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

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] could this be useful for blender ? opensubdiv

[joe]

On Tue, Aug 7, 2012 at 5:35 AM, Patrick Shirkey
pshir...@boosthardware.comwrote:


 On Tue, August 7, 2012 12:45 pm, joe wrote:
  I'm not sure I trust the FSF on this; it has a history of exaggerating
 the
  restrictiveness of the GPL.

 That's a very strange thing to say about the FSF.


We have history with them.  At one time, user-written scripts and plugins
were not covered by the GPL; now they supposedly are.  That was a very
unpleasant shock given our user base and the promises we had made to them.
At one point we seriously considered ditching the GPL.



   If we want this library, we should consult a
  lawyer to be sure.

 The FSF is pretty much a bunch of Lawyers.


Lawyers who aren't ideological, I mean.



 Then why refer to it? It could be a propaganda site that was built by
 Microsoft to further their agenda.

 It is entirely reasonable to trust the FSF about GPL compatibility
 especially when discussing a Microsoft License as theere is a long history
 of M$ sabotaging projects and the last thing Blender needs is to give
 Microsoft an opportunity to scuttle the ship.


I doubt that.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [41427] branches/bmesh/blender/source/ blender/bmesh/operators/subdivideop.c: subdivide smooth now works as in trunk.

[joe]

Shape keys have normals?

On Mon, Oct 31, 2011 at 10:17 PM, Campbell Barton ideasma...@gmail.com wrote:
 Revision: 41427
          
 http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=41427
 Author:   campbellbarton
 Date:     2011-11-01 05:17:46 + (Tue, 01 Nov 2011)
 Log Message:
 ---
 subdivide smooth now works as in trunk.
 - r35832 joeedh removed this with comment removed the smoothness parameter 
 (which never worked, anyway, even in trunk), not sure I agree here... just 
 because its not perfect doesnt mean its not working, anyway, to support in 
 bmesh at the same level as trunk is not much effort.
 - calculating the coordinates was being done on every shape key, I can see 
 this could be useful to subdiv worked on all shape keys BUT the existing code 
 didnt do this properly, for it to work right the normals would need to be 
 updated for each shape key too when calculating smoothing, so now just 
 calculate the new subdivided location and apply the difference to all other 
 shape keys.

 Revision Links:
 --
    
 http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=35832

 Modified Paths:
 --
    branches/bmesh/blender/source/blender/bmesh/operators/subdivideop.c

 Modified: branches/bmesh/blender/source/blender/bmesh/operators/subdivideop.c
 ===
 --- branches/bmesh/blender/source/blender/bmesh/operators/subdivideop.c 
 2011-11-01 04:31:25 UTC (rev 41426)
 +++ branches/bmesh/blender/source/blender/bmesh/operators/subdivideop.c 
 2011-11-01 05:17:46 UTC (rev 41427)
 @@ -168,74 +168,80 @@
  static void alter_co(BMesh *bm, BMVert *v, BMEdge *UNUSED(origed), const 
 subdparams *params, float perc,
                     BMVert *vsta, BMVert *vend)
  {
 -       float tvec[3], fac;
 -       float *co=NULL, *origco=NULL;
 +       float tvec[3], prev_co[3], fac;
 +       float *co=NULL;
        int i, totlayer = CustomData_number_of_layers(bm-vdata, CD_SHAPEKEY);

        BM_Vert_UpdateAllNormals(bm, v);

 -       origco = CustomData_bmesh_get_n(bm-vdata, v-head.data, 
 CD_SHAPEKEY, params-origkey);
 -       sub_v3_v3v3(tvec, origco, v-co);
 -
 -       for (i=0; itotlayer; i++) {
 -               co = CustomData_bmesh_get_n(bm-vdata, v-head.data, 
 CD_SHAPEKEY, i);
 -               sub_v3_v3(co, tvec);
 +       co = CustomData_bmesh_get_n(bm-vdata, v-head.data, CD_SHAPEKEY, 
 params-origkey);
 +       copy_v3_v3(prev_co, co);
 +
 +       if(params-beauty  B_SMOOTH) {
 +               /* we calculate an offset vector vec1[], to be added to *co */
 +               float len, nor[3], nor1[3], nor2[3], smooth=params-smooth;
 +
 +               sub_v3_v3v3(nor, vsta-co, vend-co);
 +               len= 0.5f*normalize_v3(nor);
 +
 +               copy_v3_v3(nor1, vsta-no);
 +               copy_v3_v3(nor2, vend-no);
 +
 +               /* cosine angle */
 +               fac=  dot_v3v3(nor, nor1);
 +               mul_v3_v3fl(tvec, nor1, fac);
 +
 +               /* cosine angle */
 +               fac= -dot_v3v3(nor, nor2);
 +               madd_v3_v3fl(tvec, nor2, fac);
 +
 +               /* falloff for multi subdivide */
 +               smooth *= sqrtf(fabsf(1.0f - 2.0f*fabsf(0.5f-perc)));
 +
 +               mul_v3_fl(tvec, smooth * len);
 +
 +               add_v3_v3(co, tvec);
        }
 +       else if(params-beauty  B_SPHERE) { /* subdivide sphere */
 +               normalize_v3(co);
 +               mul_v3_fl(co, params-smooth);
 +       }

 +       if(params-beauty  B_FRACTAL) {
 +               float len = len_v3v3(vsta-co, vend-co);
 +               float vec2[3] = {0.0f, 0.0f, 0.0f}, co2[3];
 +
 +               fac= params-fractal*len;
 +
 +               add_v3_v3(vec2, vsta-no);
 +               add_v3_v3(vec2, vend-no);
 +               mul_v3_fl(vec2, 0.5f);
 +
 +               add_v3_v3v3(co2, v-co, params-off);
 +               tvec[0] = fac*(BLI_gTurbulence(1.0, co2[0], co2[1], co2[2], 
 15, 0, 1)-0.5f);
 +               tvec[1] = fac*(BLI_gTurbulence(1.0, co2[0], co2[1], co2[2], 
 15, 0, 1)-0.5f);
 +               tvec[2] = fac*(BLI_gTurbulence(1.0, co2[0], co2[1], co2[2], 
 15, 0, 1)-0.5f);
 +
 +               mul_v3_v3(vec2, tvec);
 +
 +               /*add displacement*/
 +               add_v3_v3v3(co, co, vec2);
 +       }
 +
 +       /* apply the new difference to the rest of the shape keys,
 +        * note that this doent take rotations into account, we _could_ 
 support
 +        * this by getting the normals and coords for each shape key and
 +        * re-calculate the smooth value for each but this is quite involved.
 +        * for now its ok to simply apply the difference IMHO - campbell */
 +       sub_v3_v3v3(tvec, prev_co, co);
 +
        for (i=0; itotlayer; i++) {
 -               co = CustomData_bmesh_get_n(bm-vdata, v-head.data, 
 CD_SHAPEKEY, i);
 -
 -               if(params-beauty  B_SMOOTH) {
 -                       /* 

Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [41293] branches/bmesh/blender/source/ blender/bmesh/intern/bmesh_mesh.c: Disable converting multires to absolute space during bme

[joe]

The correct solution is probably to switch into the highest multires
level before converting to absolute space.

On Wed, Oct 26, 2011 at 5:27 AM, Andrew Wiggin ender7...@gmail.com wrote:
 Revision: 41293
          
 http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=41293
 Author:   ender79
 Date:     2011-10-26 12:27:29 + (Wed, 26 Oct 2011)
 Log Message:
 ---
 Disable converting multires to absolute space during bmesh edits, as this was 
 causing bmesh edits that used absolute space to have no effect on the higher 
 levels of the multires mesh.

 Modified Paths:
 --
    branches/bmesh/blender/source/blender/bmesh/intern/bmesh_mesh.c

 Modified: branches/bmesh/blender/source/blender/bmesh/intern/bmesh_mesh.c
 ===
 --- branches/bmesh/blender/source/blender/bmesh/intern/bmesh_mesh.c     
 2011-10-26 10:49:21 UTC (rev 41292)
 +++ branches/bmesh/blender/source/blender/bmesh/intern/bmesh_mesh.c     
 2011-10-26 12:27:29 UTC (rev 41293)
 @@ -47,15 +47,20 @@
  #include BKE_DerivedMesh.h
  #include BKE_multires.h

 +#include ED_mesh.h
 +
  #include bmesh.h
  #include bmesh_private.h

 -void BME_error(void);
 -
  /*bmesh_error stub*/
  void bmesh_error(void)
  {
 -       printf(BM modelling error!);
 +       printf(BM modelling error!\n);
 +
 +       /* This placeholder assert makes modelling errors easier to catch
 +          in the debugger, until bmesh_error is replaced with something
 +          better. */
 +       BLI_assert(0);
  }

  /*
 @@ -81,7 +86,7 @@

        bm-ob = ob;

 -/*allocate the memory pools for the mesh elements*/
 +   /*allocate the memory pools for the mesh elements*/
        bm-vpool = BLI_mempool_create(vsize, allocsize[0], allocsize[0], 0, 
 1);
        bm-epool = BLI_mempool_create(esize, allocsize[1], allocsize[1], 0, 
 1);
        bm-lpool = BLI_mempool_create(lsize, allocsize[2], allocsize[2], 0, 
 0);
 @@ -144,6 +149,12 @@
        BLI_mempool_destroy(bm-toolflagpool);
        BLI_mempool_destroy(bm-looplistpool);

 +       /* These tables aren't used yet, so it's not stricly necessary
 +          to 'end' them (with 'e' param) but if someone tries to start
 +          using them, having these in place will save a lot of pain */
 +       mesh_octree_table(NULL, NULL, NULL, 'e');
 +       mesh_mirrtopo_table(NULL, 'e');
 +
        BLI_freelistN(bm-selected);

        BMO_ClearStack(bm);
 @@ -378,6 +389,12 @@
  void bmesh_begin_edit(BMesh *bm, int flag) {
        bm-opflag = flag;

 +       /* Most operators seem to be using BMOP_UNTAN_MULTIRES to change the 
 MDisps to
 +          absolute space during mesh edits. With this enabled, changes to 
 the topology
 +          (loop cuts, edge subdivides, etc) are not reflected in the higher 
 levels of
 +          the mesh at all, which doesn't seem right. Turning off completely 
 for now,
 +          until this is shown to be better for certain types of mesh edits. 
 */
 +#if BMOP_UNTAN_MULTIRES_ENABLED
        /*switch multires data out of tangent space*/
        if ((flag  BMOP_UNTAN_MULTIRES)  CustomData_has_layer(bm-ldata, 
 CD_MDISPS)) {
                bmesh_set_mdisps_space(bm, MULTIRES_SPACE_TANGENT, 
 MULTIRES_SPACE_ABSOLUTE);
 @@ -388,9 +405,16 @@
        } else if (flag  BMOP_RATIONALIZE_NORMALS) {
                bmesh_rationalize_normals(bm, 0);
        }
 +#else
 +       if (flag  BMOP_RATIONALIZE_NORMALS) {
 +               bmesh_rationalize_normals(bm, 0);
 +       }
 +#endif
  }

  void bmesh_end_edit(BMesh *bm, int flag){
 +       /* BMOP_UNTAN_MULTIRES disabled for now, see comment above in 
 bmesh_begin_edit. */
 +#if BMOP_UNTAN_MULTIRES_ENABLED
        /*switch multires data into tangent space*/
        if ((flag  BMOP_UNTAN_MULTIRES)  CustomData_has_layer(bm-ldata, 
 CD_MDISPS)) {
                /*set normals to their previous winding*/
 @@ -399,6 +423,11 @@
        } else if (flag  BMOP_RATIONALIZE_NORMALS) {
                bmesh_rationalize_normals(bm, 1);
        }
 +#else
 +       if (flag  BMOP_RATIONALIZE_NORMALS) {
 +               bmesh_rationalize_normals(bm, 1);
 +       }
 +#endif

        bm-opflag = 0;


 ___
 Bf-blender-cvs mailing list
 bf-blender-...@blender.org
 http://lists.blender.org/mailman/listinfo/bf-blender-cvs

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Unlimited clay patch review

[joe]

On Wed, May 25, 2011 at 10:44 AM, Tom M letter...@gmail.com wrote:

 I just went through the entire patch, and it seems like almost half of
 the code in the patch isn't actually used in the patch :)

 Is there a reason so much stuff is commented out or not used anywhere?

 Is it incomplete experiments or something else?

 ie bere are all functions that are in the patch but are never used


Well, I kindof asked for the rough patch.  I wanted to see how it works.

Joe
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [36660] branches/bmesh/blender/source/ blender: rename BMINDEX_GET/SET to BM_GetIndex/BM_SetIndex

[joe]

Thank you.  Much nicer looking in the code.  Those macros have always
bugged me; dunno why it never occurred to me to do this.

On Fri, May 13, 2011 at 4:49 AM, Campbell Barton ideasma...@gmail.com wrote:
 Revision: 36660
          
 http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=36660
 Author:   campbellbarton
 Date:     2011-05-13 10:49:26 + (Fri, 13 May 2011)
 Log Message:
 ---
 rename BMINDEX_GET/SET to BM_GetIndex/BM_SetIndex

 Modified Paths:
 --
    branches/bmesh/blender/source/blender/blenkernel/intern/cdderivedmesh.c
    branches/bmesh/blender/source/blender/blenkernel/intern/editderivedbmesh.c
    branches/bmesh/blender/source/blender/bmesh/bmesh.h
    branches/bmesh/blender/source/blender/bmesh/bmesh_class.h
    branches/bmesh/blender/source/blender/bmesh/intern/bmesh_construct.c
    branches/bmesh/blender/source/blender/bmesh/intern/bmesh_inline.c
    branches/bmesh/blender/source/blender/bmesh/intern/bmesh_polygon.c
    branches/bmesh/blender/source/blender/bmesh/operators/bevel.c
    branches/bmesh/blender/source/blender/bmesh/operators/createops.c
    branches/bmesh/blender/source/blender/bmesh/operators/edgesplitop.c
    branches/bmesh/blender/source/blender/bmesh/operators/mesh_conv.c
    branches/bmesh/blender/source/blender/bmesh/operators/mirror.c
    branches/bmesh/blender/source/blender/bmesh/operators/removedoubles.c
    branches/bmesh/blender/source/blender/bmesh/operators/utils.c
    branches/bmesh/blender/source/blender/editors/mesh/bmesh_select.c
    branches/bmesh/blender/source/blender/editors/mesh/bmesh_tools.c
    branches/bmesh/blender/source/blender/editors/mesh/bmeshutils.c
    branches/bmesh/blender/source/blender/editors/mesh/editface.c
    branches/bmesh/blender/source/blender/editors/mesh/knifetool.c
    branches/bmesh/blender/source/blender/editors/mesh/meshtools.c
    branches/bmesh/blender/source/blender/editors/object/object_vgroup.c
    branches/bmesh/blender/source/blender/editors/space_view3d/view3d_snap.c
    branches/bmesh/blender/source/blender/editors/transform/transform.c
    
 branches/bmesh/blender/source/blender/editors/transform/transform_conversions.c
    branches/bmesh/blender/source/blender/editors/util/crazyspace.c
    branches/bmesh/blender/source/blender/editors/uvedit/uvedit_draw.c
    branches/bmesh/blender/source/blender/editors/uvedit/uvedit_ops.c
    branches/bmesh/blender/source/blender/editors/uvedit/uvedit_unwrap_ops.c
    branches/bmesh/blender/source/blender/modifiers/intern/MOD_array.c

 Modified: 
 branches/bmesh/blender/source/blender/blenkernel/intern/cdderivedmesh.c
 ===
 --- branches/bmesh/blender/source/blender/blenkernel/intern/cdderivedmesh.c   
   2011-05-13 10:37:58 UTC (rev 36659)
 +++ branches/bmesh/blender/source/blender/blenkernel/intern/cdderivedmesh.c   
   2011-05-13 10:49:26 UTC (rev 36660)
 @@ -1915,7 +1915,7 @@
        /* set vert index */
        eve = BMIter_New(iter, bm, BM_VERTS_OF_MESH, NULL);
        for (i=0; eve; eve=BMIter_Step(iter), i++)
 -               BMINDEX_SET(eve, i);
 +               BM_SetIndex(eve, i);

        index = dm-getVertDataArray(dm, CD_ORIGINDEX);

 @@ -1925,7 +1925,7 @@

                VECCOPY(mv-co, eve-co);

 -               BMINDEX_SET(eve, i);
 +               BM_SetIndex(eve, i);

                mv-no[0] = eve-no[0] * 32767.0;
                mv-no[1] = eve-no[1] * 32767.0;
 @@ -1946,10 +1946,10 @@
        for (i=0; eed; eed=BMIter_Step(iter), i++, index++) {
                MEdge *med = medge[i];

 -               BMINDEX_SET(eed, i);
 +               BM_SetIndex(eed, i);

 -               med-v1 = BMINDEX_GET(eed-v1);
 -               med-v2 = BMINDEX_GET(eed-v2);
 +               med-v1 = BM_GetIndex(eed-v1);
 +               med-v2 = BM_GetIndex(eed-v2);
                med-flag = ME_EDGEDRAW|ME_EDGERENDER;

                if (has_crease)
 @@ -1965,7 +1965,7 @@

        efa = BMIter_New(iter, bm, BM_FACES_OF_MESH, NULL);
        for (i=0; efa; i++, efa=BMIter_Step(iter)) {
 -               BMINDEX_SET(efa, i);
 +               BM_SetIndex(efa, i);
        }

        index = dm-getTessFaceDataArray(dm, CD_ORIGINDEX);
 @@ -1974,14 +1974,14 @@
                BMLoop **l = em-looptris[i];
                efa = l[0]-f;

 -               mf-v1 = BMINDEX_GET(l[0]-v);
 -               mf-v2 = BMINDEX_GET(l[1]-v);
 -               mf-v3 = BMINDEX_GET(l[2]-v);
 +               mf-v1 = BM_GetIndex(l[0]-v);
 +               mf-v2 = BM_GetIndex(l[1]-v);
 +               mf-v3 = BM_GetIndex(l[2]-v);
                mf-v4 = 0;
                mf-mat_nr = efa-mat_nr;
                mf-flag = BMFlags_To_MEFlags(efa);

 -               *index = add_orig ? BMINDEX_GET(efa) : 
 *(int*)CustomData_bmesh_get(bm-pdata, efa-head.data, CD_ORIGINDEX);
 +               *index = add_orig ? BM_GetIndex(efa) : 
 *(int*)CustomData_bmesh_get(bm-pdata, efa-head.data, CD_ORIGINDEX);

        

[Bf-committers] need help on vgroup/mdisp allocation

[joe]

A while back, testers of bmesh were complaining of performance issues
related to vgroup and mdisp allocation.  I wrote a temporary fix
(BLI_cellalloc.h/c) but it's too evil for trunk.  The basic problem is
how vgroups/mdisps overuse the system allocator.  The optimal solution
would be to compile with jemalloc on all platforms, but I dunno how
hard that would be (I think Firefox does it).

Anyway, help on other solutions would be great.  MDisps should be
easy; I can add a mempool to CustomDataLayer, and use it for
allocation (though it would touch a lot of code).  Vgroups have a
variable allocation size, however, and I'm unsure how to deal with
them (they really can cause significant performance problems).

Using jemalloc on all platforms might be the best approach, plugged
into guardedalloc.  Integrating something like mempool or memarena in
CustomData is possible, but not ideal (given how much code it would
affect, and how close we are to trunk integration).

Joe
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [36565] branches/bmesh/blender: warning fixes

[joe]

thanks!!

On Mon, May 9, 2011 at 2:20 AM, Campbell Barton ideasma...@gmail.com wrote:
 Revision: 36565
          
 http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=36565
 Author:   campbellbarton
 Date:     2011-05-09 08:20:39 + (Mon, 09 May 2011)
 Log Message:
 ---
 warning fixes

 Modified Paths:
 --
    branches/bmesh/blender/intern/ghost/intern/GHOST_EventManager.cpp
    branches/bmesh/blender/source/blender/blenloader/intern/readfile.c
    branches/bmesh/blender/source/blender/bmesh/intern/bmesh_private.h
    branches/bmesh/blender/source/blender/bmesh/intern/bmesh_structure.c
    branches/bmesh/blender/source/creator/creator.c

 Modified: branches/bmesh/blender/intern/ghost/intern/GHOST_EventManager.cpp
 ===
 --- branches/bmesh/blender/intern/ghost/intern/GHOST_EventManager.cpp   
 2011-05-09 08:15:38 UTC (rev 36564)
 +++ branches/bmesh/blender/intern/ghost/intern/GHOST_EventManager.cpp   
 2011-05-09 08:20:39 UTC (rev 36565)
 @@ -249,7 +249,7 @@
                wm = sys-getWindowManager();
                windows = wm-getWindows();

 -               while (str = fgets(buf, 256, m_playfile)) {
 +               while ((str = fgets(buf, 256, m_playfile))) {
                        GHOST_IWindow *iwin = NULL;
                        GHOST_TEventType type;
                        double time;

 Modified: branches/bmesh/blender/source/blender/blenloader/intern/readfile.c
 ===
 --- branches/bmesh/blender/source/blender/blenloader/intern/readfile.c  
 2011-05-09 08:15:38 UTC (rev 36564)
 +++ branches/bmesh/blender/source/blender/blenloader/intern/readfile.c  
 2011-05-09 08:20:39 UTC (rev 36565)
 @@ -3493,7 +3493,7 @@
                                memcpy(disp2, mdisps[i].disps, 
 MEM_allocN_len(mdisps[i].disps));

                                MEM_freeN(mdisps[i].disps);
 -                               mdisps[i].disps = disp2;
 +                               mdisps[i].disps = (float (*)[3])disp2;
                        }

                        if( (fd-flags  FD_FLAGS_SWITCH_ENDIAN)  
 (mdisps[i].disps) ) {

 Modified: branches/bmesh/blender/source/blender/bmesh/intern/bmesh_private.h
 ===
 --- branches/bmesh/blender/source/blender/bmesh/intern/bmesh_private.h  
 2011-05-09 08:15:38 UTC (rev 36564)
 +++ branches/bmesh/blender/source/blender/bmesh/intern/bmesh_private.h  
 2011-05-09 08:20:39 UTC (rev 36565)
 @@ -51,7 +51,7 @@
  if (bmesh_check_element(bm, el, ((BMHeader*)el)-type))\
                printf(check_element failure, with code %i on line %i in 
 file\n    \%s\\n\n, bmesh_check_element(bm, el, ((BMHeader*)el)-type), 
 __LINE__, __FILE__);

 -#define bm_get_edge_link(e, v) (Link*)((v) == ((BMEdge*)(e))-v1 ? 
 (((BMEdge*)(e))-dlink1) : (((BMEdge*)(e))-dlink2))
 +#define bm_get_edge_link(e, v) (((v) == ((BMEdge*)(e))-v1) ? 
 (Link*)(((BMEdge*)(e))-dlink1) : (Link*)(((BMEdge*)(e))-dlink2))

  int bmesh_radial_length(struct BMLoop *l);
  int bmesh_disk_count(BMVert *v);

 Modified: branches/bmesh/blender/source/blender/bmesh/intern/bmesh_structure.c
 ===
 --- branches/bmesh/blender/source/blender/bmesh/intern/bmesh_structure.c      
   2011-05-09 08:15:38 UTC (rev 36564)
 +++ branches/bmesh/blender/source/blender/bmesh/intern/bmesh_structure.c      
   2011-05-09 08:20:39 UTC (rev 36565)
 @@ -194,7 +194,7 @@
        }

        if (v-e == e)
 -               v-e = e!=e1-next ? (BMEdge*)e1-next : NULL;
 +               v-e = (e != (BMEdge *)e1-next) ? (BMEdge *)e1-next : NULL;

        e1-next = e1-prev = NULL;
  }

 Modified: branches/bmesh/blender/source/creator/creator.c
 ===
 --- branches/bmesh/blender/source/creator/creator.c     2011-05-09 08:15:38 
 UTC (rev 36564)
 +++ branches/bmesh/blender/source/creator/creator.c     2011-05-09 08:20:39 
 UTC (rev 36565)
 @@ -356,7 +356,7 @@
        }
  }*/

 -int segmentation_handler(int sig)
 +void segmentation_handler(int sig)
  {
        char fname[256];

 @@ -372,8 +372,6 @@
        /*induce a real crash*/
        signal(SIGSEGV, SIG_DFL);
        *(int*)NULL = 0;
 -
 -       return 0;
  }

  static int nocrashhandler(int argc, const char **argv, void *data)

 ___
 Bf-blender-cvs mailing list
 bf-blender-...@blender.org
 http://lists.blender.org/mailman/listinfo/bf-blender-cvs

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [36451] branches/bmesh/blender: = bmesh version of prior trunk commit=

[joe]

Here's a patch; either one is probably fine.

On Wed, May 4, 2011 at 2:02 PM, joe joe...@gmail.com wrote:
 It should still confirm on simple click without release_confirm on,
 though.  The two are separate features; one releases on mouse up in
 edge slide itself, while the other allows you to quickly add loopcuts
 without having to cancel out of edgeslide every time (but you might
 not want release_confirm on).

 Still, the patch is certainly a lot simpler and less intrusive.  If I
 keep the OPERATOR_ABORT_MACRO flag, I can probably get rid of the
 timer and launch_event thing (and of course that extraneous user pref)
 and do everything in loopcut.  How's that?

 Joe

 On Wed, May 4, 2011 at 11:17 AM, Campbell Barton ideasma...@gmail.com wrote:
 Heres a patch on r36449 (before this commit) which uses existing
 transform release preference and from what I can tell works ok. (no
 timer, no new preferences, no macro abort option).

 Patch:
 http://www.graphicall.org/ftp/ideasman42/click_release_loopcut_36449.py

 If its acceptable Ill add an RNA function RNA_property_unset() and do
 the ID property adjustment there.

 Joe, Martin - what do you think?

 On Tue, May 3, 2011 at 6:50 PM, joe joe...@gmail.com wrote:
 On Mon, May 2, 2011 at 9:24 PM, Martin Poirier the...@yahoo.com wrote:

 Yes and I happen to think I know those parts of the code (macro, 
 transform) as well if not better than you do.

 :P


 This isn't a nice way at all to solve this problem.


 I saw the nasty hack for manipulators, which  lead me to think I *was*
 doing a nice solution, short of rewriting the entire release_confirm
 functionality.

 Martin
 ___

 Joe
 ___
 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


Index: release/scripts/startup/bl_ui/space_userpref.py
===
--- release/scripts/startup/bl_ui/space_userpref.py	(revision 36489)
+++ release/scripts/startup/bl_ui/space_userpref.py	(working copy)
@@ -795,9 +795,6 @@
 
 sub.separator()
 
-sub.label(text=Loop Cut:)
-sub.prop(inputs, loopcut_finish_on_release)
-
 sub.label(text=Orbit Style:)
 sub.row().prop(inputs, view_rotate_method, expand=True)
 
Index: source/blender/makesdna/DNA_userdef_types.h
===
--- source/blender/makesdna/DNA_userdef_types.h	(revision 36489)
+++ source/blender/makesdna/DNA_userdef_types.h	(working copy)
@@ -383,13 +383,13 @@
 	short autokey_mode;		/* autokeying mode */
 	short autokey_flag;		/* flags for autokeying */
 	
-	short text_render, dsm_maxmem;		/*options for text rendering*/
+	short text_render, pad9;		/*options for text rendering*/
 	float pad10;
 
 	struct ColorBand coba_weight;	/* from texture.h */
 
 	float sculpt_paint_overlay_col[3];
-	int loopcut_finish_on_release;
+	int pad3;
 
 	char author[80];	/* author name for file formats supporting it */
 } UserDef;

Index: source/blender/makesrna/intern/rna_userdef.c
===
--- source/blender/makesrna/intern/rna_userdef.c	(revision 36489)
+++ source/blender/makesrna/intern/rna_userdef.c	(working copy)
@@ -2676,10 +2676,6 @@
 	RNA_def_property_enum_items(prop, view_zoom_axes);
 	RNA_def_property_ui_text(prop, Zoom Axis, Axis of mouse movement to zoom in or out on);
 	
-	prop= RNA_def_property(srna, loopcut_finish_on_release, PROP_BOOLEAN, PROP_NONE);
-	RNA_def_property_boolean_sdna(prop, NULL, loopcut_finish_on_release, 1);
-	RNA_def_property_ui_text(prop, End Loopcut Slide On Release, End Loopcut Slide On Mouse Release, a 'click-drag-and-hold' workflow);
-
 	prop= RNA_def_property(srna, invert_mouse_zoom, PROP_BOOLEAN, PROP_NONE);
 	RNA_def_property_boolean_sdna(prop, NULL, uiflag, USER_ZOOM_INVERT);
 	RNA_def_property_ui_text(prop, Invert Zoom Direction, Invert the axis of mouse movement for zooming);

Index: source/blender/editors/transform/transform.c
===
--- source/blender/editors/transform/transform.c	(revision 36489)
+++ source/blender/editors/transform/transform.c	(working copy)
@@ -1521,9 +1521,7 @@
 	t-mode = mode;
 
 	t-launch_event = event ? event-type : -1;
-	if (RNA_property_is_set(op-ptr, launch_event))
-		t-launch_event = RNA_int_get(op-ptr, launch_event);
-	
+
 	if (t-launch_event == EVT_TWEAK_R)
 	{
 		t-launch_event = RIGHTMOUSE;
Index: source/blender/editors/transform/transform_ops.c
===
--- source/blender/editors/transform/transform_ops.c	(revision 36489)
+++ source/blender/editors/transform

Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [36451] branches/bmesh/blender: = bmesh version of prior trunk commit=

[joe]

On Mon, May 2, 2011 at 9:24 PM, Martin Poirier the...@yahoo.com wrote:

 Yes and I happen to think I know those parts of the code (macro, transform) 
 as well if not better than you do.

:P


 This isn't a nice way at all to solve this problem.


I saw the nasty hack for manipulators, which  lead me to think I *was*
doing a nice solution, short of rewriting the entire release_confirm
functionality.

 Martin
 ___

Joe
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [36451] branches/bmesh/blender: = bmesh version of prior trunk commit=

[joe]

It wasn't in the code, and if it was it wouldn't have worked (the
launch event isn't recorded when edgeslide is executed after loopcut,
so I had to add an RNA property that lets you pass it to transform).

Joe

On Mon, May 2, 2011 at 7:55 PM, Matt Ebb m...@mke3.net wrote:
 On Tue, May 3, 2011 at 11:52 AM, Joseph Eagar joe...@gmail.com wrote:

 I added a new Input user pref, for ending edge slide
 on mouse up after a loop cut.  I can see ton's point on
 the extra strain of click-hold-and-drag workflows. This
 is might only be useful for tablet users.

 I thought this already happened if you have 'drag immediately' on or
 whatever it's called now, I added that behaviour for this reason.

 cheers

 Matt
 ___
 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] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [36451] branches/bmesh/blender: = bmesh version of prior trunk commit=

[joe]

On Mon, May 2, 2011 at 8:52 PM, Martin Poirier the...@yahoo.com wrote:
 I'd also like to see this reverse. For the reasons that Campbell outlined and 
 others.

 Martin

Did you read my reply?

Joe
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Collision for Hair Particles

[joe]

I have CCD code for hair (continuous collision detection) but right now I'm
finishing up bmesh. Collisions should sortof work in trunk though, you might
need to tweak the settings a bit.

Joe

On Wed, Mar 16, 2011 at 5:46 PM, Tobias Oelgarte 
tobias.oelga...@googlemail.com wrote:

 I just noticed that hair particles don't collide with objects anymore.
 Guess they didn't for the whole time in 2.5x. But are there any plans to
 get the collisions back or any documentation on what is the current
 progress? I would be very interested since I'm planning to use a lot of
 hair in the future - but without collisions I will have to stick with 2.49.

 Any hint on how the development goes in this aspect would be nice.

 Greetings from Tobias Oelgarte
 ___
 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] Component Group Proposal

[joe]

I'm bumping this thread, was any consensus ever reached on this topic?

On Thu, Jul 8, 2010 at 2:58 AM, Nathan Vegdahl ces...@cessen.com wrote:

 Hmm... I shouldn't skim threads to quickly.  It seems all my points
 have already been addressed.  In that case, I second the gist of the
 proposal. ;-)

 On Thu, Jul 8, 2010 at 11:56 AM, Nathan Vegdahl ces...@cessen.com wrote:
  I agree with this.  But I'd also like to point out that in complex
  rigging the rigger often also wants to make distinctions that are not
  inherent in the software, as well as associate things that are not
  inherent in the software.  I wouldn't want to be stuck with one set of
  vertex groups that are only for bones, and another that's only for
  particle emission, and another that's only for something else, etc.  I
  may want to make a vertex group serve a dual purpose for a bone weight
  and something else, for example.  Or I might want two armature deform
  modifiers, but operating with different weighting.  Or who knows what.
   Rigging is a crazy thing.
 
  So if we head in this sort of direction, I would rather have a system
  that lets me organize vertex groups myself (perhaps with some sane
  defaults) than a system that enforces upon me distinctions and
  similarities that may not fit how I've constructed a rig.  Maybe
  something like vertex group groups.  Ha ha. ;-)
 
  --Nathan
 
  On Tue, Jun 22, 2010 at 9:45 PM, Daniel Salazar - 3Developer.com
  zan...@gmail.com wrote:
  That proves my point, there is a need for a distinction, and its not
 that
  simple. You would need to also name all your bones starting with RIG
 because
  vgroups are linked to bones by the names
 
  Daniel Salazar
  www.3developer.com
 
 
  On Tue, Jun 22, 2010 at 1:42 PM, Mike Belanger
  mikejamesbelan...@gmail.comwrote:
 
  In current ( 2.49b) to make a distinction between modifier and rigging
 vert
  groups, I just prefix names with RIG or VERT.  Does this help?
 
  On Tue, Jun 22, 2010 at 2:03 PM, Daniel Salazar - 3Developer.com 
  zan...@gmail.com wrote:
 
   Also I want to mention this would help on the tasks of deleting all
  vgroups
   used on an armature without deleting the ones used on hair or similar
   stuff.
   Currently I use a simple py script with an exclusion list for this
   repetitive task. Would be nice if we could do this kind of operations
 for
   the relevant set only
  
   Daniel Salazar
   www.3developer.com
  
  
   On Tue, Jun 22, 2010 at 12:58 PM, Daniel Salazar - 3Developer.com 
   zan...@gmail.com wrote:
  
Yah I mentioned this is a visual separation I'm proposing
and completely optional. A group belonging to one set or another
  woudn't
have any effect on the group's usage all over blender.
   
Daniel Salazar
   
   
   
On Tue, Jun 22, 2010 at 8:49 AM, Brandon Phoenix 
 ktblu...@yahoo.com
   wrote:
   
Hey Daniel,
Just to clarify: Maybe you can expand this concept to include
 Group
Sets? This would be bags of data groups that could
classifyvertes/edges/groups for their usage. Here you're
 essentially
suggesting groups of groups? So that all of the vert groups used
 in
   rigging
are kept separate from, say, the groups used to emit hair etc.?
I'm not sure I agree with this though: example the set of vertex
groups that an specific armature modifier uses should not be
 visually
mixed with the ones that are just used to feed another modifier.
 I
  can
think of cases that it may be beneficial to use the same edge
 group
  for
multiple things. For example, it is often beneficial to seam UVs
 along
   hard
normal edges, so the sharp marked edge group could just be passed
 into
   the
UV set, if that makes sense. Perhaps if it was at the user's
  discretion
   to
separate the group sets. I'll need to speak to matt_e about a UI
implementation of this, because I'm not sure I've seen something
 like
  it
(outside of the outliner). I like the idea though, I'll see what I
 can
   draw
up.
Thanks,
-Brandon Phoenix
(I realized in my initial e-mail, I signed my name Brandon
 Phoenix?.
Oops.)
---Date:
 Sun,
  20
Jun 2010 21:11:04 -0600
From: Daniel Salazar - 3Developer.com zan...@gmail.com
Subject: Re: [Bf-committers] Component Group Proposal
To: bf-blender developers bf-committers@blender.org
Message-ID:
aanlktilmavqrurz6nq-m4g2os-n4hwy58bdurxsk6...@mail.gmail.com
 
Content-Type: text/plain; charset=UTF-8
   
This is something that has been a real need since the introduction
 of
modifiers. Maybe you can expand this concept to include Group
 Sets?
This would be bags of data groups that could classify
vertes/edges/groups for their usage, example the set of vertex
 groups
that an specific armature modifier uses should not be visually
 mixed
with the ones that are just used to feed another modifier
   
cheers
   

[Bf-committers] siggraph

[joe]

I thought I'd check if anyone still wants a siggraph hotel mate, but
it's no big deal if not, just a bit longer to travel by subway is all.

Joe
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Path to integrating bmesh in trunk

[joe]

@Gustav, ok, thanks.  @Michael, yes I've done that recently.

Joe

2010/7/24 Gustav Göransson gustav.gorans...@gmail.com:
 FYI, I've started a thread at blenderartists were people who aren't
 active in the IRC channel can give feedback and discuss bugs, I'll try
 to summarize everything in the first post:

 http://blenderartists.org/forum/showthread.php?t=192498

 /gustav

 On Thu, Jul 22, 2010 at 05:09, joe joe...@gmail.com wrote:
 BMesh is nearing full completeness and stability, and I believe it can
 be merged into trunk within one (at most two)
 months.  Since I've never had good success with posting testing builds
 (as a way of getting serious user testing),
 I'm going to get users to build/test it on IRC and hopefully have more
 success at finding all the show-stopping
 issues.

 I'll try to post some developer docs in the wiki; there's a bunch of
 comments in source/blender/bmesh/*.h and some
 docs in bmesh/docs, but I need to consolidate and organize all the
 information in a better way and fill in the gaps
 still.

 Once I have it fully ready, the merge itself will have to be scheduled
 so it doesn't interfere with a release (there are
 always issues that only show up in trunk, when many more users start
 using the code in real projects, so there
 needs to be enough time to work those out before any release).  One
 potential issue is mesh RNA; the current RNA
 mesh API is going to change, and I'm going to write an RNA api
 wrapping bmesh as well.  It should be
 possible to write a wrapper .py module that emulates the current API,
 to avoid having to totally rewrite the current
 set of mesh scripts.

 Anyway, feel free to look over the branch and ask questions, I'll try
 to be in IRC as much as possible.  Questions will help me in making a
 good set of dev documentation, that's clear about why things are the
 way they are.

 Joe
 ___
 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

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Path to integrating bmesh in trunk

[joe]

BMesh is nearing full completeness and stability, and I believe it can
be merged into trunk within one (at most two)
months.  Since I've never had good success with posting testing builds
(as a way of getting serious user testing),
I'm going to get users to build/test it on IRC and hopefully have more
success at finding all the show-stopping
issues.

I'll try to post some developer docs in the wiki; there's a bunch of
comments in source/blender/bmesh/*.h and some
docs in bmesh/docs, but I need to consolidate and organize all the
information in a better way and fill in the gaps
still.

Once I have it fully ready, the merge itself will have to be scheduled
so it doesn't interfere with a release (there are
always issues that only show up in trunk, when many more users start
using the code in real projects, so there
needs to be enough time to work those out before any release).  One
potential issue is mesh RNA; the current RNA
mesh API is going to change, and I'm going to write an RNA api
wrapping bmesh as well.  It should be
possible to write a wrapper .py module that emulates the current API,
to avoid having to totally rewrite the current
set of mesh scripts.

Anyway, feel free to look over the branch and ask questions, I'll try
to be in IRC as much as possible.  Questions will help me in making a
good set of dev documentation, that's clear about why things are the
way they are.

Joe
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] small scale suggestion : keyframe extra tools

[joe]

I for one would love this.

Joe

On Tue, May 11, 2010 at 4:58 AM, Muhamad Faizol Abd. Halim
faizol.blen...@gmail.com wrote:
 Hi,

  Thanks for the feedback.

 On Tue, May 11, 2010 at 8:11 AM, Joshua Leung aligor...@gmail.com wrote:

 Hi,

 On Tue, May 11, 2010 at 9:19 AM, Muhamad Faizol Abd. Halim
 faizol.blen...@gmail.com wrote:
  1. To have an in-between keyframe can be inserted on the timeline using
  right-mouse-button (RMB) to position it at a specific timeline, and
  middle-mouse-button (MMB) to put a keyframe at that timeline. Other mouse
  gestures will simply cancel the operation. This will help animators to
  create follow ups keyframe much more easily and can consolidate several
  dopesheet operations into just 2 clicks on the timeline.
 
  Example is posted  at this link:
 
  http://www.pasteall.org/pic/3226   (blender_suggestion_01.png)
 So is the main purpose of this to just insert breakdowns using a
 modal-workflow without having to scrub the time cursor over to where a
 keyframe is desired (with the keyframe taking the interpolated values
 at the point where they are inserted)? I don't really understand the
 point of this, and don't really consider this as too much of a
 benefit.


 It's not taking the interpolated values at the point where they are
 inserted, but taking the _current frame_ 's  interpolation values to be
 inserted at the _desired frame_ (blue bar). Doing it this way then a user
 doesn't have to keyframe the desired values at the current frame and move it
 again afterwards to the desired frame.


 I do understand the need to be able to add keyframes tagged as
 'breakdowns' in an easier way, and for that I do intend to add a way
 to choose the type of keyframes inserted. However, the best way to
 present this functionality is still a bit unclear, though I don't
 think this is the right approach.


 There might be a better approach, just that this feature is readily
 available in other commercial 3d application and it helps animators to
 simplify the keyframe workflow. The same result can be done through
 dopesheet, but if we can consolidate a few operations into just two simple
 clicks, then in my humble opinion, I think it's worth a try.


 
  2. My second suggestion is to more keyframes management tool/handler. One
 of
  them is a box handler, more or less like this. I'm hoping that this could
  help animators to handle/manage large amount of keyframes much more
 easily.
 
  example: http://www.pasteall.org/pic/3227 (blender_suggestion_02.png).
 This sort of tool has been on my todo for a couple of months now.
 Basically, it's pending work on a generic manipulator widget API
 before work progresses on setting this up.


 Cool. Glad to know that it's there in the roadmap.

 Again, thanks for the feedback.

 Regards,
 Faizol Abd. Halim
 ___
 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] Hi. I have just joined.

[joe]

Thanks for the feedback!  We really love feedback from users such as yourself.

About the curve issues you posted; curves are a problem, and one we
need to solve, but we don't really have anyone in charge of curves
overall (there are one or two people working on NURBS surfaces, but
that's about it).  It's an issue we haven't had resources for, what
with everything else that needed doing (blender's development since
going open source has probably been 90% refactoring, with new features
being a side effect, and curves have mostly been left alone if I
remember right, though some improvements have been made).

On the pin animation, could you describe that in more detail? I'm in
charge of mesh refactoring, and I suspect I'm going to need to make
some internal design changes for this sort of thing.  On the topic of
multiple cloth modifiers; in theory this is possible, though we'll
need some detailed use cases to implement it correctly (for example,
should each modifier be aware of each other, e.g. for collision?
should they all internally share the same solver, or use one solver
per modifier?).

For the vertex painting issue, there is an option to paint per-vertex
as opposed to per-face; looks like it's either not on by default or
isn't working correctly, or something like that (this whole area of
the code has a few hard-to-track-down bugs still).  I'll try to take a
look as soon as I have time.

I'd suggest mailing such things directly to this list, and/or joining
irc://irc.freenode.org/blendercoders , since blenderartists isn't
always the best place (though it has improved a lot, I'm still scared
of it from past experiences :) ).

Joe

On Sat, May 8, 2010 at 4:19 AM, Glenn Melenhorst
glenn...@optushome.com.au wrote:
 Hi all. I have just joined the mailing list.
 I am a director of animation at Iloura (www.iloura.com.au) and am the
 lead VFX supervisor at it's Film and Tv department.
 I am using blender both professionally and privately and have 25 years
 working in VFX and CGI (I was the first person to use 3Ds for a use
 other than cad believe it or not).

 I have been working through 2.5 since the start getting into Matt Ebb's
 and Aligorith's ears a bit :) and have some thought's I'd like to see
 discussed if possible. Things like this:
 http://blenderartists.org/forum/showthread.php?p=1622201#post1622201

 My focus is on bringing Blender into a mainstream film pipeline and how
 it interacts with other 3d/2d apps and workflows. Any questions about
 film and VFX that might lend weight to how you develop 2.5, I'm your guy.

 ~Glenn Melenhorst
 www.glennmelenhorst.com

 ___
 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] The final step that Blender needs to take in order to become fundamentally perfect

[joe]

We'll get to nodes eventually; I'm not sure why this contention is
going on, from scanning the emails it seems to be mostly from
non-developers speaking with too much authority :)  Like I said
before, we have ideas for nodes for meshes and shaders, and we'll find
our way to cooler stuff too eventually (honestly a large-scale node
refactor is completely impossible right now, but there's no real
reason to do such a thing; I'd suggest asking the moonlight3d guys how
well that worked for them ;) ).  Really there are only a few key areas
to look at first, and I think smaller-scale efforts will work a lot
better in the end; each area has different needs from a node graph
solver, and creating a global solver would be premature since we don't
even know what would be required of it (other app's examples help, but
none of them are perfect, and none of them are blender, and there are
always a *ton* of hidden quirks to work out).

joe

On Mon, May 10, 2010 at 4:53 PM, Knapp magick.c...@gmail.com wrote:
 On Mon, May 10, 2010 at 4:40 PM, Raul Fernandez Hernandez
 ra...@info.upr.edu.cu wrote:
 Hi there

 I know resources are limited but what is to stop a few from starting a
 branch and exploring this very interesting area? I could see it as
 being a nodal extension of the game engine. I do admit to knowing very
 little about this subject but that is what it looked like in that
 SUPER cool video.

  You cannot fork Blender for a huge revamp in its current state, when
 haven't finished the previous revamp because then the sync back could
 become near impossible, you could base your entire codebase in things
 that simply will change or could dissapear in the official branch. Only
 after few stable releases you could fork Blender for a major architecture
 change like this.

 I agree that we don't want to but we could provided we had the people
 to do it. All it takes is man power and money. None of which do I want
 to see divided but I think one person exploring the possible would not
 hurt anything.


 --
 Douglas E Knapp

 Massagen Arbeit in Gelsenkirchen Buer
 http://bespin.org/~douglas/tcm/ztab1.htm
 Please link to me and trade links with me!

 Open Source Sci-Fi mmoRPG Game project.
 http://sf-journey-creations.wikispot.org/Front_Page
 http://code.google.com/p/perspectiveproject/
 ___
 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] help with readfile.c::do_version

[joe]

Ah, iirc the correct way to do this would be to handle this in the
appropriate lib_link_*** function (lib_link_sensors, or whatever it
is).  You could check if the old pointer is NULL, and if so check if
there is a name in the name field, then look up the id block.

Joe

On Mon, May 10, 2010 at 10:03 AM, Dalai Felinto dfeli...@gmail.com wrote:
 Hello there,
 as mentioned in last dev meeting I changed a few Game Sensors to use a
 datablock pointer instead of a string.
 e.g. the Collision Sensor struct used to have a string with the name
 of the material to trigger the collision, but now it will have a
 struct Material *ma; instead.

 Therefore I need a nice do_version to convert the char[] to *Material.
 In order to accomplish that I'm using BLI_findstring() . It works
 fine, however it gives me the new pointer for the image datablock, not
 the one stored in the file. That means that when we get in
 lib_link_object() the pointer will try to be converted into itself,
 what will not work since the new pointer will not be in the list of
 the old pointers.

 The workaround I found for it is totally hacky. I created a function
 called oldlibadr() that gives me the old pointer once I provide it
 with the new one. It's the opposite of newlibadr() used in
 lib_link_object(). You can see the patch for readfile.c here -
 http://www.pasteall.org/13020/diff

 Looking forward for directions on that.

 Thanks,
 Dalai
 ___
 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] The final step that Blender needs to take in order to become fundamentally perfect

[joe]

All of these things are basically on the horizon eventually,
depending on need, developer resources, etc.

Houdini-like geometry DOPs are something I want to do for bmesh, but
at this point it's hard to tell when
that can happen.   Shader nodes (real ones, that compile to a real
shader language) is also planned, but
again no one knows when it'll happen.  As for opencl, many of us are
excited to start playing around with
it :)

Joe

On Fri, May 7, 2010 at 1:32 PM, nautilus nautilus...@googlemail.com wrote:
 XSI's ICE is the use of a customizable node which can be compared to
 the VOP node of Houdini, although ICE is even easier to use than VOP
 (which at times can be more complicated).

 Houdini uses a more advanced network of nodes which is integrated
 throughout the application, resulting in it being more difficult to
 learn and use but ultimately more powerful. Look for example at what
 this person has done (it shows the power of Houdini quite well):
 http://www.youtube.com/watch?v=jOLhnwllpgs . Houdini is extremely
 powerful for things like visual effects and certain types of modelling
 (and animation). It's power, because of its advanced node-based
 procedural architecture, is still unexplored. It's simulation ablities
 are unmatched (only XSI's ICE can come close), and the ability for the
 user to make changes with real-time feedback that can only be made
 through an advanced node-based procedural method cannot be done
 through traditional non-procedural methods or easily done through
 unintuitive python scripts.

 Softimage's objective was to create a node-based environment that
 would be easier to use than Houdini and for some tasks almost as
 powerful. That is why ICE and Houdini are not the same thing, and
 should be seen as having different strengths and thus complementing
 each other.

 Textual programming was created because of the need to optimize
 programming code as well as possible per cpu clock without regards to
 readability, given the fact that cpu's were at the time inherently
 constrained in terms of performance - python and c look the same and
 are mostly the same in regards to intuitiveness. Visual programming is
 inherently more intuitive. The use of charts, diagrams, and graphs
 combined with some readable text is preferable to raw text. This is
 the basis of visual programming, the next step that presents a visual
 and interactive environment for the user, something that textual-based
 programming could never achieve and which is why is seen as not being
 as intuitive by the common user.

 Houdini has been stated many times as being able to save countless
 hours of programming by using its well thought-out nodes instead of
 textual-based programming (if we take into account the difference
 between the amounts of time needed to learn visual and textual-based
 programming, and slower than ideal usage of textual-based programming
 procedures given the lesser intuitiveness and more complicated nature,
 for the common user, of the textual approach). Studios use Houdini
 because it is more intuitive and also because in being more intuitive
 it is faster to set-up and use. However, Houdini is not exempt from
 criticism regarding intuitiveness. These are two good examples that I
 have found:

 POPS, this for me needs a re-write, I'd actually like to see more of
 a VOPS style system with multiple inputs/outputs on nodes, I guess
 after using VOPS and softimage ICE, this seems like a friendlier way
 of constructing a complex particle system.

 Some attention to VOPs perhaps?
 I really believe that VOPs are very powerful, but could we get some
 more functionalities as nodes?
 I really liked XSI ICE's user friendliness.. Also I kind of liked the
 fact that we could create and delete points from within the ICE
 network.. Something like this in Houdini could be very helpful (AFAIK
 using VEX/VOPs we can't create or delete data inside VOP Networks..
 Please correct me if I'm wrong)

 ICE is the most intuitive and useful for some tasks. Houdini is used
 for when the user needs more control and power. Blender needs to excel
 in being able to create 3d animation as easily, as quickly, and as
 well as possible by combining non-procedural and procedural workflow
 as well as possible.

 This is therefore the next step that Blender needs to take after 2.6

 2.6 will be released 2 and half years after it has been announced. 2.8
 can take a similar amount of time. 2.6 was focused on restructuring
 and redesigning Blender and making it competitive against all other
 packages except Houdini. For 2.8, Blender needs to become competitive
 against Houdini by integrating a Houdini-like advanced node-based
 all-permeating procedural system (which allows for, and is not limited
 to, modelling, animation, rigging, and more), and also integrate a
 system like ICE. When this happens, Blender will have finally reached
 completion from a theoretical and fundamental point of view. What it
 will then be refining

Re: [Bf-committers] jemalloc blender tests.

[joe]

Guardedalloc adds a great deal more overhead to allocations then
system allocators do, which I think explains much of it (and too
fine-grained allocations of course).

Joe

On Wed, Apr 14, 2010 at 2:08 AM, Campbell Barton ideasma...@gmail.com wrote:
 Recently I was looking into blender using a lot more memory then it
 should, where blender reported ~75mb, and the OS reported 750mb.
 This made one of the animators run out of ram, so I did a lot of
 checks and made sure it wasn't a leak (calling exit() and have
 valgrind report all unfree'd memory works pretty well).

 It turns out that this is *(most likely) because of memory
 fragmentation, so I tried malloc replacements 'hoard' and 'jemalloc',
 which had tried before and found gave minimal/no performance gains.
 But they do help with using less memory from the OS.
 (Keep in mind, using 64bit linux - ubuntu karmic, mileage would vary
 depending on the OS ofcourse).

 jemalloc gave better results so did some further tests.
 On loading the same file it used ~500mb rather then ~750mb. This was a
 scene with sintel so I suspect fragmentation could be because of
 vertex groups but not 100% sure.

 Then tested the alley scene, jemalloc - linux's default malloc,
 interesting results!
 (scene http://durian.blender.org/wp-content/uploads/2010/03/alley.png)
 (maximum memory used, from the OS's memory monitor. unscientifically
 took notes while rendering)
 new file (idle): 53mb - 55mb
 loaded alley scene (idle): 671mb - 1300mb
 render shadowbuffer: 5.5gig - 6.8gig
 raytree: 3.6gig - 4.0gig
 sss: 3.1gig - 4.1gig
 rendering (/w gi): 6.2gig - 7.2gig
 after rendering (idle): 4.0gig - 6.7gig
 new file after render (idle): 140mb - 3.1gig

 From what I have read, linux malloc implementation is considered to be
 quite good, (not worth replacing), so I'm guessing blender is using
 more fine grained malloc's then it should be.

 Im not sure of the details, if libc is keeping the ram for the
 application, but when you want to have more then 1 blender loaded at a
 time, its annoying to have to restart it just to free the memory.

 So I'd be interested if someone could test memory usage on windows
 with jemalloc since we get a lot of complaints about memory on windows
 systems,

 see: http://www.canonware.com/jemalloc/
 note: needed to compile with ./configure --disable-tcache, it was
 crashing when rendering. (bug reported)
 note: rendertimes were not noticeably different.

 According to the site http://www.canonware.com/jemalloc/
 facebook server, firefox and FreeBSD use jemalloc.

 Could be worth including with blender, especially if it helps windows
 users from running out of ram so easily.

 --
 - 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

Re: [Bf-committers] Applying tool/modifier to multiple objects simultaneously

[joe]

Modifiers are specific to one object instance, so making them apply to
multiple is a little iffy at the moment.

I'll probably clean this up when I get around to tackling the mesh
py/RNA API.  We do need some sort of modifier - tool bridge, so you
can use modifiers as tools, py api functions, etc, but I'm unsure how
such a thing would work (it's easy to write a simple interface layer,
but it's not good
to stack wholly different systems onto each other that way without
first carefully thinking it through).

warning: tangent to topic
The modifier system (in fact the whole DerivedMesh concept) is pretty
much used for three things; deforming, drawing, and converting
fundamentally different mesh data structures in a unified manner (it's
not really an abstract mesh class like I once thought, heh, it's meant
for drawing, conversion, and topology-unaware deformation, and there
it should stay, I think. past ideas we've thrown around of an
AbstractMesh API, where you can write tools that work on all current
DerivedMesh backends through an abstract API, would be much slower
then current design, because of memory/execution cache behavior).
/tangent

Anyway, this is definitely an issue I'll need to keep in mind going forward.

Joe

On Sun, Mar 21, 2010 at 1:32 PM, Seppo Tukiainen stu...@windowslive.com wrote:

 Hi,

 Even though the blender is great program, the following thing has been 
 annoying me for quite long time, but I don't know, if it’s a buck or lag of 
 feature, anyway here it is:

 In cases where modifiers or tools have to be applied to several objects (that 
 is: to all selected ones) simultaneously, it is not working. Instead 
 modifier/tool is applied only to the last selected object and one has to go 
 through every other pieces one by one or use “Make Links…” command.

 If it’s not a bug, I hope this kind of ‘applying to multiple objects’ support 
 will be build in the blender. It wasn’t in the 2.4x, but since 2.5x are 
 constructed better in many ways, as I’ve understood, there must be structures 
 for this kind of feature in already.
 In fact, this kind of functionality should have been build into kernel in the 
 first place. Applying any command should always go through the list of 
 selected objects and try to apply it into them all (cause it’s user’s will).

 Sorry, if this is what you have already planned to do in the future, but I 
 just wanted to let you to know that these kind of small things are also 
 important.

 br: Seppo
 _
 Windows puhelimella saat enemmän vastinetta rahoillesi.
 http://www.windowsmobile.fi
 ___
 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] scons/install stale files problem.

[joe]

. . .And you totally and completely missed my point :)

Joe

On Sat, Feb 13, 2010 at 4:06 PM, Martin Poirier the...@yahoo.com wrote:
 Blender on windows already supports having the .blender folder in different 
 locations outside of the install folder, regardless of the build engine used.

 That's not a new thing and not a big issue.

 Martin

 --- On Sat, 2/13/10, joe joe...@gmail.com wrote:

 From: joe joe...@gmail.com
 Subject: Re: [Bf-committers] scons/install stale files problem.
 To: bf-blender developers bf-committers@blender.org
 Received: Saturday, February 13, 2010, 6:21 PM
 I wasn't implying we should keep old
 scripts around.  Simply that you
 shouldn't play around so freely with the behavior of build
 systems
 like this, at least not without thorough testing :)

 IMHO it should not use the $HOME directory unless your
 explicitly
 making a release package.

 Joe

 On Sat, Feb 13, 2010 at 3:18 PM, Campbell Barton ideasma...@gmail.com
 wrote:
  This is whats happening on linux/unix for years with
 blender 2.4x, if
  ~/.blender is defined, maybe we switch to
 ~/blender-2.5.x in future,
  this has been discussed in other posts.
 
  They can be made to co-exist pretty easy I think, just
 make
  $PWD/.blender override $HOME/.blender
 
  I explained in the first post the problems with
 keeping old scripts around.
 
  On Sun, Feb 14, 2010 at 12:08 AM, joe joe...@gmail.com
 wrote:
  That would be bad, as it'd make different branches
 share the same
  .blender folder.
 
  Why are you messing with this?
 
  Joe
 
  On Sat, Feb 13, 2010 at 4:26 AM, Campbell Barton
 ideasma...@gmail.com
 wrote:
  Update: only remove the scripts dir now, not
 the entire install
  folder, apparently gives troubles on windows,
  We should still look into having a blender
 home on windows that isnt
  related to the install dir, and making it
 usable (create on startup if
  its not there for instance).
 
  On Sat, Feb 13, 2010 at 10:51 AM, joe joe...@gmail.com
 wrote:
  The install folder scons spits out is
 supposed to create/use a
  .blender folder in the same folder.
 
  Joe
 
  On Fri, Feb 12, 2010 at 3:53 PM, Campbell
 Barton ideasma...@gmail.com
 wrote:
  to conclude this tedious topic I
 better give an update for those who
  dont read the logs.
  Discussed this with Brect (over lunch)
 and Martin (over IRC) and Both
  agree this is best in the long run.
 
  Now the default scons behavior is to
 remove the install dir each time
  so it always contains an up to date
 build, however Aligorith uses
  scons for development on windows,
 which needs DLL's etc, so copying
  each time isnt nice.
 
  For this case I added
 WITHOUT_BF_OVERWRITE_INSTALL
 
  This also brought up the issue that on
 windows there isnt a ~/.blender
  directory thats easy to access/create
 (I'm not clear on the details).
  Would be good to have a home dir on
 windows too but thats another
  topic.
 
  On Thu, Feb 11, 2010 at 1:51 PM,
 Brecht Van Lommel bre...@blender.org
 wrote:
  Hi,
 
  I don't think we should try to
 support people installing scripts there
  and try to make the build systems
 clever about this. These really are
  just standard building rules,
 don't work in directories or files that
  are autogenerated by the build
 system because any changes will get
  overwritten. If anyone wants to
 make this kind of unsupported usage
  more convenient I guess they can,
 but more important in my opinion is
  fixing the problem of outdated
 scripts, and getting loading scripts
  from the user directory to work
 properly.
 
  Loading from the user directory
 seems to be suboptimal on Windows
  right now, the expected directory
 is this.
  C:\Documents and
 Settings\User\.blender\scripts
 
  That can be changed to this, and
 the folder can be created
  automatically on startup to make
 things easier.
  C:\Documents and
 Settings\User\Blender Foundation\Blender\scripts
 
  Brecht.
 
 ___
  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
 
 
 
 
  --
  - 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
 
 
 
 
  --
  - Campbell
  ___
  Bf-committers mailing list
  Bf-committers@blender.org
  http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] scons/install stale files problem.

[joe]

The install folder scons spits out is supposed to create/use a
.blender folder in the same folder.

Joe

On Fri, Feb 12, 2010 at 3:53 PM, Campbell Barton ideasma...@gmail.com wrote:
 to conclude this tedious topic I better give an update for those who
 dont read the logs.
 Discussed this with Brect (over lunch) and Martin (over IRC) and Both
 agree this is best in the long run.

 Now the default scons behavior is to remove the install dir each time
 so it always contains an up to date build, however Aligorith uses
 scons for development on windows, which needs DLL's etc, so copying
 each time isnt nice.

 For this case I added WITHOUT_BF_OVERWRITE_INSTALL

 This also brought up the issue that on windows there isnt a ~/.blender
 directory thats easy to access/create (I'm not clear on the details).
 Would be good to have a home dir on windows too but thats another
 topic.

 On Thu, Feb 11, 2010 at 1:51 PM, Brecht Van Lommel bre...@blender.org wrote:
 Hi,

 I don't think we should try to support people installing scripts there
 and try to make the build systems clever about this. These really are
 just standard building rules, don't work in directories or files that
 are autogenerated by the build system because any changes will get
 overwritten. If anyone wants to make this kind of unsupported usage
 more convenient I guess they can, but more important in my opinion is
 fixing the problem of outdated scripts, and getting loading scripts
 from the user directory to work properly.

 Loading from the user directory seems to be suboptimal on Windows
 right now, the expected directory is this.
 C:\Documents and Settings\User\.blender\scripts

 That can be changed to this, and the folder can be created
 automatically on startup to make things easier.
 C:\Documents and Settings\User\Blender Foundation\Blender\scripts

 Brecht.
 ___
 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

Re: [Bf-committers] scons/install stale files problem.

[joe]

That would be bad, as it'd make different branches share the same
.blender folder.

Why are you messing with this?

Joe

On Sat, Feb 13, 2010 at 4:26 AM, Campbell Barton ideasma...@gmail.com wrote:
 Update: only remove the scripts dir now, not the entire install
 folder, apparently gives troubles on windows,
 We should still look into having a blender home on windows that isnt
 related to the install dir, and making it usable (create on startup if
 its not there for instance).

 On Sat, Feb 13, 2010 at 10:51 AM, joe joe...@gmail.com wrote:
 The install folder scons spits out is supposed to create/use a
 .blender folder in the same folder.

 Joe

 On Fri, Feb 12, 2010 at 3:53 PM, Campbell Barton ideasma...@gmail.com 
 wrote:
 to conclude this tedious topic I better give an update for those who
 dont read the logs.
 Discussed this with Brect (over lunch) and Martin (over IRC) and Both
 agree this is best in the long run.

 Now the default scons behavior is to remove the install dir each time
 so it always contains an up to date build, however Aligorith uses
 scons for development on windows, which needs DLL's etc, so copying
 each time isnt nice.

 For this case I added WITHOUT_BF_OVERWRITE_INSTALL

 This also brought up the issue that on windows there isnt a ~/.blender
 directory thats easy to access/create (I'm not clear on the details).
 Would be good to have a home dir on windows too but thats another
 topic.

 On Thu, Feb 11, 2010 at 1:51 PM, Brecht Van Lommel bre...@blender.org 
 wrote:
 Hi,

 I don't think we should try to support people installing scripts there
 and try to make the build systems clever about this. These really are
 just standard building rules, don't work in directories or files that
 are autogenerated by the build system because any changes will get
 overwritten. If anyone wants to make this kind of unsupported usage
 more convenient I guess they can, but more important in my opinion is
 fixing the problem of outdated scripts, and getting loading scripts
 from the user directory to work properly.

 Loading from the user directory seems to be suboptimal on Windows
 right now, the expected directory is this.
 C:\Documents and Settings\User\.blender\scripts

 That can be changed to this, and the folder can be created
 automatically on startup to make things easier.
 C:\Documents and Settings\User\Blender Foundation\Blender\scripts

 Brecht.
 ___
 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




 --
 - 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

Re: [Bf-committers] scons/install stale files problem.

[joe]

I wasn't implying we should keep old scripts around.  Simply that you
shouldn't play around so freely with the behavior of build systems
like this, at least not without thorough testing :)

IMHO it should not use the $HOME directory unless your explicitly
making a release package.

Joe

On Sat, Feb 13, 2010 at 3:18 PM, Campbell Barton ideasma...@gmail.com wrote:
 This is whats happening on linux/unix for years with blender 2.4x, if
 ~/.blender is defined, maybe we switch to ~/blender-2.5.x in future,
 this has been discussed in other posts.

 They can be made to co-exist pretty easy I think, just make
 $PWD/.blender override $HOME/.blender

 I explained in the first post the problems with keeping old scripts around.

 On Sun, Feb 14, 2010 at 12:08 AM, joe joe...@gmail.com wrote:
 That would be bad, as it'd make different branches share the same
 .blender folder.

 Why are you messing with this?

 Joe

 On Sat, Feb 13, 2010 at 4:26 AM, Campbell Barton ideasma...@gmail.com 
 wrote:
 Update: only remove the scripts dir now, not the entire install
 folder, apparently gives troubles on windows,
 We should still look into having a blender home on windows that isnt
 related to the install dir, and making it usable (create on startup if
 its not there for instance).

 On Sat, Feb 13, 2010 at 10:51 AM, joe joe...@gmail.com wrote:
 The install folder scons spits out is supposed to create/use a
 .blender folder in the same folder.

 Joe

 On Fri, Feb 12, 2010 at 3:53 PM, Campbell Barton ideasma...@gmail.com 
 wrote:
 to conclude this tedious topic I better give an update for those who
 dont read the logs.
 Discussed this with Brect (over lunch) and Martin (over IRC) and Both
 agree this is best in the long run.

 Now the default scons behavior is to remove the install dir each time
 so it always contains an up to date build, however Aligorith uses
 scons for development on windows, which needs DLL's etc, so copying
 each time isnt nice.

 For this case I added WITHOUT_BF_OVERWRITE_INSTALL

 This also brought up the issue that on windows there isnt a ~/.blender
 directory thats easy to access/create (I'm not clear on the details).
 Would be good to have a home dir on windows too but thats another
 topic.

 On Thu, Feb 11, 2010 at 1:51 PM, Brecht Van Lommel bre...@blender.org 
 wrote:
 Hi,

 I don't think we should try to support people installing scripts there
 and try to make the build systems clever about this. These really are
 just standard building rules, don't work in directories or files that
 are autogenerated by the build system because any changes will get
 overwritten. If anyone wants to make this kind of unsupported usage
 more convenient I guess they can, but more important in my opinion is
 fixing the problem of outdated scripts, and getting loading scripts
 from the user directory to work properly.

 Loading from the user directory seems to be suboptimal on Windows
 right now, the expected directory is this.
 C:\Documents and Settings\User\.blender\scripts

 That can be changed to this, and the folder can be created
 automatically on startup to make things easier.
 C:\Documents and Settings\User\Blender Foundation\Blender\scripts

 Brecht.
 ___
 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




 --
 - 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




 --
 - 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

Re: [Bf-committers] scons/install stale files problem.

[joe]

Also, alternatively we could store scripts as a gzip file datatoc'd
into blender, and extract it to a hidden temp folder on startup (or
even have python directly read from the gzip file, though I'm not sure
how to do this).

Joe

On Wed, Feb 10, 2010 at 8:44 AM, Campbell Barton ideasma...@gmail.com wrote:
 target would be ok but I expect people wont use it and we end up with
 the same problem.

 Could be good if making release also made a zip,
 blender_$OS_$ARCH_$REVISION.zip or something like this might encourage
 casual users/devs to use this target to save them compressing
 themselves.

 On Wed, Feb 10, 2010 at 2:18 PM, Martin Poirier the...@yahoo.com wrote:
 If that's done, it should be either with a special target (scons release) or 
 an option that defaults to false (scons BF_CLEAR=1). Of the two, I prefer 
 the target, it's clearer that this is building for redistribution.

 Martin

 --- On Wed, 2/10/10, Campbell Barton ideasma...@gmail.com wrote:

 From: Campbell Barton ideasma...@gmail.com
 Subject: [Bf-committers] scons/install stale files problem.
 To: bf-blender developers bf-committers@blender.org
 Received: Wednesday, February 10, 2010, 5:15 AM
 A while ago I posted about blender
 removing scripts on installation.
 while possible this isn't trivial with scons. (needs to
 have some
 post-install step I think, that runs before installing)

 So could we remove the directory blender installs into
 instead?
 would have the effect of..
 rm -rf ../install/linux2

 On the blenderartist forum about 2.5 there have been a
 number of
 people complaining about import/export (obj/3ds/fbx).
 and bug reports like this one I cant redo.
 http://projects.blender.org/tracker/index.php?func=detailaid=21001group_id=9atid=498

 If blender is being bundled into a directory why would you
 want it to
 contain files that are not apart of blender? this is what
 the user
 scripts directory is for.
 The fact that we remove scripts from svn and they still end
 up on
 graphicall builds is really bad. would like to resolve this
 somehow.

 --
 - Campbell
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers



      __
 Make your browsing faster, safer, and easier with the new Internet Explorer® 
 8. Optimized for Yahoo! Get it Now for Free! at 
 http://downloads.yahoo.com/ca/internetexplorer/
 ___
 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

Re: [Bf-committers] Anymated textures in the 3Dview

[joe]

There's a function to update and get the image data,
image_update_for_frame or um something like this.  The backjground
image code does this.

Joe

On Wed, Feb 10, 2010 at 12:12 PM, Benoit Bolsee benoit.bol...@online.be wrote:
 Hi,

 Recently, based on my status of the VideoTexture module mantainer, I've
 been asked whether video textures could be displayed dynamically in the
 3D view (based on frame number). Unfortunately, the BGE and Blender use
 a different realtime render engine, so the VideoTexture module is no use
 in Blender.

 Nevertheless, I've studied the question and isolated the places in the
 code that must be changed to allow dynamic textures in the 3D view. I
 thought I would release this information as some Blender dev might want
 to implement the changes.

 /benoit

 Here is the study:

 I finally had the time to look into that. It is not a simple problem. I
 have identified the 2 missing links to get animated texture in the 3D
 view but I'm not confident to implement them. The affected code is part
 of the Blender UI render engine that I'm not familiar with.

 I can give pointers to the code. Note that the following explanations
 are applicable to Blender 2.5.

 The function that is not doing the right thing is GPU_verify_image() in
 source/blender/gpu/gpu_draw.c This function is called whenever a
 textured face must be rendered in the 3D view. It calls the
 BKE_image_get_ibuf() function (line 447) to get the image buffer. Note
 that it uses a Image object, which is the central place in Blender where
 images are stored, including images from movies. It passes NULL as
 second argument, which means that the last loaded image from the movie
 will be returned.

 This is not a problem if the image corresponding to the current frame
 was loaded before this function is called. Unfortunately, there is no
 proper mechanism in Blender to ensure that. I found that displaying the
 Texture in the Button panel partially works: the frame number is updated
 whenever you modify something on that panel. This could be fixed by
 proper notifier/event but has the inconvenient that you have to keep the
 texture panel opened. A better way would be scan all Images (there is a
 global link of such objects) and update those pointing to movies
 whenever the frame number is changed. I don't think that is particularly
 difficult to do.

 The second problem is at line 446: if the image was already bound to a
 GPU texture, it simply rebinds and the image is not reloaded.  The
 proper load code is below at line 553. The idea would be to keep at
 Image level the number of the frame that was last loaded on the GPU and
 if it differs from the frame returned by BKE_image_get_ibuf, reload the
 image. Again I don't think this is complicated to do.

 

 ___
 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] A question about CMP_scale.c

[joe]

IIRC scalefast_compbuf is just a more optimized scaling function (we
have optimized scaling stuff in imbuf too, so I'm not sure is the
compbuf function really has any reason to exist or not).

Joe

On Fri, Feb 5, 2010 at 12:12 AM, James Ruan ruanbeih...@gmail.com wrote:
 In version 10342, 'scourage' added the CMP_scale.c using IMB_scaleImBuf(),
 while in the same version 'scourage' added the scalefast_compbuf() in
 CMP_util.c.
 What's the difference between them? And should there be a unique way to
 scale the CompBuf?

 This question is probably prepared for 'scourage'.

 Thanks,

 --
 James Ruan
 ___
 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] New project member: Daniel Salazar

[joe]

Congrats!

On Tue, Feb 9, 2010 at 12:19 PM, Christopher Cherrett
st...@trackingsolutions.ca wrote:
 Yes that is what I thought you would be thinking :)

 Congrats!
  Original Message  
 Subject: Re: [Bf-committers] New project member: Daniel Salazar
 From: Daniel Salazar - 3Developer.com zan...@gmail.com
 To: bf-committers@blender.org
 Date: 02/09/10 11:54
 http://www.youtube.com/watch?v=So9tL5DPkpg

 hehehe!

 Daniel Salazar
 www.3developer.com

 --

 Message: 3
 Date: Tue, 9 Feb 2010 16:44:47 +0100
 From: Ton Roosendaal t...@blender.org
 Subject: [Bf-committers] New project member: Daniel Salazar
 To: bf-committers@blender.org
 Message-ID: 0945ef56-c426-410c-856d-8885ca771...@blender.org
 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes

 Hi all,

 I've added Daniel 'Zanqdo' Salazar to the bf-blender project with
 commit rights.
 He will do (UI) script maintenance mostly, and works with Campbell as
 code buddy.

 Welcome! :)

 -Ton-

 
 Ton Roosendaal  Blender Foundation   t...@blender.org    www.blender.org
 Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands


 ___
 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

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] faster usage of panels via pie menu

[joe]

Can we *please* get a vertical layout of the header as well?

Joe

On Tue, Feb 9, 2010 at 2:01 PM, Tom M letter...@gmail.com wrote:
 Matt and others, on IRC we were discussing how slow and workflow
 disrupting it is to move to the vertical panel layout and then scroll
 to the option you want to tweak.

 It was suggested that a hotkey combo bringing up a pie menu of the
 current available panels would be a lot faster, and would eliminate
 the need to scroll, similar to how the F6 key after an operator brings
 up the tweak operator menu.

 LetterRip
 ___
 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] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [26582] trunk/blender/release/scripts/ modules/rigify/shape_key_transforms.py: Added a new rig type shape_key_transforms that d

[joe]

A field for an offset might be nice too, for shape keys driving
multiple keys (looks like you could drive 2 keys with this, by
negating the multiplier, but not more then that).

Joe

On Wed, Feb 3, 2010 at 7:40 AM, Nathan Vegdahl ces...@cessen.com wrote:
 Revision: 26582
          
 http://projects.blender.org/plugins/scmsvn/viewcvs.php?view=revroot=bf-blenderrevision=26582
 Author:   cessen
 Date:     2010-02-03 16:40:56 +0100 (Wed, 03 Feb 2010)

 Log Message:
 ---
 Added a new rig type shape_key_transforms that drives shape keys based on 
 the local transforms of a single bone.  Quite useful in a variety of 
 situations.

 Required options:
    mesh:  name of mesh object(s) to add/get shapekeys to/from
           (if multiple objects, make a comma-separated list)
 Optional options:
    loc_x/y/z:       name of the shape key to tie to translation of the bone
    loc_x/y/z_fac:   default multiplier of the bone influence on the shape 
 key
    rot_x/y/z:       name of the shape key to tie to rotation of the bone
    rot_x/y/z_fac:   default multiplier of the bone influence on the shape 
 key
    scale_x/y/z:     name of the shape key to tie to scale of the bone
    scale_x/y/z_fac: default multiplier of the bone influence on the shape 
 key

 Added Paths:
 ---
    trunk/blender/release/scripts/modules/rigify/shape_key_transforms.py

 Added: trunk/blender/release/scripts/modules/rigify/shape_key_transforms.py
 ===
 --- trunk/blender/release/scripts/modules/rigify/shape_key_transforms.py      
                           (rev 0)
 +++ trunk/blender/release/scripts/modules/rigify/shape_key_transforms.py      
   2010-02-03 15:40:56 UTC (rev 26582)
 @@ -0,0 +1,263 @@
 +# # BEGIN GPL LICENSE BLOCK #
 +#
 +#  This program is free software; you can redistribute it and/or
 +#  modify it under the terms of the GNU General Public License
 +#  as published by the Free Software Foundation; either version 2
 +#  of the License, or (at your option) any later version.
 +#
 +#  This program is distributed in the hope that it will be useful,
 +#  but WITHOUT ANY WARRANTY; without even the implied warranty of
 +#  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 +#  GNU General Public License for more details.
 +#
 +#  You should have received a copy of the GNU General Public License
 +#  along with this program; if not, write to the Free Software Foundation,
 +#  Inc., 59 Temple Place - Suite 330, Boston, MA  02111-1307, USA.
 +#
 +# # END GPL LICENSE BLOCK #
 +
 +# pep8 compliant
 +
 +import bpy
 +from rigify import RigifyError
 +from rigify_utils import copy_bone_simple
 +from rna_prop_ui import rna_idprop_ui_prop_get
 +
 +#METARIG_NAMES = (cpy,)
 +RIG_TYPE = shape_key_transforms
 +
 +
 +def addget_shape_key(obj, name=Key):
 +     Fetches a shape key, or creates it if it doesn't exist
 +    
 +    # Create a shapekey set if it doesn't already exist
 +    if obj.data.shape_keys is None:
 +        shape = obj.add_shape_key(name=Basis, from_mix=False)
 +        obj.active_shape_key_index = 0
 +
 +    # Get the shapekey, or create it if it doesn't already exist
 +    if name in obj.data.shape_keys.keys:
 +        shape_key = obj.data.shape_keys.keys[name]
 +    else:
 +        shape_key = obj.add_shape_key(name=name, from_mix=False)
 +
 +    return shape_key
 +
 +
 +def addget_shape_key_driver(obj, name=Key):
 +     Fetches the driver for the shape key, or creates it if it doesn't
 +        already exist.
 +    
 +    driver_path = 'keys[' + name + '].value'
 +    fcurve = None
 +    driver = None
 +    new = False
 +    if obj.data.shape_keys.animation_data is not None:
 +        for driver_s in obj.data.shape_keys.animation_data.drivers:
 +            if driver_s.data_path == driver_path:
 +                fcurve = driver_s
 +    if fcurve == None:
 +        fcurve = obj.data.shape_keys.keys[name].driver_add(value, 0)
 +        fcurve.driver.type = 'AVERAGE'
 +        new = True
 +
 +    return fcurve, new
 +
 +
 +# TODO:
 +def metarig_template():
 +    # generated by rigify.write_meta_rig
 +    #bpy.ops.object.mode_set(mode='EDIT')
 +    #obj = bpy.context.active_object
 +    #arm = obj.data
 +    #bone = arm.edit_bones.new('Bone')
 +    #bone.head[:] = 0., 0., 0.
 +    #bone.tail[:] = 0., 0., 1.
 +    #bone.roll = 0.
 +    #bone.connected = False
 +    #
 +    #bpy.ops.object.mode_set(mode='OBJECT')
 +    #pbone = obj.pose.bones['Bone']
 +    #pbone['type'] = 'copy'
 +    pass
 +
 +
 +def metarig_definition(obj, orig_bone_name):
 +    bone = obj.data.bones[orig_bone_name]
 +    return [bone.name]
 +
 +
 +def main(obj, definitions, base_names, options):
 +     A rig that drives shape keys with the local transforms of a single 
 bone.
 +
 +        Required options:
 +            mesh:  name of mesh object(s) to add/get shapekeys to/from
 +                   (if multiple objects, make

Re: [Bf-committers] Particle surfaces update

[joe]

Oh awesome.  We've been needing something like this.

Joe

On Thu, Jan 28, 2010 at 7:23 AM, Raul Fernandez Hernandez
ra...@info.upr.edu.cu wrote:
 Hi all

 Last nigth I have finishing implementing the surface refinement for
 particles, this allow to increase the resolution of the mesh for smoother
 surfaces. I still need to redefine my current surface evaluation from
 particles because I´m getting the wrong isosurfaces  but still I could
 show you my progress.

 I'm very exited about it because I'm learning the necesary skills to
 tackle later Voxel Sculpting since are based on the same technologies :)
 Is not a beatufl pictures and for end users this may still tell noting but
 a month ago I only could dream about achiving this:

  http://farsthary.wordpress.com

  the longest journey start with a step ;)

                 Cheers  Farsthary

 ___
 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] MultiRes Shapekeys??

[joe]

I don't think this would work, unfortunately.  It'd be more feasible
to support branching within a single multires modifier, and it's
probably much more practical to simply make sure the existing shape
key tools do what we need.

Joe

On Fri, Jan 29, 2010 at 7:38 AM, Juan Pablo Bouza jpbo...@hotmail.com wrote:

 Hi guys! This is just a thought...

 What if Blender was able to use more than 1 multires modifier per object?

 Imagine that you have a highpoly multires character, then, you add a second 
 multires modifier which uses the previous multires modifier as its base. 
 Then, with that second modifier enabled, you sculpt veins, or little 
 wrinkles. The information that the second modifier should store would only be 
 the displacement against the previous modifier, so the file size should not 
 be too big.

 The idea would be to control the influence of the second modifier with a 
 driver or something, that way you would be able to have a kind of high 
 resolution shapekey.

 _
 ¡Usá Messenger en todas partes! Sumate a Somos Messenger Siempre y chateá 
 desde tu celu
 http://www.somosmessengersiempre.com/?ocid=TWLH
 ___
 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] gettimeofday in thread.c's wait_timeout

[joe]

Isn't time in whole seconds?

Joe

On Fri, Jan 22, 2010 at 8:09 PM, Mitchell Stokes moguri...@gmail.com wrote:
 Hello Blender Devs,

 A recent commit to threads.c added a function called wait_timeout. In
 this function gettimeofday() is used, which MSVC does not define.
 However, it looks like to me that time() could be used instead of
 gettimeofday(). Also, timeval.tv_usec is in microseconds while I think
 the code was using it as milliseconds. So, here is a patch to use
 time(). It compiles on MSVC, but I didn't test it much beyond that.

 http://www.pasteall.org/10517/diff

 Cheers,
 Mitchell Stokes (Moguri)
 ___
 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] [Bf-blender-cvs] [26206] Compiling issue

[joe]

What are you talking about specifically?  It helps with ghash, because
each bucket node was being allocated individually, causing a
significant speed problem.  This particular solution was very
appropriate; it's why we have the mempool library in the first place.

Now, the experimental code I committed (#ifdef'd out) to guardedalloc
is different (and was a
different commit even).  This particular commit has nothing to do with
that.  On that topic, OSX has (or had, anyway) a reputation for having
a system allocator almost as slow as windows; linux is the only OS as
far as I know (other then the BSDs I guess) that doesn't suffer from
this.  So it's hardly simply a windows issue.

The overhead we get from guardedalloc isn't all that bad, really.  I
wasn't talking about that in the slightest.  What I was talking about
was the significant performance loss we get from overusing the system
allocator, which has caused significant problems for me and others.  I
committed the code #ifdef'd out, so people who need it can play around
with it but not cause problems for others.  There's a reason it's
*experimental*.

Joe

On Sat, Jan 23, 2010 at 5:46 AM, Brecht Van Lommel bre...@blender.org wrote:
 Hi Joe,

 I'm trying to understand when using a memory pool for small
 allocations would help here. I doesn't avoid any of the overhead of
 our own guardedalloc code, it just replaces malloc. So it's basically
 expected to be a better malloc, in case the one provided by the system
 doesn't work well? To my knowledge, this is only applicable to
 Windows. Perhaps a better solution would be to link in a library like
 tcmalloc or jemalloc on Windows (like e.g. Google Chrome does), rather
 than trying to do this ourselves. It seems to me this is quite a
 complicated thing to do right, and it's already been done better.

 Brecht.

 On Sat, Jan 23, 2010 at 1:16 PM, joe joe...@gmail.com wrote:
 I'll look into it.

 On Sat, Jan 23, 2010 at 4:02 AM, Thomas Dinges din...@gmx.de wrote:
 Hi,
 this breaks compiling again.
 scons/msvc

 http://www.pasteall.org/10530

 Some unresolved stuff in the linking process.




 Am 23.01.2010 12:25, schrieb Joseph Eagar:
 Revision: 26206
            
 http://projects.blender.org/plugins/scmsvn/viewcvs.php?view=revroot=bf-blenderrevision=26206
 Author:   joeedh
 Date:     2010-01-23 12:25:20 +0100 (Sat, 23 Jan 2010)

 Log Message:
 ---
 Initial results of my profiling of the animation system.
 Basically two simple changes, changes, I pulled in the faster
 ghash in bmesh (which uses mempools for allocation, providing
 a substanstial speedup in some cases, and also I inlined some
 of the functions), and I changed __inline to __forceinline for inlining
 of math functions.

 I also removed the timer in the view3d zoom op (ctrl-middlemouse)
 that was making it nonfunctional.  Why was that there?

 ___
 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


 ___
 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] [Bf-blender-cvs] [26206] Compiling issue

[joe]

The purpose was simple experimentation, since we need to do
*something* and at the time I didn't think people would go for using
jcmalloc.  Vgroups really are a bad source of performance loss, mostly
in debug builds (which we need to be usable but aren't in some cases).
 I was hoping to elicit ideas from other people, and go from there.
Anyway, it was silly of me to ignore the possibility of using
jcmalloc, which we can probably drop in as a replacement for malloc
within guardedalloc itself (and even have compile time options to have
guardedalloc go straight through to jcmalloc).

Joe

On Sat, Jan 23, 2010 at 6:53 AM, Brecht Van Lommel bre...@blender.org wrote:
 Hi Joe,

 Right, I replied to the wrong mail, I was talking about the
 guardedalloc changes. I understand this is experimental, but I don't
 think some more experimentation will be prove this to be the right
 thing to do. It may well lead to a speedup in simple test cases, but a
 simple use of pooling can lead to much wasted memory and make problems
 worse when running Blender for a while. So it is not clear to me what
 the purpose is here, if this is the start of writing an advanced
 memory allocator then I don't think we should try to do that
 ourselves, and if not then I don't think this can be good enough to
 put in a release.

 Brecht.

 On Sat, Jan 23, 2010 at 3:19 PM, joe joe...@gmail.com wrote:
 What are you talking about specifically?  It helps with ghash, because
 each bucket node was being allocated individually, causing a
 significant speed problem.  This particular solution was very
 appropriate; it's why we have the mempool library in the first place.

 Now, the experimental code I committed (#ifdef'd out) to guardedalloc
 is different (and was a
 different commit even).  This particular commit has nothing to do with
 that.  On that topic, OSX has (or had, anyway) a reputation for having
 a system allocator almost as slow as windows; linux is the only OS as
 far as I know (other then the BSDs I guess) that doesn't suffer from
 this.  So it's hardly simply a windows issue.

 The overhead we get from guardedalloc isn't all that bad, really.  I
 wasn't talking about that in the slightest.  What I was talking about
 was the significant performance loss we get from overusing the system
 allocator, which has caused significant problems for me and others.  I
 committed the code #ifdef'd out, so people who need it can play around
 with it but not cause problems for others.  There's a reason it's
 *experimental*.

 Joe

 ___
 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] gettimeofday in thread.c's wait_timeout

[joe]

Brecht fixed this, he used a function called ftime.

Joe

On Sat, Jan 23, 2010 at 10:09 AM, Mitchell Stokes moguri...@gmail.com wrote:
 Yes and so is timeval.tv_sec, and timeval.tv_usec is in microseconds.
 Although I think I do see an error in my patch, it probably should be
 now / 1000.0 instead of now*1000.

 On Sat, Jan 23, 2010 at 3:06 AM, joe joe...@gmail.com wrote:
 Isn't time in whole seconds?

 Joe

 On Fri, Jan 22, 2010 at 8:09 PM, Mitchell Stokes moguri...@gmail.com wrote:
 Hello Blender Devs,

 A recent commit to threads.c added a function called wait_timeout. In
 this function gettimeofday() is used, which MSVC does not define.
 However, it looks like to me that time() could be used instead of
 gettimeofday(). Also, timeval.tv_usec is in microseconds while I think
 the code was using it as milliseconds. So, here is a patch to use
 time(). It compiles on MSVC, but I didn't test it much beyond that.

 http://www.pasteall.org/10517/diff

 Cheers,
 Mitchell Stokes (Moguri)
 ___
 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

 ___
 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] [Bf-blender-cvs] [26206] Compiling issue

[joe]

To reiterate my position.  I committed this on an experimental basis,
and I originally planned to get some other people to run some tests
and review the code accordingly.  I never, ever, *ever* wanted this
code *as it is now* in a release, or enabled by default.  I'm
certainly open to the idea of trashing my code, which again, was
*experimental*, and playing with plugging in jcmalloc or whatever.

This isn't a problem anyway has had time to tackle, and I need to for
bmesh.  I'm certainly not going add anything that's actually enabled
after much testing and developer discussion, this was more of an
effort to get the dialoge started.

Joe

On Sat, Jan 23, 2010 at 10:53 AM, Geoffrey Bantle hair...@yahoo.com wrote:
 Apologies for the lack of line breaks in the last email,
 I had forgotten that yahoo mail doesn't insert them
 automatically. Below is the original message formatted
 sanely (I hope).

 ==

 I feel like I should comment on this

 I originally wrote the mem-pool joeedh is using because
 b-mesh performance on windows was *significantly* slowed
 down by the amount of small allocations it made. It's
 actually much worse than edit-mesh in those regards, and
 I wanted to do something a *little* bit more sophisticated
 than the editmesh fast calloc functions/callbacks. That
 being said, the mem-pool is not particularly clever or
 complicated code and it should be remembered that it
 was written to solve a very specific problem.

 Anyway, if I recall correct it was someone on IRC who
 suggested I put it in Blenlib in case someone else might
 find it useful. Despite this, I think it's only really
 appropriate for a narrow range of applications (edit-mesh
 and b-mesh being the obvious choices.) I question the
 wisdom of tying it to something like guarded alloc where
 it has the potential to have unintended and adverse effects
 on the rest of the system.

This is also something I've had to deal with in the bmesh branch, and
the code I wrote there should never see the light of day in trunk
(which motivates me to tackle this now :) ).  It's really quite
horrible what I wrote to deal with vgroups performance problems.

Joe

 When you mention 'horrible performance problems' associated
 with vertex groups I'm curious whether or not you measured
 this. Did you do profiling? What did you pinpoint as the
 biggest bottlenecks?

 Cheers,
 Geoff



 ___
 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] [Bf-blender-cvs] [26206] Compiling issue

[joe]

Somehow I proof read that without catching the grammar mistakes.

To reiterate my position.  I committed this on an experimental basis,
and I originally planned to get some other people to run some tests
and review the code accordingly.  I never, ever, *ever* wanted this
code *as it is now* in a release, or enabled by default.  I'm
certainly open to the idea of trashing my code, which again, was
*experimental*, and playing with plugging in jcmalloc or whatever.

This isn't a problem any*one* has had time to tackle, and I need to for
bmesh.  I'm certainly not going to add anything that's actually enabled
*until* after much testing and developer discussion, this was more of an
effort to get the dialoge started.

Joe

On Sat, Jan 23, 2010 at 3:13 PM, joe joe...@gmail.com wrote:
 To reiterate my position.  I committed this on an experimental basis,
 and I originally planned to get some other people to run some tests
 and review the code accordingly.  I never, ever, *ever* wanted this
 code *as it is now* in a release, or enabled by default.  I'm
 certainly open to the idea of trashing my code, which again, was
 *experimental*, and playing with plugging in jcmalloc or whatever.

 This isn't a problem anyway has had time to tackle, and I need to for
 bmesh.  I'm certainly not going add anything that's actually enabled
 after much testing and developer discussion, this was more of an
 effort to get the dialoge started.

 Joe

 On Sat, Jan 23, 2010 at 10:53 AM, Geoffrey Bantle hair...@yahoo.com wrote:
 Apologies for the lack of line breaks in the last email,
 I had forgotten that yahoo mail doesn't insert them
 automatically. Below is the original message formatted
 sanely (I hope).

 ==

 I feel like I should comment on this

 I originally wrote the mem-pool joeedh is using because
 b-mesh performance on windows was *significantly* slowed
 down by the amount of small allocations it made. It's
 actually much worse than edit-mesh in those regards, and
 I wanted to do something a *little* bit more sophisticated
 than the editmesh fast calloc functions/callbacks. That
 being said, the mem-pool is not particularly clever or
 complicated code and it should be remembered that it
 was written to solve a very specific problem.

 Anyway, if I recall correct it was someone on IRC who
 suggested I put it in Blenlib in case someone else might
 find it useful. Despite this, I think it's only really
 appropriate for a narrow range of applications (edit-mesh
 and b-mesh being the obvious choices.) I question the
 wisdom of tying it to something like guarded alloc where
 it has the potential to have unintended and adverse effects
 on the rest of the system.

This is also something I've had to deal with in the bmesh branch, and
the code I wrote there should never see the light of day in trunk
(which motivates me to tackle this now :) ).  It's really quite
horrible what I wrote to deal with vgroups performance problems.

Joe

 When you mention 'horrible performance problems' associated
 with vertex groups I'm curious whether or not you measured
 this. Did you do profiling? What did you pinpoint as the
 biggest bottlenecks?

 Cheers,
 Geoff



 ___
 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] [Bf-blender-cvs] [26206] Compiling issue

[joe]

jcmalloc seems the best, at least from the profiling results the
firefox people got with it.  Doug lea's malloc is a bit dated, iirc of
the three or four good ones, it was the worst? can't remember
precisely, I could easily be wrong.

Joe

On Sat, Jan 23, 2010 at 1:06 PM, Erwin Coumans erwin.coum...@gmail.com wrote:
 Have you tried the very fast and popular Doug Lea Malloc, or dlmalloc?

 ftp://g.oswego.edu/pub/misc/
 http://g.oswego.edu/dl/html/malloc.html

 Cheers,
 Erwin


 On 23 January 2010 10:49, Campbell Barton ideasma...@gmail.com wrote:
 did you try one of the malloc replacements? - should be able to do it
 without rebuilding blender even.
 I tried 3 popular malloc replacements (benchmarked with the game engine)
 jemalloc, nedmalloc and hoard IIRC None made much of a difference for
 me though perhaps the  BGE isnt a good test case, was also trying on
 linux with an optimized build.


 On Sat, Jan 23, 2010 at 5:21 PM, joe joe...@gmail.com wrote:
 This is also something I've had to deal with in the bmesh branch, and
 the code I wrote there should never see the light of day in trunk
 (which motivates me to tackle this now :) ).  It's really quite
 horrible what I wrote to deal with vgroups performance problems.

 Joe

 On Sat, Jan 23, 2010 at 8:20 AM, joe joe...@gmail.com wrote:
 The purpose was simple experimentation, since we need to do
 *something* and at the time I didn't think people would go for using
 jcmalloc.  Vgroups really are a bad source of performance loss, mostly
 in debug builds (which we need to be usable but aren't in some cases).
  I was hoping to elicit ideas from other people, and go from there.
 Anyway, it was silly of me to ignore the possibility of using
 jcmalloc, which we can probably drop in as a replacement for malloc
 within guardedalloc itself (and even have compile time options to have
 guardedalloc go straight through to jcmalloc).

 Joe

 On Sat, Jan 23, 2010 at 6:53 AM, Brecht Van Lommel bre...@blender.org 
 wrote:
 Hi Joe,

 Right, I replied to the wrong mail, I was talking about the
 guardedalloc changes. I understand this is experimental, but I don't
 think some more experimentation will be prove this to be the right
 thing to do. It may well lead to a speedup in simple test cases, but a
 simple use of pooling can lead to much wasted memory and make problems
 worse when running Blender for a while. So it is not clear to me what
 the purpose is here, if this is the start of writing an advanced
 memory allocator then I don't think we should try to do that
 ourselves, and if not then I don't think this can be good enough to
 put in a release.

 Brecht.

 On Sat, Jan 23, 2010 at 3:19 PM, joe joe...@gmail.com wrote:
 What are you talking about specifically?  It helps with ghash, because
 each bucket node was being allocated individually, causing a
 significant speed problem.  This particular solution was very
 appropriate; it's why we have the mempool library in the first place.

 Now, the experimental code I committed (#ifdef'd out) to guardedalloc
 is different (and was a
 different commit even).  This particular commit has nothing to do with
 that.  On that topic, OSX has (or had, anyway) a reputation for having
 a system allocator almost as slow as windows; linux is the only OS as
 far as I know (other then the BSDs I guess) that doesn't suffer from
 this.  So it's hardly simply a windows issue.

 The overhead we get from guardedalloc isn't all that bad, really.  I
 wasn't talking about that in the slightest.  What I was talking about
 was the significant performance loss we get from overusing the system
 allocator, which has caused significant problems for me and others.  I
 committed the code #ifdef'd out, so people who need it can play around
 with it but not cause problems for others.  There's a reason it's
 *experimental*.

 Joe

 ___
 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




 --
 - 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

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] [Bf-blender-cvs] [26206] Compiling issue

[joe]

http://blog.pavlov.net/2007/12/04/vlad-and-analysis-of-dtrace-was-used/

On Sat, Jan 23, 2010 at 5:56 PM, Erwin Coumans erwin.coum...@gmail.com wrote:
 Dough Lea's malloc was updated a few months ago. I think Unreal Engine
 3 is using it too.

 Do you have a URL of this allocator benchmark?

 Thanks,
 Erwin

 Sent from my iPhone

 On Jan 23, 2010, at 15:16, joe joe...@gmail.com wrote:

 jcmalloc seems the best, at least from the profiling results the
 firefox people got with it.  Doug lea's malloc is a bit dated, iirc of
 the three or four good ones, it was the worst? can't remember
 precisely, I could easily be wrong.

 Joe

 On Sat, Jan 23, 2010 at 1:06 PM, Erwin Coumans erwin.coum...@gmail.com
  wrote:
 Have you tried the very fast and popular Doug Lea Malloc, or
 dlmalloc?

 ftp://g.oswego.edu/pub/misc/
 http://g.oswego.edu/dl/html/malloc.html

 Cheers,
 Erwin


 On 23 January 2010 10:49, Campbell Barton ideasma...@gmail.com
 wrote:
 did you try one of the malloc replacements? - should be able to do
 it
 without rebuilding blender even.
 I tried 3 popular malloc replacements (benchmarked with the game
 engine)
 jemalloc, nedmalloc and hoard IIRC None made much of a difference
 for
 me though perhaps the  BGE isnt a good test case, was also trying on
 linux with an optimized build.


 On Sat, Jan 23, 2010 at 5:21 PM, joe joe...@gmail.com wrote:
 This is also something I've had to deal with in the bmesh branch,
 and
 the code I wrote there should never see the light of day in trunk
 (which motivates me to tackle this now :) ).  It's really quite
 horrible what I wrote to deal with vgroups performance problems.

 Joe

 On Sat, Jan 23, 2010 at 8:20 AM, joe joe...@gmail.com wrote:
 The purpose was simple experimentation, since we need to do
 *something* and at the time I didn't think people would go for
 using
 jcmalloc.  Vgroups really are a bad source of performance loss,
 mostly
 in debug builds (which we need to be usable but aren't in some
 cases).
  I was hoping to elicit ideas from other people, and go from
 there.
 Anyway, it was silly of me to ignore the possibility of using
 jcmalloc, which we can probably drop in as a replacement for
 malloc
 within guardedalloc itself (and even have compile time options
 to have
 guardedalloc go straight through to jcmalloc).

 Joe

 On Sat, Jan 23, 2010 at 6:53 AM, Brecht Van Lommel bre...@blender.org
  wrote:
 Hi Joe,

 Right, I replied to the wrong mail, I was talking about the
 guardedalloc changes. I understand this is experimental, but I
 don't
 think some more experimentation will be prove this to be the
 right
 thing to do. It may well lead to a speedup in simple test
 cases, but a
 simple use of pooling can lead to much wasted memory and make
 problems
 worse when running Blender for a while. So it is not clear to
 me what
 the purpose is here, if this is the start of writing an advanced
 memory allocator then I don't think we should try to do that
 ourselves, and if not then I don't think this can be good
 enough to
 put in a release.

 Brecht.

 On Sat, Jan 23, 2010 at 3:19 PM, joe joe...@gmail.com wrote:
 What are you talking about specifically?  It helps with ghash,
 because
 each bucket node was being allocated individually, causing a
 significant speed problem.  This particular solution was very
 appropriate; it's why we have the mempool library in the first
 place.

 Now, the experimental code I committed (#ifdef'd out) to
 guardedalloc
 is different (and was a
 different commit even).  This particular commit has nothing to
 do with
 that.  On that topic, OSX has (or had, anyway) a reputation
 for having
 a system allocator almost as slow as windows; linux is the
 only OS as
 far as I know (other then the BSDs I guess) that doesn't
 suffer from
 this.  So it's hardly simply a windows issue.

 The overhead we get from guardedalloc isn't all that bad,
 really.  I
 wasn't talking about that in the slightest.  What I was
 talking about
 was the significant performance loss we get from overusing the
 system
 allocator, which has caused significant problems for me and
 others.  I
 committed the code #ifdef'd out, so people who need it can
 play around
 with it but not cause problems for others.  There's a reason
 it's
 *experimental*.

 Joe

 ___
 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




 --
 - 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

 ___
 Bf

Re: [Bf-committers] New Developer Meeting minutes

[joe]

Yeah it's fairly common iirc.  I do, and I know of at least two other
devs who have done the same.

I think the problem here is none of us have time to test cmake
thoroughly to evaluate it, and I'm not sure how many other devs have
had the same speed issues I have, that motivates me to evaluate cmake
in the first place..

Joe

On Sat, Jan 16, 2010 at 8:30 AM, Erwin Coumans erwin.coum...@gmail.com wrote:
 How about those projectfiles_vc9? A working cmake should make them redundant.

 It would be great if Andrea Weikert (Elubie) and Benoit could switch
 from manual updating those projectfiles_vc9 (and vc7) to cmake.

 That would help cmake in Blender quite a bit I think.
 Cheers,
 Erwin

 Out of curiosity: are any of the scons users using those
 projectfiles_vc9 (occasionally) on Windows?



 2010/1/14 Benjamin Tolputt btolp...@internode.on.net:
 joe wrote:
 I use msvc for source editing and debugging, and scons for compiling.
 Build systems don't have to replace project files, I use scons mostly
 because there's more control that way for what I do.


 And if the project files were updated along with the Scons build files -
 that is all well  good. Seriously, all I am concerned about is the
 capability of extending  debugging Blender in an IDE (namely MSVC 
 XCode being a Windows/Mac guy for graphics). CMake has that by
 default, being the way it operates, were Scons to provide the project
 files either automatically or through the use of a command line
 parameter - I'd be all for it.

 The slower build time of Scons, while a niggle, is not the issue. It is
 the disconnect between using/editing Scons  using an IDE that is
 causing myself and the developers I've talked to (an entire two of them
 :P ) grief. The build of a release version of Blender is not a daily
 thing. Updating the projects to the latest versions from SVN is such a
 common task.

 --
 Regards,

 Benjamin Tolputt
 Analyst Programmer

 ___
 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

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] New Developer Meeting minutes

[joe]

I use msvc for source editing and debugging, and scons for compiling.
Build systems don't have to replace project files, I use scons mostly
because there's more control that way for what I do.

Joe

On Thu, Jan 14, 2010 at 2:28 PM, Mike Pan madoni...@gmail.com wrote:
 As mentioned before, I think one of the key benefit of cmake is the ability
 to generate solution/project files.  This might be not be a huge deal to
 seasoned coders, but for beginner coders who just wants to explore the
 Blender source code a bit, having an IDE like Visual Studio really helps.

 -mike





 On Thu, Jan 14, 2010 at 2:21 PM, joe joe...@gmail.com wrote:

 Sounds like us scons people need to try out cmake.  See how good it
 is.  I don't have time now, but will try to get to it.  Also need to
 look at how easy it is to maintain, that's one of the really nice
 things about scons.

 Joe

 On Thu, Jan 14, 2010 at 6:04 AM, Miguel A. Figueroa-Villanueva
 migu...@ieee.org wrote:
  On Tue, Jan 12, 2010 at 2:51 AM, Mats Holmberg wrote:
  On 12.1.2010, at 8.39, Nathan Letwory wrote:
  2010/1/12 Erwin Coumans:
  I'm surprised of so much resistance among the Blender developers
  to such a nice build system as cmake.
 
  Thanks,
  Erwin
 
  We can also reverse the question - we have a very nice and working
  SCons system. Why would you want to get rid of the nice system I
  created?
 
  I'm surprised at the resistance among certain people to such a nice
  build system as SCons
 
  Just to comment on this: I know nothing about the hassle that is
 required for maintaining any of these systems, but from a Blender user
 standpoint scons is very easy to use. As Nathan said, I do svn up  python
 scons/scons.py and that's all that's ever needed. During the years, I
 haven't seen anything being even close to that kind of ease of use.
 
  Dont' take that away, please!
 
  -mats
 
  I'm not a community member, so please pardon the intrusion (I am
  interested in blender, have compiled it with the cmake system, and I
  am looking forward to contributing to it in the future, but haven't
  had the time yet...).
 
  However, I just started reading this thread and it seems to me there
  is a lot of resistance, as Erwin mentions, to cmake without real
  justification. Although I understand the why, I think the arguments
  against CMake are not well founded. Most, if not all, of the problems
  that have been mentioned are related to rules either not updated or
  wrongly written in the CMakeLists.txt. These are issues with the build
  system maintainers not with CMake's capabilities. With properly
  written and maintained CMake files you would have both a very powerful
  command line based system and an equally powerful IDE based system.
 
  For example, the argument of ease of use can certainly be used as a
  positive aspect of scons, but I find it to be unfounded when arguing
  against CMake. That is because I do the following version of svn up
   python scons/scons.py to build my projects, not only on Ubuntu but
  on Windows:
 
  ctest -S simple_ctest_script.cmake
 
  With a small script ctest will: update (from svn,cvs,hg,etc),
  configure, build, test, and submit the build to a dashboard (or any
  subset of these steps).
 
  Again, I don't want to argue against scons, but I think that arguments
  against cmake are not really flaws of cmake but rather bad experiences
  because of not knowing how to do things (either from part of the user
  or the build system maintainer) and not giving it enough of a chance.
  I think that if the blender community really gives cmake a chance, it
  will not be dissapointed with the clean, simple, and flexible product
  that cmake can provide. Whether it should then replace, coexist, etc.
  with scons is a discussion that I wouldn't feel comfortable providing
  any input on.
 
  Just my $0.02,
  --Miguel
  ___
  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

 ___
 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] Bringing anti-aliasing back by fixing selection method

[joe]

Explicitly disabling it in the selection draw functions seemed to work
well enough before, via glDisable(GL_ARB_MULTISELECT).

Joe

On Wed, Jan 13, 2010 at 8:32 AM, Damien Plisson damien.plis...@yahoo.fr wrote:
 Hi all,

 FSAA was breaking border/lasso select operations (e.g. orphan vertices were 
 selected).

 FYI, The root cause for this issue is that as soon as FSAA is enabled at 
 pixelformat level, even if not enabled afterwards, some color artifacts may 
 appear in draw operations.
 This breaks the color coding selection method that is currently used in 
 Blender for various selection tools like border, lasso, circle... when 
 occlude geometry is enabled.

 To fix it, the color coding selection method has to be replaced, and this is 
 what this patch does by implementing the occlusion query method for the 
 border/lasso/circle selection tools:

 http://projects.blender.org/tracker/index.php?func=detailaid=20660group_id=9atid=127

 I'm looking forward for your feedback / comments / suggestions...

 Damien
 ___
 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] Bringing anti-aliasing back by fixing selection method

[joe]

Though of course rewriting it more properly is good too.  I've not
looked into occlusion query since the original nvidia extension; how
well does it work across disparate video cards?

Joe

On Wed, Jan 13, 2010 at 9:15 PM, joe joe...@gmail.com wrote:
 Explicitly disabling it in the selection draw functions seemed to work
 well enough before, via glDisable(GL_ARB_MULTISELECT).

 Joe

 On Wed, Jan 13, 2010 at 8:32 AM, Damien Plisson damien.plis...@yahoo.fr 
 wrote:
 Hi all,

 FSAA was breaking border/lasso select operations (e.g. orphan vertices were 
 selected).

 FYI, The root cause for this issue is that as soon as FSAA is enabled at 
 pixelformat level, even if not enabled afterwards, some color artifacts may 
 appear in draw operations.
 This breaks the color coding selection method that is currently used in 
 Blender for various selection tools like border, lasso, circle... when 
 occlude geometry is enabled.

 To fix it, the color coding selection method has to be replaced, and this is 
 what this patch does by implementing the occlusion query method for the 
 border/lasso/circle selection tools:

 http://projects.blender.org/tracker/index.php?func=detailaid=20660group_id=9atid=127

 I'm looking forward for your feedback / comments / suggestions...

 Damien
 ___
 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] New Developer Meeting minutes

[joe]

On Mon, Jan 11, 2010 at 10:10 AM, Erwin Coumans erwin.coum...@gmail.com wrote:
 Just don't complain that dependencies don't reliably work, or that
 cmake is a bit slow :-)

 I follow the advice of the CMake developers for the Bullet project,
 and I'm happy with it.

This isn't convincing me that CMake is any better then anything else;
it may generate project files, but I don't use that, and our scons
setup could be setup to do the same thing as well.  I care very much
about dependencies, mostly because I can't afford to do clean builds
as often as is often necessary in a build system with unreliable
dependency updates (old, crappy hardware is just too slow to do that).

Joe

On Mon, Jan 11, 2010 at 10:10 AM, Erwin Coumans erwin.coum...@gmail.com wrote:
 From the CMake mailinglist:

 http://www.cmake.org/pipermail/cmake/2009-July/030535.html


 The problem with globbing is that CMake has no way to determine that new

 source (or header) files were added to a directory, other than ALWAYS
 running when someone types 'make' (or the VS equivalent). This is not
 really desirable behaviour, because oftentimes no new files will have
 been added. And therefore, that's not how CMake behaves.

 So, in general, when using globbing, YOU are responsible for rerunning
 CMake whenever you've added a source file. Otherwise you run the risk of
 the new file not being compiled. Furthermore, you might accidentally
 compile sources that were just lying around in your directory as test
 code. Deletion of sources can also cause interesting effects if you
 create a library, because the object will remain in that library until
 you (manually) remove and recreate the library.

 I hope my examples convinced you enough that globbing is (in general) a
 bad idea.


 Re-running cmake each time to recognize new/deleted headerfiles
 doesn't seem efficient,

 but if developers prefer ease of use at the cost of some performance
 you might want to use GLOB.



 2010/1/11 Erwin Coumans erwin.coum...@gmail.com

 The stackoverflow answer seem to confirm there are some dependencies and
 performance issues with GLOB.

 I'm interested to hear what the 'official' recommendation is by the cmake
 developers.
 Cheers,
 Erwin


 2010/1/11 José Ignacio jose.cyb...@gmail.com

 On Mon, Jan 11, 2010 at 1:17 PM, Erwin Coumans erwin.coum...@gmail.com
 wrote:
  The is no problem using GLOB with a wildcard, as I mentioned at least
  times in this thread ;)
 
  But explicitly listing each file seems recommended, I forgot why.
  Perhaps GLOB needs to search for (potential) new headerfiles, every
  time you build and a .cpp changed (slowing down things unnecesarily)?
 
  Perhaps reading the docs, using google or asking on the cmake
  mailingslist will tell why GLOB can better be avoided in CMakeLists.txt?
 
 IIRC, if you use globbing and added a new file after you build for the
 first time, it won't take it into account for the next call of make
 unless you touch the CMakeLists.txt file or clear the cache and
 rebuild. (though maybe that behavior changed on newer versions of
 cmake)

 oh, a google search gave me this link:

 http://stackoverflow.com/questions/1027247/best-way-to-specify-sourcefiles-in-cmake

  Cheers,
  Erwin
 
 ___
 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

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] New Developer Meeting minutes

[joe]

That's what I was trying to figure out, whether it's as good as scons
or not.  It sounds like it might be comparable, so I'm going to try it
as soon as I get time.  If it is, I'll be very happy, since for all
it's ease of use and maintenance, scons really is super slow.

Joe

On Mon, Jan 11, 2010 at 2:30 PM, Erwin Coumans erwin.coum...@gmail.com wrote:
 ah, ok, I would have been interested in open source scons project file
 generation.

 (actually at Havok we had scons create cross-platform project files,
 but these extensions were kept in-house)

 As far as I know, cmake works very well for both command line and
 projectfiles.

 I still haven't heard a convincing argument of scons features that cmake
 doesn't have.
 GLOB works fine (even though manual is better)

 How is cmake not good enough?
 Thanks,
 Erwin




 2010/1/11 joe joe...@gmail.com

 I wasn't saying we should abandon support for projectfiles.  My point
 is that cmake must perform on the command line build workflow as well
 as project file workflows.  And that support for projectfiles doesn't
 make it great for command line (and vice versa).

 I wasn't advocating generating project files from our scons system,
 heh.  I'm all for replacing scons, actually, either by rewriting our
 scons wrapper and infrastructure to use waf, or replacing it with
 cmake if cmake is good enough.

 Joe

 On Mon, Jan 11, 2010 at 2:10 PM, Erwin Coumans erwin.coum...@gmail.com
 wrote:
  it (cmake) may generate project files, but I don't use that
 
  It sounds a little bit selfish, there are many developers who want to use
  project files.
 
  and our scons setup could be setup to do the same thing as well.
 
  Can scons create decent MSVC and Xcode project files? Who maintains such
  project generation?
 
  Thanks,
  Erwin
 
 
  2010/1/11 joe joe...@gmail.com
 
  Does it run automatically or do you have to run it yourself?
 
  Joe
 
  On Mon, Jan 11, 2010 at 1:53 PM, Campbell Barton ideasma...@gmail.com
  wrote:
   @joe, From my experience cmake doesnt require you to do more clean
   builds then scons. The only thing is is dependencies change cmake .
   needs to run again in the build dir, building after only does a
   partial build like scons.
  
   If I understand this correctly, only generating the Makefiles is
   slower with GLOB, not running the subsequent make's (else it should
   find the new C/H files also).
  
   re: defining all files, not having to re-run cmake . would be nice
   but Im not that fussed, if we only used CMake, maintaining the file
   lists might not be so hard, but is some dev adds a file and they use
   another build system its annoying for them to have to update the CMake
   files (think msvc project files).
  
   On Mon, Jan 11, 2010 at 10:41 PM, joe joe...@gmail.com wrote:
   On Mon, Jan 11, 2010 at 10:10 AM, Erwin Coumans 
  erwin.coum...@gmail.com wrote:
   Just don't complain that dependencies don't reliably work, or that
   cmake is a bit slow :-)
  
   I follow the advice of the CMake developers for the Bullet project,
   and I'm happy with it.
  
   This isn't convincing me that CMake is any better then anything else;
   it may generate project files, but I don't use that, and our scons
   setup could be setup to do the same thing as well.  I care very much
   about dependencies, mostly because I can't afford to do clean builds
   as often as is often necessary in a build system with unreliable
   dependency updates (old, crappy hardware is just too slow to do
 that).
  
   Joe
  
   On Mon, Jan 11, 2010 at 10:10 AM, Erwin Coumans 
  erwin.coum...@gmail.com wrote:
   From the CMake mailinglist:
  
   http://www.cmake.org/pipermail/cmake/2009-July/030535.html
  
  
   The problem with globbing is that CMake has no way to determine
 that
  new
  
   source (or header) files were added to a directory, other than
 ALWAYS
   running when someone types 'make' (or the VS equivalent). This is
 not
   really desirable behaviour, because oftentimes no new files will
 have
   been added. And therefore, that's not how CMake behaves.
  
   So, in general, when using globbing, YOU are responsible for
 rerunning
   CMake whenever you've added a source file. Otherwise you run the
 risk
  of
   the new file not being compiled. Furthermore, you might accidentally
   compile sources that were just lying around in your directory as
 test
   code. Deletion of sources can also cause interesting effects if you
   create a library, because the object will remain in that library
 until
   you (manually) remove and recreate the library.
  
   I hope my examples convinced you enough that globbing is (in
 general) a
   bad idea.
  
  
   Re-running cmake each time to recognize new/deleted headerfiles
   doesn't seem efficient,
  
   but if developers prefer ease of use at the cost of some performance
   you might want to use GLOB.
  
  
  
   2010/1/11 Erwin Coumans erwin.coum...@gmail.com
  
   The stackoverflow answer seem to confirm there are some

Re: [Bf-committers] New Developer Meeting minutes

[joe]

Well, it's had a rough start and some of us are wary of using it
exclusively without assurance it's not going to be a step backwards :)
 I also think the fact that it generates makefiles makes some of us
initially nervous, since makefiles are usually synonymous with
immensely painful and difficult to maintain.

Joe

On Mon, Jan 11, 2010 at 3:08 PM, Benjamin Tolputt
btolp...@internode.on.net wrote:
 Erwin Coumans wrote:
 Have you seriously tried to find a solution?

 I'm surprised of so much resistance among the Blender developers
 to such a nice build system as cmake.

 Agreed. There seems to be quite a few posts *looking for* problems with
 CMake... I have not found any problems with CMake (provided I've set the
 right options) and the capability of having a standard make along with
 XCode  MSVC projects (I compile on all three platforms, though only use
 Blender on Win/Mac) kind of tilts things in CMake's favour.

 That is not to say Scons is bad, I find it pretty good too - just not as
 easy to use with an IDE. I just don't understand the animosity there
 appears to be for CMake.

 --
 Regards,

 Benjamin Tolputt
 Analyst Programmer


 ___
 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] New Developer Meeting minutes

[joe]

But of course I'm going to look into it more now, I would love to be
able to not have to deal with the sheer slowness of scons.

Joe

On Mon, Jan 11, 2010 at 3:26 PM, joe joe...@gmail.com wrote:
 Well, it's had a rough start and some of us are wary of using it
 exclusively without assurance it's not going to be a step backwards :)
  I also think the fact that it generates makefiles makes some of us
 initially nervous, since makefiles are usually synonymous with
 immensely painful and difficult to maintain.

 Joe

 On Mon, Jan 11, 2010 at 3:08 PM, Benjamin Tolputt
 btolp...@internode.on.net wrote:
 Erwin Coumans wrote:
 Have you seriously tried to find a solution?

 I'm surprised of so much resistance among the Blender developers
 to such a nice build system as cmake.

 Agreed. There seems to be quite a few posts *looking for* problems with
 CMake... I have not found any problems with CMake (provided I've set the
 right options) and the capability of having a standard make along with
 XCode  MSVC projects (I compile on all three platforms, though only use
 Blender on Win/Mac) kind of tilts things in CMake's favour.

 That is not to say Scons is bad, I find it pretty good too - just not as
 easy to use with an IDE. I just don't understand the animosity there
 appears to be for CMake.

 --
 Regards,

 Benjamin Tolputt
 Analyst Programmer


 ___
 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] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [25765] trunk/blender/source/blender/ windowmanager/intern/wm_gesture.c: *Disabled filled lasso drawing on Windows for now, was ca

[joe]

What sort of strange problems? As far as I know, the SGI tesselator
implementation is used everywhere.

Anyway, you can use scanfill, it's not really difficult to use, look
at the old lasso code (though the old lasso code went through the
curve code and didn't use scanfill directly, not sure it really
matters though).

Joe

On Tue, Jan 5, 2010 at 10:51 PM, Matt Ebb m...@mke3.net wrote:
 Revision: 25765
          
 http://projects.blender.org/plugins/scmsvn/viewcvs.php?view=revroot=bf-blenderrevision=25765
 Author:   broken
 Date:     2010-01-06 07:51:04 +0100 (Wed, 06 Jan 2010)

 Log Message:
 ---
 *Disabled filled lasso drawing on Windows for now, was causing some strange 
 problems,
 perhaps GLU incompatibilities? If any Windows GL guru can help here, it would 
 be
 most appreciated!

 Modified Paths:
 --
    trunk/blender/source/blender/windowmanager/intern/wm_gesture.c

 Modified: trunk/blender/source/blender/windowmanager/intern/wm_gesture.c
 ===
 --- trunk/blender/source/blender/windowmanager/intern/wm_gesture.c      
 2010-01-06 06:04:07 UTC (rev 25764)
 +++ trunk/blender/source/blender/windowmanager/intern/wm_gesture.c      
 2010-01-06 06:51:04 UTC (rev 25765)
 @@ -209,6 +209,9 @@

  }

 +#ifndef WIN32
 +/* Disabled for now, causing problems on Windows.. */
 +
  /* more than 64 intersections will just leak.. not much and not a likely 
 scenario */
  typedef struct TessData { int num; short *intersections[64]; } TessData;

 @@ -237,10 +240,14 @@
        gluDeleteTess(tess);
  }

 +#endif
 +
  static void wm_gesture_draw_lasso(wmWindow *win, wmGesture *gt)
  {
        short *lasso= (short *)gt-customdata;
        int i;
 +
 +#ifndef WIN32
        TessData *data=MEM_callocN(sizeof(TessData), tesselation data);
        GLUtesselator *tess = gluNewTess();

 @@ -263,6 +270,8 @@
        glDisable(GL_BLEND);

        free_tess_data(tess, data);
 +
 +#endif

        glEnable(GL_LINE_STIPPLE);
        glColor3ub(96, 96, 96);


 ___
 Bf-blender-cvs mailing list
 bf-blender-...@blender.org
 http://lists.blender.org/mailman/listinfo/bf-blender-cvs

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Usage of PyUnicode_FromString() in blender 2.50

[joe]

BTW, keep in mind that on windows, argv is always in ascii (not UTF-8).

Joe

On Mon, Dec 7, 2009 at 1:44 AM, Yomgui yomg...@gmail.com wrote:
 Hi,

 I've seen in many places that the Python function PyUnicode_FromString
 (and similar) is used to convert system strings like argv[] and IO
 pathname.

 If we look at the Python 3.1 documentation
 (http://docs.python.org/3.1/c-api/unicode.html?highlight=pyunicode_fromstring#PyUnicode_FromString)
 this function supposes that the input string is UTF-8 encoded.
 That's not a strict rule for all OS. This function should be reserved
 to pass string for runtime usage like if it was given in a script, but
 not for OS/IO strings.

 A better (I know... with just more arguments) function to convert
 system strings is PyUnicode_Decode()
 and use as encoding parameter: Py_FileSystemDefaultEncoding

 Thanks.
 ___
 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] View data?

[joe]

Well, what with the recent changes in the python api in the BGE, I
think it's reasonable for people to ask questions about it.

http://www.blender.org/documentation/249PythonDoc/GE/index.html

Here's the API reference for the game engine.  I'd suggest asking
further questions on irc://irc.freenode.net/blendercoders , though GE
people seem to show up somewhat randomly so you might not always be
able to get help.

Joe

On Thu, Dec 3, 2009 at 6:03 PM, José Ignacio jose.cyb...@gmail.com wrote:
 On Thu, Dec 3, 2009 at 11:00 PM, Scott Wengenroth
 weng8...@kettering.edu wrote:
 If I have a Python script as a controller in the Game Logic for an object, 
 is there any way for that script to get data of, say, what a camera was 
 viewing?

 Wengenroth


 Could you elaborate, please? also note this is not an user support
 list, but a developers' forum.

 Thanks
 ___
 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] GPU computing

[joe]

Working on the renderer would be infeasible, however.  You'd have to
essentially rewrite the whole thing.  Physics would be the same way.
The reason I mentioned subsurf and armature is they're much smaller
subsystems, and are much more feasible projects.

Animation is a big part of blender, and faster subsurf/armature
systems would be very, very helpful.  To be honest it'd be far more
helpful then faster physics or rendering systems, and you'd have a
much better shot at success.

Joe

On Tue, Nov 24, 2009 at 6:42 AM, Ishan Arora ishanar...@gmail.com wrote:
 @ Farsthary,

  I would recomend OpenCL, since it aims to be hardware independent, not
 even just GPU but almost every piece of metal out there that could
 perform calculations :) , while CUDA is currently more mature than OpenCL
 is tied to NVIDIA brand :(
 I know CUDA is tied to NVIDIA, but I can not figure out where to begin
 with OpenCL. There is one available for Mac, one for NVIDIA, and if I
 am right one for ATI too. Windows has its own API called
 DirectCompute.
 However the kernel based programming paradigm is more or less the same
 in both CUDA and OpenCL. So even if one does not work out well,
 porting to the other wont be difficult.

  And while is not an easy task what you propose I think the most needed
 are are: Rendering,Modeling,Compositing
 I know it wont be easy. Thankfully I have this big dev group to help me out :)

 @Joe

 I'm not sure how many areas we should be messing with GPU stuff right
 now. . .I'd say ignore the renderer and physics systems, but subsurf
 and the armature modifies might be good candidates to play around
 with.  That's just me though.
 Okay. But I think the whole point of GPU computing is to aid in the
 most CPU intensive tasks. I think rendering would be the top
 candidate, and all the computational parts that make UI less
 responsive

 Regards,
 Ishan
 ___
 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] GPU computing

[joe]

Our render archetecture doesn't lend itself to gpu-type processing.
You might be able to hack in something for e.g. soft shadows or
whatever, but I think that would be a mistake; such an effort should
be coordinated with the other refactors we need to do there, and I
don't know if anyone even knows when those refactors will happen, or
what their final form will be.

Joe

On Tue, Nov 24, 2009 at 7:19 AM, Charles Wardlaw
cward...@marchentertainment.com wrote:

 Animation is a big part of blender, and faster subsurf/armature
 systems would be very, very helpful.  To be honest it'd be far more
 helpful then faster physics or rendering systems, and you'd have a
 much better shot at success.


 I would love to see GPGPU-enabled armature calculations... Although, since
 many of the best rigs require custom python scripts I wonder if Python
 wouldn't be a bottleneck there.

 On the renderer: you wouldn't have to rewrite everything.  Not every part of
 the rendering process benefits from multiprocessing anyways, just like not
 every part benefits from the various data structures.  But there've been a
 number of nice papers on using GPGPU processing to accelerate the parts of
 rendering that tend to be the most heavy -- ray collisions, subdivision (as
 you said above), ambient occlusion, or even the generation of point clouds
 for other purposes (AO, GI, FG).  If Blender could generate point clouds
 quickly and that data could be accessed and exported, a lot of studios would
 be very interested.

 There's also the idea of accelerating nodes in the compositing or texture
 graphs.  And now that sculpt is multithreaded, I wonder how hard it would be
 to get some of the processing offloaded to OpenCL cores.

 Then again, hardware-accelerated subdivision is a serious boon.  At work
 we're using Mach Studio, which is a GPU-based real-time rendering system.
  It subdivides on the fly, on the card, and even with a few million polys in
 a scene you have completely interactive turnarounds.  Less so with
 full-scene AO, but it's still usable.  The last version released something
 akin to the DX11 Tessellator functionality on DX10 cards, and watching it
 generate a million polygons from a bump map and a plane is something to
 behold.

 ~ C
 ___
 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