Scene Partitioning

Moderator: andrewmac

  • 1
  • 2
12 posts Page 1 of 2
lowlevelsoul
Posts: 23
Joined: Mon Mar 30, 2015 10:02 pm
by lowlevelsoul » Wed Nov 25, 2015 4:26 pm
I have a few questions w.r.t. the partitioning of the visual scene.

  • Is there any partitioning happening at all?
  • If so, what scheme is being used? (sphere tree, octree etc.)
  • Would there be scope to add other/custom partitioning schemes?
andrewmac
Posts: 295
Joined: Tue Feb 03, 2015 9:45 pm
 
by andrewmac » Fri Nov 27, 2015 9:13 pm
Right now there's no scene partitioning in place. It's simply renders whatever is in scene. I've been tossing around ideas in my head but I haven't settled on anything yet.

Are you talking about dynamically partitioning the scene for performance or an artists ability to break a larger scene into a series of smaller scenes?

Either way I'm open to ideas if you want to toss a few around.
lowlevelsoul
Posts: 23
Joined: Mon Mar 30, 2015 10:02 pm
by lowlevelsoul » Sun Dec 06, 2015 10:09 am
andrewmac wrote:Are you talking about dynamically partitioning the scene for performance or an artists ability to break a larger scene into a series of smaller scenes?


I think both options are valid, although I would lean more towards dynamic partitioning, with a common scene manager interface that can be abstracted from.

In my view/experience, for a general purpose game engine, a single partitioning scheme isn't going to fit very well. For large open scene, a quad tree or simple 2d grid would work well, but for enclosed/indoor scenes, you might want a loose oct-tree, kd-tree or something similar. I suppose you could even use the same interfaces to implement the "sub-scene" concept where it's up to the artist to split things up.

So I guess the requirements would be;
  1. Implement a general purpose scene interface
  2. Implement some simple abstractions (default(just holds a list of scene items), quad tree and oct tree)
  3. Specify the scene partition type in either script or in the resource scripts
andrewmac
Posts: 295
Joined: Tue Feb 03, 2015 9:45 pm
 
by andrewmac » Tue Dec 08, 2015 4:54 pm
@
User avatar
lowlevelsoul
: I think I'll implement this is two phases. Phase one is the ability to add SubScene objects to a scene. This will allow you to point to an existing scene file and append it to your scene. This should allow easy artist controlled partitioning of the scene. I can also very easily add a culling distance for each SubScene object so it won't be rendered after it's a certain distance from the camera.

The second phase is the culling library I'm working on as a separate project. I want the library to support fast frustum culling, bounding volume hierarchy based culling, and occlusion culling via software rasterization. I could expand the library to include various different algorithms though and make them options in the Camera. Obviously different degrees of culling would be ideal based on your scene/setup so this will be tweakable.

I think that covers all the major bases.
rlranft
Posts: 298
Joined: Thu Feb 05, 2015 3:11 pm
 
by rlranft » Thu Dec 10, 2015 3:16 pm
Technically you can already do the "sub-scene" thing - just write a group to disk, then load it later on a trigger, or check on level load, or something....
andrewmac
Posts: 295
Joined: Tue Feb 03, 2015 9:45 pm
 
by andrewmac » Thu Dec 10, 2015 4:48 pm
rlranft wrote:Technically you can already do the "sub-scene" thing - just write a group to disk, then load it later on a trigger, or check on level load, or something....


Right now my scene loading functions erase the previously loaded scene when you load a new one. You're right though, with its usage of SimGroups and TAML it wont be a stretch to load SubScenes. The main thing I want to add is a SubScene object that just points to another scene file. That way it can be included in a scene as read-only. I can also add editor support for switching a SubScene to read/write and letting you save back out your changes, and also the ability to simply add the objects of that scene into your own scene without the use of a SubScene.
rlranft
Posts: 298
Joined: Thu Feb 05, 2015 3:11 pm
 
by rlranft » Fri Dec 11, 2015 12:54 am
I like the SubScene thing for the possibility of keeping the object but potentially loading and unloading the contents - so in the main Scene TAML file you have SubScene objects... blah blah - and can use them as a rudimentary pre-cull if you like. Or even have SubScene objects that add levels of detail, or whatever.

All in all, good concept and having it in the engine would add another trick to the bag.
andrewmac
Posts: 295
Joined: Tue Feb 03, 2015 9:45 pm
 
by andrewmac » Fri Dec 11, 2015 2:04 am
@
User avatar
rlranft
: Unity has recently added this and it's pretty snazzy. It's partly where I got the idea from. You can load the contents of the SubScenes while you're in the editor or you can leave it unloaded and trigger the load from script as you see fit.
lowlevelsoul
Posts: 23
Joined: Mon Mar 30, 2015 10:02 pm
by lowlevelsoul » Sun Feb 21, 2016 9:06 am
Sorry, I haven't had a look at this thread for a while due to work and stuff.

I think the basic issue is that it doesn't really matter if you implement sub-scenes, some sort of soft occlusion culling tech or whatever; you're still having to test every object in the currently active scene against the frustum. If there's no trivial rejection before you're determining if something can be seen by the camera, that's a lot of work and a lot of memory to plough through, even on a moderately complex scene.

I suppose it depends who you think the "customer" for T6 is going to be. Is it going to be people who make games only for high-end desktop hardware? It going to be people who want to use mobile (console, phone, tablet) as well as desktop?

I would consider at least think of adding some sort of basic scene type interface in there. Rather than having the renderer just iterate through all of the objects, have it loop through some sort of list of objects provided by the scene interface. The default implementation could just function "as is" and build a list of everything, but it gives people scope to add their own trivial rejection scene, (kd-tree, sphere tree, oct tree etc) in its place.

It might be worth point out that my reason behind asking this, is that I work for one of the large console manufacturers, supporting developers in technical issues and focusing on performance. I'm a pretty low-level guy, but I fid the best optimisations are the high-level ones that require the least amount of work :)

One of my biggest bug bears is helping with performance opt on Unity. Unity is pretty ubiquitous these days, it's on everything. One of the big issues facing Unity is that you can't make a graphically complex game on anything but desktop, because it just checks EVERYTHING against the frustum or it uses Umbra which isn't optimised for some platforms (mobile, some consoles). It does't perform any sort of trivial rejection. So you end up with an operation (frustum cull) that SHOULD take around 3 milliseconds for a complex scene, taking anything between 32 and 64 milliseconds (that's 2 and four frames at 60 fps) in Unity.

So I'd like to see at least some basic support for trivial rejection in there - even if it's "here's the interface, implement your own as a plug-in".

Of course, that makes it sound like a lot less work than it actually is. The scene manager would need an interfaces that;

* Allows objects to be marked as dirty when they are added to the scene, moved or have their bounds changed ( The objects would mark themselves as being dirty, notifying the scene that they should be added to a dirty list)
* Update the dirty objects, sorting them into the correct partitions (this should happen before frustum culling)
* Tell the partitioning scheme to build a list of visible objects

If I have the time, I'll take a look at the render submission code and prototype my own interfaces as an example. Assuming I can get it to build on Mac :)
andrewmac
Posts: 295
Joined: Tue Feb 03, 2015 9:45 pm
 
by andrewmac » Mon Feb 22, 2016 5:36 pm
@
User avatar
lowlevelsoul
: I've decoupled render data from scene objects. When a scene object becomes dirty it refreshes which allows it to update the settings on its render data. This way there is a list of opaque surfaces in contiguous memory for quick rendering by rendering paths. Right now there's a spot in the render loop to filter the lists but it doesn't do anything at the moment. The idea is to allow different cameras to use different methods for culling. I've left culling alone for the time being because I want to do it well and try to avoid the pitfalls you describe. You sound experienced on the topic so any advice you can offer is much appreciated.

Though it wouldn't be ideal for mobile platforms I'm (slowly) working on a separate solution: https://github.com/andr3wmac/SoftOcclude a software based occlusion culling library. Basically it rasterizers a cheap depth buffer and then pass/fails objects tested against it. It's based on Intels work: https://software.intel.com/en-us/blogs/ ... ing-update

Essentially I've built the scene processing in a way that lends itself very well to various culling methods, but I haven't settled on one yet.
  • 1
  • 2
12 posts Page 1 of 2

Who is online

Users browsing this forum: No registered users and 2 guests