Update from 1.3.5 to 1.4 caused physics problem.. *solved*

hi,
just started on sio2 . First job, update our game from 1.3.5 to 1.4 sdk. After making the not too many changes , it wasn't working as expected .
The problem was that our bike objects would collide 'incorrectly' with the landscape. After going thru lots and lots of dead ends , it appears that the default output for the export script has changed for 'actors' that haven't got a 'bounds' specified. Previously this seems to have defaulted to '4' or 'triangle mesh' , now it doesnt' and leaves a 'box' instead.
Currently, rather than ask my artist to go through all the objects and edit this setting (he's busy editing UV's),I've done a quick hack to revert the defaults of the 1.3.5 script.
Something like this ( including the comment and commented out old version) , ( obv this is only for people with problems who haven't been thru and explicitly edited the setting in the blend file , once this is done the hack to the export py file isn't needed)

Code:


               #====================================
               # OBJECT BOUNDS
               #
               # 0 - Cube
               # 1 - Sphere
               # 2 - Cylinder
               # 3 - Cone
               # 4 - Static Triangle Mesh
               # 5 - Convex Hull
               #====================================
#               bounds = obj.rbShapeBoundType
#               mass  = 0.0
#
#                                 
#               if( obj.rbFlags & Object.RBFlags[ "DYNAMIC" ] ):
#   
#                  mass = obj.rbMass
#                  
#                  if( obj.rbFlags & Object.RBFlags["SOFTBODY"] and
#                        bounds != 5 ):
#   
#                        bounds = 5
#   
               bounds = 4
               mass  = 0.0
                              
               if( obj.rbFlags & Object.RBFlags[ "DYNAMIC" ] ):

                  bounds = obj.rbShapeBoundType

                  if( obj.rbFlags & Object.RBFlags[ "RIGIDBODY"] or
                     obj.rbFlags & Object.RBFlags[ "DYNAMIC"  ] and
                        bounds != 4 ):
                     
                        mass = obj.rbMass


                  if( obj.rbFlags & Object.RBFlags["SOFTBODY"] ):
                  
                        mass = obj.rbMass
                     
                        if( bounds != 5 ):
                           bounds = 5




*beware* I'd never used python before, so for those others that havent', the layout is important! ( look up offside http://en.wikipedia.org/wiki/Off-side_rule).
Thanks to francescu for the gldebug thing, that showed up that boxes rather than mesh was being used .
Oh and , no doubt after I've posted, I'll instantly find a message about this on the forum!
-dave-
now, back to the ai I was supposed to be writing

*however*
the app now runs at 8fps on the 1.4.0 sdk , rather than about 12fps on the 1.3.5.

I tried reverting the bullet code, and that seemed to make no difference.

Any ideas what might have happened??

User shark to profile... also if you have made the switch to 3.0 at the same time im not surprised... I found a performance loss in the texture upload / download...

shark *seems* to show 60% of time in sio2vertexgrouprender.

50% in gldrawelements,,, so i'm guessing the rest in the bind? <- though not obvious from the shark output..

in instruments ( opengles ) the non-zero stuff is something like,
command buffer used max size 1340784
gartresident object count 53
command buffer allocated bytes 3194880
owning PID 769
gartwired object count 53
scene count 6
command buffer count 2
command buffer submit count 6
resource bytes 22347776
command buffer submitted bytes 8044896
context count 3
command buffer free count 1
core animation frames per second 6 (!!!)
tiled scene bytes 499712
resource count 74
gartwired object size 18513920
gartpage in count 53
tiler utilization 39%
command buffer used avg size 1340784
command buffer used min size 1340784
garpage in size 18513920
xrvideo card run time stamp 202697878
command buffer largest size 1556480
command buffer total size 3112960
gart resident object size 18513920
render utilization 9%

all i can 'think' there is that it's slow, but the resident object size isnt too big?
anyone got any pointers on any of the other numbers
thnx
-dave-

we *have* tried to make a texture atlas which was annoying since then we couldnt use tile as much, we hoped that would speed things up, but it doesnt seem to have

we've also tried , os3.0 but with the older code that works with sdk 1.3.5 ( with appropriate compiler change so it works)

and this runs at the same speed as before. so it doesnt appear to be the new os3.0 ..

which implies its the change from sdk 1.3.5 to 1.4.0 that has caused the slowdown .

since it seems to be in the render most of the time , is it possible that a new 'feature' of the engine has caused this slowdown? perhaps new information is exported ?

( At first I thought , physics, however I've tried turning the physics off and/or reverting to the previous bullet code, but that made no measurable difference ( got 6 bikes on the terrrain)..)

after comparison with 1.3.5.

it *looks* like the commandbuffers are now approximately twice as large as before.
is there any reason this has happened? i'm guessing the info is in the vbo setup ?

anyone?

your guess is as good as mine

The garden is about 20k with lighting and physic, and its running at 15fps+

the model we have ( of a city , where you race bikes across it... in theory ).. is about 23k verts and 21k faces (850 objects) and *did* run at 15fps.. however it now runs at 9fps .

looking at the opengles runs using instruments, it just seems to be the command buffer sizes thats noticably different, so i'm assuming the difference is in there..

( also did some runs with no physics running, or at least i dont *think* the physics was running, removed the call to sio2PhysicRender and left the state as paused, made less than 1fps difference , also ran shark, shark had most of the time spent in sio2VertexGroupRender, in fact drawelements in the main)..

Check the object file with a text editor to make sure what exactly you are exporting...

The buffer haven't change from 1.3.5 to 1.4...

okay, found whats 'different'

in sio2_resource.cc.. the old 'do we render this object' check is something like,

if( _SIO2object->dst > 0.0f && ( _SIO2object->type & SIO2_OBJECT_SOLID ) )

the new check is like this,
if( ( _SIO2object->type & SIO2_OBJECT_SOLID ) && _SIO2object->dst )

the effect is that *all* the potential objects are drawn rather than over half being culled ( in the test position). I'm assuming this relates to distance from the camera, and used to cull objects ' behind' ? Since the dst is being set via sio2ResourceCull and uses the function sio2CameraSphereDistInFrustum , is it correct to just 'put back' the >0 check? Or will that cull a few too many?

Dude... dst is the distance from the pivot point to the object... that should cull allright

I don't understand , if dst is a distance, then how does '&& _SIO2object->dst' work?

surely it is 'true' for all but exactly 0?

and it doesn't cull any , honest , i've checked !

Im pretty sure it cull allright... cuz the bounding sphere radius tested on the frustum clipping plane should never give a negative number if it is not visible

If it doesn't cull, its because you haven't update the perspective and the modelview matrix

Cheers,

ahh yeah the changed sphere distance function now returns 0.. that's changed as well.. hehe , i'm having fun jumping thru both codebases in xcode


now, i wonder how my hacks for 'ghost' have affected things :-/ , first check , the 'revert' meant ghosts didnt have a distance set (DOH!)

hmm camera frustum is all Nan..



at least i'm getting somewhere today ,now to check the changes i made to the camera init code when moving sdk's .... getting there

If the camera frustum is all null, 2 choice: 1 the camera is not initialized, second you got a leak somewhere that is pushing the bytes...

modelview and projection in the camera seem to be 0 ? which doesnt help in sio2CameraUpdateFrustum..

I can't work out where these values are read from, they just seem to be 'malloc'd ?


ahh,
added
sio2CameraGetModelviewMatrix( sio2->_SIO2camera );
sio2CameraUpdateFrustum( sio2->_SIO2camera );
to the code

crossing fingers !

[edit]
sio2CameraGetModelviewMatrix( sio2->_SIO2camera );
and
sio2CameraGetProjectionMatrix( sio2->_SIO2camera );
i mean...

yay

seems when I updated , I just swapped the sio2CameraSetPerspective for sio2Perspective , I missed the new functions sio2CameraGetProjectionMatrix sio2CameraGetViewMatrix , that need to be called..

now, for an appropriate icon..

and it doesn't cull any , honest , i've checked !

>> Yeah, always put the blame on SIO2

sio2interactive wrote:and it doesn't cull any , honest , i've checked !

>> Yeah, always put the blame on SIO2

well it didnt cull any ..

coz the camera was all messed up !

coz the camera was all messed up !

>> Because of SIO2 or its user? 99% of the bugs comes from the users

sio2interactive wrote:coz the camera was all messed up !

>> Because of SIO2 or its user? 99% of the bugs comes from the users

I had a look at the new tutorials and what they did for the new camera call, but the one i picked didn't use the camera 'fully' ie have culling working. So I missed the extra functions that are needed..

user bugs === features

So davefb... following your drift I should take the features... so there's no more users bug?

Hummmmmm