Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (499)
Games in Android Showcase (118)
games submitted by our members
Games in WIP (567)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Occlusion Culling  (Read 5299 times)
0 Members and 1 Guest are viewing this topic.
Offline StumpyStrust
« Posted 2013-11-18 06:53:13 »

I am wanting to try this in 3D (can really exist in 2D with out some shadowing going on). I have read many things online but am very worried about diving into it. Does anyone on here have any experience with it? Any tips before diving in? Is it worth it?  Huh

Offline gouessej
« Reply #1 - Posted 2013-11-18 15:51:09 »

Hi

I just looked at this before trying to answer your question. I implemented occlusion culling based on cells and portals in a simplified case several years ago. I have tried to create a more general implementation for years, it doesn't work yet. A very few engines provide efficient culling except frustum culling. Octrees are supported by JMonkeyEngine 2, Tesseract uses BSP trees as far as I know. What do you want to achieve?

Offline Riven
« League of Dukes »

JGO Overlord


Medals: 801
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #2 - Posted 2013-11-18 17:59:59 »

It might be shocking to some - but some modern AAA-grade engines use a seriously low-res software renderer (just a depth-buffer) to see how many samples get through for a certain shape.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline pitbuller
« Reply #3 - Posted 2013-11-18 18:04:41 »

What you are trying to achieve with occlusion culling? Performance or just some effects?

For occlusion culling, software rastersation with heavy threading and SIMD optimizations is going to be really fast. There are optimized version of Intel test sample with lot of info. http://fgiesen.wordpress.com/2013/02/17/optimizing-sw-occlusion-culling-index/
Offline StumpyStrust
« Reply #4 - Posted 2013-11-18 18:09:46 »

These are a few of the many things I have read but there are not code examples just a bunch of theory which is what it sounds like.

http://http.developer.nvidia.com/GPUGems/gpugems_ch29.html

http://www.gamasutra.com/view/feature/3394/occlusion_culling_algorithms.php

I want to "render" (not actually but loaded in memory) 60 million cubes at 60 frames per a second. On my desktop I am at 9-10 million at 10-12 fps. I want more. I can still do greedy meshing but I am hitting a fill rate limit which greedy meshing won't help. So I need to simply only render what is visible.

Offline Riven
« League of Dukes »

JGO Overlord


Medals: 801
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #5 - Posted 2013-11-18 18:55:55 »

I know it's offtopic, but please...! No more cube world threads..!

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline StumpyStrust
« Reply #6 - Posted 2013-11-18 19:24:07 »

For the love of God NO! I am not making another cube world. I just wanted to see if I could squeeze a bunch of voxel cubes out. There is no adding/removing cubes, infinite worlds or anything just some 3d noise. I am learning 3D via cubes. If this does go anywhere, it is to use the voxels as data for generating a polygonal mesh similar to Voxel Farm which EQ Next is using. I think cube worlds are nice for dipping into 3D as you do not need to have to worry about real asset loading because you just use textured cubes. By dipping I mean more then a rotating shape. 

Back on topic, from what I have read I think I will try the portals/doors/windows idea as it is more in my ballpark.

Offline gouessej
« Reply #7 - Posted 2013-11-19 09:46:34 »

Back on topic, from what I have read I think I will try the portals/doors/windows idea as it is more in my ballpark.
This is the kind of thing that I have tried to achieve:
http://geck.bethsoft.com/index.php/Occlusion_Culling

If you need some help, let me know. I use quads to represent the portals and I advise you not to use polygons. I store the cells in a graph.

Offline Roquen
« Reply #8 - Posted 2013-11-19 10:15:18 »

Unless terminology has changed, occlusion culling refers to quite something different then cell-and-portal style PVS determination.

The simplest (which is far from the most efficient) way to implement cell-and-portals is to render (at least the depth-buffer) of the cell which contains the camera and objects within that cell (at least ones that can potentially occlude).  Then render all portals with writes disabled and asking a counter for number of pixel rendered.  If not zero, then mark that cell to be rendered...repeat.
Offline theagentd
« Reply #9 - Posted 2013-11-19 13:46:03 »

You could probably do something like cull chunks based on using an occlusion test with a cube that encases that chunk.

1. Draw the closest X chunks since they're most likely to be visible anyway.
2. Fire occlusion tests. The farther away the chunks are, the bigger your occlusion cubes to cull multiple chunks with a single cube to avoid heavy depth overdraw and CPU overhead.
3. Read the occlusion results from the previous frame. Although this will delay the results from your occlusion queries by a single frame, it'll prevent a performance killing CPU and GPU stall while waiting for occlusion results.
4. Render the remaining chunks that passed their occlusion tests.

Myomyomyo.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Roquen
« Reply #10 - Posted 2013-11-19 14:14:25 »

Like I said my quick-to-hack-together sketch is far from ideal but if you're drawing N portals in a stage you don't need to query the first until after you've submitted them all.  If the first one passes you can start rendering that cell before you query the 2nd portal for it's result, etc.  Smartly choosing the ordering (say smallest screen coverage) and not blindly submitting all portals (such a CPU side back-facing test, etc) lowers the burden. 
Offline gouessej
« Reply #11 - Posted 2013-11-19 15:19:20 »

Unless terminology has changed, occlusion culling refers to quite something different then cell-and-portal style PVS determination.
Ok but it seems to be unclear in Wikipedia and the wiki of the Geck engine.

I start in the (current) cell in which I am, I render it. For each portal of the current cell, if it is in the view frustum, then I render the other cell bound to this portal, I compute another view frustum from this portal that I use to visit this other cell (its portals) and so on...


Offline Roquen
« Reply #12 - Posted 2013-11-19 16:30:54 »

Sorry...I'm not intending to be a stickler for terminology in this case.  I'm simply not clear what OP is really asking.  For highly occluded scenes a well implemented cell-and-portals is approaching optimal.  But if the case if different: say along the lines of "can I see that hill ahead of me through the trees" then the answer is different.

Clipping the contents of cells starting with the frustum and modifying the bounding volume as it passes through portals is a very good way to lower the PVS and consider much fewer "distant" portals, etc.
Offline StumpyStrust
« Reply #13 - Posted 2013-11-19 19:44:26 »

I knew some people on here knew stuff thanks. Yes I know that the cells/portals are not real Occlusion culling. I was mainly just wanted to hear some peoples ideas/experience with occlusion culling or similar strategies so I may avoid common hickups/mistakes. I think the portals will be a good start before trying real occlusion culling. From what I understand this technique is rather complex and considered "advanced" but that really is all a matter of perspective.

Thanks gouessej for the link that will help.

The idea I had was that I find the "closest" cube to start with and then build a frustum based on its location and add it to a list of frustums. These frustums are from objects that we know/hope are visible. Before rendering a volume we check it against these frustums to see if it is completely contained in any. If it is, we do not render as it is occluded, else we had its frustum to the list.

I could pick the starting objects by first sorting things out by distance from camera and then proceed by starting with the closes objects. Or, I could do a few ray casts to pick a bunch of objects I know are visible and start with them. I am not sure how costly building frustums and checking if a volume is completely contained in said frustums is. This is all conjecture at this point with no experience which is where y'all come in and tell me I am crazy.

Obviously for the cube world thing (sorry riven) it is too costly to do every single cube but maybe do it based off of large faces from sets of cubes as the near face of the frustum. Oh all of the directions of these frustums will be based on their direction to the camera.

Offline gouessej
« Reply #14 - Posted 2013-11-20 12:31:57 »

I would rather use the empty space in which the player can move to compute the cells and the portals which should be easier than in the general case as you only have cubes. You have to attach each cube to (at least) one cell.

Offline lcass
« Reply #15 - Posted 2013-11-24 11:31:41 »

See this depends if you are using something like opengl because that can support occlusion culling by just enabling it.
Offline Roquen
« Reply #16 - Posted 2013-11-24 12:04:09 »

No it doesn't.
Offline opiop65

JGO Kernel


Medals: 154
Projects: 7
Exp: 3 years


JumpButton Studios


« Reply #17 - Posted 2013-11-24 13:45:40 »

Face culling isn't occlusion culling. I think that's what you're thinking of.

Offline Roquen
« Reply #18 - Posted 2013-11-24 14:04:08 »

Potentially visible set determ & occlusions are high level constructs so you can have your low-level (OpenGL in this case) consider drastically less data.
Offline lcass
« Reply #19 - Posted 2013-11-24 14:44:50 »

See this depends if you are using something like opengl because that can support occlusion culling by just enabling it.
Ignore that entirely forgot D:
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Pippogeek (38 views)
2014-09-24 16:13:29

Pippogeek (29 views)
2014-09-24 16:12:22

Pippogeek (18 views)
2014-09-24 16:12:06

Grunnt (42 views)
2014-09-23 14:38:19

radar3301 (24 views)
2014-09-21 23:33:17

BurntPizza (61 views)
2014-09-21 02:42:18

BurntPizza (31 views)
2014-09-21 01:30:30

moogie (36 views)
2014-09-21 00:26:15

UprightPath (49 views)
2014-09-20 20:14:06

BurntPizza (53 views)
2014-09-19 03:14:18
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!