It looks really nice,
I wish I understood GLSL better,
Could you make a demo where every triangle gets replaced by a object from the scene?
like a cube ? and the triangles orientation is used to face the cube?
that way people who don’t understand the code can still use it?
Could you make a demo where every triangle gets replaced by a object from the scene?
No that is not possible. The shader can only affect geometry where it runs on. Not other geometry.
It is only possible to generate simple geometry like a particle, plane or cube on geometry points of the given mesh.
you can transform the emmited verticies though?
can you build faces from the emmitted geometry?
add in shading?
(loop through the faces of the donated mesh and somehow use those to transform the created geometry?)
How do they instance geometry in other engines?
(like a level made out of the same pieces over and over? static draw call batch?)
7x slower for rendering 1 item,
but what about 1000?
I thought that was the draw here,
The test was done with 26999 Cubes.
For one cube I get 1110 frames for display list and VBO. The actual BGE VBO (without hardware instancing only VBO) rendering slow done drastically as more objects are in the scene.
I meant with hardware instancing,
I thought instancing used VBO
Add four new examples (tessellation, wireframe).
On the hewletpackard 2011x i am using.I get this error for the second layer.
~Blender Game Engine Started
---- Vertex Shader Error ----
Vertex shader failed to compile with the following errors:
ERROR: 0:8: error(#421) Keyword or operator “out” usage incorrect. GLSL version number 130 is required.
ERROR: 0:9: error(#421) Keyword or operator “out” usage incorrect. GLSL version number 130 is required.
ERROR: 0:10: error(#421) Keyword or operator “out” usage incorrect. GLSL version number 130 is required.
ERROR: error(#273) 3 compilation errors. No code generated
---- Vertex shader failed to compile ----
I think they are adding true hardware VBO in upbge.
IS the last one is the updated version?
They are are you sure of that?
IS the last one is the updated version?
Yes. It is a dropbox link, so every time if I change something it will be automatically updated.
#1. all instances drawn with a VBO instances are a single batch?
#2. once sent, can’t VBO live on the GPU, and be recalled and (since they are static) not need to be updated?)
#3. is that the same with arrays? (you can store them on the gpu?)
#4 (unrelated) can FBO speed your cube map reflection shaders? (offscreen render?)
@BPR, i think you could use this-> http://ogldev.atspace.co.uk/www/tutorial33/tutorial33.html and recode it for pyopengl as a test example.
#1. Instanced meshes will reduce the draw call overhead on the CPU but will not reduce the GPU cost. In fact the GPU time can increase when using instancing.
This process has to do with the limitations of the CPU vs. GPU and how the API (OpenGL or DirectX) tries to maximize this limitation through batching. Instancing being a special case of batching. With a scene rendered with many small or simple objects each with only a few triangles, the performance is entirely CPU-bound by the API; the GPU has no ability to increase it. More precisely, "the processing time on the CPU for the draw call is greater than the amount of time the GPU takes to actually draw the mesh, so the GPU is starved. So batching attempts to allow the CPU to combine a number of objects into a single API call. In the case of Instancing it is the one mesh and the number of times you are drawing with a separate data structure for holding information about each separate mesh.
#2. VBO only live on the GPU, as long you are not delete them. Normally you don’t update a static VBO. If you want use an animated mesh which updates very often, then you should use GL_DYNAMIC_DRAW instead.
#3. Yes a VAO live also on the GPU, as long you are not delete them. A VAO is used to store all VBO(s) related binding information. So the CPU only need one call and the GPU will bind the VBO(s) and the vertexarray uniforms to the shader.
#4. A FBO is only on off screen render buffer. It renders the scene by using a GLSL shader into a non displayed texture buffer. Basically it is similar to that what the texture module does. So if you store the image into a FBO or a texture (TBO) should not make much difference.
So if node cube map is to slow for you, then no there will not much performance improvement.
The reason why the GLSL cube map is so slow is the ‘plot’ function which I have used to stitch all six images together. If I would use the BGL wrapper instead it should be much faster. Like the node version with six single images.
Would using GL_DYNAMIC_DRAW enable people to use the marching cubes algorithm in there videogames?Would GL_DYNAMIC_DRAW improve the framerate for those types of videogames?
#4. A FBO is only on off screen render buffer. It renders the scene by using a GLSL shader into a non displayed texture buffer. Basically it is similar to that what the texture module does. So if you store the image into a FBO or a texture (TBO) should not make much difference.
So if node cube map is to slow for you, then no there will not much performance improvement.
The reason why the GLSL cube map is so slow is the ‘plot’ function which I have used to stitch all six images together. If I would use the BGL wrapper instead it should be much faster. Like the node version with six single images.
I would love to see this/use it
2 . is there any way to render the player onto each instance? (because he would not be in the cube map)
Basically what I am asking is can dynamic light probes be done using the dynamic cube map of the player?
I see, thanks for the explanation.