search

Tarek-Aziz / gamekit

Automatically exported from code.google.com/p/gamekit
0 stars 0 forks source link

2.63 (upcoming) Problem #221

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
What steps will reproduce the problem?
1. Export a Default-Scene with current Blender-SVN-Version (Release announced 
for april)
2. Load the scene in Runtime

What is the expected output? What do you see instead?
I should see the the cube, nothing is seen. Actually the runtime runs well, 
just isn't able to build meshes anymore.

I tracked the problem down to gkMeshConverter::convert(void)

In <2.63-Files Mesh->mface had data, this isn't true anymore for at least the 
current version. (as already mentioned here: 
http://code.google.com/p/gamekit/issues/detail?id=214 ). 

Any suggestions or information about how to solve that problem?

One first step was to update blender.h:
I tried to created a new Blender.h/32bit dna with the bParse's Headergenerator 
and put that in the source, which lead to a Memory-Problem. Updating fbt with 
that Blender.h didn't succeed as well. 
What is the easiest workflow to create a current blender.h-file?

What version of the product are you using? On what operating system?
32bit linux

Original issue reported on code.google.com by thomas.t...@googlemail.com on 20 Mar 2012 at 8:27

GoogleCodeExporter commented 8 years ago 
For testing here a 2.63-File! 
You can also see, that something is really different when you just try to load 
a 2.63-File into e.g. 2.62. The surfaces are gone...due to the bmesh-stuff

Original comment by thomas.t...@googlemail.com on 20 Mar 2012 at 8:37

Attachments:

GoogleCodeExporter commented 8 years ago 
Ok, I make progress with this. At least momo_ogre.blend works again and it 
was/is a hard fight. Actually the whole structure about mesh-data changed and 
it took quite a while to figure out where to find the corresponding data.All is 
done with Poly and Loops now.

For now I use fbt with a newly blender.h-file generated by bparse (is this the 
right workflow). I had to adjust the blender.h-file cause fbt is not able to 
parse uint64_t, so I set that 4 fields to 'long' which actually must have a 
side-effect somewhere...(didn't figure out how to change this,yet) 

Nevertheless most seem to work now. Honestly imo a miracle :D Only problem so 
far are the vertex-colors. 1) the colors are wrong. Maybe they save them in 
another color-format.
2) Trying the old vertex-color-regressiontest showed a nice "matrix" like scene 
:D (see attachment. nice, but not right :D Any suggestions?)

Still I need to do some checks and also I doubt a bit if the downwards 
compatibility is still there. I have to think about a good strategy.

Original comment by tomag...@googlemail.com on 21 Mar 2012 at 3:46

Attachments:

GoogleCodeExporter commented 8 years ago 
Sounds all great!

You might have to run an unpatched working version side by side with your 
updated/patched version and compare where the vertex color issue happens.

Original comment by erwin.coumans on 23 Mar 2012 at 10:06

GoogleCodeExporter commented 8 years ago 
...even my trunk version has issues with this sample, but I'm sure I did see it 
work once. The strange thing is that vertex colors are working now, but not 
using this sample. Strange strange :D

About the 2.63 filetype: I got it work with fbt. I added the "uint64_t" to the 
Blender.h-parser and it works for old and new filetypes. bParse don't work for 
both. Here I can only say load old or new type using the new or the old 
blender.h along with a coresponding DNA. (For now I added a cmake-option to say 
I want bParse <=2.63 or >=2.63, so bParse is still in the game :D) Nevertheless 
there were some data that was just missing for the mesh (collider / 
invisible)....I worked around for now.

Along with this I also updated Ogre1.8 to the latest trunk-version which wasn't 
as trivial as it sounds and there might be some issues somewhere. So I'm 
working on to constructions sites right now.

And also added accelerometer to android's OIS plus communication from and to 
android-java through gamekit's message-system....

I think it would be a good idea to create a branch for this update until it is 
100% stable. What do you think? (And yes, I would like to have commit-access)

At the moment I'm testing all of this on all platforms and I think I could 
update to branch on sunday...

Original comment by thomas.t...@googlemail.com on 23 Mar 2012 at 11:25

GoogleCodeExporter commented 8 years ago 
Ok, here we are.I more or less got all problems fixed (which does not mean that 
there isn't anything left, yet :D)

1)Even the Vertexcolors worked now (see attachment). Actually it was a material 
problem, and vertexcolors seem not to work with rtss (as it was in the version 
before). 
2)Only on Mac with RTSS the multitexture doesn't work. That is strange because 
it worked on all other systems including android and iphone/ipad. I tested the 
ogre-material based technique on my own and got it work. Don't know where the 
problem is exactly,..maybe we will have to throw an eye on this,...

What is in this Monster-Patch?
1) Ogre3d-Trunk
- that wasn't so easy. Lot's of cmake-changes on the ogre-side made this quite 
hard. There maybe some switches that need to be set a different way. I got some 
problems with OgreViewport...
2) Blend263 support. As mentionend above. FBT is now selected from the 
beginning as it can read all files without problem. If you select bParse you 
have to decide if you want to load old or new-filetypes. The switch apperantly 
chooses the right Blender.h/dna-files to be included in cmake. 
The meshimporter itself is for now implemented nearly as a copy of the former 
one. I didn't know if I want to pollute the one file with dozens of 
define-switches and actually I don't know what is going to come with blender is 
in the future file releases...
3) Ghost-Support. If you set collision-type to sensor or ghost this object is 
mapped as btGhostObject. This is alpha and not tested 100% a test-case is 
attached.You can query collision by brick or (new)lua-functions
4) Lua: new Lua-Functions:
- Scene: getPickRay,getMainCamera
- ActionActuator: get/setAnimPosition, isActionEnded()...
- physics: getContactAmount(), getContact(nr)
- gsGameObject: getChildCount(),getChildAt(nr)
- Message: getMessages from the MessageSensor

5) Android:
- new toolchain (call should be the same like before or just use it as 
toolchain in cmake-gui NDK-env must be set). The new toolchain let you compile 
for different archs. armv7a is default, which means support of 
hw-floatingpoint. before it was only arm5/6 with software fp) Makes the stuff a 
bit faster :D
- Android-Accelerometer: This is mapped passed via jni to the main.cpp (which 
is still a horrible class, which we have to do from scratch new someday :D) 
main.cpp 
then injects the values to the ois-joystick that I implemented in 
AndroidInputSystem
- Main.cpp adds itself as Message-Listener and passes all messages to the 
android's GameKitJNI-class. 
- The other way round is also possible. Use sendMessage in Main.java. This 
makes it possible to add actually many android-specific stuff to 
gamekit-applications.

I made a big effort to test all of this on all supported 
systems(linux32,win32,mac32,android,ipad). And at least it seems to be quite 
stable. Runtimes for all of this are available here: 
http://gamekit.org/forum/viewtopic.php?f=2&t=354

I don't know if we really need a new branch as I mentioned before. It's your 
call Erwin. Maybe we can let the patch here for one week for people to test and 
then commit it to trunk...(I can do it then, if you give me commit-right)

Ok, I think we are on track with gamekit. And it just begins... :D

Comments are very welcome.

Original comment by thomas.t...@googlemail.com on 25 Mar 2012 at 2:11

Attachments:

GoogleCodeExporter commented 8 years ago 

Great.

Why don't you try to commit this yourself, because you are added to the 
committers now :)

Original comment by erwin.coumans on 27 Mar 2012 at 12:32

GoogleCodeExporter commented 8 years ago 
Ok, I finally commited all modifications. I let the old ogre-1.8-folder as is, 
as it might be possible we have to check at some points. Once we consider 
ogre-1.8rc(the new folder name) I will delete this.

Keep the fingers crossed everything went well.

Original comment by thomas.t...@googlemail.com on 28 Mar 2012 at 1:53

GoogleCodeExporter commented 8 years ago 
Thanks for this work!

Original comment by erwin.coumans on 30 Mar 2012 at 6:54

GoogleCodeExporter commented 8 years ago 
Hello

I am getting "fbtBlend.h: No such file or directory" errors when using Bparse 
(tested with both versions of the dna files), but i need Bparse since a couple 
of tricks i do in my project are bparse related so not supported by fbt.
Any idea about this?

Original comment by joeyferweda@gmail.com on 19 Apr 2012 at 9:56

GoogleCodeExporter commented 8 years ago 
Have you tried doing make clean after changing the cmake parameter?

Also, I'm curious about what sort of tricks you can do with bParse that is not 
possible with FBT.

Original comment by kungfoobar@gmail.com on 19 Apr 2012 at 10:10

GoogleCodeExporter commented 8 years ago 
@kungfoobar: Yes the problem remains the same, looking at the 
gkBlendInternalFile.h, there is a if statement excluding fbtBlend.h from the 
build when using bparse.
I think there is some leftover code still doing calls to fbtBlend.h but i can 
not find where that should be, since the Blendloading part is a little over my 
head.

Tried with a clean checkout btw

Original comment by joeyferweda@gmail.com on 19 Apr 2012 at 10:25

GoogleCodeExporter commented 8 years ago 
Wasn't able to reproduce the error, yet. Even though I know it and it should be 
fixed.

But you said you are working on a clean checkout!? Hmm...
Maybe you can tell about your system and how you call the cmake-script (via gui 
or commandline!?)

Original comment by thomas.t...@googlemail.com on 19 Apr 2012 at 1:29

GoogleCodeExporter commented 8 years ago 
@Thomas: My system is a 32bit Fedora 16 (updated), but i also tried on 64bit 
Ubuntu 11.04, with the same results.
I am using Cmake 2.8.7 and compile with default settings.

My steps:
1 - svn checkout
2 - cmake-gui
3 - Configure for Unix Makefiles
4 - Select bParse, use BPARSE_FILE_FORMAT 1 (default) and Generate makefiles
5 - make

Currently the issue i am having is BlenderSceneConverter.cpp:652:21 error: 
'struct Blender::Object' had no member named 'collision_boundtype'

Original comment by joeyferweda@gmail.com on 19 Apr 2012 at 1:59

GoogleCodeExporter commented 8 years ago 
Well, actually that is not the same result as the one before... 
but this error makes more sense,...this variable ('collision_boundtype') came 
with blender 2.62 and we just use it since one week or such.

I fixed it for bparse-format 1 in svn now. 
Caution:the runtime-sample in svn is in 2.63-format. So in order to play this 
you need to compile with bparse_format 2.

Original comment by thomas.t...@googlemail.com on 19 Apr 2012 at 5:09

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
Well, yes zlib is a dependency, but since the beginning I think. Don't see the 
connection between the error you mentioned above and zlib...any hint? Where do
you see the connection?

Original comment by thomas.t...@googlemail.com on 19 Apr 2012 at 8:05

GoogleCodeExporter commented 8 years ago 
That bParse error is my fault, as I forgot to modify it. Please revert that fix 
(I think it wouldn't work for versions 2.61 and 2.62) and apply this patch 
instead.

As you can see, there are 3 misplaced struct members so they won't be 
compatible between blender versions. Hopefully those aren't important (view 
drawtype, restrict flag) and gamekit doesn't need them.

Original comment by kungfoobar@gmail.com on 20 Apr 2012 at 7:44

Attachments:

GoogleCodeExporter commented 8 years ago 
Oh, also the position of the old boundtype is different from the new one. Now 
the old is called "pad5" (I think FBT won't read that field correctly from old 
files but mysteriously blender does) and I renamed the new one to 
"visual_boundtype" in bParse 25 to keep the old name.

Original comment by kungfoobar@gmail.com on 20 Apr 2012 at 8:02

GoogleCodeExporter commented 8 years ago 
Ok, commited the 2.61/62-compatiblity. 
http://code.google.com/p/gamekit/source/detail?r=1081
Close this issue.

Original comment by thomas.t...@googlemail.com on 15 May 2012 at 5:27