   Scene manager, virtual function, performance
  Hi there !I'm new to this forum but i read the news and the different topic every day !Good job for your work and excuse my language mistakes.I have a lot of question for the exert (or not) but i'll try to make it clear and fast.I'm developing a graphic engine based on OpenGL. I have done a little one a few years ago but i want to make now something that i can be proud :).1) i'm very confused about what kind of structure i can use in my engine for objects (static and dynamic) rendering, culling, and updating. I read a lot of paper about octree bsp portal bounding volumes, sphere tree ....I want a structure that can be used for indoor and outdoor and handle static and dynamic.I know that its pretty impossible and i have to make choice but i'm wondering if someone know how can i achieve this.2) I want to avoid the virtual functions for speed but i want again my engine be extremely generic( for instance the user can build a vertex buffer based on float or on int or whatever). For this i'm using template but it is a little bit hard to handle.Rendering use vertex buffers normals bufffer .... so i can't write template because of polymorphism.... So the rendering need to store an abstract type AbstractBuffer and call draw() on each element. draw() is virtual so the critical function of the engine is virtual too bad !. I read a few paper about meta programming and simulate template polymorphism but with this techniaues you cannot store differents objects because 2 template differents instances are differents objects !.So my question :1) Have you an idea to make my scene manager handling static dynamic object efficiently with fast culling occlusion algorithm ?2) how can i build differents buffers (storing int float) and make my engine with NO virtual function ?3) Do you have paper about what you are saying ?4) When the algo say " render object " it mean calling drawArrays or updating data to the graphic card memory then call drawArrays ? If you use VBO when updating data to memory ? I think when loading level updating all geometry to memory (graphic card) and then choose to render something with drawArrays. Am i wrong with this ?What is for you the best way to achieve what i want ? ( how unreal engine do dynamic culling and occlusion without portal and bsp ?)An other thing --> if you use octree for culling and image you are culling with frustrum, how can you discard the octree occluded by the room you are ( you can not see throught a wall but frustrum culling allow you to render the octree behind the wall)Thanks for you ALL !!!!   
Quote:Original post by ftyouSo the rendering need to store an abstract type AbstractBuffer and call draw() on each element. draw() is virtual so the critical function of the engine is virtual too bad !How often do you call draw()?Virtual functions aren't really what you call "slow", they just perform an additional memory lookup and do an indirect call.So there is a certain cost, but it's only noticable in tight loops. If you're calling a virtual function once every x*100 asm ops, it's not something to worry about.   ;  Hi ! thanks for your answer.Yes i know that virtual function need to check a table to know the address of function call. In fact the draw() function is critical because maybe the most important (in number of call).maybe for 60 FPS and for 1000 objects in scene = 60 000 call in one second. But actually i don't know because i'm just brainstorming right know. The basic idea is to have objects in scene (mesh) that implement draw()   ;  Hey, 60000 calls per second is nothing. If one vcall would have 20 CPU cycles overhead, this overhead would account for 0.04 % of total execution time.   ;  Ok ! So why some paper tell to avoid virtual function so ? the most critical call is in a real time execution program, so if virtual cost nothing, why avoid it ?thanks for the answer anyway !Ok do someone have answer for other questions ?[Edited by - ftyou on May 28, 2010 9:55:18 AM];  Because some people are stuck in the stone ages. The overhead of the draw  call is most likely negligible in comparison to the work done inside the function. Besides - do you need the functionality that virtual functions provide? If you do, it doesn't really matter how fast or slow they are. Unless you think you can roll your own dynamic dispatch mechanism, virtuals are the best you're going to get.   ;  Thanks for your answer ? And the others questions ?   ;  Performance is always relative. Making statements regarding performance without providing context is a stupid thing to do, and applying those statements outside of their context isn't any better. In the case of virtual functions, the actual amount of overhead depends on the hardware/platform, the compiler, and how many times you call a function. Whether or not that amount of overhead is "bad" or "unacceptable" depends on the requirements of the app or game, and the cost of designing out the need for them. For a lot of people (such as most people who develop for consoles), the situation is such that a virtual "Draw" function would probably be considered "bad". For many others, it wouldn't be worth it. For you, who knows.On a related note, I once read a presentation (I think it was about Mortal Kombat vs. DC Universe) said "virtual functions on PS3 = death by a thousand paper cuts". Funny stuff. :P   ;Quote:Original post by MJPOn a related note, I once read a presentation (I think it was about Mortal Kombat vs. DC Universe) said "virtual functions on PS3 = death by a thousand paper cuts". Funny stuff. :PLol :)   