Bloodpass Warband Map Editor

Users who are viewing this thread

bloodpass

Veteran
Download link
http://www.mbrepository.com/file.php?id=3051


Finally, we can call this a true map editor.
I'm sure there are still some features that would be nice to have, but I think I've taken this editor far enough to be genuinely useful to those with a basic or better modding skill level.
  • Terrain painting, including water->land or land->water (see known issues below)
  • Basic terrain morphing (raise/lower terrain, leveling)
  • Movement/rotation of module_parties.py objects for settlement and bridge changes (requires module system know-how)
  • Multiple rendering modes and a brand new native user interface
  • Basic vertex editing (it'll be tedious for huge changes, but this will let you do things like smooth out a coastline or fix up land features to look nicer)
  • Updated rendering engine libraries (so anyone who had issues running the previous version may have better luck this time)
  • A config.ini file to customize a few things like window size/position, and the names of files used to load/save
  • As of 1.1 - Basic, experimental Viking Conquest support. See the mbrepository post for more info on 1.1 changes.

uefZZoE.jpg

eddU3u2.png

ScF3r8A.png

tPuchvx.jpg

uBDRZEK.png

lGUWeVs.jpg

fpDZZO8.jpg

eVDdyOe.jpg

WcNudDP.jpg


Download link
http://www.mbrepository.com/file.php?id=3051

 
Bloodpass said:
-Movement and placement of "stuff" on the map, such as towns or spawn points
This is what I think would be most practical *currently*. (Particularly in conjunction with the numerous Wings3D obj-to-map converters out there ex. http://www.mbrepository.com/file.php?id=1839 which allow you to use a full featured 3d modeler to modify the map's shape and terrain.) Of course I'd need to switch gears from 3d stuff to editing module files, and I've NO idea what the complexity/difficulty of doing this is yet.
IMO it's not so important, as you can get coords from edit mode and type them into whatever files. On the other hand, while trying to provide editor compartibility with txt and module system, you would need to go through a whole bunch of hurdles

Bloodpass said:
-Terrain "painting" (basically you should be able to paint rivers, plains, raise/lower land, and so on without worrying too much about polygons!)

-More "3d-modeler" type features, similar to what's currently implemented with the vertex positioning, more practical features to create/delete/reshape polys, retexture large areas at once, change terrain height, etc.
Not at the top of the list since we have stuff like Wings3D to do this now... but this would include quad-based modeling instead of the more difficult triangle-based.
Specifically, you might want to concentrate on getting map look as close to ingame one as possible. Meaning terrain texture placements, terrain shader lighting, snow patterns on mountains. It's a major pain to recheck all the edits ingame, and correct them when it occures that mapeditor and game show things differently.

After that, I'd say one of crucial things (and simple to code in) is edge operations - tesselating and flipping
 
-To begin with--does it start up at all (the .bat files, java, etc.)?
Yes.

-Compatibility testing with various Windows OSes (32 vs 64 bit, 7/Vista/XP)
64bit. Windows 7.

-Performance testing (there's always room for improvement here but it should be "acceptable", I hope)
Slow. Lags somewhat with map1.txt. CPU usage 50%! (Intel i5).

-Bugs/crashes - stability testing
Non so far.

Hope this helps.
 
GetAssista said:
Bloodpass said:
-Movement and placement of "stuff" on the map, such as towns or spawn points
This is what I think would be most practical *currently*. (Particularly in conjunction with the numerous Wings3D obj-to-map converters out there ex. http://www.mbrepository.com/file.php?id=1839 which allow you to use a full featured 3d modeler to modify the map's shape and terrain.) Of course I'd need to switch gears from 3d stuff to editing module files, and I've NO idea what the complexity/difficulty of doing this is yet.
IMO it's not so important, as you can get coords from edit mode and type them into whatever files. On the other hand, while trying to provide editor compartibility with txt and module system, you would need to go through a whole bunch of hurdles

Actually, module system support would really increase productivity speeds, and it really wouldn't be that difficult. Just read the python file, create objects to store the data, and rewrite when you're ready to save/commit changes. Don't worry about dynamically editing the file.
 
GetAssista said:
Specifically, you might want to concentrate on getting map look as close to ingame one as possible. Meaning terrain texture placements, terrain shader lighting, snow patterns on mountains. It's a major pain to recheck all the edits ingame, and correct them when it occures that mapeditor and game show things differently.

Really?  I'll have to play around with this in game a little to see what the deal is there.  I didn't know that was a major issue.  Unfortunately getting a truly accurate representation of what the game is going to do might be pretty difficult.  (Does Thorgrim's editor do a good job there?)  I've used three 3d engines, all for different languages, and the fundamentals are the same but there can be some big differences with how they're used and how they behave.  Getting one to emulate any quirks or specifics that come naturally in another engine could be hard.  (Won't stop me from trying at some point.)

"Will this map editor support new terrains in the future?"

I don't believe it's possible, those are currently hard coded into the game afaik.

Performance - Can anyone else confirm or provide info about the performance on their machines so I can tell whether this is widespread?  I don't see 50% CPU or notice any major lagging, but I'm on a somewhat decent PC.  It could be a hardware specific thing I guess (in which case that sucks), but it's more likely that I could be doing something better.  This should be using the GPU (like any 3d game, it uses hardware accel so it can't run on a laptop without a decent graphics card), but I know some 3d engines like Papervision (for Flash) may only work on certain cards at the moment.

"This will make the world a better place."
-And hopefully, if Bioxx or myself can pull it off, a more interesting place!  :grin:

Thanks for feedback so far!
 
Also, regarding performance, if any 'sluggishness' is happening briefly when first holding down an arrow key to navigate (a slight delay after the first 'jump') - that's your operating system's key repeat delay. There are some ways around that if it's truly hated, but just don't confuse that for performance.  Doing a little experimenting now to see where the performance bottlenecks are.
 
First off, I should say nice work. The iterations of my editor that I've worked on have never really gotten past the rendering stage, so you're beating me there. Your library seems to scale well across multiple cores, I have a 6-core AMD and I noticed it using several of them. Obviously that won't help with ppl with dual cores so I can't comment there. The camera system is my only complaint, it's slow to respond and difficult to navigate around. Something I'm curious on tho, I show 14 distinct textures when I look in the map file, however I notice that you only have 7 in your textures folder. Just wondering if there was a reason that you don't do the others.
 
I've actually found some performance bottlenecks that might hurt on an older system (now fixing that is on the todo list), so I think performance should be able to be upped quite a bit once I figure out that issue, even though at least on my system I don't notice any show stoppers.

14 vs 7 textures - well AFAIK M&B isn't using a different texture for every terrain type.  The "forest" terrains seem to just be regular terrains with the game adding in some 3d trees, "deep ocean" seems to be just the regular ocean texture and I guess the game is doing something texture or shading wise in real time.  I haven't focused too much yet on getting an accurate (other than being able to distinguish different terrains) representation of the game's texture, because the prospect of getting it just right seems like it could be difficult. (You might have better luck than me on this front.  Especially if the engine you're using is the exact same M&B uses - no idea if that's public knowledge or not.)  I know there's a few things the game seems to do that isn't simple texture mapping, like the snow on mountains and the animated river textures.  I still have some work to do to better understand what the game is doing to render that map.

Also, I could only find the 7 textures in M&B's resource files (the actual ones the game has are much larger, and are BMP format), and I wanted to focus on actually getting something 'working', so that's what I stuck with for now.

Camera is pretty minimal right now, and the slow response is likely your OS keyboard repeat delay - I just confirmed that the repeat delay setting does control that initial scrolling on my pc.
 
Personally, could care less if it's a good representation of the vertex shaders used.  I honestly think it's more important that it can deal with arbitrary mesh imports so that we can build terrain from heightmaps and optimize it elsewhere, etc.
 
That's not too hard really, but do you know about the obj to map converters out there?  I have a Java based converter (link is in my first post here) that's confirmed to work w/Wings3D and a few other modelers, and there's a few others out there as well on the repository.  For the short term at least you should be able to get that done using those converters.  (Obviously since I already have the code done I'll eventually add .obj support here.)
 
OBJ support would be just fine with me; just saying that I'd rather build map geometry with something else, then bring it in and do a final editing pass there.  It's a shame that editing locations of things is such a pain, in terms of code complications; I'd much rather edit it all in one place.
 
xenoargh said:
Personally, could care less if it's a good representation of the vertex shaders used.
It's because you are not yet at the stage where general shape of map is done, all parties are placed, and one arrives at the possibility of making finer improvements for map features. Inability to see how things will really look ingame in the main bottleneck together with inability to tesselate/flip individual edges.

xenoargh said:
  I honestly think it's more important that it can deal with arbitrary mesh imports so that we can build terrain from heightmaps and optimize it elsewhere, etc.
You can convert obj>map for like 3 years, and map->obj for like 3 months already, there are converters out there
 
GetAssista said:
inability to tesselate/flip individual edges.

Could you explain a little more about this and why it's something that's needed?  Not saying it isn't, but I'm not sure I fully understand what you're getting at.
 
Back
Top Bottom