mikew
-
Posts
4,798 -
Joined
-
Last visited
-
Days Won
12
Content Type
Profiles
Forums
Calendar
Posts posted by mikew
-
-
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.
-
Wouldn't 'Happy Birthday Donster!" have sufficed?
-
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.
-
...or maybe not. It takes about 700 lines of code even with a Python wrapper to get Vulkan to display anything. 😠
-
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.
-
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.
-
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.
-
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.
-
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...
-
..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...
-
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.
-
No hurry as it's perfectly usable as it is. I know how you like general feedback though.
...and it fits in with the general Linux experience where most things work but nothing is as polished as on Windows.
-
Yes, although it's good if you know what debug channels you're interested in otherwise it's a bit much.
If I run from the command line, without extra debugging, I get the following when the VRML file loads:
002f:fixme:dxgi:DXGID3D10CreateDevice Ignoring flags 0x20.
002f:fixme:dxgi:DXGID3D10CreateDevice Ignoring flags 0x20.
002f:fixme:dxgi:wined3d_bind_flags_from_dxgi_usage Unhandled DXGI usage 0x40.
0031:fixme:d3d:state_linepattern_w Setting line patterns is not supported in OpenGL core contexts.
0031:fixme:d3d_shader:shader_glsl_interpolation_qualifiers Unhandled interpolation mode 0x3.
0031:fixme:d3d_shader:shader_glsl_interpolation_qualifiers Unhandled interpolation mode 0x3.Pressing the left/right buttons doesn't add anything to this list, so seem to be ignored.
It'll probably be fine again in the next Wine release.
-
Just checking in, although nothing really to report in this debytecodeification project as I only get to look at this stuff now and then...
I fixed the hanger with the shared vertices problem (sep 18th 2018) by creating a new vertex index if used previously. The problem now is 002d. I don't seem to be rendering all the submeshes, although the ones that are rendered are OK.
I have no idea what's going wrong, so need to introduce a diagnostic system. To get the information required for a VRML file, I need to run all the bytecode in the 0015, 002d, 0008 etc subroutines and sort out the resulting mess.
By the way, Linux/Wine support for Lean Viewer has deteriorated for me recently. It takes about 5 seconds for the image to be rendered and the next/previous function doesn't work, even from the menu.
-
Indeed it does. There may be an F22 at about the 2:28 mark as well.
Great find!
-
Vietnam...Interesting place.
My tour occurred some 50 years after OG's and in markedly different circumstances, so not much common ground for discussion.Thinking about the political events in SE Asia in the 1960s is enough to give anybody the blues...
-
Splendid!
That reminds me of this tune which also came out in 1967, although I don't know which came first...
-
I'm afraid that's slightly too old, but I'll meet you half way...which is about 1970.
-
No need for words like that...at least if I can find all my receipts, which I have. 😇
So just a case of putting on some pleasant music on the gramophone while I scan them.
-
-
-
-
-
Better get around to sorting out my Q1 accounts, so some background music is needed...
TAW terrain format
in F22: ADF / TAW
Posted
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.