Vegetation Earth map

[Tentaculars]

I've read through the thread and i am still not 100% sure what you are trying to achieve.

You are trying to change/modify the earthglobe with new features/visuals ?
What is the current status and how can i possibly be helpful ?

If there are some questions about using Blender i might be able to answer them, but my experience is limited to basic modeling so do not expect to much .

Tentaculars

[moriarty]

Hi Tentaculars!

Well, I was aiming for an improved globe with a little bit more detail... and since Volutar's Globe Editor can export to .obj format, and Blender can edit .obj files, I was looking for somebody with more experience in using Blender.

So basically, if you have the time, perhaps you could take an exported .obj file (see attachment) and make the landmass a little bit more natural-looking (less blocky), without increasing the poly count too much. then we can re-import it and adjust the terrain, giving us earth 2.0 

[Volutar]

Little progress in globe.dat browser here.
Vertex can be selected and deleted. And currently I'm stuck at vertex adding. To add 4th vertex I need to pick one of 3 sides which is to be "splitted". And I'm kinda fail with that. Currently I'm using distance to line segment, and it doesn't work for cases when you're trying to put 4th vertex beyond one of corners, it's the case when distances to edges are equal. I need to use some technique to avoid self-intersected polys.

[Tentaculars]

Hi Tentaculars!

Well, I was aiming for an improved globe with a little bit more detail... and since Volutar's Globe Editor can export to .obj format, and Blender can edit .obj files, I was looking for somebody with more experience in using Blender.

So basically, if you have the time, perhaps you could take an exported .obj file (see attachment) and make the landmass a little bit more natural-looking (less blocky), without increasing the poly count too much. then we can re-import it and adjust the terrain, giving us earth 2.0 

What are the limits ? If there are any it is important to know them. Increasing detail decreasing blockiness is sometimes possile if the model is realy worse organized. In this case i dont see how i can improve detail without doubling/trippeling the polycount. Best way would be to simply redraw the continents with a more smoother look. In theory we could give mountains f.e. a physical height if we push up the polycount. Some work and i am not sure if this would be beneficial at all for the game itself. As for more detail we ask, the more it comes into conflict with the current used ingameresolution. 320x200 it is, i think - and thats pretty few pixels.

But for sure there are questions remaining that might be important for reimporting to openxcom.

As you already said:

a) the Meshes seemed to be grouped into zones - is this somehow relevant for the game ?

b) what kind of texture resolution supports openxcom ? does it support animated textures ?
   There are no materials importet with the OBJ File. Materials = visual information for surfaces. Are they shiny, glossy shadeless, what color do they have - do they use textures and so on.

[moriarty]

a) the Meshes seemed to be grouped into zones - is this somehow relevant for the game ?

b) what kind of texture resolution supports openxcom ? does it support animated textures ?
   There are no materials importet with the OBJ File. Materials = visual information for surfaces. Are they shiny, glossy shadeless, what color do they have - do they use textures and so on.

the meshes are grouped by in-game terrain type. each terrain has its own texture for in-game purposes, but it's assigned by a value in the original .dat file, which has been converted into a "group membership" by Volutar's converter.

so for now, all we can do is edit the shapes, and then change polys to new terrains using Volutar's editor.

the shape needs to be 2d, which is then pseudo-wrapped into a spherical earth by the game. I don't think that actual height is supported before the whole thing is changed to opengl hd rendering in V1.0+++

the screen is limited to 320x200, but the globe can be zoomed, so there are a lot more details possible and visible.

I'm not sure as to how high the poly count can go without noticeably increasing the CPU load for rendering... I guess it's "try and find out"

[Volutar]

After "delete vertex" I finaly made "add vertex" tool properly (it shouldn't make ugly self-crossed polys). Still no add/delete poly.
Uploaded new version.
Select poly with LMB, after - select vertex, and "delete" to remove (you can even remove all vertexes). "insert" key - inserts vertex (at cursor position). Cursor keys - move selected vertex coord.

Speaking of "accurate" globe lines.. Did you know that UFO never had Sulawesi island done properly? Alright. Now you know! I don't know who's responsible for this, but 583 and 584 polys are identical. And there is a hole where it shouldn't. Obviously this is mesh error, which NOONE have noticed before:). Do you think people will notice if you made less obvious mistakes? I doubt it.

[SupSuper]

I don't think any scripting language will help until it be using all of data pre-loaded. And text->bin conversion should happen at game starting stage. At the moment I believe it converts data to usable form each time when this data requested. And I'm not even sure it pre-loads this config (Yeah, like, each time it opens file, parses it and gets ONE variable).

Not only new game started too slow, but saved game loading too. Application also starts with kinda delay. Is there any logging? It might be helpful to find delay reason. Logging is the first thing each application should have.

Don't exaggerate, all data is pre-loaded, accessing everything as requested from disk would be insane.

This is veering off-topic, but to clarify:
- At application startup, all resources are loaded into memory (graphics & audio) and kept until application terminates, as well as a whole bunch of setup done. That's all the time when you see the initial "Loading..." screen. Battlescape also does some resource loading itself on start/end.
- When you select a language (or memorized from Options), this is loaded into memory and kept until application terminates.
- When a new game is started, ruleset is loaded into memory and kept until that game is terminated. That's all the time the game "hangs" when you press New Game. It is not loaded at startup because in the future rulesets will be more modular and different games can be using different rulesets. New savegame is then created in memory when a difficulty is selected.
- When a game is loaded/saved, ruleset and savegame are loaded into memory and kept until that game ends.

Yes this might be slow, unoptimized, unefficient, crappy, maybe I'm just doing it all wrong, whatever. Right now the goal is functionality, not performance, and YAML was chosen because it's incredibly easy to implement, modify and debug which is what we need at this stage. When the goal changes then we can look at all the million formats and all the possible solutions to make OpenXcom leaner and meaner, if you wanna look into this topic yourself that's up for you.

[Volutar]

It wasn't nice when some continents become torn apart. So I've made a longitude shift in order to make map wrapped nicely.
In-editor X coordinates are shifted +1360 units. When saving world.dat - they are shifted backwards, so nothing should be corrupted.
And obj exported/imported files are also treated as shifted. (uploaded)
Poly delete/add is the next feature.

Added: BTW, moriarty, though I can't get semi-transparent background with globe image, I still can try to draw opaque image... when some "alt" key pressed. I thought it could be even more useful than semi-transparent, because semi-transparent images one over another often obscure - you may not identify which part is background and which - foreground. Only grid line over "background" alternative should be helpful.

[Volutar]

Implemented add/delete poly. When no poly is selected, "insert" key creates 1-point poly at cursor, and next "insert" adds next vertex to this poly. So creating poly is a simple action of: deselecting, pressing "insert" multiple times for each vertex.
New poly added at the end of list.
After deleting poly other polys moved up through the list.
Implemented "poly drag" - extra vertex (it looks like single pixel at the center of selected poly). You can select it and drag whole poly with mouse or cursor keys.
Tab/Shift+Tab switches through selected vertex.
Escape - deselect poly.
No multiselect. And I doubt it will be implemented, since it's too complicated.

Next thing I will be thinking of - is "slice poly" tool. My vision of it: select poly, tap "slice" key, and "draw" a line of slice. After releasing LMB selected poly will be splitted, and both of them are deselected.
Also I'm planning to implement simple undo (limited levels, since I'm planning to save whole globe after some time after each action);
(New version uploaded)

[Daiky]

So you can now edit the globe without going via another 3D modeling tool? That's cool. Does it work with TFTD too?

Also, there are more textures than terrains, so maybe it is interesting for people wanting to create new terrains to see which ones are being re-used.
Unfortunatly, they are still hardcoded: (they need to go into rulesets really soon)

Code: [Select]


switch (_worldTexture)
{
case 0:
case 6:
case 10:
case 11:
{
if (_ufo != 0)
{
if (_ufo->getLatitude() < 0)
{ https:// northern hemisphere
_terrain = _game->getRuleset()->getTerrain("FOREST");
}else
{ https:// southern hemisphere
_terrain = _game->getRuleset()->getTerrain("JUNGLE");
}
}
else
{
_terrain = _game->getRuleset()->getTerrain("FOREST");
}
break;
}
case 1:
case 2:
case 3:
case 4:
{
_terrain = _game->getRuleset()->getTerrain("CULTA");
break;
}
case 5:
{
_terrain = _game->getRuleset()->getTerrain("MOUNT");
break;
}
case 7:
case 8:
{
_terrain = _game->getRuleset()->getTerrain("DESERT");
break;
}
case 9:
case 12:
{
_terrain = _game->getRuleset()->getTerrain("POLAR");
break;
}


[Volutar]

Daiky, yeah, I'm going forward to avoid external editing tool. I guess it will be fine even on vertex-by-vertex base
TFTD uses same world.dat, though different "color coding". And it looks weird
You can even drop "world.dat" into openxcom data/geodata folder and watch what happen.

Really we can get hundered textures for globe. The only thing is making some sort of "lut" which will convert texture into particular type battlescape zone. What you've made right now - is crude hardcoded texture->terrain case statement. And obviously it should be replaced with something more flexible. With ruleset YAML chunk, for example.

Look how TFTD globe look like with UFO1 colors. If you notice - there are LOT of overlapped polys, And I believe number of polys can be reduced without any flaw.

[Volutar]

Another update.
Slice implemented, though it's only "alpha slice" so may be buggy (for example - slicing going through a corner vertex can create unpredictable results - to be fixed).
Enables with checkbox or hotkey "s", and poly must be selected (todo: change cursor)
Cutting 1 corner from quadrangle should create triangle and 5-angle, but we can have maximum 4 angles, so 5th angle will be lost
I don't know how to get a workaround for this case, probably "cutting" is not the worst:)

[Volutar]

Slicing through corner vertex is fixed (or at least should be fixed - if there will be strange results - msg me).
Undo/redo implemented!!! (50 levels). Undo levels are shown at status bar.
Though undo is quite silly - it stores whole globe after modifying action is ended (with some pause).
Will upload in 1 hour. uploaded
Is someone interested?

I guess it's time to rename it to Editor
Done, also "knife" cursor added (hotkey "s").

Random areas is not shifted (as map), so it can't be anyhow reliable

[Volutar]

Experimenting with globe texture as background in 2d mode.
Added "fast'n'ugly" stretch-blitting. It should work fine when image is not shrinked.
Note - there is some geographicsl anomaly ... some islands are not where they should be...
"Load BG" is button for loading of background files. I suggest you to edit background in editor to get it better colors.
Switch "show background" can be triggered with mouse, and with "shift" key (temporary inversion of mode). I think this is much useful than just trigger.
Note - since I cannot render semitransparent things, so I just skip polygon fill an draw only contours.
When zoomed-out with background rendering might become very slow. (It really depends on bg image size).
Number at the right of "BackGND" is texture visual offset for "longitude" (in order to fit geography). Also you can prepare background image to fit this number.
RandomZones also fixed (shift'n'wrapped) and should fit geography nice (so you can adjust geography position not to get cities in teh ocean).

I'll upload it later...
Uploaded as usual: https://volutar.eu5.org/worlddat.zip

Added: Fixed error while "undo" slicing.

[moriarty]

very nice, volutar!

see, we're back to where the thread started... now we can actually go and make a geographically-correct globe 

I still wonder how many polys we can use before performance on the geoscape will drop noticeably... I guess we'll find out...