Getting Better Framerates

Thanks for the feature. I hope this can bring more attention to the next step in this project, automatically creating an index buffer array calculated from vertex position, to supply a [jit.gl.mesh]. With the original shape from my patch, the icosphere, it's a bit easier to see the math and patterns of how all the vertices are distanced from each other, since the object is symmetrical. Hopefully i can get some assistance on this or leads in the right direction. Everything i've read so far about creating an index buffer does it manually. Maybe there is no universal solution that would work for all objects...

hi greg, there's code here that does this: https://github.com/opengl-tutorials/ogl/blob/master/common/vboindexer.cpp

based on this tutorial: http://www.opengl-tutorial.org/intermediate-tutorials/tutorial-9-vbo-indexing/

would be very interested to know if this gives you speed improvements.

cool, thanks for the links. a quick glance through and i see they explain that they're reducing shared vertices, but not much about how they group the vertices after to draw the triangles. It's probably all in the code functions, but it'd be cool to know the math behind those functions, since i'd probably have an easier time converting that math into a series of object in Max, rather than porting the code into gen and figuring out the correct input/outputs. (unless it's fairly straightforward to port // it'll probably compute quicker in gen // i'll look a little more in depth at that code later)

So for example, in that tutorial link, what makes the code draw the index array as (in max formatting): 0 1 2 1 2 3

rather than 0 1 3 0 2 3

but ya, i'm also very interested to see if there are speed improvements, or as you mentioned before, will only reduce memory usage.

interesting

Unfortunately the patch crashes my Mac MAX 7.2 after opening. I didn't try it with Max 7.1. The jit.Window is shown (with graphics) for a second. Then Max quits. Always the Main Thread crashes with EXC_BAD_ACCESS (SIGSEGV) in do_jit_world_draw.

hi MVF.

could you send a message to support with your system specs and a crash report? i believe this is related to opening a patch with jit.world @enable 1, and i'd love to get this tracked down.

here's a modified version of the patch without @enable 1 that should open for you:

Ok well I did it, I rebuilt the index buffer, and Rob I'm pretty sure is right. No discernible differences in speed. That's because, i'm assuming, the index buffers are actually the same dimensions (but i'm not sure because I don't know how to see a jit.gl.model's index buffer, but we don't see extra faces being drawn, so it should be the same. perhaps the only difference is jit.gl.model's index buffer is listing all vertices just once [rendundant included] whereas mine will reuse vertices, since it eliminated any redundant ones). With the low poly icosphere, there is 20 faces, so each one needs 3 vertices to define the face, which gives a 60 vertex index buffer. If you see the dimensions of its original matrix output, that is also 60.

I guess I also didn't try piping my icosphere model into a mesh before, but that gets 60fps just fine.

But in the spirit of sharing, here's the new vertex reduction patch which also rebuilds the index buffer. If anything, it's fun watching it create all the faces. Load in the icosasphereHi and have fun watching it build 1620 faces.

inside the subpatch vertexReduction is the index rebuilder on the right side of it. it's kinda a spaghetti monster, but works. let me know if i need to explain any of the mess.

enjoy.

now that i think about it, we do see jit.gl.model's index buffer array, it's the first 3 planes of the matrix output (position array - xyz). the first 3 cells are the first face, the next group of 3 is the second face and so on. Knowing this is exactly how i was able to build the index array.

also i might have organized/ordered the vertices backwards (not that it matters much), but if you enable the poly~ for the Vertex Labelling section, you'll notice that the highest numbered vertex is facing you. To fix this so it's the lowest/0th vertex, go into the vertexReduction subpatcher, and find the message box that is sending "renumber, dump" into a [coll final]. change the message to: "sort 1 -1, renumber, dump", and then you can hit the recalculate bang and it should fix the ordering.

I just ran a 58,000 vertex model through the patch. It took 2 hours and 15 minutes, which began with a spinning color wheel for about 3 minutes (which is the time it took to eliminate the redundant vertices) where i was really tempted to force quit (i'm sure if i added some delays like i did with the reindexing programming, it wouldn't give you the scary wheel of death), but max triumphed and made this:

(original on the left, max on the right)

ok, i fixed an issue with models that have multiple drawgroups and gave the patch some cleaning and organization:

posted this in the Jitter facebook group, but forgot to update here:

"After much tweaking I think i'm ready to roll out the next version of the GL Model Optimizer (reduces redundant vertices for better framerates with [jit.gl.multiple] and more accurate vertex modification with [jit.gl.mesh]) Updates: - added support for the original model's texcoord + lighting normal arrays - the ability to save/load arrays. This means, you only have to optimize once, and then future times you can instantly load these saved arrays - added an example of tweaking the mesh vertices with noise I attached a starter pack with some example arrays / index arrays Let me know of any issues. Enjoy."