How about a MM GUI-driven map generator?

[Big Daddy Jim]

It would sure be nice to have a GUI-driven MM map generator. I've been able to generate 15 new maps and associated mini-maps using custom-generated C-code and 'mas' hand-tweaking. But it would really be super if someone would take the binary-database info that I have and transform it into a GUI interface.

Perhaps Mike, Grayface, and myself could 'join forces' and get this done.

Mike?

Grayface?

BDJ

[Talin_Trollbane]

you mean like, doing new maps in MM6, for example?

or just a random landscape generator?

[mkienenb]

It would sure be nice to have a GUI-driven MM map generator. I've been able to generate 15 new maps and associated mini-maps using custom-generated C-code and 'mas' hand-tweaking. But it would really be super if someone would take the binary-database info that I have and transform it into a GUI interface.

Perhaps Mike, Grayface, and myself could 'join forces' and get this done.

Mike?

Grayface?

BDJ

Well, I didn't want to get anyone's hope's up since it is still early, but do you mean something like this?





Greyface is already helping me with it. So is Angel Death.

This is a couple of week's worth of work so far. The foundational framework can load most of the resources from directories of extracted resources.

This is a completely different approach than I used with the first editor. That editor was more of a decoding tool. I'm probably beyond the need for such a tool now. That tool tried to work with generic objects, one resource at a time.

This tool is geared at specific targets (MM6Project is the first one, MM7/8Projects would be added later) with no guessing what something is. The entire project structure is loaded at one time rather than pieces here and there. Every item is something the tool specifically expects in a certain place and format.

I actually have a draft email to you still sitting in my Drafts box to request any information you have compiled while creating TCC and the M7 Mod that I might not have Many things I now completely have decoded (99% accuracy)

[mkienenb]

I won't promise this will all happen right away, but the platform I'm building it on is perfect for this type of project. It already provides every api you'd want for an editor, including built-in tutorials


Here's another open source level editor project using the same techology:

http://farm4.static.flickr.com/3099/280 ... cfdc7f.jpg

http://sourceforge.net/project/screensh ... _id=144749

http://images.google.com/images?hl=en&c ... i=&start=0



Here's a slightly different use of the graphics engine allowing real-time terrain editing (this is a trivial example program).

http://pub.admc.com/pts/

specifically,

http://pub.admc.com/pts/terrainrunner-p ... M&param=-t

[quote]
SimpleGame: Interactive HillHightMap with editable Elevations and Textures* Keys to use are listed on the screen.

* Numpad + - to elevate or excavate
* Numpad * to texturize
* _ to smooth/flatten
* ,.[] keys to adjust editing parameters. The m value shown is magnitude). r is brush Radius. Set magnitude to 1 to completey flatten terrain. Set tex# to -1 to restore the default (dirt) terrain, 0 for grass, 1 for snow.

Notice that the elevation-derived texturing is applied dynamically and automatically as you alter elevations, and that interactive edits override that texturing behavior, as it should. Automatically persists and loads changes to/from binary .ser file. To reset, delete the following file in your temp dir: TerrainRunner-<USERNAME>.ser. The saving is done very efficiently: We save only precisely what has been changed. Make changes and check the size of your .ser file.
[/quote]

[GreatEmerald]

How does the editing work? Per vertex/edge/poly? Since it would be very easy to use greyscale heightmaps for importing something like that.

[mkienenb]

It's very flexible.
It can take height-map data from any source.

Since I actually contributed the ImageBasedHeightMap class back in 2004 to jME, that's certainly one possible source we can support

[mkienenb]

How does the editing work? Per vertex/edge/poly? Since it would be very easy to use greyscale heightmaps for importing something like that.

Not sure I completely answered your question. Since MM works completely on height map data (also with normal vectors for MM7, not sure about MM6--my 3d graphic skills are poor, and I'm still figuring the graphic stuff out), we probably would limit the editing to changing the height map and normal at that grid location. Not much point in allowing anything finer since the engine won't support it.

[Lord13]

All these sounds very interesting. Although I didn't understand
most of them...haha. Thanks for your hard work, I wish I had
the knowledge helping you. Cheers!

[mkienenb]

All these sounds very interesting. Although I didn't understand
most of them...haha. Thanks for your hard work, I wish I had
the knowledge helping you. Cheers!

Be careful what you wish for.
You might not be able to help by decoding file formats or programming 3d views, but we have plenty of work to go around

I can use people to write tutorials to use the editor.
I can use people to replace the default graphics for the required game pieces (like the title page, screens, player animations)
I can always find something for you to do

[GreatEmerald]

Not sure I completely answered your question. Since MM works completely on height map data (also with normal vectors for MM7, not sure about MM6--my 3d graphic skills are poor, and I'm still figuring the graphic stuff out), we probably would limit the editing to changing the height map and normal at that grid location. Not much point in allowing anything finer since the engine won't support it.

What do you mean by "changing the height map and normal at that grid location"? If you import the data via heightmap, and you want to edit it without changing your initial heightmap in a graphics editing program, whose height can you change - vertices, edges, polys? I'd assume vertices - but in that case, doesn't it take a really long time to fine tune all the vertices by hand? Or can you manipulate several vertices at the same time?

I've used some terrain editing tools before, and I have to say that there are a few nice tools in Unreal Engine 2: you have a sort of brush that has a radius, and you can literally paint mountains - every vertex in the radius gets elevated up depending on how close it is to the centre of the brush. Furthermore, there is a Flatten tool that makes the vertices the same height as the centre of the brush is - very useful for areas where you need to place buildings, roads and such, although it creates steep hills. Then there is a smoothen tool - makes all the vertices in the radius of the brush closer to their height (I guess that would equal to the flatten tool if its strength was increased to 100%), and the noise tool that creates random bumps on the ground for it to look more realistic.

Just throwing some ideas

[mkienenb]

Not sure I completely answered your question. Since MM works completely on height map data (also with normal vectors for MM7, not sure about MM6--my 3d graphic skills are poor, and I'm still figuring the graphic stuff out), we probably would limit the editing to changing the height map and normal at that grid location. Not much point in allowing anything finer since the engine won't support it.

What do you mean by "changing the height map and normal at that grid location"? If you import the data via heightmap, and you want to edit it without changing your initial heightmap in a graphics editing program, whose height can you change - vertices, edges, polys? I'd assume vertices - but in that case, doesn't it take a really long time to fine tune all the vertices by hand? Or can you manipulate several vertices at the same time?

I've used some terrain editing tools before, and I have to say that there are a few nice tools in Unreal Engine 2: you have a sort of brush that has a radius, and you can literally paint mountains - every vertex in the radius gets elevated up depending on how close it is to the centre of the brush. Furthermore, there is a Flatten tool that makes the vertices the same height as the centre of the brush is - very useful for areas where you need to place buildings, roads and such, although it creates steep hills. Then there is a smoothen tool - makes all the vertices in the radius of the brush closer to their height (I guess that would equal to the flatten tool if its strength was increased to 100%), and the noise tool that creates random bumps on the ground for it to look more realistic.

Just throwing some ideas

The only thing you can change is a 128x128 height map, the tiles mapped to it, and the normals assigned to those "squares" formed by the height map values. I guess you'd call it vertexes, but I don't think it's an exact match to what you're saying.

The engine itself then generates vertexes, polys and all that good stuff based on that data. So you don't get to directly work with the 3d objects.
This is a game released in 1998 Graphics wasn't at the same state that it is now

Basically you manipulate four vertex influencers each time you change the height map value. But not the vertexes themselves. Each heightmap square influences four vertexes. And each vertex is influenced by four height map squares.

But yes, the plan is that you'll be able to click on the terrain, and then raise or lower it. Or use some kind of mountain brush

I don't know how close we will come to emulating the exact 3d result that the MM engine creates. Probably pretty close if someone other than me is working on the 3d graphics Not so close for me, although it's getting closer with each iteration

And of course, I could be completely wrong. AngelDeath is really the expert in this area.

[GrayFace]

As far as I can tell each height map pixel controls height of a single vertex.

[mkienenb]

As far as I can tell each height map pixel controls height of a single vertex.

Yes, it's quite possible I made it more complicated than it really is.
Maybe the heightmap[x,z] is the vertex rather than the point between heightmaps.

But the result is the same. The x,z values of the vertex are fixed. So your only options are changing the height map (y) value.

[GreatEmerald]

Hmm, what coordinate system does it use? Y is up or Z is up?

[mkienenb]

Hmm, what coordinate system does it use? Y is up or Z is up?

There is a 128x128 grid of height values.

so Map(x,z) = y with y being up.

[mkienenb]

Hmm, what coordinate system does it use? Y is up or Z is up?

There is a 128x128 grid of height values.

so Map(x,z) = y with y being up.

In reality, it's arbitrary. Most of the time in the old MM8LevelEditor, I called the height coordinate z since it was the third one listed. Now I call it y because the 3d library I'm using treats up as y

[Big Daddy Jim]

Hmm, what coordinate system does it use? Y is up or Z is up?

There is a 128x128 grid of height values.

so Map(x,z) = y with y being up.

In reality, it's arbitrary. Most of the time in the old MM8LevelEditor, I called the height coordinate z since it was the third one listed. Now I call it y because the 3d library I'm using treats up as y

In the overland map system, the MM7&MM8 display engine assigns Z as the height parameter, with X&Y being the standard horizontal and vertical axis. It is implied that MM6 does this also.

BDJ

Seven Days and Counting ......

[mkienenb]

I have now created a document to describe how to get the MMLevelEditor (without an 8 -- not sure if we should come up with a better name) project up and running in its current form.

http://mm8leveleditor.cvs.sourceforge.n ... ctions.txt

This is not a release or even a preview. This is for those who would like to help develop the editor.

But if you're a non-programmer, and you still want to help, here's an opportunity. You can go through the process and let me know if there's any errors in the instructions Note that this is currently an involved process.

[mkienenb]

Another area for non-programmers to help is to categorize all of the icon files in the icon.lod for MM6 (I'm specifically targeting MM6 for the first milestone of the project -- I don't expect MM7 and 8 will be much more difficult, but the slight differences in file formats would unnecessarily complicate things to start). Some of these are required for the game to work. Some of them are only necessary for certain maps (I think -- I might be wrong about this). Some are only necessary for certain player choices (like player face animations, equipment dolls).

For example, I did the pcx files a couple weeks back:

<game interface screens>

JVC.PCX -- produced by screen
MM6TITLE.PCX -- title screen without menus
Title.pcx -- title screen with menus

LSAVE640.PCX -- load game selection screen
Border2.pcx -- party interface graphic border
Border1.pcx -- control interface panel

Makeme.pcx -- party creation background
Seg_scrl.pcx -- segue ("transition into") image which scrolls down to start location
Segue_bg.pcx -- image of start location

loading.pcx -- load game screen
womover1.pcx -- left-section animation 1
womover2.pcx -- left-section animation 2
demover.pcx -- right-section animation 1
demover2.pcx -- right-section animation 1

WINBG.PCX -- win game background
LOSEBG.PCX -- lost game background

Drag5.PCX -- 2nd load screen? unused?
Smokover.PCX -- 2nd load screen animation? unused?



Eventually, I would like to replace every required file with a freely-distributable contribution from the community. This is a low priority goal, but it will take a long time to achieve.

At that point, a "Create New MM6 Project" will work without having any LOD files

[GreatEmerald]

MMLevelEditor (without an 8 -- not sure if we should come up with a better name)

Enroth Level Editor? Horizon/Labyrith Level Editor? * Resource Editor?