
Advertisement
????????? ?????
Member
Content Count
11 
Joined

Last visited
Content Type
Profiles
Articles and Tutorials
News
Contractors
Columns
Podcasts
Games Industry Event Coverage
Gallery
Forums
Calendar
Blogs
Store
GameDev Links
Projects
Developers
Everything posted by ????????? ?????

Hello i recently started to tackle the various mesh decimation & simplification algorithms, mostly from Hoppe & Melax. The algorithms in question are the Quadric error metrics mesh simplification & the Progressive mesh simplification. I found a few good github starting points (VTK, hoppe's & melax's githubs etc.) to try and test the various implementations but i run into some problems:1. I tried to simplify a few of mine and a few of the provided (inside the code base) meshes and i noticed that not all meshes survive the same simplification. For example a 400 vertices robot mesh can be simplified down do 1020 (or about 37% of the src vertices) vertices without any problem no missing faces or huge topology distortion, yet an Eagle mesh with 3000 vertices can be just simplified to 19002000 (or about ~6070% of the src vertices) vertices before i start noticing that the mesh starts to lose faces (which leads to a mesh with quite noticeable number of holes). And that is something i noticed with quite a few models (be it mine or the provided). I would like to know what is the actual cause which stops / prohibits some meshes from being simplified as much as others. I am probably asking a quite stupid or obvious question 2. Even if the simplification was perfect i still have difficulty figuring out how would i preserve the vertex appearance (uv coord, tangents, normals etc.) I read a few papers  one in particular from Hoppe  New Quadric Metric for Simplifying Meshes with Appearance Attributes. But did not find any real world examples or at least snippets of code to give me a better grasp of the technique Furthermore what has been bugging me lately is more about techniques to dynamically render different LOD levels when walking over a large terrain mesh (non regular grid  NOT generated from a height map, noise, 2D data, etc. so clipmapping techniques and alike go to the bin). I will give you a CS:GO analogy or Take League of Legends as it seems a more appropriate example here, i am not sure if they are doing that exact thing, but presume that their maps are mostly hand crafted, all trees, boxes, walls buildings which are not interactive, destructible or static are probably embedded and modeled along with the rest of the map & terrain. This can potentially allow for fewer draw calls, and much richer environment. But then again how would one optimize such a huge rendering step, where the entire model of the map / terrain may consist of at least 400500k triangles at bestOr is it just a flat plane, with everything else rendered as a separate entity on top (instancing where possible, although given that most objects are quite unique and not very many instancing will be limited) ?

Hello, times came when i had to implement some culling into my engine. I started by reading some stuff and so far so good. I managed to create an octree which can effectivly divide my geometry's vertices (per mesh) into an octree. But here i have some Questions: Currently i am using immediate mode to test if the culling works. And it does work, i am recursivly traversing the tree's nodes and testing against the node's bounding box if the frustum intersects with it. Repeat untill leaf is found and render that leaf's geometry (with immediate mode for testing) But now i would like to use VBO/VAO's to render the geometry in the leaves and here i see two options:  1.Each time the i traverse the tree push the leaves that intersect with the frustrum into a list then get the vertices out of them and construct a VBO and send it to be rendered.  2.Pre build a VBO for each leaf then just rebind for each visible leaf and render. Anyway, which is the better option rebuilding a new vbo each time the frustum changes, or just rebinding multiple vbos (which is also expensive). Also is this even the right approach , maybe i am missing something. bool view_Culling(CFrustum& frusrum, COctree *node) { if (!node) return false; if (frusrum.CubeInFrustum(node>GetCenter().x, node>GetCenter().y, node >GetCenter().z,(node>GetWidth()/2.0f))) { if (node>IsSubDivided()) { view_Culling(frusrum, node>OctreeNodes()[TOP_LEFT_FRONT]); view_Culling(frusrum, node>OctreeNodes()[TOP_LEFT_BACK]); view_Culling(frusrum, node>OctreeNodes()[TOP_RIGHT_BACK]); view_Culling(frusrum, node>OctreeNodes()[TOP_RIGHT_FRONT]); view_Culling(frusrum, node>OctreeNodes()[BOTTOM_LEFT_FRONT]); view_Culling(frusrum, node>OctreeNodes()[BOTTOM_LEFT_BACK]); view_Culling(frusrum, node>OctreeNodes()[BOTTOM_RIGHT_BACK]); view_Culling(frusrum, node>OctreeNodes()[BOTTOM_RIGHT_FRONT]); } else { //use prebuilded vbo here //or push these vertices here in a list later build a dynamic vbo //from them node>DrawOctree(node); return true; } } return false; }

Octree Frustrum Culling
????????? ????? replied to ????????? ?????'s topic in General and Gameplay Programming
As i told you above i have implemented the culling on object/mesh level , and i am sattisfied with it . I want to try and go deeper and see what i can do , if it does not work,if i dont see any performance gain i will not use it ofcourse. I think your attitude is a little passive aggressive , instead of an answer i get some bull and you are wasting your and mine time. 14 replies

1

Octree Frustrum Culling
????????? ????? replied to ????????? ?????'s topic in General and Gameplay Programming
Thanks , i was away for a while. But i was wondering, since my geometry is split between all leaves, so each leaf has some chunk of the terrain vertices (for now just vertices,no indices involved to avoid complications). So i am using flat out buffer where all vertices are ordered according to the indices, ready to be drawn. But since my geometry is split , how sould i specifiy offsets to the glVertexAttribPointer (or rather how would one obtain those offsets per leaf) Thanks ! 
Octree Frustrum Culling
????????? ????? replied to ????????? ?????'s topic in General and Gameplay Programming
Yea but i specifically said in my first post that the octrees wont be created at run time cause we are talking about static geometry. I am sorry if the quote wasn't very accurate. Anyway i was looking on a way to actually draw a specified range from a vbo, how would that work. Currently i am having the geometry of a given object split in the leafs of an octree. So i should be having some range from where i want to draw from the VBO in each leaf 
Octree Frustrum Culling
????????? ????? replied to ????????? ?????'s topic in General and Gameplay Programming
Well currently i am using assimp. And when loading the model i am loading all meshes in that model and grouping them all under 1 VBO and 1 IBO . So for the example of Sponza all meshes within the model are in 1 VBO for me. But what i am worrying about is sending vertices thru' the pipeline that are not visible at all. If your target machine is GPU bound suddently all those invisible vertices you send to the shader for calculations are becoming a problem. Your approach is to devide the the model into meshes , cull the meshes if visible  thats a possibility , mine was about deviding the enire VBO into chunks in an octree. What i understand you are saying is the following: Draw the entire model if its completely visible (1 draw call) if only parts of the model are visible  Draw those parts(meshes) of the model , rest is culled That's what i am saying for the last 2 posts. The only difference is that my model wont be split into meshes but rather chunks in the octree. That's why you'r subdivisoun will stop at say certain(reasonable amount) amount of vertices What updates on the octree when i clearly stated it's not the case. Actually i was talking about your statement from before , not your post as a whole I do not agree. You cant say that because you may be sending 100% of the model when you are actually seeing 5%. If the calculations per vertex are expensive or you are GPU bound (saying that cause my GPU is not the greatest and doing extra stuff seems to be unnecessary 
Octree Frustrum Culling
????????? ????? replied to ????????? ?????'s topic in General and Gameplay Programming
Okay, well. Correct me if i am wrong your idea is to use each object's bounding box as a culling mechanism. And just yesterday i implemented something like tha. Using bullet physics (which i use in the engine for other purposes) i managed to implement frustum culling (it also supports occlusion culling but i wont dive into that just for now). So bullet maintains a dynamic AABB tree which contains the aabb of each model so i managed to make it cull the geometry on object basis.Bullet retuns a List of visible objects and the rest is just looping over them (here i may want to sort on some criteria to avoid state changes) Works nice and neat for about 6000 objects (about 2 500 000 triangles) getting stedy 500 FPS (and about a few millsecs per frame rendering). I guess i can easily get reasonable fps with x4 or even x5 times individual objects. Also perfromed a profiling and the most expensive call is to DrawElements, cause they are all individual objects (not batched), guess that's expected. "Simply not worth the cost just to avoid drawing a few offscreen triangles" I dont think that's very true. You consider only a terrain as a type of shape that can have dense amount of triangles , and that's just not true. Imagine i wanted to load a model type (for example the Sponza) it's heavy and huge and doesnt have "just a few offscreen triangles" (if you decide to use it as a building type). And sponza (and similarly huge geometry) is worth going deeper into some kind of spacial part. That was my itial idea , to keep another level of tree for models similar to that. Why i said that it will present problems with materials and shaders ? Well , because what i meant is to stuff the entire scene into the tree based on the vertices not a AABBs. Then each node will become a mash between multiple objects and pain. But i think that's unnecessary. And besides the scope of the Q 
Octree Frustrum Culling
????????? ????? replied to ????????? ?????'s topic in General and Gameplay Programming
@L. Spiro I think you misunderstood what i meant. You are assuming that the octree is divided by AABB when its not.Even then if a Terrain AABB intersects the frustum i will have to draw the entire thing which can be humongus, still drawing invisible parts of it. Further more I dont want to determine if An object is visible i want to determine which parts of it are visible if its too big to render completely. Also I realize that the entire scene can be stuffed inside one octree and culled from there , but that adds rather complicated problems (with materials,textures,shaders etc). My idea and approach will be different The idea is that i have some kind of a BVH(maybe octree of AABBs) which will contain the Bounding Volumes of each object in a given scene. Then i will perfrom frustum tests on that structure to determine the nodes (and respectivly the models in that node) that are visible or not. Those that are not visible are simply not drawn, Those that are visible have 2 options:  They are Partly visible (their bounding volume is bigger than the frusum but still visible  Terrains,Big Buildings etc...)  Here is where the Octree from above comes into play. They will be tested against an Octree to determine exaclty which parts of them are visible. I wont go deep into my implementation but to clarify i can say that each object has modeldata property , modeldata can be reused among many objects. Each modeldata contains  vbo,ibo, vertices. Now it will contain prebuilt octree from the vertices so i can use it when i need to determine what to draw when the model is partly visible. I will probably test in object space since the vertices are already there and i will need to translate the frustum also in object space.  They are entirely visible (their bounding volume is smaller than the frusum)  Directly sent to be drawn Currently that is going to be applied to static , nonmoving objects. @Hodgman I think thats what i am looking for. Using 1 VBO (which i already have prebuilt) and only extract the vertices i currently need at each test against the tree. Can you explain further , maybe with some codeblocks how would that work ? Thanks ! Edit: What structure should i use to store the bounding boxes of the objects . I assume i can group the boxes in huge chunks and test against that and discard the entire chunk if not visible . But how would one build that structure ? 
Octree Frustrum Culling
????????? ????? replied to ????????? ?????'s topic in General and Gameplay Programming
Okay , but the mesh is devided between the leaves. so for each leaf of the octree i will have 1 VBO with some vertices which will represent part of the mesh. And ill only render the parts that are visible thus binding multiple vbos. And its better right ? 
Hello, recently i started to implement simple bounding volumes in my Engine. So far i have implemented a Sphere and AABB , also i implemented simple rayintersection methods for those two volumes. But i am STUCK on how to create a Oriented Bounding Box (OBB). Looking over the internet i find bits and pieces , mostly theory not actual straightforward information. On one side somewhere i've read that the OBB should consist of extend / center and local orientation vectors , on other sources i saw some people talking about covariance matrices etc. Also i should mention that i found this very simple and neat custom method, when i was looking for a OBB > Ray Intersection.The code works fine, but i would like to have separate OBB generation rather than this. I will paste that here. Basically this method takes AABB (max,min) ModelMatrix and RayOrigin and RayDirection converts the AABB to OBB and does the intersection test.Note that the Scaling is separated and only applied on max,min. So i was trying to extrapolate only the conversion from AABB to OBB but the calculations involve the ray's data so. I have dones some refactoring of the code. Al in all my Question is for a straight forward method or algorithm on how to create a OBB , also is it possible to generate one from a AABB ? bool RayCast::RayBoxCollision(AABB *aabb, const ModelMatrices& BaseModelMatrix , float *intersection_distance){ const glm::vec3& aabb_min = vec3(BaseModelMatrix.Scaling * vec4(aabb>getMinBound(), 1.0f)); const glm::vec3& aabb_max = vec3(BaseModelMatrix.Scaling * vec4(aabb>getMaxBound(), 1.0f)); const glm::vec3& ray_origin = this>ray_start; const glm::vec3& ray_direction = glm::normalize(this>ray_end  this>ray_start); const glm::mat4& ModelMatrix = BaseModelMatrix.Transformation * BaseModelMatrix.Rotation; float tMin = 0.0f; float tMax = INFINITY; glm::vec3 AABBposition_worldspace(ModelMatrix[3].x, ModelMatrix[3].y, ModelMatrix[3].z); glm::vec3 delta = AABBposition_worldspace  ray_origin; { glm::vec3 xaxis(ModelMatrix[0].x, ModelMatrix[0].y, ModelMatrix[0].z); float e = glm::dot(xaxis, delta); float f = glm::dot(ray_direction, xaxis); if (fabs(f) > 0.001f){ float t1 = (e + aabb_min.x) / f; float t2 = (e + aabb_max.x) / f; if (t1>t2){ float w = t1; t1 = t2; t2 = w; } if (t2 < tMax) tMax = t2; if (t1 > tMin) tMin = t1; if (tMax < tMin) return false; } else{ if (e + aabb_min.x > 0.0f  e + aabb_max.x < 0.0f) return false; } } { glm::vec3 yaxis(ModelMatrix[1].x, ModelMatrix[1].y, ModelMatrix[1].z); float e = glm::dot(yaxis, delta); float f = glm::dot(ray_direction, yaxis); if (fabs(f) > 0.001f){ float t1 = (e + aabb_min.y) / f; float t2 = (e + aabb_max.y) / f; if (t1>t2){ float w = t1; t1 = t2; t2 = w; } if (t2 < tMax) tMax = t2; if (t1 > tMin) tMin = t1; if (tMin > tMax) return false; } else{ if (e + aabb_min.y > 0.0f  e + aabb_max.y < 0.0f) return false; } } { glm::vec3 zaxis(ModelMatrix[2].x, ModelMatrix[2].y, ModelMatrix[2].z); float e = glm::dot(zaxis, delta); float f = glm::dot(ray_direction, zaxis); if (fabs(f) > 0.001f){ float t1 = (e + aabb_min.z) / f; float t2 = (e + aabb_max.z) / f; if (t1>t2){ float w = t1; t1 = t2; t2 = w; } if (t2 < tMax) tMax = t2; if (t1 > tMin) tMin = t1; if (tMin > tMax) return false; } else{ if (e + aabb_min.z > 0.0f  e + aabb_max.z < 0.0f) return false; } } *intersection_distance = tMin; return true; } Edit: Well i did presume that this is possible but since i post here for the first time there is no any editor showing similar to other forums. What are those tags again ..!?

Model / Mesh Constructing OBB
????????? ????? replied to ????????? ?????'s topic in General and Gameplay Programming
Thanks , well i was just judging by what i see in the code snippet i applied. It works perfectly , but i am not sure that i can understand it completely. But i get the most parts. How exactly does it work ? And it can actually compute a OBB from AABB data

Advertisement