Author Topic: Scene .SCO Toolset - heightmap converters, object placers, and texture importers! Oh my!  (Read 23527 times)

0 Members and 1 Guest are viewing this topic.

cmpxchg8b

  • Modder++
  • Count
  • *
  • Master of rglPool
    • View Profile
  • Faction: Vaegir
  • MP nick: cmp
  • M&BWBWF&SNW
I don't know why I expected something less arcane,... and full of hacks.
In my experience the majority of hacks are a result of the code being modified over time; however, even a small change to the generation algorithms can result in a completely different terrain, so I assume that code has remained largely unchanged since the early days of Mount&Blade...

Swyter

  • Grandmaster Knight
  • *
  • »Star Wars Conquest Dev Team Leader
    • View Profile
    • [my tiny homepage]
  • Faction: Swadian
  • MP nick: Sareth | Swyter
  • WBM&BWF&S
I don't know why I expected something less arcane,... and full of hacks.
In my experience the majority of hacks are a result of the code being modified over time; however, even a small change to the generation algorithms can result in a completely different terrain, so I assume that code has remained largely unchanged since the early days of Mount&Blade...

That surely means that "Mount&Blade 2: Revamped: Look my Graphics" isn't going to be compatible at all.
And, it's me or the code base started from a DirectX 9 SDK tech example? I mean, look at the menus :)

xenoargh

  • Grandmaster Knight
  • *
    • View Profile
  • Faction: Neutral
Quote
In my experience the majority of hacks are a result of the code being modified over time; however, even a small change to the generation algorithms can result in a completely different terrain, so I assume that code has remained largely unchanged since the early days of Mount&Blade...
Yeah, it works (on most hardware) and it's straightforward (if a bit inefficient here and there) so why bother writing a new one from scratch?  Totally understandable.  It's not how I would have designed it, personally, but then again, I wouldn't have kept Warband tied to the outdated Pixel Shader 2.0 specification, either.  That's always a tough call for game developers, though; go too far ahead of players' hardware and you can get badly burned.

Quote
That surely means that "Mount&Blade 2: Revamped: Look my Graphics" isn't going to be compatible at all.
They've already said as much; no more Module System (which I for one think is a really good thing) and presumably a lot of the guts are going to get reworked.  I suspect it will be pretty much a new engine in a lot of ways.  The success of Warband has hopefully given them plenty of funding to spend their time reworking the critical areas :-)

Even more OT:  I am a little worried about what their new body system's going to mean for people wanting to develop content for it, but that's a bridge that will have to get crossed when / if they start discussing how it works and how modders can build content to work with it.

cmpxchg8b

  • Modder++
  • Count
  • *
  • Master of rglPool
    • View Profile
  • Faction: Vaegir
  • MP nick: cmp
  • M&BWBWF&SNW
And, it's me or the code base started from a DirectX 9 SDK tech example? I mean, look at the menus :)
Yes, even Armagan said that in a post.
I'm not sure what version of DirectX, though... like, why is FFP mode called DirectX 7 if there isn't a single line of DirectX 7 code? Maybe they used DirectX 7 before updating the graphics engine, but I haven't really checked.

Disgrntld

  • Regular
  • *
    • View Profile
  • Faction: Neutral
It was kind of a pain to fill out the mission_object_t structs so I added a matrix transformation API similar to OpenGL. However, I believe it's limited to affine transformations as we don't transform the vertices ourselves but rather define a frame for the Mount&Blade engine to transform them later. Since this frame is non-homogeneous, I think all projective transformations are lost in place_object. If someone who can math better than me would clear that up though, I'd really appreciate it.

Anyway, here's the link and some examples:

Colosseum -
(click to show/hide)
(click to show/hide)
(click to show/hide)
(click to show/hide)
Jousting lanes -
(click to show/hide)
(click to show/hide)

Swyter

  • Grandmaster Knight
  • *
  • »Star Wars Conquest Dev Team Leader
    • View Profile
    • [my tiny homepage]
  • Faction: Swadian
  • MP nick: Sareth | Swyter
  • WBM&BWF&S
*Raises eyebrows*

Let's recap: soo, you've made a extremely detailed procedurally generated coliseum using your own wrapper around scoUtils in a way we can easily make all kinds of great creations, something that wasn't even proposed in the six years of existence of Mount&Blade. And you are asking for help with 3D math.

I sincerely doubt I can help you there, mate. Let me know if you need CSS for the manual :)


Small digression: Somebody should tell Marco (mtarini) about this, it would be great to have map editing capabilities within OpenBRF.

Imagine, the app already mimics the game's asset loading, parses the text files, displays well most part of the shaders. We can already walk in first person using the appropriate camera mode, there are only a few parts missing, implement the TerrainGen class, add the scoUtils, some menus, implement a gizmo-like object handling in the 3D view, and some logic behind all that.

Bingo. You've a realtime usable scene editor and a handy previewer out of the game.

xenoargh

  • Grandmaster Knight
  • *
    • View Profile
  • Faction: Neutral
Yeah, that's kind of what I've been thinking, too.  And it would eat a lot less RAM than doing it in the in-game editor.  The only wrinkle is that auto-generated flora wouldn't be displayed, but that's very minor edits.  If it could manipulate the AI mesh, which has got to have a pretty simple data structure... well, that would sure beat working for 45 minutes on a Scene only to have the engine crash, which has happened to me more than once...

The procedural stuff is really great; I think it's necessary to test performance for that stuff vs. single meshes, though.  But an auto-city generator that laid out a set of buildings from a text file list of Scene Props or BRFs, for example... that would be a power tool!

Swyter

  • Grandmaster Knight
  • *
  • »Star Wars Conquest Dev Team Leader
    • View Profile
    • [my tiny homepage]
  • Faction: Swadian
  • MP nick: Sareth | Swyter
  • WBM&BWF&S
Yeah, that's kind of what I've been thinking, too.  And it would eat a lot less RAM than doing it in the in-game editor.  The only wrinkle is that auto-generated flora wouldn't be displayed, but that's very minor edits.  If it could manipulate the AI mesh, which has got to have a pretty simple data structure... well, that would sure beat working for 45 minutes on a Scene only to have the engine crash, which has happened to me more than once...

I was thinking more about using Recast for generating the navigation mesh for us:
http://code.google.com/p/recastnavigation/

You know, having a pretty optimized AI mesh in seconds for every scene in your module.
Does it sound tempting enough?

xenoargh

  • Grandmaster Knight
  • *
    • View Profile
  • Faction: Neutral
That would change everything, frankly.

It's one of the primary reasons I have to keep my time budget for level design really small.

Disgrntld

  • Regular
  • *
    • View Profile
  • Faction: Neutral
:lol: Thanks for the kind words, Swyter, but I'm still ignorant about a lot of the gory, projective space details. Specifically, I was trying to transform the stairs in the colosseum example into more of a trapazoidal shape so they would fit without gaps. As it stands, I just plugged the holes with barriers. :|



xenoargh, I agree, performance might suffer if we get too overzealous with objects. I haven't looked into generating BRFs that much because I don't know if we can add them to existing mods (which is what I'm interested in)? Also, that Recast sounds very close to what you were looking for with the AI mesh stuff! If I have some free time I might try to dive into mtarini's BRF domain and see how Recast might fit into all this.

xenoargh

  • Grandmaster Knight
  • *
    • View Profile
  • Faction: Neutral
The main issue with objects is that collision detection involves a fair amount of brute-force checks; the engine handles fairly large numbers of static objects pretty well but it is a concern.  If the NW patch really deals with the LOD4 issue (sorry that may be a needlessly opaque digression) then one of the major performance issues with city battle scenes (namely, overdraw) is removed, and it's down to pathfinder costs and collision objects.  Can't do anything about the former, which is already fairly efficient, if a bit, er, dumb, but the latter remains an issue that hasn't really been experimented with a lot, in terms of testing real-world impact with a bunch of Agents and missiles flying around.

cmpxchg8b

  • Modder++
  • Count
  • *
  • Master of rglPool
    • View Profile
  • Faction: Vaegir
  • MP nick: cmp
  • M&BWBWF&SNW
The only wrinkle is that auto-generated flora wouldn't be displayed, but that's very minor edits.
That can be arranged.

Barabas

  • Master Knight
  • *
    • View Profile
  • Faction: Neutral
  • MP nick: Bassa Bar
  • WB
In case anyone is interested, I made a .sco to .obj converter. It's only a first attempt, but I thought I'd share anyway :)

(click to show/hide)

[spoiler = Nevermind, fixed it! :)]
I've been trying to make a correct 3d mesh for the terrain using the terrain-key and sco file as inputs. However, the sco code is in c which fails to compile in visual studio and the terrain-key code is in c++ which fails to compile in my MinGW setup. I mainly have problems with the GNU compiler complaining about multiple definitions of functions in Utils.h. I sort of understands why, because it compiles all the object (.o) files seperately and then tries to put them together to make an executable. And all these object files have definitions of these fuctions. But how the hell do you fix this? It's driving me nuts.[/spoiler]
« Last Edit: May 28, 2012, 01:15:16 AM by Barabas »

Barabas

  • Master Knight
  • *
    • View Profile
  • Faction: Neutral
  • MP nick: Bassa Bar
  • WB
No idea why the engine calls it leveling, possibly remains of something older. It's actually the color layer, and you have to parse cells as unsigned ints (AARRGGBB) instead of floats.

This doesn't work in the current implementation. I'm not exactly sure why not, but an easy fix is using an union with a float and unsigned int and detect when to assign the integer.
« Last Edit: May 28, 2012, 11:24:16 AM by Barabas »

cmpxchg8b

  • Modder++
  • Count
  • *
  • Master of rglPool
    • View Profile
  • Faction: Vaegir
  • MP nick: cmp
  • M&BWBWF&SNW
Whether you cast or use an union is exactly the same thing, if one didn't work you probably made a mistake in the code...