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

[Bf-committers] GSoC 2018: Layer Painting Proposal

[Cheryl Chen]

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

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

[Bastien Montagne]

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

[Bf-committers] [Proposal] summer of code

[amar]

Hi,
I am a student participating in summer of code, i want to bring intuitive 
human-to-computer interface to games.

Synopsis:
In particular, i think that speech-recognition technology has made great 
progress and is ready to be integrated into games because speech is 1) higher 
bandwidth connection than a keyboard and 2) easier to use than a mouse. I 
propose to make speech-recognition easier to incorporate into games by 
integrating the greatest open source speech-to-text engine with blender. 
However, i came to the conclusion that in order to do that, two things will 
need to be done first 1) daemonization of cmu sphinx speech-to-text engine and 
2) creation of an interface or API between the daemon and applications 
requesting transcription i.e the blender game. Because 1) speech-recognition is 
getting better all the time, so we want to use the better model as soon as it 
is available, and this feature would allow that. 2) it provides a general 
solution which can work for applications besides blender and blender games. 
After that is done, blender can be extended to work with the API and the daemon 
easily.

Here is my proposal in full: 
https://github.com/radamar/eve/blob/master/README.md

Thanks for your consideration,
amar
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers