Well Im curios after reading a bit about vbo’s, if they are used by jme3.
As far as I know on android you must use them? while on desktop you can use the older systemof rendering each object with a own draw call?
Is this true?
Does jme3 use vbo on desktops?
What would be neccesary to use/implement vbo’s for desktop if not used already?
1 Like
Jme uses VBOs for the underlying meshes.
VBOs are not incompatible with “rendering each object with a own draw call”, which is what jME3 is doing. You reduce draw calls by using batching, not by using VBO.
VBOs are used by default in the OpenGL2 and OpenGL ES 2 renderers. OpenGL1 uses arrays since that’s the only thing supported by baseline OpenGL1.1.
Yes i understand, but if i understood it correctly a vbo could contain multiple geometrys with different materials, something batching cannot archieve.
If this is right it would be interesting to make a vbo batch module, that could batch a whole node into a vbo (kinde like batchnode from the user perspective)
Even if you pack a node into a large VBO, you still have the same number of draw calls, thus performance won’t improve much. We actually supported this some time ago in the engine, but the complexity of the code to handle it was so large the feature was removed.
Ah ok i see, so maybee if i ever find time but nothing really significant.
Still on the topic of handling VBOs, but less regarding @EmpirePhoenix’s point, I’m curious how index-typed VBOs relate to TexCoord-type VBO.
For example, Quad.java sets 4 buffers: Position, TexCoord, Normal and Index. Are the values in the Index buffer used to lookup values in the TexCoord buffer?
(REALLY sorry if this is a silly question)
thanks!
Nope the index buffer actually tells the GPU how faces are laid out.
for example a quad has 2 faces, and 4 vertices. the index buffer will have 6 elements that explains how vertices are connected together.
if you have a quad like that : the numbers in the corners are the indices in the position buffer of the vertices ( the index is actually multiplied by the number of element of the buffer to get the real index, for position buffer it’s 3.)
1-----2
| / |
0-----3then the index buffer will describe the face by laying the indices clockwise. here is 0,1,2,0,2,3.
(forgive my lame asccii art skill)
1 Like
@nehon the ASCII art makes perfect sense!
Looks like I was thinking about the indices incorrectly. Is it then true that the positions, normals, and texcoords should than correspond in-order 1-1 in the other 3 buffers?
thanks again!
@jagwire, AFAIK that depends what type you use for texcoords by default texcorrds is Vec2f while the other tree are Vec3f. In that case the texcorrds would not map 1-1.
@jagwire said: @nehon the ASCII art makes perfect sense!Looks like I was thinking about the indices incorrectly. Is it then true that the positions, normals, and texcoords should than correspond in-order 1-1 in the other 3 buffers?
thanks again!
not really
position and normal yes…but that’s just because they have both 3 elements.
But texcoords has 2 elements (in most cases).
for example vertex 3 position will start at index 3x3 = 9 in the position buffer (same for Normal)
But vertex 3 texcoord will start at index 3x2 = 6 in the texcoord buffer.
But back to topic, since someone pushed it and i am also currently thinking about it:
Lets assume my whole scene uses only one type of shader and my gpu supports EXT_texture_array. The only difference between the object’s are different textures. In theory i could then:
- pass all my textures as an array to the shader
- simple merge all the buffers of all meshes
- use an additional int buffer on the the mesh for identifying the correct texture.
Would’nt this allow me to draw the whole scene in one drawcall?
@nehon said: not reallyposition and normal yes…but that’s just because they have both 3 elements.
But texcoords has 2 elements (in most cases).for example vertex 3 position will start at index 3x3 = 9 in the position buffer (same for Normal)
But vertex 3 texcoord will start at index 3x2 = 6 in the texcoord buffer.
I think you are thinking about a different index.
The index buffer refers to vertexes, texture coordinates, normals, etc. 1 to 1. The actual index of the float may be different but if you have 4 vertexes then you always have 4 (or none) texture coordinates, normals, tangents, etc… There is a 1 to 1 relationship between these things.
@zzuegg said: But back to topic, since someone pushed it and i am also currently thinking about it:Lets assume my whole scene uses only one type of shader and my gpu supports EXT_texture_array. The only difference between the object’s are different textures. In theory i could then:
- pass all my textures as an array to the shader
- simple merge all the buffers of all meshes
- use an additional int buffer on the the mesh for identifying the correct texture.
Would’nt this allow me to draw the whole scene in one drawcall?
In theory. Though note that there are a few down sides to this approach. I would at least break up the scene spatially so that large feature culling can be done.
Yeah, nothing comes without tradeoff’s. If done transparently the whole merging process could also be a bottleneck. But sounds like a good solution to static scenery. But i also have to say that i don’t know whats more costy, changing the shader a few times or sending/drawing some not visible objects.
I can’t actually find a single site which shows the cost of different opengl operations. It looks like one is forced to try and find out…
@pspeed said: I think you are thinking about a different index.The index buffer refers to vertexes, texture coordinates, normals, etc. 1 to 1. The actual index of the float may be different but if you have 4 vertexes then you always have 4 (or none) texture coordinates, normals, tangents, etc… There is a 1 to 1 relationship between these things.
well maybe i didn’t get the question then , i though he was talking about the index in the buffer in his second question, not the index of the vertex.
@zzuegg said: Yeah, nothing comes without tradeoff's. If done transparently the whole merging process could also be a bottleneck. But sounds like a good solution to static scenery. But i also have to say that i don't know whats more costy, changing the shader a few times or sending/drawing some not visible objects.I can’t actually find a single site which shows the cost of different opengl operations. It looks like one is forced to try and find out…
It is different for literally every type of graphics card. Some cards will be better at state switches than others… but generally, “not rendering anything” costs 0.
1 Like
@nehon said: well maybe i didn't get the question then , i though he was talking about the index in the buffer in his second question, not the index of the vertex.
Original question: “Looks like I was thinking about the indices incorrectly. Is it then true that the positions, normals, and texcoords should than correspond in-order 1-1 in the other 3 buffers?”
Maybe it was ambiguous but between the two of us, we have answered the question.
@pspeed said: Original question: "Looks like I was thinking about the indices incorrectly. Is it then true that the positions, normals, and texcoords should than correspond in-order 1-1 in the other 3 buffers?"Maybe it was ambiguous but between the two of us, we have answered the question.
heheh yeah
