Closed dfelinto closed 9 years ago
It works on my machine for sample.blend I run the tests tomorrow and come back to you.
Thanks, once we get over that I can even use the official blender buildbot to make official-like builds for OSX, Windows and Linux with the patch applied on top of 2.72b.
After a few tests then:
David
Le 11 nov. 2014 à 22:19, Dalai Felinto notifications@github.com a écrit :
Thanks, once we get over that I can even use the official blender buildbot to make official-like builds for OSX, Windows and Linux with the patch applied on top of 2.72b.
— Reply to this email directly or view it on GitHub.
Confirmed the same issue here. I will try to "git bisect" it.
@PyrApple I'm having a hard time pinpointing when this was introduced. In fact this error seems to happen even with a patched Blender 2.69. Can you double-check if the Spider is really working with 2.69?
Nor does it work with 2.70a (haven't got 2.69 compiled at the moment)
Le 13 nov. 2014 à 19:33, Dalai Felinto notifications@github.com a écrit :
@PyrApple I'm having a hard time pinpointing when this was introduced. In fact this error seems to happen even with a patched Blender 2.69. Can you double-check if the Spider is really working with 2.69?
— Reply to this email directly or view it on GitHub.
Let me know if you can test the 2.69 version. I created a branch [1] with the code merged from 2.69 to 2.72, which works for 'git bisect' [2].
The patch was added after commit bbd9b5f4 as the commit 149fa998. From there I did a git cherry-pick of all Blender code from 2.69 to 2.72, to inspect. But while the original patched commit (roughly 2.69) worked at first, it failed afterwards.
The idea test would be to build in your system from the original instructions, with the original patch. If it works then build from commit 149fa998 (in blender-vr-bisect, let me know if you need help with that).
That should give us an understanding of what the issue may be. It's different to chase a bug that was introduced at some point, or that always existed, but it was not perceived before.
[1] https://github.com/BlenderVR/blender/tree/blender-vr-bisect [2] http://git-scm.com/docs/git-bisect
(there is a chance the issue was not noticeable in the CAVE because the spide is always in the front screen, while in my tests with a dual setup the spider is split in two screens. The terrain itself looks fine)
Yosh, I'll give it a try tomorrow.
For the notice, I've already seen the spider functional on a previous blenderCave version. (Damien, it rings a bell?)
David
Le 14 nov. 2014 à 20:33, Dalai Felinto notifications@github.com a écrit :
Let me know if you can test the 2.69 version. I created a branch [1] with the code merged from 2.69 to 2.72, which works for 'git bisect' [2].
The patch was added after commit bbd9b5f4 as the commit 149fa998. From there I did a git cherry-pick of all Blender code from 2.69 to 2.72, to inspect. But while the original patched commit (roughly 2.69) worked at first, it failed afterwards.
The idea test would be to build in your system from the original instructions, with the original patch. If it works then build from commit 149fa998 (in blender-vr-bisect, let me know if you need help with that).
That should give us an understanding of what the issue may be. It's different to chase a bug that was introduced at some point, or that always existed, but it was not perceived before.
[1] https://github.com/BlenderVR/blender/tree/blender-vr-bisect [2] http://git-scm.com/docs/git-bisect
(there is a chance the issue was not noticeable in the CAVE because the spide is always in the front screen, while in my tests with a dual setup the spider is split in two screens. The terrain itself looks fine)
— Reply to this email directly or view it on GitHub.
btw, which darwin lib revision did you use for the compilation of [1], and how did you know which lib revision corresponds to which blender commit?
David
Le 14 nov. 2014 à 20:33, Dalai Felinto notifications@github.com a écrit :
Let me know if you can test the 2.69 version. I created a branch [1] with the code merged from 2.69 to 2.72, which works for 'git bisect' [2].
The patch was added after commit bbd9b5f4 as the commit 149fa998. From there I did a git cherry-pick of all Blender code from 2.69 to 2.72, to inspect. But while the original patched commit (roughly 2.69) worked at first, it failed afterwards.
The idea test would be to build in your system from the original instructions, with the original patch. If it works then build from commit 149fa998 (in blender-vr-bisect, let me know if you need help with that).
That should give us an understanding of what the issue may be. It's different to chase a bug that was introduced at some point, or that always existed, but it was not perceived before.
[1] https://github.com/BlenderVR/blender/tree/blender-vr-bisect [2] http://git-scm.com/docs/git-bisect
(there is a chance the issue was not noticeable in the CAVE because the spide is always in the front screen, while in my tests with a dual setup the spider is split in two screens. The terrain itself looks fine)
— Reply to this email directly or view it on GitHub.
I just try to compile. When it complains (usually about python) I just do svn log and get the corresponding python.
blendernetwork.org/dalai-felinto www.dalaifelinto.com
2014-11-14 21:49 GMT-02:00 PyrApple notifications@github.com:
btw, which darwin lib revision did you use for the compilation of [1], and how did you know which lib revision corresponds to which blender commit?
David
Le 14 nov. 2014 à 20:33, Dalai Felinto notifications@github.com a écrit :
Let me know if you can test the 2.69 version. I created a branch [1] with the code merged from 2.69 to 2.72, which works for 'git bisect' [2].
The patch was added after commit bbd9b5f4 as the commit 149fa998. From there I did a git cherry-pick of all Blender code from 2.69 to 2.72, to inspect. But while the original patched commit (roughly 2.69) worked at first, it failed afterwards.
The idea test would be to build in your system from the original instructions, with the original patch. If it works then build from commit 149fa998 (in blender-vr-bisect, let me know if you need help with that).
That should give us an understanding of what the issue may be. It's different to chase a bug that was introduced at some point, or that always existed, but it was not perceived before.
[1] https://github.com/BlenderVR/blender/tree/blender-vr-bisect [2] http://git-scm.com/docs/git-bisect
(there is a chance the issue was not noticeable in the CAVE because the spide is always in the front screen, while in my tests with a dual setup the spider is split in two screens. The terrain itself looks fine)
— Reply to this email directly or view it on GitHub.
— Reply to this email directly or view it on GitHub https://github.com/BlenderVR/blender-vr/issues/14#issuecomment-63147497.
Another tip: you can do only 'make' (without the install) and copy the 2.69 folder from the official Blender 2.69 (I had to do that, but I would do make install once per blender version first, and then override the corresponding folder)
Dalai,
Compiled [1], simple.blend works, not spider.blend.
problems to compile blender 2.69: (
The idea test would be to build in your system from the original instructions, with the original patch
)
the only blenderVR (old blederCave) patch I found was for 52200, I downloaded svn blender -r 52200, the cmake throws: (even manually defining a valid CMAKE_OSX_SYSROOT)
$ cmake ../blender/ -DWITH_PLAYER=ON -DWITH_PYTHON_INSTALL_NUMPY=OFF -DWITH_INTERNATIONAL=OFF -DCMAKE_OSX_SYSROOT='/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk ' -- Detected system-version: unsupported -- Detected Xcode-version: 6.1 -- Performing Test SUPPORT_SSE_BUILD CMake Warning at /usr/local/Cellar/cmake/2.8.12.2/share/cmake/Modules/Platform/Darwin.cmake:179 (message): Ignoring CMAKE_OSX_SYSROOT value:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSXunsupported.sdk
because the directory does not exist. Call Stack (most recent call first): /usr/local/Cellar/cmake/2.8.12.2/share/cmake/Modules/CMakeSystemSpecificInformation.cmake:36 (include) CMakeLists.txt:3 (PROJECT)
CMake Error at /usr/local/Cellar/cmake/2.8.12.2/share/cmake/Modules/Platform/Darwin.cmake:211 (message): CMAKE_OSX_DEPLOYMENT_TARGET is '10.9' but CMAKE_OSX_SYSROOT:
""
is not set to a MacOSX SDK with a recognized version. Either set CMAKE_OSX_SYSROOT to a valid SDK or set CMAKE_OSX_DEPLOYMENT_TARGET to empty. Call Stack (most recent call first): /usr/local/Cellar/cmake/2.8.12.2/share/cmake/Modules/CMakeSystemSpecificInformation.cmake:36 (include) CMakeLists.txt:3 (PROJECT)
CMake Error: Internal CMake error, TryCompile configure of cmake failed -- Configuring incomplete, errors occurred! See also "/Users/AstrApple/WorkSpace/BlenderVR_Workspace/sources_blender/blender-git-official-52200/build/CMakeFiles/CMakeOutput.log".
Which version (blender/patch blendervr) did you use for
David
Le 14 nov. 2014 à 20:33, Dalai Felinto notifications@github.com a écrit :
Let me know if you can test the 2.69 version. I created a branch [1] with the code merged from 2.69 to 2.72, which works for 'git bisect' [2].
The patch was added after commit bbd9b5f4 as the commit 149fa998. From there I did a git cherry-pick of all Blender code from 2.69 to 2.72, to inspect. But while the original patched commit (roughly 2.69) worked at first, it failed afterwards.
The idea test would be to build in your system from the original instructions, with the original patch. If it works then build from commit 149fa998 (in blender-vr-bisect, let me know if you need help with that).
That should give us an understanding of what the issue may be. It's different to chase a bug that was introduced at some point, or that always existed, but it was not perceived before.
[1] https://github.com/BlenderVR/blender/tree/blender-vr-bisect [2] http://git-scm.com/docs/git-bisect
(there is a chance the issue was not noticeable in the CAVE because the spide is always in the front screen, while in my tests with a dual setup the spider is split in two screens. The terrain itself looks fine)
— Reply to this email directly or view it on GitHub.
Hi David, You need to set CMAKE_OSX_DEPLOYMENT_TARGET. For example:
-DCMAKE_OSX_DEPLOYMENT_TARGET=10.7
You can try all the way to 10.5, though 10.7 or 10.6 should work.
> Compiled [1], simple.blend works, not spider.blend.
Did you try the branch as it is, or the hash I mentioned? The HEAD of the branch is blender 2.72, while the hash 149fa998 is a commit on top of the equivalent r60656 of SVN.
I thought the the original patch (that allegedly once had a working spider) was built on top of 2.69. I can try here to patch on top of r552200 and see how it goes.
Are you sure -r552200 is the one?
I created a branch with the original patch against r552200, but this is a Blender 2.64. The branch is blender-vr-552200.
As for the 2.69 tag I created a branch (blender-vr-2.69) as well as a tag (v2.69-blender-vr). And again the spider worked the first time I played, and went out of sync (the right side "shacking") the second time.
@touraine are you sure the spider ever worked 100%?
Compiled blender-vr-2.69 (without IK_ITASC to avoid the bug reported in https://developer.blender.org/T36207)
spider.blend works fine. Played three time in a raw with the animation sync on both master/slave.
The only issue is that the basic walk animation gets stuck after left/right animation. (pressing space, the "run animation" never fails)
David
Le 15 nov. 2014 à 16:17, Dalai Felinto notifications@github.com a écrit :
As for the 2.69 tag I created a branch (blender-vr-2.69) as well as a tag (v2.69-blender-vr). And again the spider worked the first time I played, and went out of sync (the right side "shacking") the second time.
@touraine are you sure the spider ever worked 100%?
— Reply to this email directly or view it on GitHub.
switched to blender 2.73
David, any update on that? We are waiting to see if we can produce "final" 2.72 patched Blender for all platforms.