Re: [Bf-committers] GSoC 2018: Layer Painting Proposal

[Kévin Dietrich]

Le 2018-03-23 00:28, Cheryl Chen a écrit :

> Thank you for the support, Ricardo, and thanks for the feedback, Kévin!
> I hadn't really considered how to deal with the performance issues, and
> your diff is a really helpful reference as well. May I ask what other
> difficulties you encountered while working on this feature? It may be
> because of time constraints and changes to the Blender codebase, but it is
> a bit concerning that a fair bit of work has gone into building layer
> support (seeing that there also was a GSoC project in 2010), and it hasn't
> really been completed yet. It will be really helpful to gain some more
> insight, as I may be approaching this task too naively...
> 
> Best,
> Cheryl
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers

Performance was the main issue during the various implementation
efforts. Then there is also the case of how to save layer data as
Blender does not save images currently. However, in the diff, this
behavior was changed such that image data and layers are saved to .blend
files. So performance and I/O are the important bits. 

Regards, 

Kévin.
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] GSoC 2018: Layer Painting Proposal

[Kévin Dietrich]

Le 2018-03-18 16:47, Cheryl Chen a écrit :

> Hello,
> 
> I'm Cheryl, and I'm interested in improving Blender's current texture paint
> system through the GSoC project on layer painting. I've finished the first
> draft of my proposal, and I'd really appreciate any feedback on it,
> particularly on whether the scope of the project seems reasonable, and if
> there are any other things I should consider.
> 
> Here is the link to the doc: https://docs.google.com/document/d/
> 1MlZnedwL738OmMK1IAi4veO-KDsqefNBkpfgrUR757M/edit?usp=sharing
> 
> 
> Thank you for your time!
> 
> Best,
> 
> Cheryl Chen
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers

Hi Cheryl, 

I used to worked on this very feature
(https://developer.blender.org/D1135) so I can give you some quick
feedback. 

For GSOC, your plan ('Minimum Viable Project') seems feasable.
Implementing a layer system is quite straightforward as the features
working on an image buffer will work as well on a layer buffer. So there
isn't much to implement apart from the logic of managing the layers
(adding, removing, blending, hiding, selecting current, etc...). For
example in the painting/brush code, all you have to do to support layers
is substitute the image buffer with the currently selected layer's
buffer. 

The greatest issue with such a feature I found was rendering speed.
Every time there is brush stroke, we have to compute the final image
(merge/blend all the layers) to be able to display it, and we can't
really do that on the GPU (through OpenGL). So the more layers you have,
the slower it gets. I think the only way to properly support such
feature would be to have a tiled image buffer in Blender (something easy
built on top of ImBuf could work), and then the paint system would need
to work with the tiles in mind such that only the tiles that have
changed are merged/blended for display. 

That's it from me at the moment, 

Best, 
Kévin.
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Do we accept to have infinite recursive RNA layout patterns?

[Kévin Dietrich]

Hi Bastien, 

I remember reading some details/documentation about this situation when
I worked on supporting OpenVDB in the PointCache system, but I can't
find the source back. The only thing I found is a line from Lukas' wiki
page about his Alembic point cache ideas [1]: 

"Furthermore the RNA definition for these point cache lists is horrible:
it defines a collection property inside PointCache, which leads back to
the list of which it is a part - uagh! Presumably that was a lazy
solution to avoid defining the collection in each of the point cache use
cases ..." 

So the culprit seems to be our good old friend laziness. Maybe there is
a more detailed explanation out there. 

Cheers, 

Kévin 

Le 2018-03-18 16:04, Bastien Montagne a écrit :

> FYI, decided to go with a somewhat ugly, but safe and non-API-breaking 
> solution for now, see 
> https://developer.blender.org/rB0301df40e5b6c51575d7f9013a1a28b901063829
> 
> Bastien
> 
> On 16/03/2018 15:50, Bastien Montagne wrote: 
> 
>> Hi devs,
>> 
>> So, was investigating a weird issue today found while doing some static 
>> override tests, and ended up finding the someone, at some era lost in the 
>> mist of times, had the genius idea of creating a sort of infinite recursion 
>> in  PointCache RNA struct (defined in rna_object_force.c). That is, 
>> pointcache owner has a pointer to active pointcache, and said active 
>> pointcache has a collection of all pointcaches from owner's list (since in 
>> DNA, PointCache is actually a linked list item).
>> 
>> Needless to say that this totally breaks attempt to walk in RNA data, since 
>> you'll indefinitely dive into recursive versions of point_caches collection 
>> items (giving RNA paths like that: 
>> 'particle_systems["feathers_big"].point_cache.point_caches[0].point_caches[0].point_caches[0]').
>> 
>> Before nuking this non-sense away and sanitizing the mess, I thought I'd ask 
>> if someone remembers any good reason for current RNA code/layout there... 
>> Since changing that will introduce RNA API breakage (though point_cache does 
>> not seems to be used by any addon in our repositories currently), would also 
>> probably only do it in 2.8 branch?
>> 
>> Cheers,
>> Bastien
>> 
>> ___
>> 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

 

Links:
--
[1]
https://wiki.blender.org/index.php/User:Phonybone/PointCache/InitialThoughts
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Building with openvdb

[Kévin Dietrich]

Hi Dave, 

OpenVDB 4.x has some API breakage, and only OpenVDB 3.x is supported for
now. Will probably make the switch to OpenVDB 4.x for Blender 2.8 since
it is using C++11 by default, and Blender is not yet built with C++11. 

Cheers, 

Kévin 

Le 2017-06-11 12:08, Dave Plater a écrit :

> Hi, I'm trying to introduce openvdb into the blender build. I've created 
> the openvdb package version 4.0.1 (Very memory hungry build) and then am 
> attempting to build blender but I get a build failure in
> intern/openvdb/intern/openvdb_writer.cc:
> [ 1002s] 
> /home/abuild/rpmbuild/BUILD/blender-2.78c/intern/openvdb/intern/openvdb_writer.cc:
>  
> In member function 'void OpenVDBWriter::insert(const 
> openvdb::v4_0_1::GridBase&)':
> [ 1002s] 
> /home/abuild/rpmbuild/BUILD/blender-2.78c/intern/openvdb/intern/openvdb_writer.cc:48:36:
>  
> error: no matching function for call to 
> 'std::vector 
>>::push_back(openvdb::v4_0_1::GridBase::ConstPtr)'
> [ 1002s]   m_grids->push_back(grid.copyGrid());
> [ 1002s] ^
> [ 1002s] In file included from /usr/include/c++/7/vector:64:0,
> [ 1002s]  from 
> /usr/include/boost/random/detail/polynomial.hpp:18,
> [ 1002s]  from 
> /usr/include/boost/random/mersenne_twister.hpp:32,
> [ 1002s]  from /usr/include/openvdb/math/Math.h:48,
> [ 1002s]  from /usr/include/openvdb/Types.h:37,
> [ 1002s]  from /usr/include/openvdb/openvdb.h:35,
> [ 1002s]  from 
> /home/abuild/rpmbuild/BUILD/blender-2.78c/intern/openvdb/intern/openvdb_writer.h:29,
> [ 1002s]  from 
> /home/abuild/rpmbuild/BUILD/blender-2.78c/intern/openvdb/intern/openvdb_writer.cc:26:
> [ 1002s] /usr/include/c++/7/bits/stl_vector.h:939:7: note: candidate: 
> void std::vector<_Tp, _Alloc>::push_back(const value_type&) [with _Tp = 
> std::shared_ptr; _Alloc = 
> std::allocator >; 
> std::vector<_Tp, _Alloc>::value_type = 
> std::shared_ptr]
> [ 1002s]push_back(const value_type& __x)
> [ 1002s]^
> [ 1002s] /usr/include/c++/7/bits/stl_vector.h:939:7: note:   no known 
> conversion for argument 1 from 'openvdb::v4_0_1::GridBase::ConstPtr {aka 
> std::shared_ptr}' to 'const value_type& 
> {aka const std::shared_ptr&}'
> [ 1002s] /usr/include/c++/7/bits/stl_vector.h:953:7: note: candidate: 
> void std::vector<_Tp, _Alloc>::push_back(std::vector<_Tp, 
> _Alloc>::value_type&&) [with _Tp = 
> std::shared_ptr; _Alloc = 
> std::allocator >; 
> std::vector<_Tp, _Alloc>::value_type = 
> std::shared_ptr]
> [ 1002s]push_back(value_type&& __x)
> [ 1002s]^
> [ 1002s] /usr/include/c++/7/bits/stl_vector.h:953:7: note:   no known 
> conversion for argument 1 from 'openvdb::v4_0_1::GridBase::ConstPtr {aka 
> std::shared_ptr}' to 
> 'std::vector >::value_type&& 
> {aka std::shared_ptr&&}'
> 
> Full build log at:
> https://build.opensuse.org/build/home:plater:blender/openSUSE_Tumbleweed/x86_64/blender/_log
> This is built with gcc 7 my 42.2 build with gcc48 fails to transfer the 
> -std=c++11 flag to the build, log at:
> https://build.opensuse.org/build/home:plater:blender/Leap_42.2/x86_64/blender/_log
> Have a choice for gcc5 and 6 but 42.2 defaults to gcc48.
> 
> Will appreciate any help.
> Thanks
> Dave Plater
> ___
> 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] Making C++11 required for blender2.8 branch

[Kévin Dietrich]

Le 2016-10-04 12:51, Sergey Sharybin a écrit : 

Hi, 

I'm all in for the upgrade.

> Things i'm against:
> 
> - Using shared/uniq pointers all over the place. Get the proper ownership
> model!

Whilst I may agree that shared_ptrs are basically global variables, and
that their predominant use in libs like OpenVDB is a PITA, I don't
necessarily think they go against a proper ownership model. 

The goal of unique_ptrs, as far as RAII is concerned, is to save your
ass if you forget to call `delete` (and we both know that happens, same
as `free`), or if an exception is thrown, to make sure memory is freed;
then they also force you to be mindful of the lifetime of the objects,
and since you cannot copy them (operator= is tagged as delete), the
owner is the one who created them. How does that go against a proper
ownership model? 

So my opinion would be: allowing them but be critical when they appear,
especially for shared_ptrs ; do a case by case scenario. Ultimately, in
the case of Blender, you'll need to pass raw pointers between the C and
C++ interfaces if you have to do so, therefore smart pointers can be
tricky to manage here. The object_node branch has a good example of that
(managing a refcounted pointer passed between nodes). 

> - Using auto, it's not hard to watch your types and using auto makes code
> much more tricky to follow

On the contrary, I'm all in for this one. `auto` does not necessarily
make the code harder to follow. I use it everyday, and can easily follow
code, even for code I haven't written. `auto` also forces you to always
initialize the variables, so the type is still known. When dealing with
heavily templated libraries, like OpenVDB, or ones with a shitload of
namespaces, like Alembic, `auto` is a breeze too. 

I'd rather see (and type!): 
  const auto &first = grid->cBeginOn(); 
than: 
  const typename GridType::ValueOnIter &iter = grid->cBeginOn(); 

> Things i can be convinced for:
> 
> - Enum classes

Downside is having to overload the binary operators if you intend to use
the enum as bitflags. But they don't hurt. 

> - Variadic templates (man, will make some OpenCL area in Cycles so much
> more cleaner!)

I don't use them that much, not sure if I did in real code, but they are
useful, and I would vote for. 

> - Static assert. I'm using it in Cycles, wouldn't mind if it's used more.

I wouldn't mind either. 

Also, what about lambdas? I'm a sucker for those. 

Cheers, 
Kévin
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Alembic broken in blender2.8

[Kévin Dietrich]

Le 2016-10-02 20:14, Bastien Montagne a écrit :

> Currently you cannot build blender2.8 branch with alembic enabled, 
> because it still expects particles to be there.
> 
> Think ideally, this should be fixed by temporarily disabling particle 
> part of alembic code (with a #define e.g.), don't mind trying to do it 
> but would be better if someone knowing that code well could tackle this?
> 
> Cheers,
> Bastien
> 
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers

Hi, 

Just checked and the code was already disabled by yourself it seems back
in August (https://developer.blender.org/rB069569f8). I am getting two
compile errors here due to undefined variables named "psys" (from a
recent bug fix of mine). I will quickly push a fix for those. 

Cheers, 

Kévin.
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Alembic triangulation

[Kévin Dietrich]

Please use the bug tracker [1] to report bugs/issues, with simple
example files to reproduces them. 

If one software can open an Alembic file from Blender without issues,
and another can't, for basic things like normals, then the bug is mostly
likely in the other software, not Blender, we don't do anything fancy
here. Also, can 3ds Max import materials from other software without
issues? 

Le 2016-08-20 04:38, Adriano Oliveira a écrit :

> 
> 
> bf48750
> 
> 3) Bad normals when importing from Blender-Alembic into Unreal 4.13 and 3ds
> Mac 2017.
> 
> 4) 3ds Max doesn't import materials from Blender-Alembic. Unreal 4.13 does.
> 
> *Adriano A. Oliveira*
> Professor Adjunto do Curso de Cinema e Audiovisual
> Universidade Federal do Recôncavo da Bahia (UFRB)
> Centro de Artes Humanidades e Letras (CAHL)
> Matrícula: 1673892
> (71) 99181-0123 [VIVO] / (71) 99146-8523 [TIM]
> 
> 2016-08-19 19:36 GMT-03:00 Adriano Oliveira :
> 
> Kévin,
> 
> I am very interested in the workflow Blender-Unreal through Alembic. The
> idea is to use Unreal for real time rendering.
> Alembic in Unreal 4.13 is in preview state, so it will improve a lot.
> 
> Some findings:
> 
> 1) Alembic is very usefull to export destruction simulations. I used Cell
> Fracture to explode a cube and it produces houndreds of n-gons objects. On
> importing into Unreal, it gives errors. I think this would justify an
> triangulation option, as in OBJ export.
> 
> 2) I have some crashes on importing Alembic animated characters into
> Blender or Unreal that was exported without Flatten Hierarchy.
> 
> ;)
> 
> *Adriano A. Oliveira*
> Professor Adjunto do Curso de Cinema e Audiovisual
> Universidade Federal do Recôncavo da Bahia (UFRB)
> Centro de Artes Humanidades e Letras (CAHL)
> Matrícula: 1673892
> (71) 99181-0123 [VIVO] / (71) 99146-8523 [TIM]
> 
> 2016-08-19 19:10 GMT-03:00 Kévin Dietrich :
> 
> Le 2016-08-19 23:53, Adriano Oliveira a écrit :
> 
> Hi,
> 
> Is it possible to have an option to triangulate mesh on Alembic export. I am 
> trying to import a animation from Blender to Unreal 4.13 and the late
> ask for tri or quad faces.
> 
> Also it would be nice to have Z to Y convertion options, as long as Unreal 
> rotates the Alembic imports form Blender.
> 
> Congratulations for the grate job!
> 
> *Adriano A. Oliveira*
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers 
> Hi,
> 
> Adding an option to triangulate meshes in the exporter wouldn't that
> much of a trouble (though it would have to wait for after the 2.78
> release), but I have to ask what prevents you from triangulating the
> meshes before exporting? If you've got a lot of objects to triangulate,
> a simple Python script can be written to automate the process. Shall it
> be a destructive operation, or shall it preserve the state of the meshes
> (meaning meshes in Blender are not triangulated, but the exported ones
> are)?
> 
> For the axis conversion, Alembic files written from Blender follow the
> Alembic Y-up convention, so I guess this is already what you want? I do
> plan on adding support for more (custom) axis conversions though.
> 
> Regards,
> 
> Kévin Dietrich.
> ___
> 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 

 

Links:
--
[1] https://developer.blender.org/maniphest/task/edit/form/1/
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Alembic triangulation

[Kévin Dietrich]

Le 2016-08-19 23:53, Adriano Oliveira a écrit :

> Hi,
> 
> Is it possible to have an option to triangulate mesh on Alembic export. I
> am trying to import a animation from Blender to Unreal 4.13 and the late
> ask for tri or quad faces.
> 
> Also it would be nice to have Z to Y convertion options, as long as Unreal
> rotates the Alembic imports form Blender.
> 
> Congratulations for the grate job!
> 
> *Adriano A. Oliveira*
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers

Hi, 

Adding an option to triangulate meshes in the exporter wouldn't that
much of a trouble (though it would have to wait for after the 2.78
release), but I have to ask what prevents you from triangulating the
meshes before exporting? If you've got a lot of objects to triangulate,
a simple Python script can be written to automate the process. Shall it
be a destructive operation, or shall it preserve the state of the meshes
(meaning meshes in Blender are not triangulated, but the exported ones
are)? 

For the axis conversion, Alembic files written from Blender follow the
Alembic Y-up convention, so I guess this is already what you want? I do
plan on adding support for more (custom) axis conversions though. 

Regards, 

Kévin Dietrich.
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] search specific commit on developer.blender.org

[Kévin Dietrich]

Hi, 

The simplest way would be to prefix the hash with "rB" (for Blender
repository), and then append it to the site's url
(developer.blender.org/rB) or your can also use the site's
search bar and look for "rB". 

So in your example it would be developer.blender.org/rBdccf5afbe. 

Cheers, 

Kévin 

Le 2016-06-23 14:14, hewi jupama a écrit :

> Hey all,
> 
> Is there a way to find a specific commit, e.g.
> 
> "dccf5afbe"
> 
> on the developer.blender.org site (without having to scroll through hundreds 
> of commit messages to find that specific one again)
> 
> I can't seem to figure this out
> 
> thanks for your time :)
> 
> 
> From: bf-committers-boun...@blender.org  
> on behalf of bf-committers-requ...@blender.org 
> 
> Sent: 22 June 2016 10:00
> To: bf-committers@blender.org
> Subject: Bf-committers Digest, Vol 143, Issue 15
> 
> Send Bf-committers mailing list submissions to
> bf-committers@blender.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.blender.org/mailman/listinfo/bf-committers
> Bf-committers Info Page - 
> Blender
> lists.blender.org
> Your email address: Your name (optional): You may enter a privacy password 
> below. This provides only mild security, but should prevent others from 
> messing with ...
> 
> or, via email, send a message with subject or body 'help' to
> bf-committers-requ...@blender.org
> 
> You can reach the person managing the list at
> bf-committers-ow...@blender.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Bf-committers digest..."
> 
> Today's Topics:
> 
> 1. Blender can't do hair because of this bug
> (Daniel Salazar - patazstudio.com)
> 2. Re: Blender can't do hair because of this bug (Campbell Barton)
> 3. Re: Blender can't do hair because of this bug
> (Daniel Salazar - patazstudio.com)
> 
> --
> 
> Message: 1
> Date: Tue, 21 Jun 2016 18:11:44 -0600
> From: "Daniel Salazar - patazstudio.com" 
> Subject: [Bf-committers] Blender can't do hair because of this bug
> To: bf-blender developers 
> Message-ID:
> 
> Content-Type: text/plain; charset=UTF-8
> 
> Hi all, this bug has been going on for quite a while apparently and it
> prevents hair combing to work at all since it gets corrupted on
> render.
> 
> https://developer.blender.org/T48658
> 
> For me this bug has delayed my deadline for 2 weeks now and it's hard
> to believe the same bug is not giving problems to many others.
> 
> If someone could urgently fix it please.
> 
> desperately yours,
> 
> Daniel Salazar
> 
> --
> 
> Message: 2
> Date: Wed, 22 Jun 2016 12:39:45 +1000
> From: Campbell Barton 
> Subject: Re: [Bf-committers] Blender can't do hair because of this bug
> To: bf-blender developers 
> Message-ID:
> 
> Content-Type: text/plain; charset=UTF-8
> 
> It looks like Cycles fails to set the particle system back to its
> 'preview' state because G.is_rendering is being checked in particle
> system internals.
> Uploaded a diff that fixes the issue, though it may be better to keep
> the patch smaller & more localized.
> https://developer.blender.org/D2065
> 
> On Wed, Jun 22, 2016 at 10:11 AM, Daniel Salazar - patazstudio.com
>  wrote: 
> 
>> Hi all, this bug has been going on for quite a while apparently and it
>> prevents hair combing to work at all since it gets corrupted on
>> render.
>> 
>> https://developer.blender.org/T48658
>> 
>> For me this bug has delayed my deadline for 2 weeks now and it's hard
>> to believe the same bug is not giving problems to many others.
>> 
>> If someone could urgently fix it please.
>> 
>> desperately yours,
>> 
>> Daniel Salazar
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> https://lists.blender.org/mailman/listinfo/bf-committers
> 
> --
> - Campbell
> 
> --
> 
> Message: 3
> Date: Tue, 21 Jun 2016 22:04:32 -0600
> From: "Daniel Salazar - patazstudio.com" 
> Subject: Re: [Bf-committers] Blender can't do hair because of this bug
> To: bf-blender developers 
> Message-ID:
> 
> Content-Type: text/plain; charset=UTF-8
> 
> I can confirm this is fixed by the patch!
> Daniel Salazar
> p3d.in
> 
> On Tue, Jun 21, 2016 at 8:39 PM, Campbell Barton  
> wrote: It looks like Cycles fails to set the particle system back to its
> 'preview' state because G.is_rendering is being checked in particle
> system internals.
> Uploaded a diff that fixes the issue, though it may be better to keep
> the patch smaller & more localized.
> https://developer.blender.org/D2065
> 
> On Wed, Jun 22, 2016 at 10:11 AM, Daniel Salazar - patazstudio.com
>  wrote: Hi all, this bug has been going on for quite a 
> while apparently and it
> prevents hair combing to work at all since it gets corrupted on
> render.
> 
> https://developer.blender.org

Re: [Bf-committers] is this report its properly close?

[Kévin Dietrich]

Le 2016-04-06 02:37, Nahuel Belich a écrit :

> Hi all, i just reported a crash with opend vdb and a particular atribute, and 
> the task was close as resolve with no more info or commit by a user that 
> registered an hour ago. Probably a legit resolve but i want to be sure if it 
> is ok.
> 
> https://developer.blender.org/T48064
> 
> Thanks

Hi, 

the task was closed for no reason by someone who is new to the site
apparently (registered ~5h ago), will reopen the report, as this was not
a developer's decision. 

Cheers, 
Kevin.  
  
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender Mantaflow integration

[Kévin Dietrich]

Le 2016-02-18 23:51, David Ullmann a écrit :

> Hi everyone!
> 
> My name is David and first of all thank you Sebastián for your work on the
> Mantaflow integration! I'm really looking forward to
> having its features available in blender.
> 
> I'm just coding for fun in my spare time (I'm an orthopedic surgeon), so
> when I was looking for a new project to play with
> I decided to have a look at Mantaflow and eventually build my own little
> gui to visualize simulation output.
> Since I wanted to work in C++ alone, I modified Manta's code to be able to
> call the solver via C++
> without building the Python wrapper (which also allowed me to skip the
> preprocessing step when
> building Mantaflow). While it's surely debatable if this was really
> necessary (or intelligent), it at least gave me the opportunity
> to familiarize myself with the library to some degree (also this process
> satisfies my OCD tendencies, ahem...).
> 
> Long story short, I gathered all my courage, started to cleanup the code a
> bit and published my modified version of Mantaflow on GitHub.
> One motivation was a concern raised by Kévin Dietrich on blenderartists:
> 
> *"The main thing that bothers me is the way Mantaflow works, you need to
> feed it a python script and a set of OBJ files.*
> *So in the Blender integration, it feels a bit hackish. Maybe there's a way
> to get to the C++ code directly, but I don't really know Mantaflow, so I
> can't tell"*
> 
> I'm really not sure if my modifications are useful for anyone but me
> (knowing that my skills are nothing compared to all
> the pros here) but then at least I had a lot of fun and learned a lot while
> playing around :)
> 
> modified Mantaflow repo: https://github.com/robocyte/mantaflow
> thread on BA:
> http://blenderartists.org/forum/showthread.php?373547-Lets-talk-about-Mantaflow
> 
> Cheers,
> David

Hi David, 

Your approach is not really what I had in mind. What I was thinking
about, I did briefly check, is to make use of the pre-processed files.
Basically two things happen there: 

1. the various "lookup" functions are put inside (threaded) loops [0] 
2. a Python API is generated 

My idea was to just use the result of (1.), and make a nice C/C++ API
for it for use in Blender. If that's even possible. Of course, quite an
API would need to be written, and maybe some stuff would need to
rewritten from scratch, but it's still better than hacking Blender's
Python module. Then, as I said, I don't really Mantaflow's internals, so
I'm just tossing some idea. 

With your approach, it'll make things a bit harder if we want keep the
code somewhat aligned with upstream (unless you get your work accepted
by upstream). Maybe others can comment here too. But it could work out,
I guess. 

Nevertheless, I am going to state it again: as far I'm concerned (and at
least one other developer agrees here), the only way the Mantaflow
"integration" will be accepted in Blender (in master), is to either get
rid of, or bypass, the Python API (i.e. not hacking the BPY module).
(And I know Sebastián is not really to blame here ;) ) 

[0] a bit unreadable, but to showcase what I mean
https://developer.blender.org/diffusion/B/browse/fluid
[1]-mantaflow/source/blender/python/manta_pp/plugin/advection.cpp;986093dfb7150ffb925413ffd306a261618d4c98$399


Cheers, 
Kévin. 

  

Links:
--
[1] https://developer.blender.org/diffusion/B/browse/fluid-
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Some Guidance

[Kévin Dietrich]

Le 2016-02-18 16:54, Piotr Arlukowicz a écrit :

> Thanks John
> I've read this carefully and it's a good start. However, suddenly, when you
> see sources, you get lost. So somewhere there should be a tutorial
> explaining for what are those all directories, and what's the difference
> between blenkernel and intern, for example. And what they are for, in terms
> of Blender functionality.

There is a page on the wiki to explain this a bit
http://wiki.blender.org/index.php/Dev:Doc/Blender_Source/Files_Structure


Maybe it could be linked to in the "New Developer Advice" page. 

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

Re: [Bf-committers] Blender Mantaflow integration

[Kévin Dietrich]

 

Le 2016-01-16 22:40, Sebastián Barschkis a écrit : 

> Hi all,
> 
> some Mantaflow updates! I am Sebastián, CS student and the one who is 
> currently working on the fluid branch (soc-2014-fluid). I have picked up the 
> existing Mantaflow integration and added functionality for fire, integrated 
> the pointcache and also just finished the wavelet turbulence feature for the 
> high-resolution option. 
> 
> All in all it's working quite nicely, especially because the new internal 
> Mantaflow uses OpenMP which speeds up the calculations a lot :)
> 
> The code is currently at https://github.com/sebbas/BlenderMantaflow 
> . There you'll also find 
> instructions on how to build if you decide to try it out. Or, you can just go 
> ahead and check out some renderings that I made earlier: 
> https://vimeo.com/sebbas/videos . 
> 
> So far so good, enjoy and best wishes,
> Sebastián
> 
> P.S: If someone happens to have some cool smoke or fire scenes, then I'd be 
> more than happy to render and upload them!
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers

Hi Sebastián, 

Unfortunately, your branch does not compile for me on Linux. Here is the
log: http://www.pasteall.org/63545. 

Apart from this, there are a lot of warnings generated due to the old
smoke code not being used (static functions, unused params...), and
overall the code would need a drastic cleanup ;) 

Cheers, 

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

Re: [Bf-committers] Building with OpenVDB and OSL: a Boost case

[Kévin Dietrich]

 

Le 2015-12-17 08:43, matmenu a écrit : 

> Hi Martijn and Kevin,
> What heppened to this boost update? Python was updated, OpenGL 
> requirements too, Windows XP is dropped, lets use 2.77 to move 
> everything up for the upcoming development. OpenVDB is a really much 
> needed addition for the simulation and volumetrics parts.
> Regards,
> Mat

Hi,

Well, at the moment updating Boost would be irrelevant, for two reasons:

1) when I first opened this discussion, I had just finished implementing
volume sampling and decided it could be enough for a first step. Then,
as I had more time, I started working on ray intersection (accelerated
ray marching/empty space optimization), and that's not finished... so
let's first wrap that up.

2) the main reason, the OpenVDB team at DWA reverted my patch removing
RTTI symbols in the OpenVDB library (because reasons). The only reason
to update Boost is to remove the couple of troublesome RTTI symbols in
there, but if we still have such symbols in OpenVDB, it's pointless.

In any case, let's first finish the implementation in Cycles, and then
try again to find a way to compile everything together nicely.

Cheers,
Kévin. 

> Am 15/06/2015 um 09:43 schrieb Martijn Berger: Hi Kevin,
> 
> I want to do a coordinated effort to upgrade the windows and OS X libraries
> after 2.75 is out the door.
> In addition to openvdb, Alembic might need to be included, also updates to
> llvm, boost, osl, oiio, and maybe other might be in order.
> (OpenSubDiv and PTex I am now sure about (for ptex we use OIIO i think ?))
> 
> I am fine with bumping boost to 1.57 for windows / OS X but I am not sure
> about linux.
> For Linux It seems to me that it is to new and that we should try to keep
> boost 1.48 minimal requirement if we can.
> If that is unfeasible we should bump no higher then 1.54 for linux as then
> we have debian and ubuntu stable to consider.
> 
> Martijn
> 
> On Mon, Jun 15, 2015 at 4:09 AM, Kévin Dietrich 
> wrote:
> 
> Hi all,
> 
> I mail here because it can affect anyone who builds Blender, not just
> the Cycles freaks ;)
> 
> As a reminder, OpenVDB is making use of, and relies on libraries making
> use of, C++ built-in run-time type information (RTTI). On the other
> hand, LLVM (used by OSL) has a home brew version and does not want to
> hear about the built-in one by default.
> 
> The most straightforward way to address this is by building LLVM with
> RTTI enabled, and build OSL accordingly.
> 
> But that's maybe not a possibility (because of a lot of reasons), so
> RTTI usage in VDB will need to be taken care of. By compiling Cycles
> with both VDB and OSL it appears that most RTTI symbols that give issues
> are in everyone's favorite library: Boost (I have version 1.54 here).
> There's also one in TBB, but it can be avoided by disabling the use
> exceptions there.
> 
> Although patching OpenVDB so it compiles fine with RTTI disabled is a
> no-brainer (~10 changes), we will need to upgrade boost to at least
> version 1.57. Which should also comprise the fix for the Windows compile
> issue raised by Antony.
> 
> I've just installed it, and as far as I can tell, it seems to work fine
> (_YMMV_). I've forked the openvdb repository, so to test things out you
> can get my changes from there (https://github.com/diekev/openvdb [1 [1]]) in
> the 'cycles_fixes' branch (it will also contain fixes for implicit float
> conversions happening in the library, which make Cycles grumpy). So if
> we go with boost 1.57, or above, and everything goes fine on all
> platforms, I'll make a pull request.
> 
> That's it from me for the moment,
> Cheers,
> Kévin.
> 
> Links:
> --
> [1] https://github.com/diekev/openvdb
> ___
> 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 

  

Links:
--
[1] https://github.com/diekev/openvdb
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender developers meeting notes, 26 July 2015

[Kévin Dietrich]

 

Le 2015-07-26 17:38, Ton Roosendaal a écrit : 

> - Note for Kevin Dietrich: can we get an update on how far OpenVDB is?

The code for the entire branch was put for code review a few days ago (I
think last Thursday, https://developer.blender.org/D1308) [1]. I just
updated the projects page on the wiki to point the differential revision
and my wiki page where documentations for the OpenVDB stuff is located. 

There are two sides to the patch:

- Caching
The only thing which wasn't tested here is usability. As far as my tests
go, it exports/caches fine and reads back the exported/cached file.
There might be issues I'm not aware of, and that would need user
testings. I had some but it wouldn't hurt to have some more with actual
feedback. I know more people would like to test but they can't manage to
compile OpenVDB for various reasons (platform related, conflicts with
the OpenVDB library shipped with Houdini... ). In all, I consider the
code feature complete, and pretty much done (some optimizations could
also be done, but that's detail, and could happen anytime).

- Cycles
As I mentioned a week ago, we could have volume sampling, as this is
done. Accelerated ray marching (aka leap frogging empty space) is not
done: decoupled ray marching is missing (I have some code here, but it
was crashing, so I stashed it and didn't get back to it). The initial
ray intersection needs to be done better (the check to see if we have a
hit with the bbox of the volume/domain object). BUT, it would recquire a
patched version of OpenVDB and an updated Boost. Looking at it now, I
think it'd be better to wait for DWA to accept or reject my patches, and
if accepted, wait for the next version of OpenVDB (3.1). Unless it's no
trouble to use a patched version. Or we put the Cycles OpenVDB code
behind a compile flag just like OpenSubDiv is currently.

So, as said, the code for the entire branch is up for review, including
the WIP Cycles stuff to hopefully get some feedback on the direction of
the patch, but I could as well separate the Cycles part depending on
what's decided here. 

> - Martijn Berger: if we add OpenVDB we also need to upgrade OpenImage and 
> OSL. Might have consequences for the platform maintainers.

Only if what's done in Cycles is included (volume sampling). 

 

Links:
--
[1] https://developer.blender.org/D1308)
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Building with OpenVDB and OSL: a Boost case

[Kévin Dietrich]

 

Le 2015-06-15 11:57, Sergey Sharybin a écrit : 

> But one thing is not totally clear to me after reading this discussion --
> why do we need to bump boost requirement on Linux?

I would say because after taming rtti usage in OpenVDB itself, Cycles is
still complaining about rtti stuff in boost. For example, in some place
OpenVDB is making use of boost::any which calls typeid, std::type_info
... there are also a few other places in boost with problematic rtti
usage, and those are addressed in boost 1.57, some were addressed in
1.56. So something must be done here. That is when/if OpenVDB becomes
officially supported in Cycles of course. 
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Building with OpenVDB and OSL: a Boost case

[Kévin Dietrich]

 

If Boost 1.57 on Linux isn't really feasible (I had to compile it for
instance), then there isn't that much options. It's either patch Boost
and ask people to compile that or reimplement in OpenVDB (to be clean)
the stuffs in boost that cause problem (should resolve to copy-paste +
replace/remove typeid thingy). The later case means we'll likely have to
maintain our own set of patches for VDB for until newer boost is in
official Linux repos as I hardly see such a change being accepted
upstream (as it's already in newer Boost or whatever). Still worth a try
though. In the end, that depends on people's motivation. 

Le 2015-06-15 09:43, Martijn Berger a écrit : 

> Hi Kevin,
> 
> I want to do a coordinated effort to upgrade the windows and OS X libraries
> after 2.75 is out the door.
> In addition to openvdb, Alembic might need to be included, also updates to
> llvm, boost, osl, oiio, and maybe other might be in order.
> (OpenSubDiv and PTex I am now sure about (for ptex we use OIIO i think ?))
> 
> I am fine with bumping boost to 1.57 for windows / OS X but I am not sure
> about linux.
> For Linux It seems to me that it is to new and that we should try to keep
> boost 1.48 minimal requirement if we can.
> If that is unfeasible we should bump no higher then 1.54 for linux as then
> we have debian and ubuntu stable to consider.
> 
> Martijn
> 
> On Mon, Jun 15, 2015 at 4:09 AM, Kévin Dietrich 
> wrote:
> 
>> Hi all,
>> 
>> I mail here because it can affect anyone who builds Blender, not just
>> the Cycles freaks ;)
>> 
>> As a reminder, OpenVDB is making use of, and relies on libraries making
>> use of, C++ built-in run-time type information (RTTI). On the other
>> hand, LLVM (used by OSL) has a home brew version and does not want to
>> hear about the built-in one by default.
>> 
>> The most straightforward way to address this is by building LLVM with
>> RTTI enabled, and build OSL accordingly.
>> 
>> But that's maybe not a possibility (because of a lot of reasons), so
>> RTTI usage in VDB will need to be taken care of. By compiling Cycles
>> with both VDB and OSL it appears that most RTTI symbols that give issues
>> are in everyone's favorite library: Boost (I have version 1.54 here).
>> There's also one in TBB, but it can be avoided by disabling the use
>> exceptions there.
>> 
>> Although patching OpenVDB so it compiles fine with RTTI disabled is a
>> no-brainer (~10 changes), we will need to upgrade boost to at least
>> version 1.57. Which should also comprise the fix for the Windows compile
>> issue raised by Antony.
>> 
>> I've just installed it, and as far as I can tell, it seems to work fine
>> (_YMMV_). I've forked the openvdb repository, so to test things out you
>> can get my changes from there (https://github.com/diekev/openvdb [1] [1 
>> [1]]) in
>> the 'cycles_fixes' branch (it will also contain fixes for implicit float
>> conversions happening in the library, which make Cycles grumpy). So if
>> we go with boost 1.57, or above, and everything goes fine on all
>> platforms, I'll make a pull request.
>> 
>> That's it from me for the moment,
>> Cheers,
>> Kévin.
>> 
>> Links:
>> --
>> [1] https://github.com/diekev/openvdb [1]
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers [2]
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers [2]

 

Links:
--
[1] https://github.com/diekev/openvdb
[2] 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] Building with OpenVDB and OSL: a Boost case

[Kévin Dietrich]

 

Hi all, 

I mail here because it can affect anyone who builds Blender, not just
the Cycles freaks ;) 

As a reminder, OpenVDB is making use of, and relies on libraries making
use of, C++ built-in run-time type information (RTTI). On the other
hand, LLVM (used by OSL) has a home brew version and does not want to
hear about the built-in one by default. 

The most straightforward way to address this is by building LLVM with
RTTI enabled, and build OSL accordingly. 

But that's maybe not a possibility (because of a lot of reasons), so
RTTI usage in VDB will need to be taken care of. By compiling Cycles
with both VDB and OSL it appears that most RTTI symbols that give issues
are in everyone's favorite library: Boost (I have version 1.54 here).
There's also one in TBB, but it can be avoided by disabling the use
exceptions there. 

Although patching OpenVDB so it compiles fine with RTTI disabled is a
no-brainer (~10 changes), we will need to upgrade boost to at least
version 1.57. Which should also comprise the fix for the Windows compile
issue raised by Antony. 

I've just installed it, and as far as I can tell, it seems to work fine
(_YMMV_). I've forked the openvdb repository, so to test things out you
can get my changes from there (https://github.com/diekev/openvdb [1]) in
the 'cycles_fixes' branch (it will also contain fixes for implicit float
conversions happening in the library, which make Cycles grumpy). So if
we go with boost 1.57, or above, and everything goes fine on all
platforms, I'll make a pull request. 

That's it from me for the moment,
Cheers,
Kévin. 
 

Links:
--
[1] https://github.com/diekev/openvdb
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] boost update for OpenVDB on Windows

[Kévin Dietrich]

 

Le 2015-06-13 09:31, matmenu a écrit : 

> Hi Antony,
> 
> Thanks a lot for working toward OpenVDB on Windows. From a user POV, 
> OpenVDB is really helpfull as a mesher, as a memory optimiser (cache for 
> smoke, water simulation, 3D scan visualisation, etc...). It also speedup 
> Cycles rendering for smoke as Kevin showed and will certainly help 
> Sergey toward it's goal of reducing memory footprint.
> The community is working on it since pretty long (see this 2 years ago 
> https://developer.blender.org/T35565 [1] , was already working good). I 
> think the community would be really happy if you don't use this nice 
> work only for Gooseberry and then grab it again for some more years, but 
> instead make it available to the users. I can assure you you will make 
> many people happy.
> 
> Regards

Hi, 

This work isn't for Gooseberry only, at least I wasn't targeting
Gooseberry when I started working on it. It was merged in the Gooseberry
branch for a few reasons: 

- it's somewhat usable 
- it improves cache sizes 
- it _can_ result in faster rendering (this highly depends on the VDB
tree topology) 
- coincidence (this could have been done a year ago, or after
Gooseberry) 
- the Gooseberry team is using Linux machines, and it compiles fine on
Linux (with a few quirks and quarks dependency wise) 

So yeah, it's not Gooseberry only, and any change made regarding the VDB
work in the gooseberry branch shall be ported to the openvdb branch. 

Cheers, 
Kévin 

 

Links:
--
[1] https://developer.blender.org/T35565
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] what is the difference between these 2 LINEAR operations? or a bug?

[Kévin Dietrich]

 

Le 2015-04-12 14:03, oyster a écrit : 

> Hi,
> These 2 operations in different sourcefile puzzled me. can anyone give
> me any hints?
> 1. the 'color node_mix_linear(float t, color col1, color col2)'
> function in 
> https://developer.blender.org/diffusion/B/browse/master/intern/cycles/kernel/shaders/node_mix.osl
>  [1],
> says
> [code]
> if (col2[0] > 0.5)
> outcol[0] = col1[0] + t * (2.0 * (col2[0] - 0.5));
> else
> outcol[0] = col1[0] + t * (2.0 * (col2[0]) - 1.0);
> [/code]
> if col2[0] > 0.5, then outcol[0] = col1[0] + t * (2.0 * (col2[0] -
> 0.5)) = col1[0] + t * (2.0 * col2[0] - 2.0 * 0.5) = col1[0] + t * (2.0
> * col2[0] - 1.0 ). In other word, no matter what is col2[0], outcol[0]
> is always col1[0] + t * (2.0 * (col2[0]) - 1.0).

Busted! :) 

> So, why do we need to
> write 'else' since 'osl-languagespec.pdf' says color is made from 3
> float.

I don't understand what you mean here. 

> 2. in D:\blender-2.74-src\release\scripts\addons\uv_bake_texture_to_vcols.py,
> we can find
> [code]
> elif self.blendingMode == 'LINEAR_LIGHT':
> if col_in[0] > 0.5:
> col_result[0] = col_out[0] + 2.0 * (col_in[0] - 0.5)
> else:
> col_result[0] = col_out[0] + 2.0 * (col_in[0] - 1.0)
> [/code]
> 
> So, I suppose that node_mix.osl is buggy, the correct code should be
> [code]
> if (col2[0] > 0.5)
> outcol[0] = col1[0] + t * (2.0 * (col2[0] - 0.5));
> else
> outcol[0] = col1[0] + t * (2.0 * (col2[0] - 1.0));
> [/code]
> 
> Am I right?

Actually, the formula should just be: (note that we should have a linear
mix, so to further correct) 

col_result = (1.0 - t) * col_out + t * (2.0 * col_in - 1.0); 

that is: 

col_result = mix(col_out, 2.0 * col_in - 1.0, t); 

To understand, the actual formula (as defined by Adobe) is: 

linear_burn(x, 2y, t), if y > 0.5 
linear_dodge(x, 2y - 1, t), otherwise 

where linear_burn is defined as: x + y - 1, and linear_dodge: x + y 
so that gives: 
x + 2y - 1, if (y > 0.5) 
x + 2y - 1, otherwise 

This function (and some others) was originally coined by Adobe to
overcome the weirdness of their software when it comes to color
management (I won't spend too much time explaining)... I personally
would remove it from Blender and Cycles altogether. 

 

Links:
--
[1]
https://developer.blender.org/diffusion/B/browse/master/intern/cycles/kernel/shaders/node_mix.osl
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Everything Nodes

[Kévin Dietrich]

 

Le 2015-03-07 12:38, David Fenner a écrit : 

> I remember a few demos by lukas toenne in which he had prototypes working
> with modifier nodes and particle nodes. Actually he was making arrays and
> such with nodes... Sadly I can't find the videos right now... but clearly
> he should be able to help you a little, maybe share his first attempts.
> 
> 2015-03-06 20:22 GMT-03:00 Jacques Lucke :

Well, let me google that for you ;) 

Lukas' old blog: 
http://phonybone.planetblender.org/ [1] 

His youtube channel: 
https://www.youtube.com/user/lukastoenne/videos [2] 

And the old modifiers node repo: 
https://www.gitorious.org/blender-trunk/modifier_nodes/source/cec526c61f147e0dbb2637fb9ff79a58e36a1a72
[3] 

Cheers, 
Kévin 
 

Links:
--
[1] http://phonybone.planetblender.org/
[2] https://www.youtube.com/user/lukastoenne/videos
[3]
https://www.gitorious.org/blender-trunk/modifier_nodes/source/cec526c61f147e0dbb2637fb9ff79a58e36a1a72
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Vignette node for Blender's Compositor

[Kévin Dietrich]

 

Le 2015-03-05 14:00, Johnny Matthews a écrit : 

> David, I'm not sure your tone here is helpful.
> 
> Also to take a stab at "where would the devs stop?" Take a look at
> http://www.redgiant.com/products/magic-bullet-looks/ [1]

That would be the equivalent to having a node groups library, which a
vignette effect can be part of. This is something that a lot of users
have been doing for a long time. 
 

Links:
--
[1] http://www.redgiant.com/products/magic-bullet-looks/
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Luminance patches

[Kévin Dietrich]

 

Le 2015-02-18 00:15, Campbell Barton a écrit : 

>> The color wheels (HSV) come to mind. If the developer uses the rgb_to_bw 
>> function, they just broke their entire color chain. Now the developer 
>> shouldn't use the rgb_to_bw function, but how should they know that?
> 
> just include a comment above `rgb_to_bw`, only to use when handling
> colors outside Blender's/OCIO's color-pipeline.

(To reply to this above mail and recent comments made in D1082: ) 

I do admit that color managing the UI is a bit of an overkill, but Troy
does have a point: nothing would prevent someone to screw things up if
there is a stray function in BLI, even if there is some comment
explaining what's up (let's be paranoid for a second ;) ). IMO, if
there's no real way to get this kind of changes in master unless we keep
a function for UI use then this puppy should be in the UI's own
(private) API (some `UI_get_luminance()`), as I feel BLI is more for a
general/generic use. Then this function should have weights that makes
sense, by which I mean: so far no one can truly explain where this
`rgb_to_bw()` comes from; it feels very arbitrary (as in why not using
just the red channel, or the blue one?) and should be changed. With our
patches (D1082 by Troy, and D517 by myself), we can rationally explain
those weights, and the tendency should be kept. 
 
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Weekly Blender developers meeting minutes - January 18, 2015

[Kévin Dietrich]

 

As discussed with Ton in IRC I uploaded the current patch for my OpenVDB
mesher to d.b.o (easier/faster than setting up a github repo): 

https://developer.blender.org/D1008 

I chose to create a differential for it over a simple patch, as arcanist
will put my code in context, including my commit history for the
curious, which is cool. Hope it's ok! 

Cheers, Kévin. 

Le 2015-01-18 17:40, Ton Roosendaal a écrit : 

> Hi all,
> 
> Here are the notes from today's 15h UTC meeting in irc.freenode.net 
> #blendercoders.
> 
> 1) Release targets for upcoming 2.74
> 
> - People noted that the proposed planning for next release was more than 2 
> months. 
> 
> - We might need to reserve enough time for Multiview, Viewport, and several 
> Gooseberry projects to be migrated. But if that's needed has to be figured 
> out still.
> 
> - Everyone gets one more week to get their projects shortlisted as 2.74 
> targets!
> 
> 2) Release 2.73a
> 
> - Meeting decided to go for an 'a' update after all. Minor but important 
> fixes were done already.
> For example: Knife bugs, Cycles has bug (black meshes on certain 
> circumstances).
> 
> - Monday Sergey Sharybin and Campbell Barton will review and move over the 
> essential fixes (and mail to this list to verify). If all goes fine, we then 
> ask for a build on tuesday.
> 
> 3) other projects
> 
> - Kevin Dietrich posted videos with the first OpenVDB particle results:
> http://blenderartists.org/forum/showthread.php?357512-Dev-OpenVDB-Based-Particle-Mesher-Modifier
>  [1]
> He'll be in touch with Campbell and Lukas Toenne, to make sure modifier 
> designs and particle plans are well aligned.
> 
> Thanks,
> 
> -Ton-
> 
> 
> Ton Roosendaal - t...@blender.org - www.blender.org [2]
> 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 [3]

 

Links:
--
[1]
http://blenderartists.org/forum/showthread.php?357512-Dev-OpenVDB-Based-Particle-Mesher-Modifier
[2] http://www.blender.org
[3] 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] Corrupted git repo

[Kévin Dietrich]

 

Hi all, 

I'm having some error in my checkout of the main repo, I don't know when
exactly it came up the first time (since I use either a script or 'make
update'), but here's the error I get: 

(it appears when compressing the repo) 

error: inflate: data stream error (incorrect data check)
error: failed to unpack compressed delta at offset 73813442 from
.git/objects/pack/pack-357a7be37331f2e5675029adb2a7e6f226df4abb.pack
error: failed to read object 2c5e98a291729c90c547cbd6ffa737155c2c3f72 at
offset 73813436 from
.git/objects/pack/pack-357a7be37331f2e5675029adb2a7e6f226df4abb.pack
fatal: packed object 2c5e98a291729c90c547cbd6ffa737155c2c3f72 (stored in
.git/objects/pack/pack-357a7be37331f2e5675029adb2a7e6f226df4abb.pack) is
corrupt
error: failed to run repack 

Anyone here having same kind of issue or is it my local repo screwing
things up? 

This makes me think that about a week ago I applied a patch from d.b.o
(D911) that apparently contains a corrupted png file, could that be it?
I did delete the branch but the issue still exists. 

Any help is, of course, appreciated. 

Cheers, 

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

Re: [Bf-committers] Build Error

[Kévin Dietrich]

 

Le 2014-11-24 04:05, Daniel Salazar - patazstudio.com a écrit : 

> Hi, I'm getting this on ccmake open suse 12.3
> 
> http://www.pasteall.org/55327 [1]
> 
> Daniel Salazar
> patazstudio.com
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers [2]

Hi Daniel, 

To quote Martijn from an earlier discussion [1] with same issue: 

« We did have a change in this area recently. In short we want to
install to 
the directory used for compilation when using make install. 
Unfortunately this change hit people with an already in place
CMakeCache, 
there is nothing we can do about this. You can either clear your 
CMAKE_INSTALL_PREFIX and rerun cmake or set it to "`pwd`/bin ". 
I am sorry this change impacted you. » 

Hope that helps, 

Cheers 

[1]
http://blender.45788.x6.nabble.com/Compilation-try-to-install-2-72-directly-in-usr-local-td128649.html


 

Links:
--
[1] http://www.pasteall.org/55327
[2] 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] Error in compile with scons (Linking program ==> 'makesdna')

[Kévin Dietrich]

 

LLVM is only necessary if you intend to build Cycles with OSL support. 

Le 2014-11-20 10:44, Jefferson Rausseo a écrit : 

> gcc 4.8.2
> scons 2.3.0
> 
> I can compile correctly only if I remove the last line in linux-config.py
> I have not installed "llvm", should I have it obligatory install?
> 
> 2014-11-20 4:17 GMT-04:30 Sergey Sharybin :
> That sounds weird, because linux buildbot uses scons and never run into this 
> issue. What's your compiler and it's version? P.S. Instead of modifying 
> linux-config.py it's better to do changes in user-config.py On Thu, Nov 20, 
> 2014 at 5:18 AM, Jefferson Rausseo < jeffersonraus...@gmail.com> wrote: 
> Apparently the error is in the commit 
> 80d1d624d378d4d8c03fb26ef286baf5479b6497, specifically in this file in the 
> last line: build_files/scons/config/linux-config.py If we comment the last 
> line fixes the problem: # PLATFORM_LINKFLAGS += 
> ['-Wl,--version-script=source/creator/blender.map'] 2014-11-19 15:23 
> GMT-04:30 Piotr Arlukowicz < pio...@polskikursblendera.pl : Yes, I've sent 
> this very same error just a second ago to that list. I thought that this was 
> my bad and system updates, but no. The same is mine: 
> http://www.pasteall.org/55258 [1] regards Piotr Piotr Polski Kurs Blendera: 
> http://polskikursblendera.pl [2], YT: /user/piotao?feature=guide FB: 
> /polskikursblendera TW: /piotao 2014
 -11-19
18:06 GMT+01:00 Jefferson Rausseo <
 jeffersonraus...@gmail.com 

> : Ubuntu 14.04 with scons Version blender: commit 
> cd54f07a3c71ba146542e41c7b3407b287b52b4c Error in screen: Linking program ==> 
> 'makesdna' /usr/bin/ld: anonymous version tag cannot be combined with other
 version 

>> tags collect2: error: ld returned 1 exit status scons: *** 
>> [/home/dani/Programas/blender-git/build/makesdna] Error 1 scons: building 
>> terminated because of errors. 
>> ___ Bf-committers mailing list 
>> Bf-committers@blender.org 
>> http://lists.blender.org/mailman/listinfo/bf-committers [3]
> ___ Bf-committers mailing list 
> Bf-committers@blender.org 
> http://lists.blender.org/mailman/listinfo/bf-committers [3]
 ___ Bf-committers mailing
list Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers [3] -- With best
regards, Sergey Sharybin ___
Bf-committers mailing list Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers [3] 

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

 

Links:
--
[1] http://www.pasteall.org/55258
[2] http://polskikursblendera.pl
[3] 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] Compilation try to install 2.72 directly in /usr/local/

[Kévin Dietrich]

 

Le 2014-11-17 11:58, Julien Duroure a écrit : 

> Hi all,
> 
> After a git update yesterday (last update was 2 weeks ago), my "make
> install" failed because trying of writing "2.72" directory directly in
> /usr/local/, that needs root privileges.
> 
> Here is my script used to update my build [1].
> 
> I know that there was some change last days about building configuration. I
> don't know if this is linked to these modifications.
> 
> Other problem : It seems that addons contrib are not included in my builds.
> Any ideas ? Git repository of contrib is not a submodule ?
> 
> Thanks !
> 
> [1] : http://www.pasteall.org/55205
> [1]

Hi, 

That also happened to me yesterday I think, don't know what's the cause,
but in the meantime you can set CMAKE_INSTALL_PREFIX to whatever dir you
used to build in, e.g.: 

CMAKE_INSTALL_PREFIX=/home/ju/Programmes/blender/git/build_linux/bin 

Either put that in your script or directly edit the CMakeCache.txt in
build_linux/ 

Hope that helps :) 
 

Links:
--
[1] http://www.pasteall.org/55205
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Differential, auto close

[Kévin Dietrich]

 

Maybe the system is case sensitive? Thomas' commits usually mention
"revision" instead of "Revision" like when landed through arc. 

Le 2014-11-06 09:26, Sergey Sharybin a écrit : 

> Actually,i've got second idea, which is you're committing the patches which
> nobody set status to "Accepted". That might also be an issue perhaps.
> 
> On Thu, Nov 6, 2014 at 1:18 PM, Sergey Sharybin 
> wrote:
> That's something "works for me (tm)" thing which was never disabled on 
> purpose or so. Plus works for some other devs from the quick checks: [1 [1]] 
> [2 [2]] [3 [3]]. I'm not sure why the systems decided to not like you, first 
> guess i've got is that it's somehow related on using arc, seems the 
> auto-closed revisions were submitted with arc. Try using that and see if the 
> systems starts to like you (that would also help a LOT reviewing the 
> patches).. [1] https://developer.blender.org/rBba7e504 [1] [2] 
> https://developer.blender.org/rBdfc4de0 [2] [3] 
> https://developer.blender.org/rB7c25f16 [3] On Thu, Nov 6, 2014 at 2:59 AM, 
> Thomas Dinges  wrote: Hi, we had a feature to auto close 
> a differential, by mentioning it in a commit. This seems not to work anymore? 
> See commit https://developer.blender.org/rBfb820c063831 [4] and the 
> differential: https://developer.blender.org/D860 [5] Would be nice to have 
> this back. Best regards, Thomas
___ Bf-committers mailing list 
Bf-committers@blender.org 
http://lists.blender.org/mailman/listinfo/bf-committers [6] -- With best 
regards, Sergey Sharybin

 

Links:
--
[1] https://developer.blender.org/rBba7e504
[2] https://developer.blender.org/rBdfc4de0
[3] https://developer.blender.org/rB7c25f16
[4] https://developer.blender.org/rBfb820c063831
[5] https://developer.blender.org/D860
[6] 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] Credits Page

[Kévin Dietrich]

I might sound harsh but I believe that to ease out this process, at 
least for the future, it could be time for the committers to actually 
commit with the author's name (git commit --author=insert_name) and drop 
the all "patch by someone" nonsense. If the guys taking care of the 
Linux kernel can do this with 20 times as much contributors as Blender, 
the Blender guys can do this.

Commit etiquette, simple stuff.


Le 14/09/2014 08:00, Campbell Barton a écrit :
> I'd be happy to drop the commit count, its not an accurate indication
> of contributions anyway,
>
> However I don't think doing that makes the task any easier. To get
> every patch-author we still need some way to map committed patches to
> a user name.
>
> On Sun, Sep 14, 2014 at 9:33 AM, Harley Acheson
>  wrote:
>> If it isn't possible to get the diff author information back we could
>> _consider_ the following:
>>
>> Correct a *single* commit (only) for each of the 213 missing contributors,
>> abandon the
>> "commit count" as being inaccurate from now on, and create a new "Credits"
>> page listing
>> all contributors without commit count but sorted: Ton, Core devs, module
>> owners,
>> committers, everyone else.
>>
>> Harley
>> ___
>> 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] Fluid dynamic areas for development?

[Kévin Dietrich]

> Do smoke / fluid share any structure?
>
Technically, yes. To be persnickety I'd say they sure do, as smoke is a 
fluid! A gaseous fluid to be precise.
For example, in both cases (gas and liquid), you advect a volume 
(density field) in a grid environment (domain object), then the "liquid 
volume", so to speak, ends up being meshed, while the gaseous one, well, 
is rendered as a volume.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Fluid dynamic areas for development?

[Kévin Dietrich]

Hi Alejandro,

As fas as I can tell, there is no actual - or official - roadmap/feature 
requests/work items for Blender's fluid system.

You can head over in #blendercoders channel on IRC (freenode.net), and 
ask there what you might work on.

Cheers,
Kévin

Le 19/08/2014 20:36, Alejandro Jimenez a écrit :
> Thanks for replying,
>
> Is it planned the existing fluid simulators switch to this mantaflow
> framework?
>
> I have seen the following fluid framework looking at youtube. Under Blender
> Cycles tags,
> https://www.youtube.com/watch?v=lYTVOdcgyP8
> But have not being able to find where I can find the roadmap/ feature
> request/work items, for fluid simulations in blender internals.
>
>   I am trying to find if I can contribute more specific in Multiple phase
> flow area such as water/oil or fire/water/air, can anyone point out what is
> the correct channel to sync If I can contribute in the fluid
> simulators/render engine for fluids of Blender cycles?
>
>
> On Tue, Aug 19, 2014 at 11:04 AM, Daniel Salazar - patazstudio.com <
> zan...@gmail.com> wrote:
>
>> Hey! Well it's good timing, Blender is currently getting a new fluid
>> dynamics framework called mantaflow as part of GSoC 2014 and I'm sure
>> a lot of work is needed from now on!
>>
>> http://wiki.blender.org/index.php/User:Romanp/GSoC_Mantaflow_Framework/Docs
>>
>> best regards,
>>
>> Daniel Salazar
>> patazstudio.com
>>
>>
>> On Tue, Aug 19, 2014 at 11:57 AM, Alejandro Jimenez 
>> wrote:
>>> Hi,
>>>
>>> I really like the area of fluid dynamics, from fluid simulation to
>>> rendering algorithms/mesh generation, I am currently working on setting
>> my
>>> undergrad thesis work by helping in one of these areas, can anyone point
>> me
>>> the right channel to help and find work items to improve blender in these
>>> areas?
>>>
>>> -Alejandro
>>> ___
>>> 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] GIT connection problem in release/scripts/ addons_contrib

[Kévin Dietrich]

 

Hi, 

just my two cents, but how about the config file in
.git/modules/release/scripts/addons_contrib ? 

Kévin 

Le 2014-06-22 11:00, Vicente a écrit : 

> Hi Dan,
> 
> Yes, I can browse in git.blender.org without problems, I can see the 
> commits and even the diffs.
> But happens that sometimes I get an error loading blender.org, like if 
> the timeout were too low. So if it didn't respond in 5 secs, then I get 
> an error page. I don't know but maybe is related.
> Oh and my connection is 100/100 optic fiber, so speed should not be the 
> problem. But I'm in Iceland and sometimes the ping can be high (right 
> now the ping to git.blender is 50ms, nothing special).
> 
> And here my config.
> $ cat .git/config
> [core]
> repositoryformatversion = 0
> filemode = true
> bare = false
> logallrefupdates = true
> [remote "origin"]
> url = http://git.blender.org/blender.git [1]
> fetch = +refs/heads/*:refs/remotes/origin/*
> [branch "master"]
> remote = origin
> merge = refs/heads/master
> [submodule "release/datafiles/locale"]
> url = http://git.blender.org/blender-translations.git [2]
> [submodule "release/scripts/addons"]
> url = http://git.blender.org/blender-addons.git [3]
> [submodule "release/scripts/addons_contrib"]
> url = http://git.blender.org/blender-addons-contrib.git [4]
> [submodule "scons"]
> url = http://git.blender.org/scons.git [5]
> 
> But yesterday before sending the email report I changed all the "git" 
> protocols by "http", just to try. But the error is the same.
> I have to add that sometimes other parts of the repository are 
> unresponsive but if I retry a few times they work, except addons_contrib.
> 
> I send you my IP in a private message.
> 
> Thank you,
> 
> Vicente
> 
> On 06/22/2014 04:25 AM, Dan McGrath wrote:
> Hi Vicente, Curious, can you visit http://git.blender.org/ [6] okay in a web 
> browser? Also, any chance you could paste a copy of the .git/config file in 
> your blender checkout folder? I can't promise anything, but I can at least 
> show you mine: [core] repositoryformatversion = 0 filemode = true bare = 
> false logallrefupdates = true [remote "origin"] fetch = 
> +refs/heads/*:refs/remotes/origin/* url = https://git.blender.org/blender.git 
> [7] [branch "master"] remote = origin merge = refs/heads/master [submodule 
> "release/datafiles/locale"] url = 
> https://git.blender.org/blender-translations.git [8] [submodule 
> "release/scripts/addons"] url = https://git.blender.org/blender-addons.git 
> [9] [submodule "release/scripts/addons_contrib"] url = 
> https://git.blender.org/blender-addons-contrib.git [10] [submodule "scons"] 
> url = https://git.blender.org/scons.git [11] It doesn't appear that any ip's 
> were blocked in the firewall, so I am not sure exactly what the cause it atm. 
> I would need to kno
 w the IP
address that you used to connect to the service in order to dig deeper into the 
logs. Dan On Sat, Jun 21, 2014 at 11:19 PM, Vicente  
wrote: Hi, Since like 2 weeks ago I can not get the updates from the 
addons_contrib repository. I'm using this command: git submodule foreach git 
pull --rebase origin master But I'm getting time outs. Also I have created a 
completely new folder and cloned the repository there with the same result. But 
I supposed it was my problem so I didn't say anything. But today I tried it in 
a different computer, with exact result. This is the output: $ git submodule 
foreach git pull --rebase origin master Entering 'release/datafiles/locale' 
From git://git.blender.org/blender-translations * branch master -> FETCH_HEAD 
Current branch master is up to date. Entering 'release/scripts/addons' fatal: 
unable to connect to git.blender.org: git.blender.org[0: 82.94.226.105]: 
errno=Connection timed out Stopping at 'release/scripts/addons'; scri
 pt
returned non-zero status. I also tried to use http instead of git. But it did 
no difference at all(maybe even worse response in the "working" folders). Is 
this only happening to me (and my neighbours)? Thanks Vicente 
___ Bf-committers mailing list 
Bf-committers@blender.org 
http://lists.blender.org/mailman/listinfo/bf-committers [12] 
___ Bf-committers mailing list 
Bf-committers@blender.org 
http://lists.blender.org/mailman/listinfo/bf-committers [12]

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

 

Links:
--
[1] http://git.blender.org/blender.git
[2] http://git.blender.org/blender-translations.git
[3] http://git.blender.org/blender-addons.git
[4] http://git.blender.org/blender-addons-contrib.git
[5] http://git.blender.org/scons.git
[6] http://git.blender.org/
[7] https://git.blender.org/blender.git
[8] https://git.blender.org/blender-translations.git
[9] https://git.blender.org/blender-addons.git
[10] https://git.blender.org/blender-addons-contrib.git
[11] https://git.b

Re: [Bf-committers] Luminance Coefficients

[Kévin Dietrich]

 

Hi, 

it depends on how you did the job. Perhaps this can be appended to my
patch: developer.blender.org/D517 ? 

I also intended to do something in this area ;) 

Le 2014-06-09 02:37, Troy Sobotka a écrit : 

> While looking through Blender's code, I noticed that there were legacy hard
> coded values for luminance.
> 
> These are hard coded values based on the sRGB and 709 primaries, as opposed
> to the particular color spaces a given OCIO configuration may have. This
> would lead to incorrect derivation of luminance if the reference space is
> not sRGB / 709.
> 
> I decided to patch Blender to use the reference space coefficients listed
> in the OCIO configuration file, which is relatively straightforward.
> 
> The coefficients are summoned per pixel, which would mean having a global
> structure useful to reference them, but I don't see a relevant place to
> store them.
> 
> It would seem logical to store them on configuration loading, reloading,
> and potentially if a set coefficients call is made.
> 
> Where and how does it make sense to store these values in Blender's
> architecture?
> 
> With respect,
> TJS
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers [1]

 

Links:
--
[1] 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] RGBA compositing preview missing

[Kévin Dietrich]

 

Hi Bartek, 

This issue has reported a couple of times. 

See developer.blender.org/T39799 

Kévin. 

Le 2014-04-24 14:35, Bartek Skorupa (priv) a écrit : 

> Hey,
> 
> Did something bad happen to RGBA previews of compositing output or some 
> setting has been added to make it possible to view RGBA?
> Should it be reported as a bug?
> (Another thing is that even when we had RGBA previews they were wrong… 
> http://wiki.blender.org/index.php/User:Bartekskorupa/Display_Issues [1] )
> 
> Here's a screenshot of what I mean:
> http://www.pasteall.org/pic/70278 [2]
> 
> It work this way in build of April 24, 2014, HASH: 3bcc9ee
> In official 270a it works well.
> 
> Thanks for any info.
> 
> Cheers
> Bartek Skorupa
> 
> www.bartekskorupa.com [3]
> 
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers [4]

 

Links:
--
[1] http://wiki.blender.org/index.php/User:Bartekskorupa/Display_Issues
[2] http://www.pasteall.org/pic/70278
[3] http://www.bartekskorupa.com
[4] 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] Change in Compositor OpenCL

[Kévin Dietrich]

 

Hi Jeroen, 

I have driver version 4.3.0 NVIDIA 319.37 installed. (I think I got from
installing CUDA 5.5 a while back ago.) 

Kevin. 

Le 2014-04-06 13:06, Jeroen Bakker a écrit : 

> Hi Kevin
> 
> What kind of NVidia driver have you installed?
> 
> Jeroen
> 
> On 04/06/2014 03:46 AM, Kévin Dietrich wrote:
> Hi, Here are my specs: OS: Linux Mint 15, 64-bit CPU: AMD Fx-8320 GPU: NVidia 
> GTX-650 OpenCL works fine, although a little slower than disabled. Le 
> 2014-04-05 21:38, Jeroen Bakker a écrit : Hi All, Since the last update of 
> MacOS 10.9.2 blender compositor failed in doing OpenCL. We have investigated 
> the problem and found a fix that seems to work. Unfortunately we couldn't 
> test it on all other platforms (NVidia, normal AMD, Linux, Windows, etc) Are 
> there volunteers that wants to check that OpenCL work on their platform(s). 
> The best way to test is to "Enable OpenCL" and use the "Bokeh Blur Node" in 
> the setup. Use revision recent trunk with revision 
> 49d1c8d8c689c917fa3fd7d309861f419ddac373 Regards, Jeroen & Monique - At Mind 
> - ___ Bf-committers mailing list 
> Bf-committers@blender.org 
> http://lists.blender.org/mailman/listinfo/bf-committers [1] [1] Links: -- 
> [1] http://lists.blender.org/mailman/listinfo/bf-committers [1]
___ Bf-committers mailing list 
Bf-committers@blender.org 
http://lists.blender.org/mailman/listinfo/bf-committers [1]

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

 

Links:
--
[1] 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] Change in Compositor OpenCL

[Kévin Dietrich]

 

Hi, 

Here are my specs: 

OS: Linux Mint 15, 64-bit 

CPU: AMD Fx-8320 

GPU: NVidia GTX-650 

OpenCL works fine, although a little slower than disabled. 

Le 2014-04-05 21:38, Jeroen Bakker a écrit : 

> Hi All,
> 
> Since the last update of MacOS 10.9.2 blender compositor failed in doing 
> OpenCL. We have investigated the problem and found a fix that seems to 
> work. Unfortunately we couldn't test it on all other platforms (NVidia, 
> normal AMD, Linux, Windows, etc)
> 
> Are there volunteers that wants to check that OpenCL work on their 
> platform(s).
> The best way to test is to "Enable OpenCL" and use the "Bokeh Blur Node" 
> in the setup.
> 
> Use revision recent trunk with revision 
> 49d1c8d8c689c917fa3fd7d309861f419ddac373
> 
> Regards,
> Jeroen & Monique
> - At Mind -
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers [1]

 

Links:
--
[1] 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] Google Summer of Code - proposal hints

[Kévin Dietrich]

 

Hi Piotr, 

The simple todo list is quite up-to-date afaik, but you can take a look
at https://developer.blender.org/maniphest/project/34/ [5] for simple
tasks. 

I wish you the best in your programming career. 

Regards, 

Kévin. 

Le 2014-03-02 22:55, Piotrek Chwała a écrit : 

> Hello Blender Developers!
> 
> Since Blender Foundation is accepted as Google Summer of Code 2014
> organization, I would love to take part in this event and help Blender to
> be the best. For now, I'm at the stage where I have compiled blender
> sources and I'm reading the code. As your developer wiki advise, I will
> look for some quick and simple todos to get myself familiar with the code
> base (side question: is
> http://wiki.blender.org/index.php/Dev:2.5/Source/Development/Todo/Simple_Todossite
>  [1]
> up-to-date? If not, where can I find simple todos?).
> 
> On March 10 students applications will start and, as I understand, I will
> need to submit my proposal. I was considering doing something with Video
> Editor, but as I can see, "This is not a typical beginner project though".
> In this case I'm curious what is your opinion about most suitable project
> for me. Take into consideration that I have just begun blender development.
> 
> My short bio:
> I was playing with blender in my youth for 6 years (2004-2009) (some of my
> works: http://hfaua.hostei.com/portfolio/gcng/1.jpg [2]
> http://hfaua.hostei.com/portfolio/dworek/1.jpg [3]). Then I started to focus
> mostly on programming and improving my algorithmic skills. Now I'm 21 and
> since 2012 I'm studying Computer Science at AGH University of Science and
> Technology in Krakow, Poland. Since may 2013 I'm also working as C++
> Software Developer at X-Formation (we're making security and licensing
> software).
> 
> TL;DR; I'm a student, C++ developer and blender lover. I would like to take
> part in GSoC 2014. I have little experience with blender code base (will
> improve shortly!). What would be the best project for me to submit in GSoC
> proposal to maximize value for community and possibility of completing on
> time? :-)
> 
> P.S. My apologies if this is not suitable place for posting such questions.
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers [4]

 

Links:
--
[1]
http://wiki.blender.org/index.php/Dev:2.5/Source/Development/Todo/Simple_Todossite
[2] http://hfaua.hostei.com/portfolio/gcng/1.jpg
[3] http://hfaua.hostei.com/portfolio/dworek/1.jpg
[4] http://lists.blender.org/mailman/listinfo/bf-committers
[5] https://developer.blender.org/maniphest/project/34/
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Buiding Blender with OSL fails (Linux)

[Kévin Dietrich]

 

Builds without error now, 

Thanks. 

Le 2014-02-04 22:51, Brecht Van Lommel a écrit : 

> I committed a possible fix for this:
> https://developer.blender.org/rB502f9312d8c797d93d6084e17216013da8cc956a [2]
> 
> Please try building again, thanks.
> 
> Brecht.
> 
> On Tue, Feb 4, 2014 at 10:14 PM, Kévin Dietrich
>  wrote:
> 
>> Hi, I cannot seem to be able to build Blender with OSL. Attached is the 
>> error log. Also, for completeness, Cmake returns me this: 
>> ../../lib/libcycles_kernel_osl.a(osl_services.cpp.o):(.data.rel.ro._ZTVN3ccl17OSLRenderServicesE[_ZTVN3ccl17OSLRenderServicesE]+0xb8):
>>  undefined reference to 
>> `OSL::RendererServices::pointcloud_write(OSL::ShaderGlobals*, 
>> OpenImageIO::v1_4::ustring, Imath::Vec3 const&, int, 
>> OpenImageIO::v1_4::ustring const*, OpenImageIO::v1_4::TypeDesc const*, void 
>> const**)' collect2: error: ld returned 1 exit status My Specs: Linux Mint 15 
>> 64bit GCC 4.7.2 Thanks in advance for any help. 
>> ___ Bf-committers mailing list 
>> Bf-committers@blender.org 
>> http://lists.blender.org/mailman/listinfo/bf-committers [1]
> 
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers [1]

 

Links:
--
[1] http://lists.blender.org/mailman/listinfo/bf-committers
[2]
https://developer.blender.org/rB502f9312d8c797d93d6084e17216013da8cc956a
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Buiding Blender with OSL fails (Linux)

[Kévin Dietrich]

 

Hi, 

I cannot seem to be able to build Blender with OSL. 

Attached is the error log. 

Also, for completeness, Cmake returns me this: 

../../lib/libcycles_kernel_osl.a(osl_services.cpp.o):(.data.rel.ro._ZTVN3ccl17OSLRenderServicesE[_ZTVN3ccl17OSLRenderServicesE]+0xb8):
undefined reference to
`OSL::RendererServices::pointcloud_write(OSL::ShaderGlobals*,
OpenImageIO::v1_4::ustring, Imath::Vec3 const&, int,
OpenImageIO::v1_4::ustring const*, OpenImageIO::v1_4::TypeDesc const*,
void const**)'
collect2: error: ld returned 1 exit status 

My Specs: 

Linux Mint 15 64bit 

GCC 4.7.2 

Thanks in advance for any help. 
 Determining if the pthread_create exist failed with the following output:
Change Dir: /home/kevin/Compilations/blender-git/build_linux/CMakeFiles/CMakeTmp

Run Build Command:/usr/bin/make "cmTryCompileExec1516148557/fast"
make[1]: Entering directory 
`/home/kevin/Compilations/blender-git/build_linux/CMakeFiles/CMakeTmp'
/usr/bin/make -f CMakeFiles/cmTryCompileExec1516148557.dir/build.make 
CMakeFiles/cmTryCompileExec1516148557.dir/build
make[2]: Entering directory 
`/home/kevin/Compilations/blender-git/build_linux/CMakeFiles/CMakeTmp'
/usr/bin/cmake -E cmake_progress_report 
/home/kevin/Compilations/blender-git/build_linux/CMakeFiles/CMakeTmp/CMakeFiles 
1
Building C object 
CMakeFiles/cmTryCompileExec1516148557.dir/CheckSymbolExists.c.o
/usr/bin/cc-o 
CMakeFiles/cmTryCompileExec1516148557.dir/CheckSymbolExists.c.o   -c 
/home/kevin/Compilations/blender-git/build_linux/CMakeFiles/CMakeTmp/CheckSymbolExists.c
Linking C executable cmTryCompileExec1516148557
/usr/bin/cmake -E cmake_link_script 
CMakeFiles/cmTryCompileExec1516148557.dir/link.txt --verbose=1
/usr/bin/cc 
CMakeFiles/cmTryCompileExec1516148557.dir/CheckSymbolExists.c.o  -o 
cmTryCompileExec1516148557 -rdynamic 
CMakeFiles/cmTryCompileExec1516148557.dir/CheckSymbolExists.c.o: In function 
`main':
CheckSymbolExists.c:(.text+0x16): undefined reference to `pthread_create'
collect2: error: ld returned 1 exit status
make[2]: *** [cmTryCompileExec1516148557] Error 1
make[2]: Leaving directory 
`/home/kevin/Compilations/blender-git/build_linux/CMakeFiles/CMakeTmp'
make[1]: Leaving directory 
`/home/kevin/Compilations/blender-git/build_linux/CMakeFiles/CMakeTmp'
make[1]: *** [cmTryCompileExec1516148557/fast] Error 2

File 
/home/kevin/Compilations/blender-git/build_linux/CMakeFiles/CMakeTmp/CheckSymbolExists.c:
/* */
#include 

int main(int argc, char** argv)
{
  (void)argv;
#ifndef pthread_create
  return ((int*)(&pthread_create))[argc];
#else
  (void)argc;
  return 0;
#endif
}

Determining if the function pthread_create exists in the pthreads failed with 
the following output:
Change Dir: /home/kevin/Compilations/blender-git/build_linux/CMakeFiles/CMakeTmp

Run Build Command:/usr/bin/make "cmTryCompileExec1310631033/fast"
make[1]: Entering directory 
`/home/kevin/Compilations/blender-git/build_linux/CMakeFiles/CMakeTmp'
/usr/bin/make -f CMakeFiles/cmTryCompileExec1310631033.dir/build.make 
CMakeFiles/cmTryCompileExec1310631033.dir/build
make[2]: Entering directory 
`/home/kevin/Compilations/blender-git/build_linux/CMakeFiles/CMakeTmp'
/usr/bin/cmake -E cmake_progress_report 
/home/kevin/Compilations/blender-git/build_linux/CMakeFiles/CMakeTmp/CMakeFiles 
1
Building C object 
CMakeFiles/cmTryCompileExec1310631033.dir/CheckFunctionExists.c.o
/usr/bin/cc   -DCHECK_FUNCTION_EXISTS=pthread_create   -o 
CMakeFiles/cmTryCompileExec1310631033.dir/CheckFunctionExists.c.o   -c 
/usr/share/cmake-2.8/Modules/CheckFunctionExists.c
Linking C executable cmTryCompileExec1310631033
/usr/bin/cmake -E cmake_link_script 
CMakeFiles/cmTryCompileExec1310631033.dir/link.txt --verbose=1
/usr/bin/cc -DCHECK_FUNCTION_EXISTS=pthread_create
CMakeFiles/cmTryCompileExec1310631033.dir/CheckFunctionExists.c.o  -o 
cmTryCompileExec1310631033 -rdynamic -lpthreads 
/usr/bin/ld: cannot find -lpthreads
collect2: error: ld returned 1 exit status
make[2]: Leaving directory 
`/home/kevin/Compilations/blender-git/build_linux/CMakeFiles/CMakeTmp'
make[2]: *** [cmTryCompileExec1310631033] Error 1
make[1]: *** [cmTryCompileExec1310631033/fast] Error 2
make[1]: Leaving directory 
`/home/kevin/Compilations/blender-git/build_linux/CMakeFiles/CMakeTmp'


Determining if the system is big endian passed with the following output:
Change Dir: /home/kevin/Compilations/blender-git/build_linux/CMakeFiles/CMakeTmp

Run Build Command:/usr/bin/make "cmTryCompileExec2576463542/fast"
make[1]: Entering directory 
`/home/kevin/Compilations/blender-git/build_linux/CMakeFiles/CMakeTmp'
/usr/bin/make -f CMakeFiles/cmTryCompileExec2576463542.dir/build.make 
CMakeFiles/cmTryCompileExec2576463542.dir/build
make[2]: Entering directory 
`/home/kevin/Compilations/blender-git/build_linux/CMakeFiles/CMakeTmp'
/usr/bin/cmake -E cmake_progress_report 
/home/kevin/Compilations/blender-git/build_linux/CMakeFiles/CMakeTmp/CMakeFiles 
1
Building C object CMakeFiles/cmTryCompileExec2576463542.dir/Te

Re: [Bf-committers] About default values

[Kévin Dietrich]

 

Oki doki then, 

thankfully, I haven't spent anymore time on this, so haven't wasted
time. 

Le 2014-01-23 16:10, Campbell Barton a écrit : 

> Note that this is on my personal todo list. its just not been very
> high priority.
> 
> On Fri, Jan 24, 2014 at 1:41 AM, Kévin Dietrich
>  wrote:
> Thanks for those links. I did not know someone was already on the case, but 
> it seems it was doomed. I'll probably just drop the case on this one until a 
> decision from the devs or Ton is taken. If any. Thanks. Le 2014-01-23 14:49, 
> Rasmus Lerchedahl Petersen a écrit : Note that Harley Acheson made a large 
> effort in this direction, but seemed to have trouble getting it accepted, see 
> the thread here: 
> http://lists.blender.org/pipermail/bf-committers/2013-January/038965.html [1] 
> [1] and the patch he made here: https://developer.blender.org/T32894 [2] [2] 
> Maybe make sure of the destiny of your efforts before you put them in... 
> ___ Bf-committers mailing list 
> Bf-committers@blender.org 
> http://lists.blender.org/mailman/listinfo/bf-committers [3] [3] Links: -- 
> [1] http://lists.blender.org/pipermail/bf-committers/2013-January/038965.html 
> [1] [2] https://developer.blender.org/T32894 [2] [3] 
> http://lists.blender.org/mailman/listinfo/bf-comm
 itters
[3] ___ Bf-committers mailing list 
Bf-committers@blender.org 
http://lists.blender.org/mailman/listinfo/bf-committers [3]

 

Links:
--
[1]
http://lists.blender.org/pipermail/bf-committers/2013-January/038965.html
[2] https://developer.blender.org/T32894
[3] 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] About default values

[Kévin Dietrich]

 

Thanks for those links. 

I did not know someone was already on the case, but it seems it was
doomed. 

I'll probably just drop the case on this one until a decision from the
devs or Ton is taken. If any. 

Thanks. 

Le 2014-01-23 14:49, Rasmus Lerchedahl Petersen a écrit : 

> Note that Harley Acheson made a large effort in this direction, but seemed
> to have trouble getting it accepted, see the thread here:
> http://lists.blender.org/pipermail/bf-committers/2013-January/038965.html [1]
> and the patch he made here:
> https://developer.blender.org/T32894 [2]
> 
> Maybe make sure of the destiny of your efforts before you put them in...
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers [3]

 

Links:
--
[1]
http://lists.blender.org/pipermail/bf-committers/2013-January/038965.html
[2] https://developer.blender.org/T32894
[3] 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] About default values

[Kévin Dietrich]

 

I found how to define values as seen in the interface. So that's one
less question. 

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

[Bf-committers] About default values

[Kévin Dietrich]

 

Hello everyone, 

In Blender when one wants to reset a value to its default, in most
cases, it gives you the soft minimum (i. e. Render Resolution becomes
4px * 4px). As it is in the simple todo list [1], I'd like to work on it
and hard-code all those default values. I spent a few minutes to try
things out and I have some questions : 

- Should I create a task (Bug ? UI ? - and assign it to self - or simply
upload a patch when I'm finished ? Or reopen the bug report ? 

- How to set per axis default ? By which I mean: for Gravity, if I set
the default to -9.81 all axis will inherit this value. 

- There are inconsistencies reported by some users : like fluid time is
set to 4 seconds whilst the default timing of the scene is about 10 sec.
In that case what should I do ? I'd say one should fix that. Then which
file(s) is responsible for the values we see in the interface ? 

I think that's all the questions I have. 

Regards, 

Kevin 

 

Links:
--
[1]
http://wiki.blender.org/index.php/Dev:2.5/Source/Development/Todo/Simple_Todos#RNA
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers