Jump to content
COMBATSIM Forum

mikew

Charter Member
  • Content Count

    4,075
  • Joined

  • Last visited

  • Days Won

    12

mikew last won the day on June 5 2017

mikew had the most liked content!

Community Reputation

4 Neutral

About mikew

Recent Profile Visitors

2,572 profile views
  1. It's not just Python2->Python3. There were some other changes needed to make the code more flexible to handle ADF. Well, here you go: https://app.box.com/s/aq3uxsiq8vccvnqts72wfarn2potvbsj Unzip to an empty folder and follow the instructions in ReadMe.txt. The file 'raw_names_list.txt' contain all the names we know about for TAW. Most of these will be common with ADF, but things like the RSO mission names are unlikely to be there. They may already be extracted as part of the TAW2.30 file package though. Good luck!
  2. Here's Krusade's extractor for the English version: https://app.box.com/s/al47krcbsubsy59or8ih4cjvxqhnqak5 ...although I doubt it will work with ADF. I have Python scripts that can extract TAW's .dat file, or at least could in 2013. Moving from 32bit Python2 to 64bit Python3 seems to have made them inoperable. It shouldn't be too difficult to get them working again and for ADF as well.
  3. I don't think in terms of transformation at all, and ignore things like the 0061 opcode. This hasn't been much of a problem with the models I've looked at so far, but if I want to handle things like rotating turrets on vehicles then I'm going to have to change my approach. While looking at this stuff, comments you made back in 2011 are making much more sense... I won't have time to do much coding over the next few days, but that might be a good thing as I can think about a better way of doing things.
  4. For the 002d CallDisplaced opcode, I added a new set of vertices for each submesh and that's what I'll probably try to do here...but a rotation is more complicated than a displacement.
  5. It may work, let's see what happens... Ah, some slight issues. Looking at the bytecode, it seems I need to deal with the 0049 opcode which I've avoided up to now. This is 'callTransformed' and I need to understand what that means regarding the vertices. I'll get back to you on this.
  6. Wouldn't 'Happy Birthday Donster!" have sufficed?
  7. mikew

    Wednesday

    Morning. About 55F I'd guess and not raining. That's just looking out of the window as due to May Day being public holiday for the 'people', I don't have to got to work. Go communism! Wait a minute, if I don't work, I don't get paid. Hmmn, a bit of a fundamental problem with this communism thing.
  8. ...or maybe not. It takes about 700 lines of code even with a Python wrapper to get Vulkan to display anything. 😠
  9. I wouldn't bother thinking about it too much as I'm not sure where I'm going with this. In what could laughingly be called a 'pipeline', I'm going from .3->.wrl in multiple stages where each stage is a bit crap at the moment. The 'fun' aspect here is now the task is broken down, I can add capabilities of each stage to handle different types of polygons etc and derive great satisfaction when I can see the result in Lean Viewer and now Blender. I'm beginning to wonder if my target should be SPIR-V instead of VRML as it looks easier to translate the low-level TFX bytecode to that format rather than to produce VRML which gets a bit unwieldy as the complexity increases. Obviously it needs more effort to view the result though.
  10. If some rendering order is allowed, then that would be great. Currently what I have in my Blender model of Luxor is a bunch of 'indexed face sets' all with equal priority, so if I add the base tile there is horrendous z-fighting. For the base tile, I can produce a single texture to save running any bytecode, although it looks completely different to what we see in 3view for some reason. I can't really use this approach for something like the runway as it's far too thin and would look horrendous close up.
  11. The reason that my models were mirrored is because I was only inverting the vertical axis, thus effectively creating a left handed system. To get the models the right way up in the VRML world, I need to invert Y and Z. This caused all my textures to be appear on the wrong sides but the winding can be changed to clockwise in the VRML file. So, now I can attempt to place all the buildings plus taxiway for Luxor: There's still a few things missing, and it all boils down to the coplanar texture problem. The tile model the airbase sits on has a base texture with a scruff layer on it. Then on top of that sits the taxiway as a separate model, then the runway model. There must be an easy way of handling this.
  12. Hmmn, the coordinate system problem that I ignored at the start of the VRML conversion process has come back to bite me when I try to place objects on a tile. Here, we have Luxor airbase but I've only imported into Blender the Taxiway, Control Tower and the 3 Hardened Hanger VRML files which I've translated according to the SSD file information, then added the Firehouse without any translation or scaling. Blender seems to understand that the VRML system needs converting to its own system and has applied a 90 degree rotation around its X-axis and 180 deg around its Z-axis. Ideally, I'd want to have a consistent system from the start, so that if I made a 3D model of a signpost pointing to North and East, it shouldn't need any rotations if I import into a 'world'. So already, we have three systems: Blender uses a right hand coordinate system with the Z axis pointing upwards. VRML is +X=Right, +Y=up, +Z= out of the screen (Right handed system) TFX is +X=Right, +Y=down, Z=away from screen (Right handed system), also +X=East, +Y=Down, +Z=North at world level Since TFXplorer isn't quite finished, I was thinking of playing around with Unity or Unreal in the meantime, but these use left handed systems and the axes are swapped around. In UE4, positive X is "forward", positive Y is "right" and positive Z is "up". So, my brain hurts and will probably just give up and watch the Grand Prix today. Also, while I can import .wrl VRML files into Blender, I can only export to .x3d. I haven't been able to find an appropriate plugin to do .wrl directly. There is an option to export to .stl which I thought Lean Viewer could handle but maybe that's another viewer.
  13. Now that's Season 2 of ST:D out of way, and a dramatic improvement over Season 1 it was too. Sets things up nicely for Season 3...
  14. ..and Jailhouse Rock is apparently loaded with innuendo about certain activities, but pop songs can be analysed too deeply. It's still the weekend here thanks to Jesus, so here's some ELO...
  15. Thanks but noticed no difference. If I try to associate .wrl files with Lean Viewer, I just see 'Initializing' for a few seconds and then the window crashes, but a process is left running. I'm not sure if it always did that. In general, I just start Lean Viewer and use 'file->open' Note that I'm using Fedora which is quite bleeding edge with Linux 5.0.7 and Wine 4.5. Using inbuilt Intel graphics probably isn't ideal either.
×
×
  • Create New...