Sorry your browser is not supported!

I made a draw call optimizer , that work by optimizing small (nearby) meshes into a merged optimized mesh. This all work perfectly fine for optimizing 2 meshes , but now i want to call the same optimizer to add 2 (already) optimized meshes into a new optimized mesh, and here the AppGameKit bug is:



In the glVertexAttribPointer setup in the mesh memblock, the string part length include padding in AGK.
The problem is when you process a second time, AppGameKit add another 4 byte padding so str len get 4 bytes larger. and attribytes is moved out of place.
At this point the object will not work and AppGameKit will crash if you process these objects.

I tried to correct the headers, but if i set the correct str len. then the object will not display in AppGameKit, so im kind of stuck here.

I have some GameGuru Loader customers that have made large games with many smaller objects, AppGameKit dont like many smaller objects and the fps gets lower and lower due to the many GPU stage changes going on, the drawcall optimizer give a nice fps boost, but i like to run a second pass to get a even better FPS, So i beg on my knee's for a quick fix

Test level screenshot: Same colors include 2 small objects merged into a optimized mesh:

I can confirm this bug .... its something I have noticed too.

On each creation of an object from a mesh-memblock, the text fields for "Position", "Normal" and "UV" are expanded by 4 bytes.

So if you take an object, convert it to a mesh-memblock and back to an object without any changes to it, it gets bigger by 12 bytes (4 bytes for position, normal and UV)


These are the actual values from the memblock data after successive conversions between Objects and memblocks. No data alteration was done - Each time the conversion is done, 4 bytes are added to the text fields.

(It looks like when it was written someone tried to add padding for a 4byte boundary when the coder should do that....not AGK)

However: This change in text size doesnt "break" the object or prevent it from displaying, even after multiple conversions the object still displays even with text feilds being much bigger than they should be. The third object above renders fine! It just makes the whole memblock 12/24/36/48 bytes bigger. After multiple conversions the objects still render and work fine(at least after 4 conversion they do). They just have additional blank data in them. You just need to make sure that you use the VertexOffset and IndexOffset in the memblock after you create it from an object and dont assume the data will be in the same place. (like... vertex data being at 60....it moves each time its created!)

You can correct it yourself each time by moving the attribute data back to its original size and location on each creation and moving the vertex and index data if you want to....but I dont think 12 bytes matters enough to bother - it depends how many times your doing this. (I did write a function to do it though just in case)

It is a bug... TITLE should really be "BUG: CreateMeshFromMemblock()"

I too came across this problem and let Rick/Paul know about this a few weeks ago, not sure if I was convincingly enough
And thats my little test code I sent him:

@Preben: Did you manage to get this fixed? Is it not possible to manually correct the erroneous changes in the memblock before converting to a mesh?

You can correct the extra bytes between conversions if wanted so the model is only ever 12bytes larger. I've done that.

In reality its not really needed unless you do repetative conversions between objects and memblocks.

The Devs (Paul) should be able to fix this easily. I just hope he sees this thread or reads Janbos email.

Yes it was fixed , first version of this will be in the next release ( Monday ).

It will not work on all objects for a start , mainly because i do now know the origin of the objects, and when the mesh is merged into single objects you need to rotate/match the vertex positions to be relative from the object you merge , this is all fine if you know the origin of rotation so please Paul: GetObjectPivot( objID ) , anyway it works fine on objects that have the same rotation, and it will make sure to match those.

The function will also include a flag so it will assume a origin of 0,0,0 ( mainly used in GG objects, not center ) , if you use this , it will be able to merge Trees/Bushes ... That also has a BIG drawcall problem.

In the scene above, but also added second pass merges , the FPS went from 58 to 75 from the players start position , so it gives a huge boost merging objects together. Cant wait to finish the Tree version and test that, i dont expect so large a fps increase as with smaller polygon objects , but it should give some. I also expect that merging rocks together could give a nice boost

Hopefully Paul will get GetObjectPivot( objID ) added so we can see some really huge performance boosts. Fantastic work Preben... as usual!

First version done , trees also give a nice boost
https://www.youtube.com/watch?v=2EDVD2I6OdY