[Bf-committers] Recast & Detour

[Campbell Barton]

On Sun, Sep 11, 2011 at 6:45 AM, Benoit Bolsee <benoit.bolsee at online.be> wrote:
> First time I can sit at my computer; I just saw the commits and comments
> about the Recast & Detour merge. I will do my best to reply.
>
> @Thomas: I know perfectly well that it's better to stay online after a
> merge. But this merge took much longer than expected because I had to do
> it manually (I was hoping to use svn reintegrate but it doesn't work).
> As for postponing the merge, that was not possible considering my busy
> schedule and the deadline for the branch mergers final. My only option
> was to count on the community to fix the issues, which it did well.
> Thanks to all and I'm very very sorry for the trouble.

platform/portability breakages don't worry me so much, and think its
fair to have developers maintain their platforms they use.

Thomas said there were python errors though so I'd assume these would
have happened on windows too?

> @Bastien: thanks for finding this huge bug in the ModifierType enum. It
> came from the last merge from trunk. I don't know how I missed it
> because I checked for order issues in other files. I've been waiting to
> do this merge for 1 year. It's not an excuse but it explains the
> lassitude and approximation at the end.
>
> About Linux errors: Nick and I are working on Windows. Testing on Linux
> requires someone to build the branch and do extensive tests. As you
> know, that does not happen. It raises again the question of branch
> testing. Only trunk get tested fully.
>
> @Campbell: having a C++ file in a C library is no problem if the all the
> public functions in the file are declared with extern "C". You can see
> it's done in navmesh_conversion.cpp. Yet this file has to be C++ because
> it uses the recastnavigation library, which is C++.

Saw this when baking edits to the files, looks like Recast.h could be
made C compatible if the initializers and distructors were removed
from the structs but not sure if this end up being a hassle to add
alloc/free calls all over just so we can rename the files  to *.c.

> About bad level calls: I understand the concern and I agree to find a
> solution. Let's discuss this on IRC.

Sure, don't think this is hard to solve.

> I see that modifications were done on the recastnavigation library to
> make it work in Linux and OSX. This is not too good because it is an
> external library. A better option would be to install a more recent
> version of the library that fixes the bugs. Unfortunately this will
> require another round of testing and I don't have the time to do that. I
> will see if Nick can work on that. Otherwise we can live with a patched
> library for now.

I'll commit a patch to svn showing a diff from the original, we can
then apply this to the updated library, I really prefer not to make
random changes to external libs, but getting it building was most
important.


Still I'm a bit worried about this feature, I thought this was BGE
only but it adds a modifier thats only purpose seems to be to add its
own drawing calls into the derived mesh also adds own customdata layer
- but the modifier its self stores no data.

Were less intrusive methods of storing this data investigated? -
Curve, GreastPencil, ID-Properties?

> /benoit
>
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
- Campbell