The biggest issue with our current cullers is that we don't have fast
occlusion culling.
If you look at the ms/frame that frustvis takes (only does frustum culling)
it's pretty insignificant (~2-5ms/frame). Even if you wrote a new frustum
culler that was 100x faster than the existing one, we wouldn't really notice
much of a performance improvement (unless you were already getting 60+ fps).
So I think that any culler project should be making occlusion culling the
main focus, not a possible extra.
I think the priorities should be reversed;
1) Write an occlusion query culler building up from our existing frustum
culling.
2) Work on increasing performance where possible (in either the occlusion
side or the frustum side).
3) In the unlikely event that 1 and 2 are finished with time to spare,
perhaps investigate LOD.
On 23 March 2010 08:41, Jorrit Tyberghein <jorrit.tyberghein@...:
> A better culler is certainly a very worthwhile project. Culling should
> certainly occur on object level. Not sure how to integrate this with larger
> objects like terrain but I guess you could leave terrain culling internal to
> the terrain mesh itself. Another way might be to make it so that culling
> objects are not necessarily the same as mesh object. So most mesh objects
> are exactly one culling object but bigger mesh objects might implement
> multiple culling objects. This is certainly something that has to be
> discussed.
>
> Greetings,
>
> On Tue, Mar 23, 2010 at 12:20 AM, Romulo <abra185@...> wrote:
>
>> Hi there, as i already introduced myself, i will try to describe better my
>> idea:
>>
>> First i was thinking about doing the lighter2 utilize as many
>> cores/processors as possible, but looks like this idea wont fill
>> the entire summer and everyone will NOT benefit from it (mainly modern
>> games, where everything is dynamic). My current idea
>> is to fill the lack of proper culling methods. I plan to implement an
>> octree based scene, frustum culling everything that is not visible to
>> frustum.
>> Once we get the visible objects (or theoretically visible ones) into a
>> list, we can start doing occlusion tests to prevent hidden geometry drawing
>> (think about a person/character behind a concrete wall) and reduce
>> drastically the need to process hidden geometries. Here are some catches
>> by the way, that may slow down or speed up the project:
>>
>> 1- Octrees will need to be generated and modified in real time (except for
>> static scenes). I plan to do this in an "object level" to prevent
>> culling small polygons (but i will need a solution for culling large
>> meshes like terrains). To make this task easier on CPU, i plan
>> to refine it with multi-threading. Since each node has 8 children nodes,
>> we can take each node and process it separated on a thread
>> (of course this depends on the number of processors/cores we have
>> available).
>>
>> 2- For objects that are drawn too far from the camera (we can calculate
>> the distance on the culling algorithm itself, because of the maximum camera
>> distance)
>> we can use LOD and also reduce the poly count.
>>
>> 3- Occlusion. That will need to be done on GPU. I still don't know a good
>> solution for doing it. Since i never worked with occlusion this is kinda of
>> a challenge,
>> so i will left it for the end.
>>
>> I know time constraints will keep me busy, mainly because this will give
>> me a thousand different bugs :D
>> I've worked with SoC before and i know how hard is to keep everything
>> smooth. I'm drawing a timeline soon and i will submit it. For now, i want to
>> hear opinions.
>> Thanks.
>>
>> Sincerely,
>> Rômulo Fernandes
>>
>>
>> ------------------------------------------------------------------------------
>> Download Intel® Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Crystal-develop mailing list
>> Crystal-develop@...
>> https://lists.sourceforge.net/lists/listinfo/crystal-develop
>>
>>
>
>
> --
> Project Manager of Crystal Space (http://www.crystalspace3d.org)
> and CEL (http://cel.crystalspace3d.org)
> Support Crystal Space. Donate at
> https://sourceforge.net/donate/index.php?group_id=649
> Personal page: http://users.telenet.be/jorritTyberghein/
>
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Crystal-develop mailing list
> Crystal-develop@...
> https://lists.sourceforge.net/lists/listinfo/crystal-develop
>
>
--
-Mike
|
