OpenXcom Forum
OpenXcom => Fan-Stuff => Topic started by: Volutar on July 25, 2012, 06:48:53 pm
-
Project GLC2000 provides hires info of Earth surface.
40320x16353 pixels sized tiff file with quite precise info of surface type.
I think such info could be helpful when you want to create realistic ufo-like geo->battlescape transition.
Picture in example is shrinked
-
at last, we could shoot down ufo and fight in city :)
-
Good catch.
However, this should be a post v1.0 modification.
-
post 1.0??
I see this could be used for totally different project... with colored hi-res textured globe:)
-
at last, we could shoot down ufo and fight in city :)
8)
Actually, there is no City Map in X-com. There isn't any multi-storey building.
-
post 1.0??
I see this could be used for totally different project... with colored hi-res textured globe:)
I thought the v1.0 goal was to have a close recreation of the original UFO (with some improvements), not a totally altered game... yeah, I like the 'pixelized' look of the old games :)
TBH, I would LOVE to see such a detailed globe in OXC. I would also love to have a "modern "OXC with updated high-resolution graphics, while keeping the same original core gameplay. However, like I said, I feel that these are updates that belong to the post v1.0 OXC.
-
Question ( sorry for going off topic to your original Post volutar) , How is the Globes graphics and Landmass made up? Would it be possible for a unskilled person like me to change Earth to another planet (different colours, different regions, different land-water mix), this would most likely not be for a x-com spin off , i am thinking something more along the lines of Necromunder ( not a direct clone but similar in style , Gangs fighting it out for supremacy).
https://en.wikipedia.org/wiki/Necromunda
Maybe have it change throughout the gaming experience , Ice Ages or Global Warming maybe :P
( I am not asking for it, i just want to know if/how i oneday could do this)
-
that is a very good question, I think. afaik, the globe is made up from irregular triangles, and each triangle has a defined "terrain", which determines how it looks on the globe as well as the kind of ground mission terrain spawned, right? so in order to change the globe (not just the terrain, but the layout), you would have to entirely re-define the triangles... which is really too much trouble, right?
ah, I looked around in the globe.cpp and stumbled upon the reference to the UFOPaedia, which contains the necessary information, I guess...
https://www.ufopaedia.org/index.php?title=WORLD.DAT (https://www.ufopaedia.org/index.php?title=WORLD.DAT)
I'm going to read this and see how much I can understand :P
EDIT: for personal reference: https://volutar.eu5.org/worlddat.zip (https://volutar.eu5.org/worlddat.zip)
-
It's not technically complicated, WORLD.DAT is just a huge list of triangles, which all come together to form the landmass (or the ocean in TFTD). It'd just be an incredible pain to edit by hand, unless you're really good at visualizing coordinates. :P
-
yep, that's what I figured out, too :) maybe someone really skilled at programming could make a visual editor...? that would be really nice. :D
If I was able to do it, I would change the globe to a true geodesic sphere with much higher triangle count, and build a program that lets you paint it while looking at it in 3D... if I was able. :(
-
It's not technically complicated, WORLD.DAT is just a huge list of triangles, which all come together to form the landmass (or the ocean in TFTD). It'd just be an incredible pain to edit by hand, unless you're really good at visualizing coordinates. :P
coordinates you say , would i be able to export this data into a CAD package , that is where i really shine :D
-
I was developing software for viewing world.dat file and posted it on the forum(->here (https://openxcom.org/forum/index.php/topic,156.0.html)). Editing feature was planned, but become unneccessary after Yankes' shading was implemented. Because main idea was lessen polygon granularity in order to improve land shading. And now, when there is no ugly polygon shading left, adding more details while keeping 320x200 is little out of proportions. Default world.dat have 666 polygons, and each of it projected and processed each frame, though back-side polys are skipped for drawing. Really I dont like how it made, but it work for that detail.
-
How much extra work would it take to add the EDIT functionality, and would we be able to then make a NEW planet or is something else still required for that?
-
luke83, edit functionality will be quite hard, though, it's possible to make some kind of converter dat->obj, obj->dat, in order to edit it within any cad/3d edit program supporting obj files. I was stopped only because of surface type assignation in obj file. I suppose it should be done as color coding? Polygon conversion is a piece of cake, but surface types is not that easy.
-
Volutar, could you add a function in your viewer that lets you change the surface type of a selected polygon and write that to the file? If we have that plus a converter to .obj, we can change everything, right?
btw, what would openxcom do if we provide a world.dat file with more than 666 surfaces? would it run just as fine? because then luke83 could create a completely new planet without any problems. except for nation borders and cities, of course, but that's another story... :)
-
polygon globe data is only visual part, and as you said-not the only.
there is also border line data. plus it has country data and zonal data and trajectory data. part of trajectory data is city data. also mission data. making new planet will require alot more work than you thought. i havent even thinking of all data which should be altered for new planet.
-
I asked about a converter with BombBloke and he has asked for a example CAD file, i don't know if this is the best direction to be going but to me it sounds reasonable. Please note , i have had no promise that he Will create a solution , he is simply looking into it.
I to am curious what will happen with different size worlds ?
Also my next thought leads to multiply worlds ( Mars or the Moon).
As usual just wanting to know what we can and cant do ::)
-
okay, wait.
world.dat :
1) polygons for visual. can be edited by converting world.dat to .obj and back. check.
2) terrain information. no editor yet, but shouldn't be all that hard, should it?
3) zone information. no editor yet, but shouldn't be all that hard, should it? (see https://www.ufopaedia.org/index.php?title=ZONAL.DAT (https://www.ufopaedia.org/index.php?title=ZONAL.DAT) - the zones just manage alien attack priorities)
border info : where is that stored and in what format? no editor yet.
country labels were hardcoded in geoscape.exe, so I believe they are hardcoded now, too, right?
trajectory data? what exactly does that do?
-
luke83, world.dat with polycount more or less than 666 will be okay. openxcom will load and render them all.
moriarty, border info is hardcoded into XcomResourcePack.cpp. I think SupSuper will externalize it eventually.
country labels and city names are externalized.
trajectory data isn't implemented. I've posted my findings into same topic with my world.dat viewer link.
VEry funny, that some dude from https://ufopaedia.org made same "discovery" after almost 1 year :)
-
I asked about a converter with BombBloke and he has asked for a example CAD file, i don't know if this is the best direction to be going but to me it sounds reasonable. Please note , i have had no promise that he Will create a solution , he is simply looking into it.
I to am curious what will happen with different size worlds ?
Also my next thought leads to multiply worlds ( Mars or the Moon).
As usual just wanting to know what we can and cant do ::)
Technically yes you can make your own planet, it's just a matter of putting all the relevant data together in a better externalized / editable format. Planet size is hardcoded but could probably be tweaked.
This is all the info relevant to the Geoscape planet:
- Landmass: The polygons that form the planet you see, defining what counts as "land" (for building bases, landing UFOs, doing missions, etc.) and its respective terrain for crash sites. (currently loaded from WORLD.DAT, to be moved to ruleset)
- Details: Superficial stuff like border lines, country labels, etc. (currently hardcoded and in ruleset)
- Countries: The nations that fund you and what parts of the map affect them (currently loaded from ruleset).
- Regions: The areas of the world that correspond to each region, which affects graph data and alien AI (currently loaded from ruleset).
- Cities: The points in the world that correspond to cities, which are targeted by certain missions (currently loaded from ruleset).
- Trajectories: The paths that UFOs take when performing missions (not implemented yet).
-
Distance units defined in nautical miles (nm) should be changed to something else, because by definition, nm is 1' by equator line, and no matter how big globe is - equator length will be 360*60=21600 nm. In this case if your base will be established on 2 times bigger planet, your "nm" values should be scaled.
obj format specs (a sort of): https://www.fileformat.info/format/wavefrontobj/egff.htm
I'm trying to get my world.dat browser export/import this format.
-
does anyone else think that large parts of this thread should now be split apart and put into a separate thread "geoscape globe improvements" ? 8)
things that are emerging from this:
- when Volutar finishes his "world.dat <-> .obj" - converter, we could increase the poly count to make a nicer earth
- if Volutar could add terrain/zone editing capabilities to his extraordinarily cool globe viewer tool, that "nicer earth" would even function properly :P
- of course, this would also be the first step towards making a TFTD-globe... and even a combination, which would be super-sweet...
- should we change the distance units used in-game? I'm not sure. nautical miles did historically come from 1' at equator line, but were precisely defined as 1,852 metres, so the same unit could be used for larger or smaller planets (or astronomical bodies of any kind). how exactly does the game handle these units? does it measure everything in angles or does it use 3d spatial coordinates?
-
I didn't found OBJ editor which can edit groups... They all seems to be ignoring materials and groups.
-
I have sent Bombloke some example DXF files, maybe they work better
https://docs.google.com/open?id=0B4Vlb6e97KHSQnZ1OUZBbktlSnc
You should be able to do everything you need in a free CAD package like QCAD for those who don't have a copy of autocad floating around.
-
What is this DXF file? Never heard of it. There should be textual graphics format, which includes polygons and groups.
-
Well honestly i dont know if it the BEST file for the job but it a standard format in CAD package 2D and 3D. I don't pretend its computer game related, but its used in industrial settings. The Link i made has a picture of Australia taken form your program and draw into a DXF format. Bombbloke was going to see IF it sufficient format ( i asked him after you said it was to much work).
https://en.wikipedia.org/wiki/AutoCAD_DXF
IF you look at the pics , one is a Screen shot from your software , other is my auto cad drawing saved into DXF format. Each Triangle has a enclosed Polyline ( starts and ends on it self) creating a separate object. The thought was maybe this would be a possible way to graphically change the map. Rember i am not a computer wizard so if this wont work that is fine :P
-
Well I don't need any pictures - I need specs for reading and writing.
Obj specs are here : https://www.martinreddy.net/gfx/3d/OBJ.spec
Where can I find similar description of dxf? And is it capable of handling mesh groups?
I've updated my world.dat browser and added obj export (though useless, because there's no nice editor, and no importer), surface assignment and coordinate edit abilities (text editing in memo box, hehe - enter applies changes). WORLD.DAT written by "save" button at the top.
-
Hmm now your dragging me out of what i know , i use the graphical interface ;)
Most of the below means nothing to me ::)
https://usa.autodesk.com/adsk/servlet/item?linkID=10809853&id=12272454&siteID=123112
https://images.autodesk.com/adsk/files/acad_dxf0.pdf
-
I've looked into specs, and found it too complicated. I refuse to use this format. I need simple text format, like obj. With nice specs and examples.
-
Well i am out of ideas :(
Just found a convertor that loads your .OBJ and converts to my .DXF
"SYCODE Mesh Converter v1 0 DC012011-BEAN
Description
Disks: 4 x 2,88mb Date: April 9, 2011
OS: Windows Type: Patch
Release Description:
Mesh Converter is a software to convert between various mesh file formats
Mesh Converter also has a batch conversion tool which can be used to
convert multiple mesh files at once
The supported file mesh file formats are:
AutoCAD DWG
AutoCAD DXF
3D Studio 3DS
Rhinoceros 3DM
Stereolithography STL
Wavefront OBJ
Vizualization Toolkit VTK
Google SketchUp SKP"
Most likely NOT WHAT you want ;)
-
luke83, if there won't be any chances to keep surface groups (tags), we dont need this format. Any mesh editor which can handle obj import/export will be fine with that. Obj format does have grouping, but i havent found nice obj editor which will keep these groups.
And anyway, editing polys near meridian_zero (greenwich) will be quite a pain, and there's no format which can ease this.
Unless we start to export and import globe as projected 3d sphere, not 2d map, and unproject it into world.dat.
-
blender (www.blender.org) appears to be able to load and edit .obj files. I have a little experience with blender... I'll look into it.
-
okay, it loads and displays nicely. apparently the surfaces have been grouped by terrain type...
is that intentional? scratch that, of course it is, that's what you were talking about, right? so it appears to work :)
-
blender... ehh.. never understood how to start doing something in it... useless buttons and empty screens... not for me :)
moriarty, I'm glad you managed to.. load exported world.dat into blender, right? Can you export same file into obj and send it? I have to compare what I need to change in obj importer.
BTW, I want to implement exporter/importer sphere projected land mesh.
-
with blender it's quite easy to alter the surfaces. I played around a bit and changed the shape of new zealand's northern island, attaching it to australia... now all I need is something to convert it back to globe.dat - volutar? do you have something that does this?
btw, volutar, great job on the terrain editing funtion for your viewer... that's precisely what I thought of. simple select and click-to-change. perfect!
you know what would be nice? the current geoscape globe handling makes a difference between land mass and water by defining land as "there's something" and water as "there's nothing". If we could change that to water being just a different terrain type (or rather, several different water terrain types), we would be one step closer to combining UFO and TFTD... but of course, that's V1.0+ again... although a globe with different ocean zones of different colors would be kind of nice even now.
(Attachment: globe.obj with modifications, just for proof-of-principle)
-
Volutar, here's the globe.obj file loaded into blender and re-saved. I get two files from that, one .obj and one .mat - I guess the latter contains the material information.
-
moriarty, thanks for zipped exported globe.obj.
First. I haven't written obj importer since I didn't know what to import... Every editor have different obj importer/exporter. Blender importer/exporter as I see splits mesh object with number of groups into number of objects without any groups. So I guess I have to write importer, that wouldn't be able to import its own files without blender exporter :)
The thing is.. it alters group names g1->Mesh.006_g1 g2->Mesh.005_g2 g4->Mesh.003_g4.
can you control this or it's something automatic?
I guess it is. Can you modify those object group names?
-
I don't know if the group names can be changed... maybe they can, but I cannot. :-\ My experience with blender is somewhat limited, there's a lot of "hidden" features that you can only access with key combinations.
Anybody else on here that knows more about blender? luke, didn't you say you are in contact with somebody using it?
EDIT: I've sent a message to Tentaculars, he appears to know a good deal more about blender than I do :)
-
Latest build is here:
https://volutar.eu5.org/worlddat.zip
Added obj import and it also imports groups as named objects (also tested with original xcom). Mesh names shouldn't be changed. They are decoded as "*gNN" (skips everything before "g" and treats next decimals as surface number).
When obj file is loading - it measures its Y size and uses it for scale factor (i.e. you can scale object - it doesn't actually matter).
Near pole mesh edit still is a pain :).
P.S.: Export also changed - it scales coords with 1/32 in order not to make object too big. And groups replaced with named objects (as blender exports them), so you can import own obj file without blender :)
P.P.S.: Mesh names can be changed (in the hierarchical object list at the right), but they really shouldn't, or they lose their surface link when importing into 'world browser'.
-
Awesome work , now i need to work out blender, such a strange program to learn ;)
-
OK this question will get me screamed at but i will ask anyway , is there any way to modify the world.dat whilst playing? I am thinking changing terrain types due to natural disasters , nuclear explosions or even Alien terrraforming activities, Obviously these are not for a standard Xcom game :P
-
OK this question will get me screamed at but i will ask anyway , is there any way to modify the world.dat whilst playing?
Not right now. People are just now figuring out how to modify it with external programms, while not running.
It could be added, if you find someone interested in programming it. But that is definetly stuff for after 1.0.
-
There's no need of modifying file. You may modify mesh data while game progress. Though if you try to move vertices, you may get very ugly results, like terror mission in the city which happen in the ocean, or ufo landed in the ocean (which normally doesn't happen, though I've seen once). If you want to get terrain change, like getting whole Earth frozen (spreading of ice surface) - that will be piece of cake. The only thing is that you need to save whole earth into savegames too.
-
Luke83: ooh, alien terraforming activities... I like the path this is taking :)
Volutar: awesome. Just one thing: your mousewheel zoom is backwards :) at least, when compared to the way it's used in xcom.
you know, if your viewer now allowed us to move vertices, it would be the perfect world editor. just sayin' 8)
-
Awesome work , now i need to work out blender, such a strange program to learn ;)
It's not a waste of time to know how to work with blender, and if you're good at it, you can start to make 3d models of aliens and ufos and stuff :p
-
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.
-
Added vertex dragging (of selected poly only - no multivertex drag)
Plus correct mouse wheel over map part
https://volutar.eu5.org/worlddat.zip
-
Can I has snapping too? :D
-
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 :D
-
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.
-
@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.
-
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 (https://openxcom.org/forum/index.php/topic,156.msg2122.html#msg2122).
-
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 :)
-
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: 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:
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.
-
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 :D
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. :P (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).
-
Maybe I'm wrong, but i think openxcom loads quite slow because of lot of yaml.
-
(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. :P (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 (https://www.youtube.com/watch?v=rWVGupqvCL8&t=0m12s). Maybe you can find a work for trained monkey? :D
-
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.
-
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 :)
-
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
-
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 8)
-
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.
-
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 8)
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.
-
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"
-
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.
(https://upload.wikimedia.org/wikipedia/commons/thumb/1/16/Sulawesi_map.PNG/220px-Sulawesi_map.PNG)
-
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. :P
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.
-
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.
-
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)
-
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)
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;
}
-
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.
-
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:)
-
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 :)
-
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.
-
very nice, volutar!
see, we're back to where the thread started... now we can actually go and make a geographically-correct globe 8)
I still wonder how many polys we can use before performance on the geoscape will drop noticeably... I guess we'll find out... :P
-
Probably about 5 thousands will be enough and won't be any noticable.
About editing - I know what exactly needed to make it more comfortable. Drag of "multivertex" (which belongs to number of adjacent polys). Probably I will add it, working like usual dragging but with for example "ctrl" modifier (only for selected polys).
Added: Done. Multi-Vertex drag work with mouse (+ctrl) and with cursor keys. BTW, I've made it work at edge of wrapped polys (after dragging at one side - polys become modified at other). In 3d mode near-pole editing works fine with this multivertex drag. It doesn't work if no poly/vertex selected.
Next possible thing is... last state save/load (including background image path and offset), temporary editable globe.dat, and custom colors for terrain types and "ocean". In other words - various configs.
-
hmmm... I tried some editing, and it appears that after I loaded a background image, the editor is no longer able to save anything... any idea what's going on there?
-
I don't know. I have "world.dat" saved pefectly no matter loaded background image or not. Aren't you have world.dat file locked?
New version coming, and it will get custom colors (from world.cfg config) and editor state saved on exit (2d/3d page, selected poly/vertex, checkboxes, background image, camera zoom and position) - already done.
Also I will try to get it working with globe.tmp and saving globe.dat only by button. In order to clear temp changes - just delete globe.tmp, and it will be created from globe.dat on start. Also I'll try to get UNDO data saved (!!!) on exit. So you could be able to exit, restart, and undo last changes :) But this is next todo.
-
nope.
I can open world.dat, edit it, save it, no problem.
Then I can open world.dat, load a BG image, edit something, save it, and it just doesn't save. the file simply isn't written to disk. ???
-
New version uploaded. UNDO isn't saved. Implemented config file with terrain color customization (it's possible to add more terrain colors, though it limited by window size). temporary world.tmp autosave on exit. executable become twice larger :) sorry.
moriarty, it would be more interactive if you visit irc.
Added: implemented undo save/restore.
Next todo: Implement poly order altering (move up/down) and "sliced" polys should be inserted, instead of added at the end. The only thing is - I don't know how to determine where I should insert new poly (in the list), considering insertion is possible when there is no poly selection (so "insert after selected" is illogical).
-
New version uploaded. Now it stores and restores undo buffer (up to 50 actions).
-
Nice job.
Question: what's the purpose of "randomsites.dat"?
-
That's extracted hardcoded info for mission trajectories and cities.
I've described it here (https://openxcom.org/forum/index.php/topic,156.msg2122.html#msg2122).
In short - it's a part of what SupSuper mentioned as "geoscape AI". 10(loc)x6(stage)x12(zone)=720 globe square areas (lat,lon,width,height), which used to generate new geolocation-waypoint of UFO trajectory.
Slightly "alternative" info about it is in here (https://www.ufopaedia.org/index.php?title=Talk:GEOSCAPE.EXE#Ground_patches).
-
Upcoming update:
Sliced polys are inserted where original poly was (keeping order in poly list).
New poly added where selected poly was last time (at focus rect in list).
Up/Down arrows change order of selected poly.
Optional "save undo" checkbox, for those who don't want to save relatively large undo file.
Minor bugfixes.
Uploaded
-
very cool, Volutar!
there are two things I would like to see, if it is possible:
- ability to save the 2D grid as an image file
- ability to see the terrain in the "transparent" view with the background. perhaps make the lines a little bit thicker and draw them in the appropriate color?
that would be really nice :)
-
1. 2d grid? with what resolution? isn't prn.scr not enough?
2. Isn't "shift" not enough? I hardly imagine how can I draw double two-sided lines...
-
printscreen is nice, but I have an earth image that isn't properly adjusted vertically. to make it fit better, I need some kind of reference, and low-res screenshot is not really enough... but that's just me, so I guess it's not really "needed" :)
I totally missed the shift-key part. that should be enough, of course. thank you! :)
-
Okay. If image is too large - it can fail with rendering (I need to deeply change background rendering to get large images rendered).. Equator line should be right at the center. So if you have texture 1024x1024 you should check if equator is at y=512.
https://en.wikipedia.org/wiki/Equirectangular_projection
You can even use map from this article, but beforethat you better to get rid of borders, because they will be treated as land and whole map wouldn't be in place.
this one:
https://en.wikipedia.org/wiki/File:Whole_world_-_land_and_oceans_12000.jpg
is too big :) I can't rener such large images. Though downscaled to 8000x4000 it worked as background well.
-
I've checked combined world.dat from here (https://www.strategycore.co.uk/forums/topic/9751-ufo-tftd-combo-mod-beta/) and found they're using alot of overlapped polys. They've chosen terrain=0 as ocean and added ocean layer under land layer (648 quads covering whole earth). Instead of rendering ocean as it was in original they've replaced it with "ocean" textured underlying land. Quite smart idea, though xcom doesn't have any optimization for overlapped graphics - it just draws everything over everything as it is. But who ever notice that with modern CPU power?.. 1315 polys total, 648 quads.. among those 648 there are lot of quads, which aren't visible, because totally covered by land polys... which means they've added this ocean layer with script, without any looking into what they've got.
My editor didn't work fine with overlapped layers (with LMB poly select it selected first poly in list under cursor), but now I made it select underlying polys by cycle, from most foreground to most background (when clicking in the same place with overlapped polys).
I'll upload new version later.Uploaded
-
I've added editor info into here
https://www.ufopaedia.org/index.php?title=User:Volutar#World.dat_editor
-
Dont suppose the Source Code for this Application was ever uploaded somewhere ? I just tried exporting the world data into blender, slicing everything up as a test and reimported it successfully but the new regions don't appear to have DATA ( on the Sidebar on the right, there is no Numbers for them) and i dont know how to add them to the list...
-
So the community has grown alot since this topic first went around, Anyone thinking about ways to do a Random World? Would be nice to offer support on this globe for modders and realtime changes ( terraforming, add cities to geoscape so i can crash my ufo there, destroy a city and have a new map type) one day...
-
This project looks very interesting for the Terrain Pack - I'm currently creating new terrains for all Geoscape textures and I've already felt the need to redesign the Geoscape for better correspondence between the textures and the terrains.
However, is there any idea of when it will be possible to define use a new, modified, WORLD.DAT on the ruleset? Otherwise the modified WORLD.DAT would have to replace the original file, which I prefer not to do.
-
Since Volutar's link is no longer valid, I have reuploaded the World.dat editor here (https://openxcom.org/forum/index.php?topic=11932.0) (with supSuper's permission).
Volutar, if you have an issue with that, please let me know and I will remove it.