Possible to use vertex shader without vbo?

Hi

Which optimizations have you already implemented? Actually, when a VBO is too big, the performance can decrease a lot, look at GL_MAX_ELEMENTS_VERTICES and GL_MAX_ELEMENTS_INDICES. I think about using several layers of cache (GPU, CPU, disk) but it's good to display very large meshes, I'm not sure it would be faster in your case.

when i came on board the app was drawing quads, I changed it to triangle strips and then to a single triangle strip with degenerate triangles linking them. on the non graphics side I've changed a bunch of the logic around to use less objects and arrays and more things that I know the cpu can do in a few cycles. I am trying to do some serious multithreading on the logic part but so far that doesnt work yet. I have something wrong with my synchronization. I was also looking at aparapi and opencl to move some of that to the gpu but it's such a daunting task to start that I've pushed it back until this season.

can you tell me more about the layered caching? what I would love to do is send just a delta of the vertices that have changed since the last erosion cycle that would cut down the amount of data sent to the gpu by 95% or so, but I dont know how to allocate that in the gpu.

sirus20x6 wrote

when i came on board the app was drawing quads, I changed it to triangle strips and then to a single triangle strip with degenerate triangles linking them. on the non graphics side I've changed a bunch of the logic around to use less objects and arrays and more things that I know the cpu can do in a few cycles. I am trying to do some serious multithreading on the logic part but so far that doesnt work yet. I have something wrong with my synchronization. I was also looking at aparapi and opencl to move some of that to the gpu but it's such a daunting task to start that I've pushed it back until this season.

can you tell me more about the layered caching? what I would love to do is send just a delta of the vertices that have changed since the last erosion cycle that would cut down the amount of data sent to the gpu by 95% or so, but I dont know how to allocate that in the gpu.

How many vertices do you have? How much big is latticeSizeX/Y? How many different colors do you have?

Are you performance limited? Which hw are you targetting?

    static final short lattice_size_x = 678;
    static final short lattice_size_y = 524;

2 polys per cell

    public void map_color_pre_calc(float height, Model.Vec3 color){
        float t = (height - COLOR_MIN_HEIGHT) / (COLOR_MAX_HEIGHT - COLOR_MIN_HEIGHT);

        // Clamp to range, just in case
        if (t < 0.0) t = 0.0f;
        if (t > 1.0) t = 1.0f;

        // Brown yellow map
            color.x = 0.906f + (t - 0.5f) * 0.180f;
            color.y = 0.640f + (t - 0.5f) * 0.680f;
            color.z = 0.180f + (t - 0.5f) * 0.773f;
    }


I think the height ranges from 0 - 1800f or so

You should choose a storage that fits better to what you do and you should update only a part of your VBO instead of sending again and again the whole content. Look at glBufferSubData and glMapBufferRange.

The layered caching is useful when your data can't be stored into the GPU because they're too big. Then, you really use the VBO as a buffer, you need several passes to transfer the content from the CPU to the GPU and to draw them. When your content can't be stored into the RAM, you can use the disk. Imagine that you have some mesh data about 100 times larger than the indirect NIO buffer you use to store the data in memory and your direct NIO buffer mapped on the GPU is 10 times smaller than your indirect NIO buffer, you'll have to perform 100 * 10 passes to draw your mesh with this layered caching.

sirus20x6 wrote

static final short lattice_size_x = 678;
    static final short lattice_size_y = 524;

2 polys per cell

    public void map_color_pre_calc(float height, Model.Vec3 color){
        float t = (height - COLOR_MIN_HEIGHT) / (COLOR_MAX_HEIGHT - COLOR_MIN_HEIGHT);

        // Clamp to range, just in case
        if (t < 0.0) t = 0.0f;
        if (t > 1.0) t = 1.0f;

        // Brown yellow map
            color.x = 0.906f + (t - 0.5f) * 0.180f;
            color.y = 0.640f + (t - 0.5f) * 0.680f;
            color.z = 0.180f + (t - 0.5f) * 0.773f;
    }


I think the height ranges from 0 - 1800f or so

If VBOs look slow to you, glBegin/glEnd are even worst.

Move the color calculation on the gpu and use a round robin VBO pool, 3 VBOs should be enough.

The idea is that each frame you upload and render from a different VBO.

You trade basically memory for speed.

You can take inspirantion from here, he uses 6 ones, but as McDonald at Nvidia said, 3 should be more than enough. Anyway you should profile it in any case.