Great. I think it'll be useful for user Cheer!
On Thu, Apr 10, 2008 at 6:11 AM, Souvarine <[EMAIL PROTECTED]> wrote: > Greetings everyone :) > > First my deepest apologies to you soya users, that mail is not directly > related to soya. It is about an experimental project I want to start (no > not a game) and, since I know there is some 3D pros here, I would like > to ask you guys opinion about it. That project would be a C++ library > that does scene management. > > As you know (or not) I wrote the BSPWorld scene manager for soya (and > I'm still working on it). I have been working a lot on scene management > problems. Almost all 3D engine out there comes with some scene managers > into theme. By scene manager I mean some piece of code that can handle > everything that is on a 3D scene (static geometry, movable objects...) > using some specific algorithm to speed up the rendering (most used are > BSP, Octree and QuadTree). But the more I study scene management problem > the more I think that handling scene management into 3D engine is plain > wrong, for severals reasons. So I'm planing to start writing an > independent scene management library that would not be tied to any 3D > engine, and would be potentially be used by any existing 3D engine, > including soya of course. > > Allow me to explain my point. > > First, a scene manager can be useful even without a 3D engine. Take the > example of a networked game with a server and several clients. The > server does not need a 3D engine since it does not display anything > (clients do) but it could use a scene manager to speed up collision > detection, IA, network, etc (I'm not saying that the scene manager > actually does collision detection, IA and network stuff itself, but that > it can be used used by those to optimize by cutting unnecessary > operations). > > Second, scene managers that comes with 3D engines (including my BSPWorld > in soya) are under exploited. Most of the time they are only used to > speed up rendering of scene static geometry, sometimes of movables > objects too and they can handle some basic collision detection functions > like raypicking. But a scene manager based on space partitioning > algorithm can do much much more than that ! It could be used with > physics engine (such as ODE), for sound, IA and more. You can expand > your 3D engine scene manager by subclassing it but that is a lot of work > since you have to understand its internals first. If your 3D engine > comes with several scene managers (for different type of scene) you need > to subclass them all, and once you have you can no longer switch to > another 3D engine if you need to. Modular design is beautiful ! > > Third, scene managers that comes with 3D engines don't provide easy and > complete solutions to the level editing problems. BSP scene managers can > usually load quake maps (those are widely documented on the net so it's > easy) but the possibilities of those are very limited. Nowdays, level > designers prefer to use their faithful generic 3D modeler (3DS, Maya, > Blender, add your favorite here...) than some level editing programs > like GtkRadiant. Although there is some partials solutions, I still > haven't see any system that allow a user to fully design a level in his > favorite 3D modeler (including mesh, physics...) and can then import it, > split it using some space partitioning system and use it with > optimizations. > > For all those reasons I want to make an independent library that does > only scene management and that the user could use for anything he or she > wants. I made some research and I didn't find any similar project. > That's a bit strange I think, maybe I didn't look at the right place. > > That library should have the following features : > > -> can import a 3D level modeled in Blender and extract all necessary > informations from it : mesh geometry, collision detection geometry, game > objects locations (player start points for example) etc. Then it should > be able to split the level using an hybrid space partitioning algorithm > (suitable for both outdoor and indoor scene), and then provide > informations about mesh, collision detection and stuff in a convenient > way for the 3D engine and physic engine the user will choose to use. > > -> keep track of movables objects (player, NPC...) into the level > structure using their position and bounding volume given by the user. > > -> perform various type of query. Your 3D engine could tell the scene > manager where your camera is and how the frustum is and the scene > manager will tell the 3D engine which parts of the level and which > movables are visible and should be rendered. Your physics engine could > tell the scene manager that it is going to perform collision detection > on the some movable object against it's surrounding environment and the > scene manager will tell the physic engine which other objects and which > part of the level geometry might collide with it. > Many other things are possible. For example the 3D engine can ask for a > list of all light sources that can affect the rendering of a movable > object. The IA can ask for a list of all movable objects in the > surrounding environment of a IA driven NPC so it can perform path > planing. The network engine can ask for a list of all movable objects in > the surrounding environment of a player so it can only send that player > informations about movables that are in it's range of view, reducing the > amount of data to be sent over the network. > > -> be thread safe, several thread should be able to perform query at the > same time on the same data. That would be useful especially for server > side usage in networked games. Server developers like to use > multithreading to take advantage of multicore processors. > > So, to those who have experience in 3D development, what do you think ? > Do you know some projects that already does that ? Do you think, like me > that that this approach have potential ? I'm interested in any opinion, > critics or advise you can give me. > > Again, my apologies for that (too) long mail :) > > Souvarine. > > > _______________________________________________ > Soya-user mailing list > Soya-user@gna.org > https://mail.gna.org/listinfo/soya-user > -- Thitipat Donpraiwan (Bent) http://thitipat.wordpress.com
_______________________________________________ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
