#Rendering multiple VBOs using single VAO

97 messages · Page 1 of 1 (latest)

cosmic wind
#

Hello guys, I want to render some Mesh and it's Bounding Box. I didn't want to use multiple VAOs because I thought this could be done using single one since data is kind of related (each mesh has it's own bounding box). I've created Mesh class, whose constructor initializes Bounding Box for that mesh. Bounding box holds reference to mesh so it can access it's VAO. I've filled VAO with both mesh VBO and EBO, and bounding box VBO and EBO. I was wondering if I should make separate VAOs for mesh and bounding box? Also should I make separate shaders since I am using Phong shading for my meshes (thought I could just not send uniforms to shaders since they will ignore them if vlaue is not provided)? 1st picture shows my meshes being rendered when bounding box is disabled, other one is bounding box being enabled.
https://paste.ofcode.org/FGxqCvpJws7azpJugDHs9H
https://paste.ofcode.org/LKpY864uhYFyguq39FsfLv
My Mesh and BoundingBox classes have a lot of common which is poorly written... (I've read somewhere that those should be separate classes)
I don't know how to tell program to stop after rendering Mesh data (first VBO) and then use different approach (basically just gllines instead of triangles) when it comes to rendering 2nd VBO

image.png image.png
worthy silo
#

think of the vao as your vertex input descriptor/input layout

#

normal mesh has positions, normals, uvs, perhaps tangents and other stuff

#

a bounding box is just position and color perhaps, to visualize them better

#

that means you should have 2 vaos, one per vertex type

#

since it describes how the input assembly is supposed to interpret your vertexbuffer to be able to send it off to the vertex shader

cosmic wind
#

Question just for the future reference: If VBO's have same input layouts, they will use same drawing logic? We don't have to specify when to draw data from 1st VBO, or when to draw data from 2nd VBO, it will draw it all one after the other (all must be drawn)?

#

Since VBO's have same input layouts, they will be drawn in the same way, and there won't be any complication as shown in images above? The only downside is that we can't tell VAO to draw certain amount of VBOs that it contains (for example it can't draw 5 out of 7 total VBOs that are stored in it)?

#

Should you also have different instances of vertex and fragment shaders (one for each vao)?

#

Sorry for lot of questions, I am still figuring things out 🙂

worthy silo
#

yes

#

you can just keep drawing

#

vaos only relate to vertex shader inputs

cosmic wind
#

Thank you 🙂

worthy silo
#

vao and vbo are not contained in each other

#

vaos refer to one or many vbo

#

since you can source attributes from 1 or many buffers

#

but you can change that association at any time

#

so for example, you use 1 vao for a cube, a sphere and a cone

#

but cube and sphere and cone vertices live in differnt vbos

#

then you bind the vao, bind cubevbo then draw, then bind spherevbo then draw, then bind conevbo then draw

#

there are like 10 different ways to do it better, but i suppose you are a beginner witha ll this opengl stuff, so doing it the naive way is alright

cosmic wind
worthy silo
#

no worries

#

vao/vbo/ebo and their relationship is poorly explained in any opengl tutorial

cosmic wind
#

I don't think there is need to bind VBO everytime it is being drawn since it is linked (or bound?) to VAO right?

#

Only bounding VAO is necesarry right?

worthy silo
#

if you have a vao per mesh thats fine

#

like cubevao, spherevao, conevao

#

its the most naive and trivial case beginners should implement this

#

when you learn more about opengl and what it has to offer later you can always refactor your stuff towards to "more modern" stuff

cosmic wind
#

Could you give me an example of what would more modern use of vao look like?

#

For example if I wanted to render 10 houses, 7 trees and 15 car meshes, I can't imagine putting all of that in single vao because you can't render different numbers of those meshes in same vao (i think?)

worthy silo
#

for now it really doesnt matter

#

1 vao per mesh it totally fine

#

then you add lights and shadows later

#

render more complicated things

#

perhaps try out deferred rendering or advanced forward techniques

#

then you will learn how to make that vao nonsens more proper, or get rid of them entirely

#

but its good that you understood how they work and what they mean in the beginning

cosmic wind
#

It means a lot

worthy silo
#

np

cosmic wind
#

Just for curiosity: if you have multiple vbos linked to same vao, can you render different amounts of those meshes?

#

Or is the number the same

worthy silo
#

you usually have 1 set of vbo/ebo linked to a vao at a time

#

if we stay in naive land

#

like

#

ah

#

hang on i missread

cosmic wind
#

Yeah true, but if we used more modern approach and put multiple vbos and ebos to same vao

worthy silo
#

yes

#

lets assume

#

cubevao, cubevbo, cubeebo

#

spherevao, spherevbo, sphereebo

#

you can render 1 cube and 20 spheres with that

#

or 400 cubes and 2 spheres

#

if that was the question

cosmic wind
#

I was thinking more about this case:
shared vao which contains cubevbo cubeebo spherevbo and sphereebo

worthy silo
#

keep it simple

#

IF

cosmic wind
#

Will do. Thank you very much 🙂

worthy silo
#

you understand what vaos really are

#

later

#

you can then do

#

bind vertexpositioncolor-vao

#

bind cubevbo

#

draw 100 cubes

#

bind spherevbo

#

draw 20 spheres

cosmic wind
worthy silo
#

cube and sphere vbo will match the vao, ie contain vertexpositioncolor data, in this example here

#

then you might want to draw some ui... which only has position and uv data

cosmic wind
#

Thank you once again for all the info, Ill keep going at my pace and hopefully one day make something non lame haha

worthy silo
#

bind vertexpositionuv-vao

#

draw quadsperlettertorendersometext

cosmic wind
worthy silo
#

ye

cosmic wind
#

Yeah thats what I am aiming for currently

worthy silo
#

ideally, work through learnopengl.com once, you dont have to understand each and everything immediately to the fullest, make notes about stuff which doesnt make sense, but keep on reading

cosmic wind
#

3 axis and border boxes for now

#

And clickable elements

cosmic wind
worthy silo
#

cool

cosmic wind
#

Do you recommend reading whole thing or are there some things that arent that relevant

#

Learnopengl.com is great literature, it has a lot of info, definitely best stuff that ive found on opengl

cosmic wind
worthy silo
#

dont skip

#

work through it, it wont take too much time anyway

#

and will probably explain a few things which come up later

#

or make more sense then

cosmic wind
#

Good point, I'll work through it all, it doesnt cost me anything to atleast read chapters after all