Re: [Bf-committers] Fwd: Linker fails using Xcode

[Valentin Rueda]

Thanks,
After I turn WITH_CYCLES* off - it builds successfully.

But now, when I run blender.app it fails with critical error(as I consider
when it tries to init python) http://prntscr.com/d8v4a2

I have python 2. and 3. installed.
Here is make cmake python settings http://prntscr.com/d8v2e3

If I turn WITH_PYTHON off build fails with http://prntscr.com/d8v7jn

Am I missing something?

-- 
Best regards
Rueda Valentin
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Fwd: Linker fails using Xcode

[Gruber Aurel]

Yeah that is really annoying, it’s a bug i think. Are you on MacOS Sierra 
already? I think that solves it. Also, update to latest Xcode version. I thinks 
I had the same problem and that solved the problem.

Aurel

> On 18 Nov 2016, at 14:59, Valentin Rueda  wrote:
> 
> Thanks,
> After I turn WITH_CYCLES* off - it builds successfully.
> 
> But now, when I run blender.app it fails with critical error(as I consider
> when it tries to init python) http://prntscr.com/d8v4a2
> 
> I have python 2. and 3. installed.
> Here is make cmake python settings http://prntscr.com/d8v2e3
> 
> If I turn WITH_PYTHON off build fails with http://prntscr.com/d8v7jn
> 
> Am I missing something?
> 
> -- 
> Best regards
> Rueda Valentin
> ___
> 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] Fwd: Linker fails using Xcode

[Valentin Rueda]

Thanks, now it works!

So in order to build and run blender using Xcode I had to get another
darwin version (https://svn.blender.org/svnroot/bf-blender/trunk/lib/darwin)
and turn cmake WITH_CXX11 on, and WITH_CYCLES_* off

Also, had to install Sierra update and update Xcode in order to run
blender.

Should we update
https://wiki.blender.org/index.php/Dev:Doc/Building_Blender/Mac, at least
to add the reference to c11 darwin library?

Thanks

2016-11-18 14:01 GMT+00:00 Gruber Aurel :

> Yeah that is really annoying, it’s a bug i think. Are you on MacOS Sierra
> already? I think that solves it. Also, update to latest Xcode version. I
> thinks I had the same problem and that solved the problem.
>
> Aurel
>
> > On 18 Nov 2016, at 14:59, Valentin Rueda 
> wrote:
> >
> > Thanks,
> > After I turn WITH_CYCLES* off - it builds successfully.
> >
> > But now, when I run blender.app it fails with critical error(as I
> consider
> > when it tries to init python) http://prntscr.com/d8v4a2
> >
> > I have python 2. and 3. installed.
> > Here is make cmake python settings http://prntscr.com/d8v2e3
> >
> > If I turn WITH_PYTHON off build fails with http://prntscr.com/d8v7jn
> >
> > Am I missing something?
> >
> > --
> > Best regards
> > Rueda Valentin
> > ___
> > 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
>



-- 
Best regards
Rueda Valentin
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Recent Change in Blender File Format

[homac]

Hello blender devs!


I have noticed a change in blender file format, which has some 
consequences, which I would like to discuss. Because the topic is a bit 
difficult to explain, I wrote this email. I'm also sitting in 
#blendercoders.

This change has no consequences for blender now but it may have for 
future versions of blender or thirdparty applications using .blend files.

In terms of LoC, this change is tiny, and therefore I thought there is a 
realistic chance to convince you to change it again or accept a patch, I 
could write.


The Change
==
Each block in a .blend file contains a copy of a unique area from heap 
memory. The start address stored in its block header is used to identify 
the block (and thereby the memory area) referenced by a pointer.

Thus, a .blend file represented parts of the heap from the virtual 
address space of a previous run of Blender. This implicitly meant, that 
memory areas in the file could not overlap each other (they where disjunct).

Some data structures such as trees or node networks, which have elements 
spread over several different areas in the heap, need special care: 
Traditionally, those structures where for example copied (packed) into 
one continuous memory area (e.g. an array) which is temporarily 
allocated on the heap before written to the block. To prevent malloc 
from assigning the same address to another temporarily allocated buffer, 
the buffer is deallocated after the entire file was written. That way, 
the fundamental assumption, that blocks are disjunct from each other, 
still holds.

Actually, Blender just needs the start address of a block to be unique, 
because pointers, which have to be resolved while reading a file, always 
reference start addresses only. Thus, recently (see [1]) the code for 
writing a tree structure was changed in a way which guarantees just that:

The start address of a block is unique, but its content may
 (virtually) overlap other blocks.

In this case, the start address is taken from the area inside the 
preceding block, and thus guaranteed to be unique. This is a neat trick 
to circumvent the deferred deallocation of the temporary buffer after 
writing the file but it changes the concept.


Consequence
===

A pointer, referencing an element inside of a block, such as a member of 
a struct, cannot be resolved without knowledge about the structure which 
contains the member.

For example, in the old model it was possible to map the file in memory 
and fill an address table with the start addresses and length of the 
blocks and its new address in heap. Based on this address table, any 
pointer could be mapped to its new address by identifying the block 
which contains this address.

This concept allowed for a very lazy method to read a file, just picking 
the data needed. It also allowed for a generic method which is almost 
independent from changes in blenders read and write functions.

With the new model, this is not possible, because blocks can overlap and 
addresses may be ambiguous.


Regards
  Holger Machens


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

Re: [Bf-committers] Recent Change in Blender File Format

[Bastien Montagne]

Well… I’d say your 'nice trick' to read .blend file was actually already 
wrong, outliner tree is not the only guy needing special pointer magic 
during writefile time, other areas (aware at least about some mesh data) 
need it too, so you could still have overlapping 'virtual memory areas' 
across whole file.

Further more, there is absolutely nothing saying .blend file should 
ensure a virtual non-overlapping memory map, we are only using pointers 
because it is (in most case) the easiest and cheapest way to get uuids 
for our data blocks, that’s all.

Never a good idea to rely on an implementation-specific behavior in file 
format area, only rely on written specs (though .blend format is not 
that well documented either).

My two cents anyway,
Cheers,
Bastien

Le 18/11/2016 à 16:55, homac a écrit :
> Hello blender devs!
>
>
> I have noticed a change in blender file format, which has some
> consequences, which I would like to discuss. Because the topic is a bit
> difficult to explain, I wrote this email. I'm also sitting in
> #blendercoders.
>
> This change has no consequences for blender now but it may have for
> future versions of blender or thirdparty applications using .blend files.
>
> In terms of LoC, this change is tiny, and therefore I thought there is a
> realistic chance to convince you to change it again or accept a patch, I
> could write.
>
>
> The Change
> ==
> Each block in a .blend file contains a copy of a unique area from heap
> memory. The start address stored in its block header is used to identify
> the block (and thereby the memory area) referenced by a pointer.
>
> Thus, a .blend file represented parts of the heap from the virtual
> address space of a previous run of Blender. This implicitly meant, that
> memory areas in the file could not overlap each other (they where disjunct).
>
> Some data structures such as trees or node networks, which have elements
> spread over several different areas in the heap, need special care:
> Traditionally, those structures where for example copied (packed) into
> one continuous memory area (e.g. an array) which is temporarily
> allocated on the heap before written to the block. To prevent malloc
> from assigning the same address to another temporarily allocated buffer,
> the buffer is deallocated after the entire file was written. That way,
> the fundamental assumption, that blocks are disjunct from each other,
> still holds.
>
> Actually, Blender just needs the start address of a block to be unique,
> because pointers, which have to be resolved while reading a file, always
> reference start addresses only. Thus, recently (see [1]) the code for
> writing a tree structure was changed in a way which guarantees just that:
>
>   The start address of a block is unique, but its content may
>   (virtually) overlap other blocks.
>
> In this case, the start address is taken from the area inside the
> preceding block, and thus guaranteed to be unique. This is a neat trick
> to circumvent the deferred deallocation of the temporary buffer after
> writing the file but it changes the concept.
>
>
> Consequence
> ===
>
> A pointer, referencing an element inside of a block, such as a member of
> a struct, cannot be resolved without knowledge about the structure which
> contains the member.
>
> For example, in the old model it was possible to map the file in memory
> and fill an address table with the start addresses and length of the
> blocks and its new address in heap. Based on this address table, any
> pointer could be mapped to its new address by identifying the block
> which contains this address.
>
> This concept allowed for a very lazy method to read a file, just picking
> the data needed. It also allowed for a generic method which is almost
> independent from changes in blenders read and write functions.
>
> With the new model, this is not possible, because blocks can overlap and
> addresses may be ambiguous.
>
>
> Regards
>Holger Machens
>
>
> [1] https://developer.blender.org/rBb98b331d04fe3a335cc0656809b4b09196507500
> ___
> 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] Recent Change in Blender File Format

[Ton Roosendaal]

Hi Holger,

Very cool analysis. Good to see people spend quality time on reviewing 
internals like this.

I agree with Bastien's remarks though. And I want to add this (as coder of the 
system):

The 'treestore' is for Outliner only. It saves the state as the UI shows 
outliner data.
It's not saving anything related to the scene description or relationships.

It's always been a weak design issue here. I really want UIs to be able to save 
state, but the way we do it could probably be done much better.

-Ton-


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

> On 18 Nov 2016, at 17:08, Bastien Montagne  wrote:
> 
> Well… I’d say your 'nice trick' to read .blend file was actually already 
> wrong, outliner tree is not the only guy needing special pointer magic 
> during writefile time, other areas (aware at least about some mesh data) 
> need it too, so you could still have overlapping 'virtual memory areas' 
> across whole file.
> 
> Further more, there is absolutely nothing saying .blend file should 
> ensure a virtual non-overlapping memory map, we are only using pointers 
> because it is (in most case) the easiest and cheapest way to get uuids 
> for our data blocks, that’s all.
> 
> Never a good idea to rely on an implementation-specific behavior in file 
> format area, only rely on written specs (though .blend format is not 
> that well documented either).
> 
> My two cents anyway,
> Cheers,
> Bastien
> 
> Le 18/11/2016 à 16:55, homac a écrit :
>> Hello blender devs!
>> 
>> 
>> I have noticed a change in blender file format, which has some
>> consequences, which I would like to discuss. Because the topic is a bit
>> difficult to explain, I wrote this email. I'm also sitting in
>> #blendercoders.
>> 
>> This change has no consequences for blender now but it may have for
>> future versions of blender or thirdparty applications using .blend files.
>> 
>> In terms of LoC, this change is tiny, and therefore I thought there is a
>> realistic chance to convince you to change it again or accept a patch, I
>> could write.
>> 
>> 
>> The Change
>> ==
>> Each block in a .blend file contains a copy of a unique area from heap
>> memory. The start address stored in its block header is used to identify
>> the block (and thereby the memory area) referenced by a pointer.
>> 
>> Thus, a .blend file represented parts of the heap from the virtual
>> address space of a previous run of Blender. This implicitly meant, that
>> memory areas in the file could not overlap each other (they where disjunct).
>> 
>> Some data structures such as trees or node networks, which have elements
>> spread over several different areas in the heap, need special care:
>> Traditionally, those structures where for example copied (packed) into
>> one continuous memory area (e.g. an array) which is temporarily
>> allocated on the heap before written to the block. To prevent malloc
>> from assigning the same address to another temporarily allocated buffer,
>> the buffer is deallocated after the entire file was written. That way,
>> the fundamental assumption, that blocks are disjunct from each other,
>> still holds.
>> 
>> Actually, Blender just needs the start address of a block to be unique,
>> because pointers, which have to be resolved while reading a file, always
>> reference start addresses only. Thus, recently (see [1]) the code for
>> writing a tree structure was changed in a way which guarantees just that:
>> 
>>  The start address of a block is unique, but its content may
>>  (virtually) overlap other blocks.
>> 
>> In this case, the start address is taken from the area inside the
>> preceding block, and thus guaranteed to be unique. This is a neat trick
>> to circumvent the deferred deallocation of the temporary buffer after
>> writing the file but it changes the concept.
>> 
>> 
>> Consequence
>> ===
>> 
>> A pointer, referencing an element inside of a block, such as a member of
>> a struct, cannot be resolved without knowledge about the structure which
>> contains the member.
>> 
>> For example, in the old model it was possible to map the file in memory
>> and fill an address table with the start addresses and length of the
>> blocks and its new address in heap. Based on this address table, any
>> pointer could be mapped to its new address by identifying the block
>> which contains this address.
>> 
>> This concept allowed for a very lazy method to read a file, just picking
>> the data needed. It also allowed for a generic method which is almost
>> independent from changes in blenders read and write functions.
>> 
>> With the new model, this is not possible, because blocks can overlap and
>> addresses may be ambiguous.
>> 
>> 
>> Regards
>>   Holger Machens
>> 
>> 
>> [1] https://developer.blender.org/rBb98b331d04fe3a335cc0656809b4b091

Re: [Bf-committers] Linker fails using Xcode

[Gruber Aurel]

Hey,

- So the part about Sierra and xcode is some sort of bug or incompatibility of 
xcode<->os or whatever on apples side.

- Regarding Cycles, I’m not sure what the issue is exactly, but in release 
build it works. In debug build you need to do some fiddling with the cmake file:
https://lists.blender.org/pipermail/bf-committers/2015-October/046008.html
  But I think thats an issue regardless of WITH_CXX11 and darwin libraries. Not 
sure though.

- I would like to point out the difference between C11 and C++11. C11 is the 
name of a standard of the C programming language. C++11 is a standard for the 
C++ language. While C++ was originally an extension of C, they are not the same 
language at all. Likewise, WITH_C11 and WITH_CXX11 do different things.

- Regarding the wiki, I’m not the right person to answer that question. But 
yes, it seems sensible to me. Maybe it should be pointet out, that blender will 
only support c++11 features officially with 2.8, right?

glad I could help

Aurel

On 18 Nov 2016, at 15:58, Valentin Rueda 
mailto:suares.valen...@gmail.com>> wrote:

Thanks, now it works!

So in order to build and run blender using Xcode I had to get another
darwin version (https://svn.blender.org/svnroot/bf-blender/trunk/lib/darwin)
and turn cmake WITH_CXX11 on, and WITH_CYCLES_* off

Also, had to install Sierra update and update Xcode in order to run
blender.

Should we update
https://wiki.blender.org/index.php/Dev:Doc/Building_Blender/Mac, at least
to add the reference to c11 darwin library?

Thanks

2016-11-18 14:01 GMT+00:00 Gruber Aurel 
mailto:augru...@student.ethz.ch>>:

Yeah that is really annoying, it’s a bug i think. Are you on MacOS Sierra
already? I think that solves it. Also, update to latest Xcode version. I
thinks I had the same problem and that solved the problem.

Aurel

On 18 Nov 2016, at 14:59, Valentin Rueda 
mailto:suares.valen...@gmail.com>>
wrote:

Thanks,
After I turn WITH_CYCLES* off - it builds successfully.

But now, when I run blender.app it fails with critical error(as I
consider
when it tries to init python) http://prntscr.com/d8v4a2

I have python 2. and 3. installed.
Here is make cmake python settings http://prntscr.com/d8v2e3

If I turn WITH_PYTHON off build fails with http://prntscr.com/d8v7jn

Am I missing something?

--
Best regards
Rueda Valentin
___
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




--
Best regards
Rueda Valentin
___
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] Recent Change in Blender File Format

[homac]

Hello Bastien and Ton!


Thank you for spending your quality time replying to emails!

Unfortunate for me, that I made my design on a false assumption, but 
I'll find a reasonable solution. Also, I will add this information to my 
documentation of the Blender DNA to prevent others from making the same 
mistake.

And Ton, on your statement:

 > It's always been a weak design issue here. I really want UIs to be
 > able to save state, but the way we do it could probably be done much
 > better.

I don't know, if this is meant to be an invitation to make a proposal. I 
actually don't see the issue there -- maybe because I've never looked 
into UI. I see, that there is a difference between persistent data 
stored for UI and that of the scene, since thirdparty tools just need 
the latter. But that's probably not the 'issue' you referred to.


Anyway, thanks for clarifying things.


Regards
  Holger


On 18.11.2016 18:16, Ton Roosendaal wrote:
> Hi Holger,
>
> Very cool analysis. Good to see people spend quality time on reviewing 
> internals like this.
>
> I agree with Bastien's remarks though. And I want to add this (as coder of 
> the system):
>
> The 'treestore' is for Outliner only. It saves the state as the UI shows 
> outliner data.
> It's not saving anything related to the scene description or relationships.
>
> It's always been a weak design issue here. I really want UIs to be able to 
> save state, but the way we do it could probably be done much better.
>
> -Ton-
>
> 
> Ton Roosendaal  -  t...@blender.org   -   www.blender.org
> Chairman Blender Foundation, Director Blender Institute
> Entrepotdok 57A, 1018 AD, Amsterdam, the Netherlands
>
>> On 18 Nov 2016, at 17:08, Bastien Montagne  wrote:
>>
>> Well… I’d say your 'nice trick' to read .blend file was actually already
>> wrong, outliner tree is not the only guy needing special pointer magic
>> during writefile time, other areas (aware at least about some mesh data)
>> need it too, so you could still have overlapping 'virtual memory areas'
>> across whole file.
>>
>> Further more, there is absolutely nothing saying .blend file should
>> ensure a virtual non-overlapping memory map, we are only using pointers
>> because it is (in most case) the easiest and cheapest way to get uuids
>> for our data blocks, that’s all.
>>
>> Never a good idea to rely on an implementation-specific behavior in file
>> format area, only rely on written specs (though .blend format is not
>> that well documented either).
>>
>> My two cents anyway,
>> Cheers,
>> Bastien
>>
>> Le 18/11/2016 à 16:55, homac a écrit :
>>> Hello blender devs!
>>>
>>>
>>> I have noticed a change in blender file format, which has some
>>> consequences, which I would like to discuss. Because the topic is a bit
>>> difficult to explain, I wrote this email. I'm also sitting in
>>> #blendercoders.
>>>
>>> This change has no consequences for blender now but it may have for
>>> future versions of blender or thirdparty applications using .blend files.
>>>
>>> In terms of LoC, this change is tiny, and therefore I thought there is a
>>> realistic chance to convince you to change it again or accept a patch, I
>>> could write.
>>>
>>>
>>> The Change
>>> ==
>>> Each block in a .blend file contains a copy of a unique area from heap
>>> memory. The start address stored in its block header is used to identify
>>> the block (and thereby the memory area) referenced by a pointer.
>>>
>>> Thus, a .blend file represented parts of the heap from the virtual
>>> address space of a previous run of Blender. This implicitly meant, that
>>> memory areas in the file could not overlap each other (they where disjunct).
>>>
>>> Some data structures such as trees or node networks, which have elements
>>> spread over several different areas in the heap, need special care:
>>> Traditionally, those structures where for example copied (packed) into
>>> one continuous memory area (e.g. an array) which is temporarily
>>> allocated on the heap before written to the block. To prevent malloc
>>> from assigning the same address to another temporarily allocated buffer,
>>> the buffer is deallocated after the entire file was written. That way,
>>> the fundamental assumption, that blocks are disjunct from each other,
>>> still holds.
>>>
>>> Actually, Blender just needs the start address of a block to be unique,
>>> because pointers, which have to be resolved while reading a file, always
>>> reference start addresses only. Thus, recently (see [1]) the code for
>>> writing a tree structure was changed in a way which guarantees just that:
>>>
>>> The start address of a block is unique, but its content may
>>>  (virtually) overlap other blocks.
>>>
>>> In this case, the start address is taken from the area inside the
>>> preceding block, and thus guaranteed to be unique. This is a neat trick
>>> to circumvent the deferred deallocation of the temporary buffer after
>>> writin

[Bf-committers] Blender 2.8 layer and workflow proposal

[Dalai Felinto]

Hi there,
(cross posting in multiple blender lists, if you have a reply to make
please do it on bf-committers).

In the past weeks I've been working at the Blender Institute on
unifying all the past proposals about layer, viewport, engines and
workflow designs.

Without further ado you can read the suggested proposal here:
https://code.blender.org/2016/11/layers-and-beyond/

I'm posting this to the Cycles list as well, because there are a few
cycles related changes that would be a nice fit for the current
proposal.

We're planning to present it at the usability workshop next week. But
any early feedback is welcome as well.

Regards,
Dalai
--
blendernetwork.org/dalai-felinto
www.dalaifelinto.com
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers