Vegetation Earth map

[Volutar]

moriarty, currently you can edit vertices by editing numbers in the bottom of the right panel (enter applies changes). Dragging vertices with mouse I think is possible, but quite hard to implement. And I think become unnecessary with export/import capabilities. Adding new polygons or "knife" tool is slightly harder to do, and without them dragging is senseless

Added: I didn't even tried to make mouse wheel, it works just as trackbar scrolling and depends on does it have focus or not. I will add mwheel capture next time.

[Volutar]

Added vertex dragging (of selected poly only - no multivertex drag)
Plus correct mouse wheel over map part
https://volutar.eu5.org/worlddat.zip

[kkmic]

Can I has snapping too?

[Amunak]

Speaking of vegetation map/earth surface in-game, I've noticed small artifacts that sometimes show (see the screenshot). They are visible mainly in the highest zoom. These two on the screenshot are quite small, but I've seen larger (though I can't find one now).

And another thing - I've noticed that the textures are not moving with the globe (ie. they are "static" relative to the window). It looks really weird (especially while zoomed in and rotating the globe by only little bits). It's the same behavior as in the original xcom, but it looks weird and I think that we could get rid of it. I hope that you know what I mean 

[Volutar]

Amunak, about texture stasis and strange texture "mipmaps" - it won't change until going into opengl. Raw SDL cannot provide 3d texturing.

Speaking about snapping. I believe you mean snapping to neighbor vertex? So, it will require WHOLE vertexes checking. And that will slow down editing and will create situations when there are multiple possible neighbors. Unwanted snapping will require extra "checkbox" to disable it. And all this bothering for coordinates, which already snapped to nearest "integer". I don't think it's necessary, considering you can use integer snapping with max zoom.

[moriarty]

@Volutar: Awesome. This is just awesome.   on some polys I can only select and edit some points, though (one or sometimes two are not selectable at all... the tiny square doesn't even appear when hovering near) - do you have any idea why this may be?

@Amunak: those artifacts are real and the result of slightly incorrect coordinates. look at the screenshot from Volutar's viewer (its really an editor now, isn't it? we should call it that ) - you can see it even more clearly because the line width is less.

[Volutar]

moriarty, yea, I know that. It's only appear in 3d view and related to globe wrapping (If you noticed those polys are around lon=0). I've fixed this in new build. Some dragging bugs are fixed and drag rendering speed increased (I use cached globe image while dragging). I'll upload it in 1 hour.
There is also issue with editing vertices near pole. It's almost impossible to drag them in 3d, because drag work with lat/lon comparison. I need to write workaround for it. (Now you can edit pole vertices only in 2d).

Next thing I probably try to implement is adding/deleting polys.

P.S. Second list at the right is trajectory areas. They are described here.

[moriarty]

ah, okay.

you know what would also be cool? in 2D view add an option to load an image file as background image for reference and turn the rest semi-transparent.

this kind of turns back to the original topic of the thread, because it actually gives us a relatively easy way of making a real-vegetation-adjusted globe

[Volutar]

Background image? I really doubt, because I don't know how to make them transparent. I use GDI blitting, which doesn't have any transparency things. To get transparent background it'll require full refactoring and rewrite. The thing is, it doesn't need to be precise... Do you think someone will complain about forest patch not in the place?

This topic was started without any link to xcomish vectorized globe. So I posted it into "rest" section.

I've uploaded fixed version.

[Amunak]

@Amunak: those artifacts are real and the result of slightly incorrect coordinates. look at the screenshot from Volutar's viewer (its really an editor now, isn't it? we should call it that ) - you can see it even more clearly because the line width is less.

Oh I see it now. So it's just messed in the original xcom data files.

Before you were talking about file format. Why can't we just make our own YAML config with definitions? I think that now it should be even possible to make other shapes than triangles.

like this:

Code: [Select]

Polys:
  - coords:
    - lat: 1234
      lon: 6543
    - lat: 1256
      lon: 4040
    - lat: 2500
      lon: 3800
    - lat: 2725
      lon: 6866
#    ^ this would make approx. a rectangle (4 coord pairs)
    terrain: forest
    zone: Europe
    anything: if some mod can use it...
  - coords:
    - lat: 1500
      lon: 6000
    - lat: 1000
      lon: 2500
    - lat: 2500
      lon: 2500
#    ^ just a triangle
    terrain: woodland
    zone: North America
    ocean-depth: 1

Sure, the file would be longer, but it loads into memory once anyway. We could also have country boundaries/cities in the same file defined in similar fashion. It's just about implementing it and converting the old data.

[SupSuper]

Speaking of vegetation map/earth surface in-game, I've noticed small artifacts that sometimes show (see the screenshot). They are visible mainly in the highest zoom. These two on the screenshot are quite small, but I've seen larger (though I can't find one now).

And another thing - I've noticed that the textures are not moving with the globe (ie. they are "static" relative to the window). It looks really weird (especially while zoomed in and rotating the globe by only little bits). It's the same behavior as in the original xcom, but it looks weird and I think that we could get rid of it. I hope that you know what I mean 

The rendering works behind-the-scenes, but I presume that's the simplest way to ensure the texture goes across seamlessly along all the polygons (or you'd notice the edges).

Oh I see it now. So it's just messed in the original xcom data files.

Before you were talking about file format. Why can't we just make our own YAML config with definitions? I think that now it should be even possible to make other shapes than triangles.

That is the plan, but I only have 2 hands. (also don't think the loading is free, the delay OpenXcom has when pressing New Game is all because of YAML).

Anyways original X-Com (and OpenXcom) already use 3-point and 4-point polygons. You could probably have more points but in pseudo-2D having the world split in tiny polygons makes the rendering easier (and even in real 3D OpenGL, every polygon is technically made out of triangles).

[Volutar]

Maybe I'm wrong, but i think openxcom loads quite slow because of lot of yaml.

[Amunak]

(also don't think the loading is free, the delay OpenXcom has when pressing New Game is all because of YAML).

Maybe I'm wrong, but i think openxcom loads quite slow because of lot of yaml.

Well... You probably don't want to hear this, but... Maybe it'd be better to traverse to some scripting language instead of expensive YAML. I think that having most rulesets as objects in Python would be much more beneficial (though it's not really appropriate for saving polygons). Of course I'm assuming that it would be faster than parsing YAML (though if it wasn't, it's still better to be able to actually script something ). On the other hand, one does not start a new game that often, so it's probably not really a problem. Alternativly there could be a tool to convert nice YAML config to pure binary file(s) similar to what the game uses now.

That is the plan, but I only have 2 hands. (also don't think the loading is free, the delay OpenXcom has when pressing New Game is all because of YAML).

I really wish I could help. I honestly do. Maybe you can find a work for trained monkey?

[Volutar]

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.

[kkmic]

Caching... it's good, I use it all the time (but hey, I build web applications).

The only thing you need to worry about is that you need to plan the whole system carefully, so that you can easily refresh the cache when needed.

Once the planning and implementation are done,  everything else is a breeze.


As for a runtime log.... that's something more than necessary