PlaneShift

Support => Technical Help: Problems BEFORE entering the game => Topic started by: Rulzern on May 12, 2003, 08:14:08 pm

Title: culling and loading
Post by: Rulzern on May 12, 2003, 08:14:08 pm: What sort of culling does PS use? plain brute force with backface culling? any portal system or summin?

And what sort of loading for the terrain? (ex load everything at start, load dynamically when client turns/moves into areas)

Who is in charge for engine optimization?

Thanks :)
Title:
Post by: Draxzer on May 12, 2003, 09:56:39 pm: About the loading.. I think it\'s loading dynamically... Because when I\'m in game the first time I look at the temple my fps is going way down.. After that my fps is stable.

And I think that the crew of Crystal Space is in charge for the engine optimalizations..
Title:
Post by: Atanor on May 12, 2003, 11:55:41 pm: yup :)

irc.freenode.net #crystalspace

Planeshift devs have nothing to do with the 3D engine ;-p
Title:
Post by: elminster on May 13, 2003, 12:45:22 pm: Quote
Originally posted by Rulzern
What sort of culling does PS use? plain brute force with backface culling? any portal system or summin?

The engine is a portal engine, although the world consists of only a few sectors, see your dir: planeshift/art/world. Those are the sectors.

In addition to backface culling, the system does view frustum and dynamic occlusion culling, and will support dynamic LOD (geometry reduction, images instead of far objects, etc.).

In the future, it is also likely the engine will make use of PVS. Note: the engine does NOT use BSP or octree culling. It is obsolete, dynamic occlusion culling (called dynavis in Crystal Space) is WAY more efficient, just a little more work needs to be done on it, as it is only a few months old...

I am NOT a developer of CS, just on the CS mailing list for some time now...

Greetings,
E.

P.S.: What did you meant by \"plain brute force\"?
Title:
Post by: Rulzern on May 13, 2003, 01:55:17 pm: thanks for the good reply, is the dynamic loading based on viewport or position?

I noticed the huge sectors when getting my head stuck halfway outside the world, could probably earn a bit by reducing the size of the sectors (i could see like half the cave), gonna look into this dynamic occlusion culling, only done good-old occlusion culling before

And by brute-force i meant if like large parts of the world are drawn, with only a very crude portal system.

How will you deal with popping on LOD? and how about world enteties and players? It sure wouldn\'t be good to have people floating over the horizon due to the LOD :p
Title:
Post by: elminster on May 13, 2003, 02:27:56 pm: I don\'t know anything about dynamic loading. I don\'t even know if it is supported or not. Maybe a developer can answer that...

Well, dynamic occlusion culling only has the \"dynamic\" word to show, that you can move, and the engine will determine again what is behind huge objects, and not render those.
Quote
Originally posted by Rulzern
And by brute-force i meant if like large parts of the world are drawn, with only a very crude portal system.

I still don\'t exactly know what you mean... The portal system is based on sectors, a sector is a logical part of the world, a collection of geometry, and these sectors are connected with portal polygons. A sector for example: the temple, the cave. A few of portal polygons are: the temple entrance, the well in the temple.
Quote
Originally posted by Rulzern
How will you deal with popping on LOD? and how about world enteties and players? It sure wouldn\'t be good to have people floating over the horizon due to the LOD :P

Floating???
How has that anything to do with LOD? LOD (Level-of-Detail) will be used to reduce the triangle count of the models, that are far away. If static geometry is REALLY far away, then still images will be used (like a panorama).

Greetings,
E.
P.S. Interesting: http://www.openrt.de (http://www.openrt.de)
Title:
Post by: Rulzern on May 13, 2003, 05:58:12 pm: If you have a hill like this:
###/\\#####
*#_/..\\####
#/.......\\####

it will look like this after a few steps of LOD:

###/\\###
#**/..\\##
##/.....\\##

if a player is on the left part of the mountain in the first level of LOD, he will be floating in the second level of LOD. Unless you have some ?ber-clever way of solving it, you will either have him floating or have him at the wrong coordinates.

The difference between brute-force and a portal system is generally speaking that brute force doesn\'t use any culling, portals or LOD, it just draws all the terrain that is loaded.
Title:
Post by: Cthulhu on May 13, 2003, 06:15:40 pm: Well, but if even the hills (which are quite big, normally :) ) are displayed with a lower LOD, what will happen to the player models?
If a large object is that far away that the engine drops quite a part of it, why should it even care about the entities that are on it and not just kick them off the screen? Also, if it doesen\'t, then you\'ll have to have quite good eyes to still recognize the ten or twenty pixels that the players are.
Or of what distances are you talking here?

/c
Title:
Post by: elminster on May 14, 2003, 01:27:20 pm: Cthulhu: you just posted my answer :)
Title:
Post by: Rulzern on May 14, 2003, 02:31:38 pm: the distance depends on the detail of the terrain, the more detail, the lower distance will be requred before the LOD becomes quite evident, another thing that can happen is that players can be \"eaten\" by small caves that aren\'t visible until the player gets pretty close.

And on the \"why not just ignore the models\" elminister already mentioned the use of billboarding, which almost rules out the performance question of the matter, so there would be no reason for the engine to ignore them.