Large outdoor world compositing tool
-
- Posts: 7
- Joined: Sat Mar 13, 2004 6:56 pm
Large outdoor world compositing tool
hope this is the right forum for this - I know it's technically a project announcement, but I'd like to pick your brains about how to do it before I get stuck in
There's been a lot of interest in making large, outdoor worlds with irrlicht, for which bsp's aren't really appropriate. As I myself am interested in worlds like this, I thought I'd make a tool to create them.
As far as I am aware, a large outdoor world is generally implemented as a heightmap - the terrain itself - with some little bits of geometry stuck on top, such as trees or huts or fences or whatever. I'm thinking of the lovely great big islands in Operation Flashpoint - that sort of thing.
Of course, loading a heightmap and then loading tree meshes and repeatedly calling setPosition for each one to build up the level is a pain in the hole, and can't be done WYSIWYG-style. So, the tool I intend to make is essentially a compositing tool, where you can adjust the position of meshes you've made yourself as you might in a 3D modeller, and then export your arrangements to a file which can then be read in and the world you arranged recreated from it.
The idea is:
- you'd create, texture etc all the models which you want in your gameworld as you would any other mesh
- you'd also create your heightmap and the texture(s) you want on it
- you'd then use Outdoor to load the heightmap and meshes and arrange them so that they're all in the right place, and export your arrangements to a file.
- to use it, you'd call a LoadOutdoorFile function (which I would write as well), which will read in the arrangement file and add all the meshes and heightmap and everything into the scene manager, all in the right places - basically doing the exporting stage backwards.
What I'm interested in is:
1) Is this how large outdoor worlds are/can be done?
2) Would this be useful to you?
Cheers
There's been a lot of interest in making large, outdoor worlds with irrlicht, for which bsp's aren't really appropriate. As I myself am interested in worlds like this, I thought I'd make a tool to create them.
As far as I am aware, a large outdoor world is generally implemented as a heightmap - the terrain itself - with some little bits of geometry stuck on top, such as trees or huts or fences or whatever. I'm thinking of the lovely great big islands in Operation Flashpoint - that sort of thing.
Of course, loading a heightmap and then loading tree meshes and repeatedly calling setPosition for each one to build up the level is a pain in the hole, and can't be done WYSIWYG-style. So, the tool I intend to make is essentially a compositing tool, where you can adjust the position of meshes you've made yourself as you might in a 3D modeller, and then export your arrangements to a file which can then be read in and the world you arranged recreated from it.
The idea is:
- you'd create, texture etc all the models which you want in your gameworld as you would any other mesh
- you'd also create your heightmap and the texture(s) you want on it
- you'd then use Outdoor to load the heightmap and meshes and arrange them so that they're all in the right place, and export your arrangements to a file.
- to use it, you'd call a LoadOutdoorFile function (which I would write as well), which will read in the arrangement file and add all the meshes and heightmap and everything into the scene manager, all in the right places - basically doing the exporting stage backwards.
What I'm interested in is:
1) Is this how large outdoor worlds are/can be done?
2) Would this be useful to you?
Cheers
Re: Large outdoor world compositing tool
I would just use a for loop to create the mesh, not repeatedly call it for each vert.BiggerStaff wrote:Of course, loading a heightmap and then loading tree meshes and repeatedly calling setPosition for each one to build up the level is a pain in the hole
-
- Posts: 164
- Joined: Wed May 05, 2004 5:34 pm
- Location: Germany Berlin
- Contact:
-
- Posts: 7
- Joined: Sat Mar 13, 2004 6:56 pm
That's the idea
Yeah - that's the idea. Using Irrlicht's GUI stuff, obviously. You spawn your objects and then move them around with a 3D widget (like in Maya, for instance), until you're happy with where they are. The other nice thing about it will be that looking at your world in Outdoor will take the up more or less the same amount of system resources as it will in your game (as it's using the same engine, scene manager structure etc) so if it's too big or too complex, you'll know about itLordNaikon wrote: do i place the tree's or fences or what ever with a gui like drag & drop?
That tool would be exactly what I need. In fact I was thinking about writing something that would probably do the stuff you described in more or less the same way.
I am absolutely sure, many people, including me of course, would be extremelys grateful for such a tool and might even contribute the best they can.
I am absolutely sure, many people, including me of course, would be extremelys grateful for such a tool and might even contribute the best they can.
Hey guys, I'm making a general purpose world editor, I call it FreeWorld3D. I'm fixing to release a beta version of the program, hopefully by the end of this week if I can finish everything that needs to be done. It will be shareware, so it won't be free, but it will be cheap. I know how many people have been looking for a tool like this, so I've spent a lot of time and effort trying to create a tool that is easy to use but has a lot of functionality. You can check it out here http://cs.selu.edu/~soconnell
I have screenshots and 2 videos in the media section.
I have screenshots and 2 videos in the media section.
1) Is this how large outdoor worlds are/can be done?
In Morrowind, the terrain is split into grid cells, so that each cell can be loaded/unloaded independantly as you move along.
In other games, you have loading zones.
And in others, there is only one huge terrain, but it has a limited size.
2) Would this be useful to you?
Depends if its open source or not. There can never be "one level editor for all games".
If I was going to use your editor, it'd be to save me time programming the same thing - the 3D interface that lets you place objects and store their positions.
And it'd also be because I could do things that are specific to my game; add certain properties to the objects, insert gameplay info, etc.
If I can't add features to your program that are specific to my game, then I'd have to make my own one to do it, and I'd have to re-create the 3D interface anyway. So I may as well make my own, especially if I didn't quite like the way you made the interface.
In Morrowind, the terrain is split into grid cells, so that each cell can be loaded/unloaded independantly as you move along.
In other games, you have loading zones.
And in others, there is only one huge terrain, but it has a limited size.
2) Would this be useful to you?
Depends if its open source or not. There can never be "one level editor for all games".
If I was going to use your editor, it'd be to save me time programming the same thing - the 3D interface that lets you place objects and store their positions.
And it'd also be because I could do things that are specific to my game; add certain properties to the objects, insert gameplay info, etc.
If I can't add features to your program that are specific to my game, then I'd have to make my own one to do it, and I'd have to re-create the 3D interface anyway. So I may as well make my own, especially if I didn't quite like the way you made the interface.
-
- Posts: 7
- Joined: Sat Mar 13, 2004 6:56 pm
Yes - I intend to implement some sort of system for dividing it up so that only local areas are loaded as the player moves around, in the sort of stepping-stone manner you mentioned. That may well be part of the LoadOutdoorFile function which you import into your own project, where you can specify the cell sizes you want to create, rather than baking it into the world in the editor.
On that note, I'm also thinking of adding a 'layering' technique to it, so that some objects can be in smaller cells which are only loaded when you are closer to them. You know in Vice City how buildings are drawn quite far into the distance, but then smaller things like trees and rubbish bins are only drawn when you're quite close? So you're sort of adding in a level-of-detail thing, only with actual objects rather than polycount.
As for specific information, I am going to put in 'markers', which are dummy objects which aren't added into the scene graph or anything, but whose positions are stored in a way you can then get at them in your code. An obvious use would be for start positions or waypoints. But apart from that, obviously user-specified information would be extremely useful, and so I'll find a way of implementing it.
These things are all planned features; the first step is to get the basic system working of being able to load stuff, place it, write it all out to a file and then load the file back in again, which I'm working on at the moment.
Oh and yes, it'll be free and open source and all that - I'm not going to try and charge for it!
On that note, I'm also thinking of adding a 'layering' technique to it, so that some objects can be in smaller cells which are only loaded when you are closer to them. You know in Vice City how buildings are drawn quite far into the distance, but then smaller things like trees and rubbish bins are only drawn when you're quite close? So you're sort of adding in a level-of-detail thing, only with actual objects rather than polycount.
As for specific information, I am going to put in 'markers', which are dummy objects which aren't added into the scene graph or anything, but whose positions are stored in a way you can then get at them in your code. An obvious use would be for start positions or waypoints. But apart from that, obviously user-specified information would be extremely useful, and so I'll find a way of implementing it.
These things are all planned features; the first step is to get the basic system working of being able to load stuff, place it, write it all out to a file and then load the file back in again, which I'm working on at the moment.
Oh and yes, it'll be free and open source and all that - I'm not going to try and charge for it!
Well then it sounds like it's very well thought out, and I'm looking forward to it
I take back what I said about it not being possible to make a "one level editor fits all". I forgot I'm making games in Macromedia Flash, and ALWAYS use the interface as a "level editor", no matter what game I'm designing. It's quite easy, and preferable, to adjust the way things are stored and retreived, to fit in with the existing interface.
Something like this project does need to be done, it just needs to be done well.
Sounds like you're on the right path. Maybe for custom properties, you could store extra information in the XML format or something - each object can have an unlimited number of properties to go with it, you just have to add and name them via the interface. Then you'd need a way of associating a list of properties with a mesh, and storing it somehow, so it can be duplicated - so all your ogres have hitpoints, and all your oilflasks have an oil level, etc.
I take back what I said about it not being possible to make a "one level editor fits all". I forgot I'm making games in Macromedia Flash, and ALWAYS use the interface as a "level editor", no matter what game I'm designing. It's quite easy, and preferable, to adjust the way things are stored and retreived, to fit in with the existing interface.
Something like this project does need to be done, it just needs to be done well.
Sounds like you're on the right path. Maybe for custom properties, you could store extra information in the XML format or something - each object can have an unlimited number of properties to go with it, you just have to add and name them via the interface. Then you'd need a way of associating a list of properties with a mesh, and storing it somehow, so it can be duplicated - so all your ogres have hitpoints, and all your oilflasks have an oil level, etc.
What I think you should work towards, rather than a one size fits all editor is all of you to work in a team towards a template for loading maps, textures and entities. No matter how hard you plan, someone will need something different. For instance, the guys who want a portal type map simular to Spellforce will want to define their maps differently. If you made a sort of template you could all edit it slightly to get the map editor needed for you. Would be cool to get almost a standard map XML type for all Irrlicht games I think.
I say you all rather than us all because what I am doing is a tile based game which would need a drastically different editor to you guys. If someone else is also doing a tile based game then I would be happy to help with them.
I say you all rather than us all because what I am doing is a tile based game which would need a drastically different editor to you guys. If someone else is also doing a tile based game then I would be happy to help with them.
-
- Posts: 7
- Joined: Sat Mar 13, 2004 6:56 pm
Haha! Thought that would get asked sooner or later
Well, I hope to have a basic version up and running in about a week. To my mind, the first stage is actually the most fiddly (cameras, node picking, moving stuff around etc) - all the other stuff such as markers, moving multiple objects and so on is largely variations on the base code. I think it's good to get a basic version out quickly and without too much effort so people can start using it and say what they like and what they don't - that way I don't waste loads of time coding features that no-one wants to use!
Of course, estimating the time is the bane of all computing - if the exact thing hasn't been made before, how can you possibly know, and if it has, why are you making another one?
Well, I hope to have a basic version up and running in about a week. To my mind, the first stage is actually the most fiddly (cameras, node picking, moving stuff around etc) - all the other stuff such as markers, moving multiple objects and so on is largely variations on the base code. I think it's good to get a basic version out quickly and without too much effort so people can start using it and say what they like and what they don't - that way I don't waste loads of time coding features that no-one wants to use!
Of course, estimating the time is the bane of all computing - if the exact thing hasn't been made before, how can you possibly know, and if it has, why are you making another one?