Insides can be very detailed. Here's a close-up of the interior that's glimpsed through the outside window above.
Existing game engines just aren't designed to deal with content like this when it hasn't been combined and preprocessed during the build process.
This is the curse of Second Life. Detail works fine, speed, not so much.
Couldn't you fuse multiple models into one, transforming UVs and making a texture atlas per group? Shader seems the same for all stuff?
Then no impostor tricks might be necessary at all.
Or is this what you meant form the beginning?
JoeJ said:
Couldn't you fuse multiple models into one, transforming UVs and making a texture atlas per group? Shader seems the same for all stuff?
Then no impostor tricks might be necessary at all.
Maybe. We're just the viewer, not the creator. Deciding what to group together, and being able to undo that decision, and not spending more effort creating the groups than it would take to just display them. That's the problem. Impostoring is just the display mechanism. It's the grouping that matters. Good insights here.
The entire SL system has very little idea of what objects belong together. Object owners put things someplace, and the system renders them. That has to be inferred, somehow. Is there any known system which does something like that?
There is occlusion culling in SL (see http://wiki.secondlife.com/wiki/Culling) but it doesn't help all that much. All those windows.
I see. But you have all objects, transforms and bounding boxes available. And you could make octree from all objects that do not move, then traverse it once to make groups.
I guess that's fast enough, but i won't give perfect groupings like all objects in a room. It would just cluster nearby stuff, and it would hurt the occlusion culling method as well. Could be a problem, but the link only says ‘culling’ and nothing about occlusion. So is it just frustum culling? (Which would suffer too a bit, i guess)
However, i have used this octree method for a hidden surface removal algorithm, tackling the same problem of visible interior details through windows. Worked for me. Though my goal was occlusion culling using software rendering and having manually made low polys representing the walls of the houses. So the low quality grouping bounding boxes from octree often peeked through the walls and got rendered although not visible, but it was still a big win and fast enough for dynamic scenes.
I did not bother to optimize this further by fusing textures and making UV atlas, but sounds no big problem. Maybe GPU could transform UVs with given UV transfrom per object.
(I remember i once tested to index thousands of transform matrices per vertex from video memory to draw thousands of objects with one draw call. This also worked well, so you could keep groups intact even with animation and timeslice grouping workloads.)
Maybe the worst performance issue would be to generate the fused textures. That's a lot of brute force work for CPU. A compute shader could do such composition if available? But not sure if practical with memory limits. And i'd hope they all use the same compression mode.
Well, the main conclusion so far is that the existing avatar impostor system (render more distant avatars every 250ms onto a billboard) can be improved.
See below, where the character sitting on the couch and the one sitting on the tree stump are rendering behind what they're sitting on. Worse, as their idle animations run, they toggle from being in front to being in back, since the Z decision is based on the impostor plane distance to the camera. This special case looks fixable, by having a Z layer for the impostors and using that as an depth offset when creating the final image.
No similarly easy fix seems to exist for the general case of scene objects.
