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  = grid->cBeginOn(); 
than: 
  const typename GridType::ValueOnIter  = 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 <adriano.u...@gmail.com>:
> 
> 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 <kevin.dietr...@mailoo.org>:
> 
> 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] 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] 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 <kevin.dietr...@mailoo.org>
> 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]

 

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 kevin.dietr...@mailoo.org
 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

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

[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] 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 sergey@gmail.com:
 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 sergey@gmail.com
 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 blen...@dingto.org 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
 harley.ache...@gmail.com 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 whilea...@gmail.com
 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 vicenteca...@gmail.com 
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.blender.org/scons.git
[12] 

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

[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::Vec3float 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 pthread.h

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 

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
 kevin.dietr...@mailoo.org 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::Vec3float 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

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

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]

 

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
 kevin.dietr...@mailoo.org 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

[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