Author Topic: Technical side discussion  (Read 164941 times)

spectre1989

  • Minion
  • **
  • Posts: 38
Re: Technical side discussion
« Reply #500 on: December 10, 2018, 01:05:02 PM »
Another thing - there are some (< 100) external geobin defs which aren't in defnames.

By "external geobin def" I mean I have a group in a def with a name like "path/to/something/defname". If I chop off the "defname" bit and search in defnames.bin, I'll usually find an entry there with is_geo flag false (makes sense, it's a geobin), and the file name will be something like "path/to/something/something.bin".

So, like I said, there are a bunch that just aren't in there. However, given "path/to/something/defname", I can just look in "path/to/something/something.bin", which seems to work. It's just that sometimes a geobin folder contains multiple bin files. I dunno, feels like these are broken references which are actual bad data, so I'm not sure whether to bother attempting to fix them like this!

Anywho, onwards..

Codewalker

  • Hero of the City
  • Titan Network Admin
  • Elite Boss
  • *****
  • Posts: 2,740
  • Moar Dots!
Re: Technical side discussion
« Reply #501 on: December 10, 2018, 09:43:29 PM »
Now the thing I'm wondering is - can a def have the "obj" field set (therefore having a model), as well as having child groups which also have models etc? Should be easy enough to find out.

Yes. The primary use case for doing this is 'trays' - indoor sections that are only rendered while you're inside them. Conversely, while you're inside one, the outside world is not rendered.

The top-level group will use an Obj that acts as the container geometry. For things like offices and sewers, this is often a single mesh of the ceiling, floor, walls, etc. Other styles like Arachnos bases use a solid black box with holes cut out for door connections.

The same group with the Obj also has child groups with smaller interior details that turn it from a generic room with blank walls into a finished room. Things like light fixtures, pictures on the wall, desks, machinery, etc. The child groups are only rendered while you're inside the "Obj" (or a connected tray but that gets more complicated).

spectre1989

  • Minion
  • **
  • Posts: 38
Re: Technical side discussion
« Reply #502 on: December 11, 2018, 08:41:14 AM »
Yes. The primary use case for doing this is 'trays' - indoor sections that are only rendered while you're inside them. Conversely, while you're inside one, the outside world is not rendered.

The top-level group will use an Obj that acts as the container geometry. For things like offices and sewers, this is often a single mesh of the ceiling, floor, walls, etc. Other styles like Arachnos bases use a solid black box with holes cut out for door connections.

The same group with the Obj also has child groups with smaller interior details that turn it from a generic room with blank walls into a finished room. Things like light fixtures, pictures on the wall, desks, machinery, etc. The child groups are only rendered while you're inside the "Obj" (or a connected tray but that gets more complicated).

Interesting, thanks!

Another thing - there are some (< 100) external geobin defs which aren't in defnames.
Here's the full list of those:
Code: [Select]
geobin/maps/City_Zones/V_City_05_01/V_City_05_01.bin:grp128022:V_COV/Villian_Lairs/Arachnos/Elements/Interior/elevators/Arach_Gen_Elevator_01_1&
geobin/maps/City_Zones/V_City_05_01/V_City_05_01.bin:grp128022:V_COV/Villian_Lairs/Arachnos/Elements/Interior/elevators/Arach_Gen_Elevator_01_2&
geobin/maps/City_Zones/V_City_05_01/V_City_05_01.bin:grp128022:V_COV/Villian_Lairs/Arachnos/Elements/Interior/elevators/Arach_Gen_Elevator_01_3&
geobin/maps/City_Zones/V_City_05_01/V_City_05_01.bin:grp128022:V_COV/Villian_Lairs/Arachnos/Elements/Interior/elevators/Arach_Gen_Elevator_01_4&
geobin/maps/City_Zones/V_City_05_01/V_City_05_01.bin:grp128022:V_COV/Villian_Lairs/Arachnos/Elements/Interior/elevators/Arach_Gen_Elevator_01_5&
geobin/maps/City_Zones/V_City_05_01/V_City_05_01.bin:grp128022:V_COV/Villian_Lairs/Arachnos/Elements/Interior/elevators/Arach_Gen_Elevator_01_6&
geobin/maps/City_Zones/V_City_05_01/V_City_05_01.bin:grp128022:V_COV/Villian_Lairs/Arachnos/Elements/Interior/elevators/Arach_Gen_Elevator_01_14&
geobin/maps/City_Zones/V_City_05_01/V_City_05_01.bin:grp128041:V_COV/Villian_Lairs/Arachnos/Elements/Interior/elevators/Arach_Gen_Elevator_01_1&
geobin/maps/City_Zones/V_City_05_01/V_City_05_01.bin:grp128041:V_COV/Villian_Lairs/Arachnos/Elements/Interior/elevators/Arach_Gen_Elevator_01_2&
geobin/maps/City_Zones/V_City_05_01/V_City_05_01.bin:grp128041:V_COV/Villian_Lairs/Arachnos/Elements/Interior/elevators/Arach_Gen_Elevator_01_3&
geobin/maps/City_Zones/V_City_05_01/V_City_05_01.bin:grp128041:V_COV/Villian_Lairs/Arachnos/Elements/Interior/elevators/Arach_Gen_Elevator_01_4&
geobin/maps/City_Zones/V_City_05_01/V_City_05_01.bin:grp128041:V_COV/Villian_Lairs/Arachnos/Elements/Interior/elevators/Arach_Gen_Elevator_01_5&
geobin/maps/City_Zones/V_City_05_01/V_City_05_01.bin:grp128041:V_COV/Villian_Lairs/Arachnos/Elements/Interior/elevators/Arach_Gen_Elevator_01_6&
geobin/maps/City_Zones/V_City_05_01/V_City_05_01.bin:grp128041:V_COV/Villian_Lairs/Arachnos/Elements/Interior/elevators/Arach_Gen_Elevator_01_14&
geobin/maps/City_Zones/V_City_05_01/V_City_05_01.bin:grp128035:V_COV/Villian_Lairs/Arachnos/Elements/Interior/elevators/Arach_Gen_Elevator_01_1&
geobin/maps/City_Zones/V_City_05_01/V_City_05_01.bin:grp128035:V_COV/Villian_Lairs/Arachnos/Elements/Interior/elevators/Arach_Gen_Elevator_01_2&
geobin/maps/City_Zones/V_City_05_01/V_City_05_01.bin:grp128035:V_COV/Villian_Lairs/Arachnos/Elements/Interior/elevators/Arach_Gen_Elevator_01_3&
geobin/maps/City_Zones/V_City_05_01/V_City_05_01.bin:grp128035:V_COV/Villian_Lairs/Arachnos/Elements/Interior/elevators/Arach_Gen_Elevator_01_4&
geobin/maps/City_Zones/V_City_05_01/V_City_05_01.bin:grp128035:V_COV/Villian_Lairs/Arachnos/Elements/Interior/elevators/Arach_Gen_Elevator_01_5&
geobin/maps/City_Zones/V_City_05_01/V_City_05_01.bin:grp128035:V_COV/Villian_Lairs/Arachnos/Elements/Interior/elevators/Arach_Gen_Elevator_01_6&
geobin/maps/City_Zones/V_City_05_01/V_City_05_01.bin:grp128035:V_COV/Villian_Lairs/Arachnos/Elements/Interior/elevators/Arach_Gen_Elevator_01_14&
geobin/maps/City_Zones/V_City_05_01/V_City_05_01.bin:grp128025:V_COV/Villian_Lairs/Arachnos/Elements/Interior/elevators/Arach_Gen_Elevator_01_1&
geobin/maps/City_Zones/V_City_05_01/V_City_05_01.bin:grp128025:V_COV/Villian_Lairs/Arachnos/Elements/Interior/elevators/Arach_Gen_Elevator_01_2&
geobin/maps/City_Zones/V_City_05_01/V_City_05_01.bin:grp128025:V_COV/Villian_Lairs/Arachnos/Elements/Interior/elevators/Arach_Gen_Elevator_01_3&
geobin/maps/City_Zones/V_City_05_01/V_City_05_01.bin:grp128025:V_COV/Villian_Lairs/Arachnos/Elements/Interior/elevators/Arach_Gen_Elevator_01_4&
geobin/maps/City_Zones/V_City_05_01/V_City_05_01.bin:grp128025:V_COV/Villian_Lairs/Arachnos/Elements/Interior/elevators/Arach_Gen_Elevator_01_5&
geobin/maps/City_Zones/V_City_05_01/V_City_05_01.bin:grp128025:V_COV/Villian_Lairs/Arachnos/Elements/Interior/elevators/Arach_Gen_Elevator_01_6&
geobin/maps/City_Zones/V_City_05_01/V_City_05_01.bin:grp128025:V_COV/Villian_Lairs/Arachnos/Elements/Interior/elevators/Arach_Gen_Elevator_01_14&
geobin/maps/City_Zones/V_City_05_01/V_City_05_01.bin:grp128020:V_COV/City_Zones/Grandville/Lobby_Tray/arach_rm_lobbyhospital_01_1&
geobin/maps/Missions/Unique/DoorMissions/Outcasts_Lair.bin:grp28:Omni/EncounterSpawns/Base_Missions/ES_MissionLayout_2&
geobin/maps/Missions/Unique/Flashback/FB_CoT_SAM/FB_CoT_SAM.bin:grp127:Omni/EncounterSpawns/Base_Missions/ES_MissionLayout_4&
geobin/maps/Missions/Unique/StatesmanTaskForce/IOM_CapauVictorie/IOM_CapauVictorie.bin:grp91809:Villain_Lairs/Tech/trays/halls/tek1_h_visstr_02_11&
geobin/maps/Missions/Unique/StatesmanTaskForce/IOM_CapauVictorie/IOM_CapauVictorie.bin:grp92242:Villain_Lairs/Tech/trays/halls/tek1_h_elv_1B_39&
geobin/maps/Missions/Unique/StatesmanTaskForce/IOM_CapauVictorie/IOM_CapauVictorie.bin:grp92509:Villain_Lairs/Tech/trays/halls/tek1_h_elv_2B_38&
geobin/maps/Missions/Unique/StatesmanTaskForce/IOM_CapauVictorie/IOM_CapauVictorie.bin:grp92791:Villain_Lairs/Tech/trays/halls/tek1_h_elv_3B_47&
geobin/maps/Missions/V_Mayhem/V_Mayhem_SteelCanyon_01.bin:grp76375:Streets/road_2lane/2_bend_12&
geobin/maps/Missions/V_Mayhem/V_Mayhem_SteelCanyon_01.bin:grp76375:Streets/road_2lane/2_bend_14&
geobin/maps/Missions/V_Mayhem/V_Mayhem_SteelCanyon_01.bin:grp76375:Streets/road_2lane/2_bend_15&
geobin/maps/Missions/V_Mayhem/V_Mayhem_SteelCanyon_01.bin:grp76375:Streets/road_2lane/2_bend_16&
geobin/maps/Missions/V_Office/V_Office_30/V_Office_30_Layout_08.bin:grp2:Villain_Lairs/office01/trays/rooms/dead_end/ofc1_mr_end_06_59&
geobin/object_library/Buildings/Style/deco/Deco2/Deco2.bin:decotestmaqt_C:object_library/Buildings/Style/deco/Deco1/Deco1_88&
geobin/object_library/City_Zones/Praetoria/Imperial/Imperial.bin:TempImperialCityLayout_36&:City_Zones/Praetoria/Buildings/Office/Modern_Skyscrapers/Bld_OFC_Modern_Skyscraper_B/_Bld_OFC_Modern_Skyscraper_B_07
geobin/object_library/Omni/EncounterSpawns/City_01_01/City_01_01.bin:_ES_L1_3_Ambush_City_01_01:object_library/Omni/EncounterSpawns/BaseTypes/ES_Ambush_BaseType_1&
geobin/object_library/Omni/EncounterSpawns/City_01_01/City_01_01.bin:_ES_L1_3_Ambush_City_01_01:object_library/Omni/EncounterSpawns/BaseTypes/ES_Ambush_BaseType_2&
geobin/object_library/Omni/EncounterSpawns/City_01_01/City_01_01.bin:_ES_L1_3_Ambush_City_01_01:object_library/Omni/EncounterSpawns/BaseTypes/ES_Ambush_BaseType_3&
geobin/object_library/Omni/EncounterSpawns/City_01_01/City_01_01.bin:_ES_L1_3_Ambush_City_01_01:object_library/Omni/EncounterSpawns/BaseTypes/ES_Ambush_BaseType_4&
geobin/object_library/Omni/EncounterSpawns/City_01_01/City_01_01.bin:_ES_Rikti_Ambush_City_01_01:object_library/Omni/EncounterSpawns/BaseTypes/ES_Ambush_BaseType_1&
geobin/object_library/Omni/EncounterSpawns/City_01_01/City_01_01.bin:_ES_Rikti_Ambush_City_01_01:object_library/Omni/EncounterSpawns/BaseTypes/ES_Ambush_BaseType_2&
geobin/object_library/Omni/EncounterSpawns/City_01_01/City_01_01.bin:_ES_Rikti_Ambush_City_01_01:object_library/Omni/EncounterSpawns/BaseTypes/ES_Ambush_BaseType_3&
geobin/object_library/Omni/EncounterSpawns/City_01_01/City_01_01.bin:_ES_Rikti_Ambush_City_01_01:object_library/Omni/EncounterSpawns/BaseTypes/ES_Ambush_BaseType_4&
geobin/object_library/temp/Test_smaller_doors/Test_smaller_doors.bin:Crappity_test3:object_library/Omni/NAVCMBT
geobin/object_library/temp/Test_smaller_doors/Test_smaller_doors.bin:Crappity_test3:object_library/Omni/NAVCMBT
geobin/object_library/temp/Test_smaller_doors/Test_smaller_doors.bin:Crappity_test3:object_library/Omni/NAVCMBT
geobin/object_library/temp/Test_smaller_doors/Test_smaller_doors.bin:Crappity_test3:object_library/Omni/NAVCMBT

slickriptide

  • Elite Boss
  • *****
  • Posts: 356
Re: Technical side discussion
« Reply #503 on: December 11, 2018, 03:56:59 PM »
I suppose that in a beta client, you're going to see things like "Crappity_test3", LOL.

I'd suspect that "beta test client" is a good enough explanation for most of these anomalies.

Also, thanks for the explanation of "tray", Codewalker. I'd seen to that in the past and scratched my head over what it was supposed to mean, since it clearly didn't mean the same thing as power tray or enhancement tray.

It'll be a couple of months probably before I get back to working with this stuff, but I'm keen to see where you're going, Spectre1989. I look forward to the updates.

spectre1989

  • Minion
  • **
  • Posts: 38
Re: Technical side discussion
« Reply #504 on: December 12, 2018, 02:33:16 PM »
OK so another question - is a geobin def obj field the only way that models in geos are instanced?

This file object_library/City_Zones/Atlas_Park_makeover/Decals/Crack/Crack.bin contains a single def with 8 groups. The names of those groups correspond to entries in defnames.bin, whereas what I had been doing was to only look in defnames if the group name was a path. Should I always be looking up group names in defnames?

Codewalker

  • Hero of the City
  • Titan Network Admin
  • Elite Boss
  • *****
  • Posts: 2,740
  • Moar Dots!
Re: Technical side discussion
« Reply #505 on: December 12, 2018, 04:29:25 PM »
You should always look in defnames; don't go searching for files or try to be smart about it based on the formatting of the reference.

Defnames is the master index for object library defs (available in all contexts) and should be considered authoritative.

spectre1989

  • Minion
  • **
  • Posts: 38
Re: Technical side discussion
« Reply #506 on: December 12, 2018, 04:33:47 PM »
Thanks CW  ;)

spectre1989

  • Minion
  • **
  • Posts: 38
Re: Technical side discussion
« Reply #507 on: December 12, 2018, 04:44:17 PM »
Any idea why some references are just "defname", whereas some are "path/to/something/defname"? Should I be treating them the same? In the latter case I end up just chopping off the bit after the last slash and searching for that, which works, but just seems a bit odd.

Codewalker

  • Hero of the City
  • Titan Network Admin
  • Elite Boss
  • *****
  • Posts: 2,740
  • Moar Dots!
Re: Technical side discussion
« Reply #508 on: December 12, 2018, 10:20:56 PM »
If they're in defnames (which everything in the object library should be), just ignore everything before the last /. Doesn't matter.

The only place using the full path would make a difference is if a map referenced something that's *not* in the object library, but rather another map file. That doesn't (shouldn't?) happen in production maps. When working with the map editor, layers that can be toggled on and off are usually saved in separate files, so it could occur there. They're all consolidated back into a single file when generating bins.

As for why sometimes the full path is in maps and sometimes just the short name, it probably depends on what method the designer used to insert the group -- picked it from the library catalog on the top-left, manually entered the name, imported from a file they were working on. I'm not entirely sure what all different development tools were used, but have seen enough to know they're not particularly consistent.

Codewalker

  • Hero of the City
  • Titan Network Admin
  • Elite Boss
  • *****
  • Posts: 2,740
  • Moar Dots!
Re: Technical side discussion
« Reply #509 on: December 12, 2018, 10:23:26 PM »
I suppose that in a beta client, you're going to see things like "Crappity_test3", LOL.

Nah, stuff like that has been in the release client for years. I can practically guarantee that 99% of the weird stuff you find in the I24 beta was in the I23 client, and probably a good many more before it.

Having done a lot of delta comparisons, the differences between I23 release and I24 beta client are almost all related to specific I24 content.

spectre1989

  • Minion
  • **
  • Posts: 38
Re: Technical side discussion
« Reply #510 on: December 13, 2018, 11:43:58 AM »
You should always look in defnames; don't go searching for files or try to be smart about it based on the formatting of the reference.

Defnames is the master index for object library defs (available in all contexts) and should be considered authoritative.

I must be not getting something. I'm loading City_01_01.bin, one of the refs is grp_GC_Shutdown_Atmo (I assume for Refs I DO search the geobin rather than defnames), the first group of this def is grp_Media_Intvw, which is not present in defnames  :(

slickriptide

  • Elite Boss
  • *****
  • Posts: 356
Re: Technical side discussion
« Reply #511 on: December 13, 2018, 04:33:36 PM »
I must be not getting something. I'm loading City_01_01.bin, one of the refs is grp_GC_Shutdown_Atmo (I assume for Refs I DO search the geobin rather than defnames), the first group of this def is grp_Media_Intvw, which is not present in defnames  :(

;tldr - If a def name is a model, defnames tells you what .GEO contains the model. If the def does not have an entry in defnames, it's not geometry. It's something else.

You're not finding it in defnames because grp_Media_Intvw is not a model. It's an object in the object library that is a group of "atmosphere" NPC's. It's a group of models; though, the models in question are the dev-view-only spawn point models rather than the NPC's themselves. The NPC's are entities, which is something else entirely.

Maybe Codewalker's advice needs to be qualified to say that anytime you need to find the .GEO that holds a model, you look it up in defnames rather than futz around with parsing the path leading to the def. That's what defnames is: a mapping of def names to model file names. You go to defnames when you've reached a leaf node (or, I suppose, when you have a tray, given what we've recently learned about those from Codewalker) and that's how you find the .GEO for that model.

Typically, this would be indicated by an "object" def but as we've seen this isn't always necessarily the case. So, when you get a path, the first thing you do is look for it in the object library. If there's an object library bin for that path, you add it to the scene graph and follow that new patch to its conclusion, adding whatever other pieces are indicated. Eventually, you'll reach one or more leaves with no children; at that point, you've got a model name (assuming that it's not some other kind of def, like a sound file) and you use defnames to find the .GEO for the model.

Then the real fun starts when you try to figure out how to load the model and its texture. :)

What I've taken from Codewalker's explanations in the past is that in an ideal world, the object library would be completely loaded into memory and every piece of it would always be available permanently. In the real world, that would use an unrealistic amount of RAM and instead we demand-load the pieces that are going to be used by the current scene as they're encountered in the scene graph. Presumably, we also mark the loaded models so that when the scene changes, we can do a final pass on everything in memory and unload whatever is still in RAM that isn't currently being rendered.  I've assumed that's why models get two defs - an object def and an apparently "null" def. My guess was that the "null" def is used to indicate what should be treated as cache and what should be unloaded after the scene is completely loaded but not yet rendered.

From the standpoint of loading the scene graph, you load the map bin, and when you encounter a path, you load that object from the object library, then examine the nodes in that new bin you just loaded. If there are more object library defs (say, it's a building composed of many parts that are all separate object library bits), you load them as well and process them recursively. If you encounter a leaf node and/or an "object" def, you treat it as a model (unless there's a reason to treat it as something else, because one of the other values of the def indicates that it's a sound file or LOD values or whatever).



spectre1989

  • Minion
  • **
  • Posts: 38
Re: Technical side discussion
« Reply #512 on: December 13, 2018, 05:08:09 PM »
(Quote edited to combine relevant comments)
;tldr - If a def name is a model, defnames tells you what .GEO contains the model. If the def does not have an entry in defnames, it's not geometry. It's something else.

...

So, when you get a path, the first thing you do is look for it in the object library. If there's an object library bin for that path, you add it to the scene graph and follow that new patch to its conclusion, adding whatever other pieces are indicated.

What do you mean? There's a ton of stuff in denames which are not geos, they're geobins. If the name is a path, you can't just use the path to find the geobin in the object library, because some folders contain multiple bins - that's why you have to go through denames.

You're not finding it in defnames because grp_Media_Intvw is not a model. It's an object in the object library that is a group of "atmosphere" NPC's.
It's not, it's a def in City_01_01.bin.

Based on what I'm seeing it looks like the flow for parsing groups is:

* if you get a path, chop of the end of the path and look in defnames for it, which also tells you if it's another geobin, or a model
* if it's not a path, first try to find it in the current geobin
* if it's not found in the current geobin, try defnames

PS: Everything I said could be wrong, this is just how I thought it worked?

slickriptide

  • Elite Boss
  • *****
  • Posts: 356
Re: Technical side discussion
« Reply #513 on: December 13, 2018, 08:55:55 PM »
You said, grp_Media_Intvw , right?

That's a def that has a child: grp134017. It also has some properties related to spawning parameters for the group.
The def itself is a child of grp_GC_Shutdown_Atmo, which is essentially the top of one branch of the overall scene graph tree; that is, grp_GC_Shutdown_Atmo is a direct child of the ref of the same name.

grp_Media_Intvw  is just a node in the scene graph. It doesn't need a defnames entry because it doesn't connect to anything but its own child and parent. Did you mean a different def?

If you follow grp134017 through its children and grandchildren to its terminus, you end up with the spawn markers, which is where you get into the object library. I should have been more specific about what I meant in regards to that.
« Last Edit: December 13, 2018, 10:19:35 PM by slickriptide »

spectre1989

  • Minion
  • **
  • Posts: 38
Re: Technical side discussion
« Reply #514 on: December 13, 2018, 10:57:34 PM »
Right, I know it's just in the same scene, what I'm trying to figure out is when I should be searching in defnames. What CW said sounded to me like I should always be searching in defnames. Whereas it looks to me like I should first look in the current geobin defs, then I look in defnames if it wasn't found.

slickriptide

  • Elite Boss
  • *****
  • Posts: 356
Re: Technical side discussion
« Reply #515 on: December 14, 2018, 01:06:27 AM »
You use defnames when you need to reference something that isn't already loaded. Otherwise, you can just deal with whatever's already loaded into memory. Once you load something, future references to that thing (since something like a building could be referenced multiple times) just hook into the in-memory copy of it.

Codewalker was mainly emphasizing that defnames is the definitive reference for finding content, over and above any shenanigans with parsing paths and file systems.


Codewalker

  • Hero of the City
  • Titan Network Admin
  • Elite Boss
  • *****
  • Posts: 2,740
  • Moar Dots!
Re: Technical side discussion
« Reply #516 on: December 14, 2018, 03:34:15 AM »
I must be not getting something. I'm loading City_01_01.bin, one of the refs is grp_GC_Shutdown_Atmo (I assume for Refs I DO search the geobin rather than defnames), the first group of this def is grp_Media_Intvw, which is not present in defnames  :(

You don't need to load grp_Media_Intvw, it's already defined earlier in the map; third one in the file actually. There's no reason to look it up when it's already present.

defnames is the index for loading. If something references a group that doesn't exist, that's when you fall back to the object library in order to try to make it exist -- and defnames will tell you exactly how to load it.

spectre1989

  • Minion
  • **
  • Posts: 38
Re: Technical side discussion
« Reply #517 on: December 14, 2018, 09:01:36 AM »
You don't need to load grp_Media_Intvw, it's already defined earlier in the map; third one in the file actually. There's no reason to look it up when it's already present.

defnames is the index for loading. If something references a group that doesn't exist, that's when you fall back to the object library in order to try to make it exist -- and defnames will tell you exactly how to load it.

Ok cool, I just misunderstood you. First try the current geobin, then try defnames, that's what worked last night

spectre1989

  • Minion
  • **
  • Posts: 38
Re: Technical side discussion
« Reply #518 on: January 10, 2019, 12:10:42 AM »
Finally I've got to the point where I can view a map in wireframe, here's a video https://youtu.be/D499ys9Gmtk

saipaman

  • Elite Boss
  • *****
  • Posts: 921
Re: Technical side discussion
« Reply #519 on: January 11, 2019, 04:48:26 AM »
Nice.