Krycztij

TAW 3View — A Renderer for TAW's .3 Files

56 posts in this topic

I didn't know there was such a classification in block 2 … we could give it a try. When I tried to order rendering, I sorted the shapes by their class …

Share this post


Link to post
Share on other sites

I've just been for a taxi around Luxor, and noticed the following:

1. If I look around at the starting point, I don't see the runway lights through the hanger. Some time after I taxi away though, the lights become visible.

2. If I taxi so that a building is between me and the learjets, they always remain visible.

3. If I taxi around the 3 identical hangers, they are always rendered in the correct order. I'm guessing this is based on distance to the origin of each hanger, as the order 'flips' as I reach certain points.

Share this post


Link to post
Share on other sites

...and a bit more info for point 1. above.

In this F7 view the runway lights are visible through the hanger. If I rotate the view a small amount (equivalent to walking towards the back of the aircraft) the lights disappear.

luxor1.png

EDIT:

Photobucket has downsized the picture so much, that the lights can't be seen. The picture is still useful to show the orientation though.

...and here's an approximation of the scenario from above:

luxor3.jpg

The runway lights are visible through the hanger if I view in the direction of the red arrow (roughly corresponding to the pic above), but not in the direction of the blue arrow.

Obviously, I'm nearer to the centre of the hanger than the centre of the lights (shown by the black cross) at all times.

I'm wondering the difference may be due to the angle between the viewing point and the centres of each object. It's possible that this is greater than 90 deg in the case of the red arrow....

Share this post


Link to post
Share on other sites

Just a note on the block 2 rendering order possibility, comparing block 2 to block 5 assignments, the F22 seems to be treated as a special case:

untitled.jpg

Share this post


Link to post
Share on other sites

The Block2 idea is just a desperate theory. There are probably multiple criteria determining rendering order.

Back to the 3view, and I've solved one mystery:

If you make a mosaic of the moving map data, there is a 'DID' in the northeast and southeast corners:

did.jpg

By using the viewer to 'fly' to those corners, I can confirm that there is no arrangement of terrain spelling out 'DID'.

I then did a complete trip around the edges and then diagonally across the map and I'm absolutely blown away by:

1. How good 3view is.

2. How nice the TAW2.0 terrain looks.

Congratulations to all concerned!. :thumbsup:

Share this post


Link to post
Share on other sites

Great find!

It's going to take a while until I can test the rendering order … my holiday is over :(

However, good to hear so many things work fine. I'll peek in again next weekend.

Share this post


Link to post
Share on other sites

Already taken the liberty of downloading today's offering.

The performance of the red sea explorer is great! I almost get travel sick zooming across the landscape in full screen. :)

I'm having a bit of difficulty opening individual .3 files though. I think this is since I had to reinstall win7 a few weeks back and I guess I still have some paths to set up.

...and a hint about the rendering order since we always want more ;)

bursudan.png

Share this post


Link to post
Share on other sites

For some reason, the version I uploaded has VSync disabled. This is something I do for benchmarking only, because it makes the viewer run too fast. I remember having re-enabled it explicitly for the release; I don't know why that didn't work … it's on the to-do list for tomorrow.

Yes, I'd love to begin with rendering order. However, the current supershape implementation has to be rewritten anyway and putting any efford into the rendering order at this moment would be a waste of time. I want to complete the source review this week; afterwards, I'll begin to re-implement supershapes. I'll then consider our findings about collision triangles, and experiment with what we suspect determines rendering order.

On your problem with opening individual shapes: This works fine for me here. Is the shape placed in the 3 subdirectory of a TFX\PROGRAM installation? Is the viewer's EXE also placed in a TFX\PROGRAM directory? It should work then. At the very startup, the console prints "expecting TFX 'PROGRAM' directory at XXX". Check if that path is valid; and if not, PM me with how exactly you have set up the viewer.

Share this post


Link to post
Share on other sites

The problem I have is that the .3 files might be in some arbitrary location and the "expecting..." message gives the directory above where the .3 file is.

The 3view exe is located in a TFX\program directory....and if I double click on a .3 file in that structure, it works fine.

EDIT:

It's no big deal though. I can just copy the .3 files to a more suitable location.

Share this post


Link to post
Share on other sites

Announcing
3View 1.0
snapshotmx.png



System Requirements:

I personally tested it on Windows 7 only, but it should work with Windows XP and Windows Vista, too.

You need a Direct3D 9-compatible graphics card (ATI Radeon 9500 / Nvidia GeForce MX or higher — basically any decent GPU you bought after 2003).


Download:

October 26th, 2013

September 3rd, 2012


SDK Download:

If you are a programmer — source code and the 3View DLL:

October 26th, 2013

September 3rd, 2012

Setup:

If you have not yet installed the Visual C++ 2010 SP1 Redistributables (x86) and the DirectX Runtime June 2010 Update (x86), get them here and here. Otherwise, 3View will not start due to D3DX9_43.DLL and other files missing.

Extract 3View.exe to the PROGRAM folder of your EF2000, ADF or TAW installation.

Navigate to PROGRAM\3 and double-click a .3 file. "Select a program from a list of installed programs" and click OK.

If you have already associated .3 files with a program, right-click onto the file and choose "Open with...", "Select...".

Click "Browse..." in the lower left of the new window; navigate to the 3View.exe you just extracted. Click OK.

Check "Always use the selected program to open this kind of file" if you want; then click OK. A console and a window should show up.

You can also open .ssd files.


Usage:

Just like in TAW's Quick Combat screen, you can use the mouse while holding the left mouse button to rotate the model, and hold the right mouse button to adjust the distance. The mouse wheel is used for zoom.

Parameters control the model's state. The left and right arrow keys are used to select parameters. You see the currently selected parameter in the top left behind parameter #:. Use A and Y to increase or decrease the parameter, respectively.

We have yet to identify all parameters, but for example, parameter 7 often means "damage" and the parameters 1, 2 and 3 control landing gear and the orientation of rotors and turrets.
You can see aswan_j.3 breaking by pressing the right arrow key until parameter #7 is selected and increasing the parameter by holding A.

F1 toggles wireframe mode; F2 cycles time of day (at night, N enables night vision goggles). F3 enables and disables AGP. F12 enables debugging mode, which will write a log to stdout (which is usually the console, but can be a file if you started the application from the command line).


Changes:

There is no Red Sea Explorer any more. It will soon be released as a stand-alone tool.

  • will only choose parameters which are actually used (detected automatically)
  • ignores mouse / keyboard while window is not active
  • improved behaviour on minization and restoring
  • added error message if no SSE2-compliant CPU is found
  • EF2000 v2.0 (U.S.) did.dat can be loaded
  • ADF's did1st.dat is now considered
  • implemented new 0083 / 0087 / 00A3 shape LOD identification
  • implemented shape opcode 0026
  • introduced bytecode patching
  • ssinfo.fn loading closer to TFX3

Bugs fixed:

  • all SSD's loading now
  • fixed incorrect anisotropic filtering after resizing
  • fixed resource leaks when changing time of day
  • fixed incorrect color after sRGB to linear conversion
  • EF2000 .3 files can be displayed again
  • fixed invalid texture names being read from TFX2 shapes
  • fixed a texture memory leak (90+ % less VRAM load)
  • fixed two rarely occuring texture blending bugs
  • fixed a crash on error reporting
  • fixed invalid LOD when viewing supershapes
  • fixed 16 KiB .raw textures having their red and blue channels swapped
  • fixed semi-transparent geometry being drawn solid
  • fixed semi-transparent geometry having its red and blue channels swapped
  • fixed a crash if the viewer encountered an unknown opcode
  • fixed a bug in sRGB detection
  • fail gracefully if required textures are not supported by the GPU
  • opcode 0015 'jump if triangle is invisible' is actually 'jump if triangle is visible'
  • fixed broken 004A instruction support
  • fixed 0000-class shapes showing only their first LOD
  • fixed the crash after minimization
  • fixed misdeclared yaw / pitch / roll angles
  • fixed parameter 0 not being marked active in about 65 meshes
  • fixed a verification bug (seems like it didn't have any effect though)
  • fixed invalid parameter output
  • fixed some command line bugs
  • fixed time of day crash when loading EF2000 model
  • fixed wrong opcode being shown on shape crash
  • fixed calls from command line
  • fixed 0042 opcode being ignored (oilrigs will have lights again)

Optimizations:

  • reduced memory load if using did.dat
  • improved loading time if using did.dat
  • backface culling increases performance by 20 %
  • omitting an unnecessary matrix stack in the shape virtual machine inreases performance by 10 %
  • now using pure Direct3D device
  • increased palette switching performance
  • optimized shape transformation
  • minor performance improvements on shapes with many textured polygons
  • various minor performance improvements

Miscellaneous:

  • global textures are not hard-coded any more
  • all textures are loaded at startup (to prevent seemingly random crashes on missing textures)
  • texture slots will load textures of correct type only
  • rebased texture file logic out of renderer
  • treating moonless & moonlit nights just like another time of day (in order to prepare level file loading)
  • updated the font texture to be usable with HUD
  • prepared Clang compatibility

Finally: Happy modding!

— Pjotr

Share this post


Link to post
Share on other sites

Update!

I updated the links in the post above. Changes:

  • improved TFX2 compatibility
  • can select only active parameters in SSDs (just like with 3s)
  • now supports 512×256 and 512×512 true-color textures
  • renamed AGP on/off to version Glide/Direct3D

The SDK link above now includes source code for TFXplorer.

Share this post


Link to post
Share on other sites

Great! :thumbsup: Now I'll be up all night, instead of just a part of the night, working on modifications ;)

Share this post


Link to post
Share on other sites

I have a problem with 3View.
When trying to view the explosion sequence of TFX1's 'battlesh.3' shape file, I'm being denied seeing how it ends:
bship1_s.png

Share this post


Link to post
Share on other sites

I never implemented TFX1 shapes, so the fact that you can see anything at all is something to congratulate you for :D

This assertion means that an opcode tried to draw too many polygons. If I see the situation correctly, then this specific frame tries to draw a LOT of little spheres for the splash effect.

You can raise the bar by changing the “maximalNumberOfVerticesPerPolygon” constant in TFX shape.cpp (29) until the error disappears.

Something else is wrong, though. Errors like this one should have been caught upon loading and shouldn’t manifest at run-time. I’ll debug it at some unspecific time in the future …

Share this post


Link to post
Share on other sites

Thanks!
I tried increasing that parameter from its default value of 40 up to 10000 without success. Anything higher and the program crashed. This PC has only got 8GB of RAM though, so this will have to wait until I upgrade. :)

Share this post


Link to post
Share on other sites

Mike, it’s a typo. Change the second == to <=, please. I guess the opcode never occurred in TFX2/TFX3 files, so we never noticed that :D 

Share this post


Link to post
Share on other sites

That fixed it!...and without having to change the number or buy a new PC. :)

I thought the expression looked a bit strange, but this is C++ so I assumed you'd overloaded the == operator for l33t reasons.

Share this post


Link to post
Share on other sites

Nah, I avoid that kind of stuff. I should have written isWithin(1, operand.number, maximalNumberOfVerticesInPolygon) but this tends to slow down debug builds a lot when you need to run thousands of shapes per second :(

By the way, it is pretty easy to get 3View to work with TFX1:

  • TFX Rasterizer D3D9.cpp (1327): to the block, add
    case MajorVersion::tfx1:
    	blackIndex =  32; // TODO!
    	whiteIndex =  15; // TODO!
    	break;

    You could do me a favour and check the TFX1 palettes for the positions where palette-independent black and white are actually stored …

  • to the function below, add the same

  • again TFX Rasterizer D3D9.cpp (2242): replace the <unknown> palette names with any palette from TFX1’s colours folder. The names must not exceed SEVEN characters plus dot and extension, but I’ll fix that for the next release.

  • TFX Textures.cpp (305): Just below tfxMajorVersion();, add

    if(TFX::MajorVersion::tfx1 == version) {
    	zero(result.perTimeOfDay); // TFX1 does not use any textures
    	return yes;
    }

     

You should then be able to launch shapes directly from TFX1’s extracted folder. I’ll make a new release at some time in the next week.

By the way, noname3060 is the only actual ILBM in TFX1 and can be opened in Lean Viewer. It looks pretty boring, but the thumbnail, on the other hand, leaves me clueless.

Share this post


Link to post
Share on other sites

Thanks, the weekend is ending, but I'll try and do those things over the coming days.

Regarding the TFX1 pictures, they have .lbm extensions but are in the following format that I posted elsewhere...and there's lots of them, so it would be good if Lean Viewer could handle them...
So, for example,  'mk_libya.lbm' actually looks like this:
mk_libya.png

The format is a 4 byte ASCII header 'war ', then the 768 byte palette, in 6-bit RGB, then the 320x200 body.

Share this post


Link to post
Share on other sites

This is a very simple format, so here we go: https://app.box.com/s/k18pol0h73o5yomsgog3wpvolyorsa6x

Due to the rush, this version has several vulnerabilities when opening VRML files, so keep it clear of them. (The thumbnail handler is okay, though.)

  • fixed flickering
  • fixed cancellation on empty IFF chunk
  • new lighting
  • fixed premultiplied coverage
  • added DID WAR bitmaps

Untitled 2.png

You can rename all unknown TFX files to .LBM so the thumbnail handler is triggered for them; you recognize actual images by a thumbnail being displayed:

Untitled.png

Share this post


Link to post
Share on other sites

Thank you!
Of all the files of that type, I still don't see the TFX angry guy, so there's some still some mystery to be solved:
 

angry_guy.png

Share this post


Link to post
Share on other sites

I don't think we know the format of the .spr files...or if there is a common format.

Not much time recently, but I had quick at those TFX1 edits above, and they don't really work, causing a bytecode parsing error. I'm not sure why it worked earlier.

A lot of the TFX1 palettes are 8 letters long before the .col extension, and a scan through them shows the whiteIndex to be OK at 15, but there is no common blackIndex except for 0, and that's used as a transparency in TFX2&3. If that is likely to cause issues then I suggest using a blackIndex of 5. The RGB values are mostly something like 5 8 7 which should be very dark.

Share this post


Link to post
Share on other sites
30 minutes ago, mikew said:

A lot of the TFX1 palettes are 8 letters long before the .col extension, and a scan through them shows the whiteIndex to be OK at 15, but there is no common blackIndex except for 0, and that's used as a transparency in TFX2&3. If that is likely to cause issues then I suggest using a blackIndex of 5. The RGB values are mostly something like 5 8 7 which should be very dark.

0 is a problem, but 15 & 5 seem to work fine; thanks! :thumbsup:

Share this post


Link to post
Share on other sites

Just looking at luxor.ssd in 3View and I seem to remember being able to change the Parameter=7 value to blow everything up.
It doesn't work now though. Did it ever for ssds? I may be imagining things.

The version I'm running is built from last December's code.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now