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
