Re: [Soya-user] External scene manager project, ask for opinion
Souvarine wrote: > I have been told that SketchUp is the only modeler that support > collada natively and properly (don't know if that is true). Even if it is, it's probably only in the version you have to pay for, not the free version (which comes with very few exporters). On the other hand, Sketchup is scriptable in Ruby, so you can probably program it to export in just about any desired format, given enough work. I think there's also a C++ library you can call from external code to read Sketchup files, if you want to approach the problem from the other end. Being able to create scenes for this thing in Sketchup is something I'd be very interested in! > Since you > like SketchUp, can you tell me if it is possible to model a whole level > with it ? Including the possibility to model terrains, put light > sources, place locations and name them, label some parts of the geometry > with specific names ? I've recently been working on a project using Sketchup to create levels for Aleph One (an open source development of the Marathon game engine). I managed to get it to do very nearly everything the Marathon engine supports, all with Ruby scripting inside Sketchup. Ruby code can attach arbitrary attributes to any object in the model, so there should be no trouble naming things. Light sources and such like can be modelled using placeholder objects that are recognised and treated specially by the exporter. There is a set of "sandbox" tools that could be used to edit a terrain mesh. So yes, all those things should be doable with Sketchup, I think. Something to consider when deciding on an export/import strategy is that funneling everything through a common format can lead to loss of information. Some modellers may support things that it would be useful to get into the scene for the game engine to use, but if they can't be expressed in the intermediate file format, you're out of luck. For example, Sketchup has a very powerful notion of component definitions and instances, which can greatly reduce the amount of data needed to describe a scene with a lot of repeated elements. But if the intermediate format didn't support component instances, the game engine wouldn't be able to take advantage of that. -- Greg ___ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
Re: [Soya-user] External scene manager project, ask for opinion
Greg Ewing wrote: > This sounds very interesting, especially the part about > being able to use a variety of existing 3D model formats > as input. Actually it's about being able to handle levels (scenes) modeled with any modeler (at least the most used). Level designers all have their modeler of choice and they don't like to change, it is not a good idea to tell a 3DS pro that he must use Blender instead. That's one of the hard part of the project (but not the hardest I think). There is several solutions to that problem, I haven't done much research on those yet. The best would be to find a standard file format that all modeler can support and implement only that one, sounds like a dream... Unfortunately I'm not sure such a format exist yet. Their is the Collada format that have been made to be a standard but it seems that it is not well handled yet by modelers. Blender have a plugin for it but it seems very incomplete. For 3DS it look like you have to pay to get a collada plugin. I have been told that SketchUp is the only modeler that support collada natively and properly (don't know if that is true). Since you like SketchUp, can you tell me if it is possible to model a whole level with it ? Including the possibility to model terrains, put light sources, place locations and name them, label some parts of the geometry with specific names ? Other possibilities are either to handle several of the most used 3D files format, or to write exporters for the most used modelers. I don't feel comfortable about using non standard file format since they might change with new software version and not necessarily be reverse compatible. Also it look like a basic exporter does not require much line of code. It might be easier to code and maintain severals exporters for the most used modelers than trying to support their file format. Any informations on this would be appreciate. Souvarine. ___ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
Re: [Soya-user] External scene manager project, ask for opinion
Souvarine wrote: > 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. This sounds very interesting, especially the part about being able to use a variety of existing 3D model formats as input. I'll be looking forward to seeing what you come up with! -- Greg ___ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
Re: [Soya-user] External scene manager project, ask for opinion
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 thi
[Soya-user] External scene manager project, ask for opinion
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 o
