   Directional lighting that's won't slow everything down?
  Hi, I was just going through the NeHe tut on Cel-Shading (#37) and absolutely loved it. After a little bit of modification to my code I got the actual cel-shading going no problem, but it isn't much without the anime-like lighting. So heres the thing:After analyzing the code, it just seemed crazy to have to calculate the face normals EVERY frame. Just mad. And you'd have to get the position of ALL the vertices after all the transformations, which should kill any serious game.Currently I'm using display lists so everything is precompiled. How am I supposed to get a decent looking lighting going and still keep a decent FPS? (It was pretty slow before the lists, btw.)Basically, if I gave all the necessary info at the time of generating the list, i.e.:for(...)glNormal3fv(...);glColor3fv(...);    //<< I realize this can't be changed, so I guessglVertex3fv(...);   //   glTexCoord1f isn't gonna work like the tut eitherShould GL be able to figure out the normals on its own from that later?(I currently upload the local axes of the object to the modelview matrix before calling the list. Dunno if that's relevant :P Thanks.)EDIT: ^^*that won't* wooptie   
  You shouldn't have to recalculate the normals each frame unless the mesh was dynamically being altered for some reason...And DL should be fast.   ;  I just had a quick look at that tutorial, and I couldn't believe my eyes. This must be one of the worst ways to do cell shading I've ever seen. Reminds me why I hate NeHe's stuff so much...Anyway, glopen, you are perfectly right. Submitting the geometry every frame, while doing all calculations on the CPU is indeed madness. Forget everything you 'learned' from that 'tutorial'.You obviously want to use shaders. They will solve all your problems. You load the geometry into a static VBO (keep in mind that display lists are obsolete since OpenGL version 3.0 !). You would then perform the actual cell shading math in a vertex and/or fragment shader, depending on the effect you would like to achieve. Everything will be done entirely on the GPU, so it's going to be lightning fast.   ;  Hey thanks for the replies. Sorry for the late reply, my internet connection was down :(@MARS_999:Yeah I kind of implemented the lighting (nothing fancy, just the basic GL_LIGHTING) and calculated the normals while making the list. The lighting seem to be working OK, but not quite what I wanted.@Yann L:Tell me about it :) I just rendered the game in immediate mode and it was as if it wasn't even running.Quote:You obviously want to use shaders. They will solve all your problems. You load the geometry into a static VBO (keep in mind that display lists are obsolete since OpenGL version 3.0 !). You would then perform the actual cell shading math in a vertex and/or fragment shader, depending on the effect you would like to achieve. Everything will be done entirely on the GPU, so it's going to be lightning fast.I'll be taking keywords right out of this and plugging them into google :) I guess shaders are the way to go but the resources seem to be a bit scarce. Aren't VBOs generally slower than DLs? Oh well, so much for the good old DL, I guess.Thanks for the input. (Any suggestions/recommendations will be appreciated :))   ;  Info on shaders is scarce?  Shouldn't be - there's tons of docs out there plus a few books.  Try a search for GLSL.Lighthouse 3D has a tutorial which specifically walks through cel-shading.  It only walks through the shader portion though (not specifying normals, VBOs, or much that exists outside the shader).In regards to VBOs being 'generally slower' than DLs, I've found that VBOs can be slower for static data, but for dynamic data VBOs are considerably better suited.  But since DLs are being deprecated, well, choose the thing that isn't obsolete.  :-);  Ah, I guess the info isn't that scarce. My bad :)Funny you should mention Lighthouse3d because I was just going through the toonshading tut and decided to try it out in combination with my other codes. Apparently the shading is pretty flawless even when using display lists so I guess the shading bit works pretty much the same regardless how the data is pushed into the pipeline? That's good :DYeah I gather that DLs are getting deprecated but either I have an odd affinity towards them or an inexplicable fear of VBOs *shrugs* But I'll switch eventually.Thanks :)   ;Quote:Original post by Yann LI just had a quick look at that tutorial, and I couldn't believe my eyes. This must be one of the worst ways to do cell shading I've ever seen. Reminds me why I hate NeHe's stuff so much...Firstly, it was written 7 years ago on a TNT 2, as a quick and dirty implementation to the article on this very website (which was also written 7 years ago, and sadly I never found the time to update/fix/finish it).Secondly, all calculations are performed in software so the reader could fully understand what was going on. This includes transforming the vertex normals each frame, as the model is rotating. I seem to remember the TNT 2 lacking hardware TnL as well.Finally, I'm not even sure if VBOs were even around back then, and using immediate mode was perfectly suitable for the purposes of the tutorial. It was to show how to do cel-shading in the most simplest of ways, not how to build a bleeding-fast cel-shaded graphics engine.Anyway, glad to see that people are still getting some use out of the article. Just be warned that it was never efficient to begin with, and graphics hardware has moved quite a bit in the past decade :).edit: damnit Yann, I would've thought you'd be above criticising a basic tutorial so obviously aimed at beginners. Even if it wasn't my article I'd still be disappointed with you :/   ;Quote:Original post by MENTALQuote:Original post by Yann LI just had a quick look at that tutorial, and I couldn't believe my eyes. This must be one of the worst ways to do cell shading I've ever seen. Reminds me why I hate NeHe's stuff so much...edit: damnit Yann, I would've thought you'd be above criticising a basic tutorial so obviously aimed at beginners. Even if it wasn't my article I'd still be disappointed with you :/It's a basic tutorial, aimed at beginners, showing them the complete wrong way to do something. That's worthy of criticism in my book.I'm also not sympathetic to the contention that because it is old, it should not be criticized. It's completely irrelevant on modern hardware.It may have been a great tutorial at the time, but today it's completely irrelevant and just misleading for people trying to learn how to do cel shading. It should really disappear from NeHe altogether. But I guess if NeHe got rid of all the outdated/wrong information, there wouldn't be much left, would there?   ;Quote:Anyway, glad to see that people are still getting some use out of the article. Just be warned that it was never efficient to begin with, and graphics hardware has moved quite a bit in the past decade :).I quite liked it actually :) But couldn't believe the inefficiency either. But got familiar with the theory nonetheless, which is good. Apparently the GLSL code for it in Lighthouse3D is pretty much the same.And yeah, the TNT2 didn't have T&L :)BTW, I was trying to get things to get shaded by its own color specified by glColor3f. Doing this for the vertex shader code:Quote:...varying vec4 tmpColor;void main(){...tmpColor = gl_Color;}and this for fragment:Quote:...varying vec4 tmpColor;void main(){...if (intensity > 0.95)color = vec4(tmpColor.r,tmpColor.g,tmpColor.b,tmpColor.a);...gl_FragColor = color;}I'm getting inconsistent colors, i.e. specified a few recopmiles/runs ago. Sorry if this is stupid. I just started GLSL an hour ago :)   ;Quote:I'm also not sympathetic to the contention that because it is old, it should not be criticized. It's completely irrelevant on modern hardware.I'm just saying that it seems rather petty and redundant to slate an incredibly simplistic 7 year old article for containing incredibly simplistic 7 year old information :D.Even back then, using Immediate mode for anything other than testing/prototyping/explaining led to slow code, and I would've assumed that it's common knowledge to use batched rendering methods whenever possible.Anyway, I'll butt out of this thread now. Assuming your card supports them, use shaders and vbos whenever possible. afaik practically all immediate mode and fixed function stuff doesn't go through the "fast path" (which is the combination of objects/commands that results in the highest degree of hardware acceleration).Using the vertex colours will give an incorrect result, as the hardware will blend the 3 different vertex colours (3 vertices obviously) together, this removing the banding effect. Using the 1D texture is still the way to do it (of course, do it in shaders). Rather than interpolating the colours, the shader will interpolate the texture coordinate instead (just like regular texturing). You can then use the interpolated texture coordinate in the fragment shader and grab the right colour from the texture.That's a really bad explaination, but it is 2am :D   