33 replies to this topic

[Reedbeta]

Is your model an entire level environment or something? In that case, it might well have many materials.

[Alienizer]

They are obj models many of them converted from 3ds models. Some have 100+ textures, some only 10 or so.

I was trying google Sketchup and it uses OpenGL to model your scene, and it has no problem doing front/back and transparencies. I tried it full screen on a model with 200+ textures, it's a big house, many windows, pool etc. and you can rotate, pan and zoom with no noticable delay. I just want to make a viewer that can rotate, pan and zoom only and not crawl at doing it, but not just for little models of 4 or 8 textures!

[Reedbeta]

For big environments to draw efficiently you're getting into the realm of frustum and occlusion culling. I.e. you can't just throw all the polygons at the GPU and expect it to sort them out; you need some kind of scene graph to efficiently cull out the stuff that's offscreen.

But it sounds like you're not at the point yet where you can feasibly code that kind of system, if you're still learning how to do basic drawing with vertex arrays and textures, etc. You might have to ramp down your expectations a bit.

[Alienizer]

Even using frustum and occlusion culling would do no good in full screen with the full model in view, since there will be nothing to clip off the edges.

But I know what you're saying, I just loaded that huge house and doing it with glDrawArrays is super fast. No textures tho, just colors, but ti does have transparencies, it's 3.5 miilion poly, it's super fast without frustum and occlusion culling.

[Alienizer]

Can I use texture_3d or that too has a 32 depth limitation?

[Vilem Otte]

Eh... I just went through the whole topic. The whole point is, that your level is made up of several (it can range from single, to dozens, hundreds, etc.) pieces called meshes, for each this mesh you will have own VBO, own material, etc.

Then when you load Obj model, you render all these meshes in a single loop:

for(i = 0; i < mesh_count; i++)
{
     materials[i].bind();
     mesh[i].render();
}

Where materials::bind() method (or procedure, or function, or whatever - based upon programming paradigm you're working in) binds textures to texture units (and now I mean diffuse map, normal map, specular map and whatever map for exact material).
And mesh::render() method binds VBO (or VAO if you decide to optimize with Vertex Array Objects) and renders single mesh from whole model (through glDrawArrays, or glDrawElements mostly, though somethimes there are different procedures used (ranged elements drawing, or instancing - but thats just for optimization!)).

After you have this working (e.g. the basic Obj (+Mtl for materials) loader, plus rendering of loaded Obj model with lots of textures), you can start adding:
1.) Optimization stuff - Frustum culling (Kd-trees, BVH, Grids, etc. awaits!), Occlusion culling (Hierarchical Z-Buffer culling for example, or PVS precomputed data - like in BSP files), Dynamic streaming of huge data sets from HDD (if you have some 16 GiB meshes, you can't hold it in RAM/VRAM at once - this is where streaming comes in), etc.
2.) Fancy stuff - Transparency, Better lighting, Shadows, well.... you know the stuff

I can post some basic obj + mtl loader stuff later in the evening (right now I'm forced to help my girlfriend with some work)

[Stainless]

Yes Vilem has spotted what you are doing wrong.

A SCENE is not a single mesh. You might create it as a single file in your 3d editor,but it is NOT a single mesh.

You may have hundreds of meshes in a scene. Each of them can have it's own textures, so you can easily get large numbers of textures in the scene.

(Note you should try to avoid this as if you run out of video ram to store the textures you can get a big overhead as textures are thrown between machine ram and video ram)

When you display a scene you can do all sorts of speed ups.

Frustum culling can eliminate whole objects from the display list saving you lot's of t states.

You need to think about what you are trying to do rather than how to display a huge mess of triangles

[Alienizer]

ah, that makes sense! thank you guys, I have it working nicely doing it this way! What a big difference from the gl_begin/end old way of doing it. Now I can view an obj model with any number of textures, and even loaded 4.9 million poly model and the delay was about 1/2 sec when rotating in full screen! I guess that's not bad at all is it?

[Vilem Otte]

No, it's not bad ... though you can do ~5M triangle scenes without any problems at realtime framerates (thats our average game scene, note... without tessellation). What is important now is optimization - your goals should be (Note. I'm not saying this is the only and best way, but it should give you a picture of your TODO):
1.) For each mesh create AABB and build a hierarchy of your scene (this is often called scene-graph - add ability to dynamically add/remove objects, while refitting tree after doing so)
2.) With this scene-graph it's quite trivial to add frustum culling (this gives quite a speedup)
3.) It's worth to try to implement occlusion culling (hierarchical Z-buffer) which might (and also might not) give you a speedup - it really depends (also for most common cases it gives slightly better performance, for some it gives huge speedup). Or if you have static scene, trying some PVS (potentially visible sets) is a way to implement always faster occlusion culling.
4.) You definitely know that shader-change, texture-change and such are slow operations, pre-sorting them for achieving as less as possible state changes also speeds stuff (and sometimes a LOT).

So far this should give you quite decent speed to handle practically any geometry (that is enough small to fit to your RAM/VRAM), and for most games this is enough. Although if you're planning really huge worlds (or worlds with extreme detail), you can't go far with your RAM/VRAM - then you'll need to start doing LOD (Level of Detail) and streaming of data from HDD (the background streaming thread rulez). With this extension (which is quite huge, because it's not as simple as it sounds) you'll probably be able to handle any scene I can handle now - that means pretty much everything, but still a lot artist dependent (someone must create those LODs ... a generator can do that, or you can use just mesh and impositor, or ... there are lots of ways to "get rid of more artist work").

Note that someone really should make an article how to build optimal renderer (e.g. all the stuff with frustum/occlusion culling, getting rid of so much state changes, LOD, etc.).

And second note, i'm not saying that the way I mentioned is the best, but it at least works correcly and isn't the slowest out there, so it kinda works well.

[Alienizer]

I know exactly what you mean. I did this, I sorted the poly by materials, and gained way more speed. Then, I used 8 samplers and grouped the polys into one draw array for each 8 textures, and wow, what a speed. Then I did the max for my card, 32 samplers, and guess what, no delay at all on that 4.9M poly. You guys are genius, thank you all.

What I would like to see on this site for others that starts with glsl/OpenGL as I did are short but very clear tutorials...

1. OpenGL basics, how those binding works, and where and how to use them, textures, how are they used etc etc.

2. Vertex shader, what does it process exactly, what variables are being interpolated, what can you pass to it and how, limits etc.

3. Fragment shader, same as above.

You know, the stuff that we puzzle all the time. I didn't know why some of the vars in my vertex shader were not the same when passed to my fragment shader. Just to found out it was getting interpolated and I had to use flat to prevent that. All those little things are obscured, and very hard to fiund out, especially if you don't know about flat, or that all your vars are getting interpolated.

Simple things, not just code example, there are plenty, but why, what happens when I do activeTexture, and why do I have to call bindTexture afterward, what happens, and how is it attributed to shaders, and why it doesn't. blah blah blah.

[Vilem Otte]

As for those tutorials (articles) - to actually explain what is happening, it's probably the best to write whole article about how 3d rendering works (now I mean rasterization) - the best would be CPU implementation, that means loads and loads of math.

In my opinion it would be far better than jumping directly into OpenGL/Direct3D - why, well simply because you'll understand whats going on in the api, what your calls actually do and thus figure out what exactly you have to do/supply. Of course explanation how you can build your own shading language and implement it in software renderer isn't exactly what I mean, but explaining basically and generally how stuff works with related code for software renderer gives a good idea what actually GPU does.

I can't promise anything (basically because I don't have much free time - put together paid work, unpaid work, school, crazy girlfriend (+ anime in this field), games, cycling, fencing and linux - and generally time chaos begins (but I think that pretty much everyone here doesn't have much free time)) - but I can give it a try and put together few lines of text & code.

[Reedbeta]

The best modern OpenGL tutorials I have found are at http://www.opengl-tutorial.org/ . These are all-in on VBOs, shaders, and so forth from the beginning, which is nice since they avoid teaching you at all about outdated things that don't perform well, like glBegin/glEnd, which you usually see in older OpenGL tutorials, but then have to unlearn.

[Alienizer]

Nice tutorial Reedbeta, but it lacks the "why" parts! Like, it tells you how to draw your first triangle, and show you the code, but there is no "why do I have to call glGenBuffers, what does this do?" kind of things. Not so much to explain the language and functions, but rather, the core, what's going on when you call glGenBuffers, does it talk to the card, or just the driver? What about states? who knows about that beside the experts like you guys. I didn't, untill you guys told me to try not to change states so much to get more speed. Those are the kind of tutorial I think is better to read first, then you go to opengl-tutorial.org and learn more about the language and functions etc.

It's like trying to learn how to drive a car not knowing it has wheels to make it move (not knowing what make it move). I'd rather learn how a car is made first, then when I learn how to drive it, I can relate my actions to the machanics and perform stunts wich I'd never thought I could do or be done. Just like this draw arrays deal, I always thought it can only use one texture at a time!

[rouncer]

you gotta know the difference between drawing from video, and drawing from SYSTEM CALLS. b gives you shit all speed, its basicly not even reaching anywhere near the power of the video card, and is speed dependant on the motherboard, funnily enough.

good for you you at least managed a video brute force, thats the first thing to get over the pipeline bottleneck.


no pro programmer would ever get a job without knowing this problem in its entirety.