Jump to content
COMBATSIM Forum
Krycztij

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

Recommended Posts

Got it.:

  1. When I added building damage to TFXplorer, it required each shape having its own parameters. (Not all buildings being demolished at the same time because they use the same parameters.)
  2. I changed the rendering code, implemented building damage, and after some weeks the feature was fine.
  3. The new code didn’t work with 3View, though.
  4. I had run out of time so I just placed a dummy which disabled the feature altogether.
6 hours ago, mikew said:

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

Please open ThreeView SupershapeSession.cpp, find void SupershapeSession::draw() { at the bottom. Replace

static UInt1B const zeroParameters[8 * TFX::Supershape::maximalNumberOfShapes] = { };

with

// Parameters of all shapes need to be stored consecutive in memory. Reserve a region and duplicate the user’s parameters
//  into every possible slot.
UInt1B allParameters[8 * TFX::Supershape::maximalNumberOfShapes];
for(auto i = 0; i < TFX::Supershape::maximalNumberOfShapes; ++i) {
	for(auto j = 0; j < 8; ++j) {
		allParameters[8 * i + j] = parameters[j];
	}
}

Four lines below that, replace zeroParameters with allParameters. Re-compile and you should be fine!

Share this post


Link to post
Share on other sites

Thanks! I'll try that later.

I had a look at the code, but my search for 'disable_visible_damage_in_ssd_mode=1' came up empty. ;)
The reason this came up was that I wondering how easy it would be to add some extra buildings to a tile and this would be a way to see if the engine recognised them before integrating the ssd into a map.
I had assumed that you were deriving the bounding boxes for collision detection from the .3 shape rather than using the COLLISION_BOX information in the ssd...but now I'm not so sure.

Share this post


Link to post
Share on other sites

That code snippet gives the required effect. Thank you. :)

Adding some extra buildings is not a trivial job though. So, may have to park that idea for a while. :(

Share this post


Link to post
Share on other sites

Trying to run Lean Viewer on Linux with Wine, but get the following 2 lines in the bottom panel:

D3D info: GPU supports Direct3D 9.0c

Direct3D 11 error: GPU too old

 

No it isn't, it's supposed to be D3D12 compatible (Intel Iris-650).

Probably Wine's fault, but I thought I'd mention it here.

 

Share this post


Link to post
Share on other sites

Thanks for mentioning!

 

There are two possible problems:

  1. Wine: I got a message lately from someone that a different version of the viewer works fine on Wine. Wine could be outdated or your configuration could be wrong.
  2. Graphics drivers: Intel is known for low driver quality, and some driver problem could cause Wine to downgrade to D3D 9.0c.

I’m sorry I cannot be more specific, but I neither have Wine here nor an Intel Iris. All I know is someone else successfully uses my D3D 11 renderer on Wine.

Share this post


Link to post
Share on other sites

Ah, I hadn't realized that Lean Viewer was DX11 based, so thought that might have been a spurious message.

 

It's good to know that it works for someone. While my Wine version is very recent, it probably needs some tweak, and having an Intel GPU isn't helping.

I'm not sure I can be bothered to investigate exactly why it doesn't work as luckily I haven't thrown out my Win7 machine. :)

 

Is there any escape from Microsoft? Unless you like sysadmin duties, Linux isn't the answer. :(

 

 

 

Share this post


Link to post
Share on other sites

Precisely, Lean Viewer uses the Direct3D 11 runtime and requires a GPU with Direct3D 10.1 or higher. (There has actually been a request to port it to D3D 9, but it’s too much trouble to be worth it – D3D 9 has restrictions on the number of triangles you can draw at once, so I’d have to split meshes into fitting pieces before rendering them.)

 

I’ve been watching ReactOS for a long time. I never had the time to actually try it, though. If some gave me a hundred thousand dollars, I’d probably quit my job and invest ten years into improving ReactOS – Windows 7 support end is coming closer; I don’t want to use Windows 10 (and it’s not even compatible with my machine) and Linux is, like you said, not the answer.

Share this post


Link to post
Share on other sites

ReactOS looks great in theory, although I guess a big problem would be hardware support.

As annoying as Win10 is, most things work quite nicely from an OS point of view so it may be the least worst option for a while longer.

Share this post


Link to post
Share on other sites

Suitably intrigued, I thought I'd try out ReactOS on my mini pc, so I go to their ISO download page, but....
" Due to problems with the USB stack it is NOT currently possible to install ReactOS from a USB stick or USB CD-ROM, the setup process will fail partway through. This worked previously but was broken several years ago by a rewrite of the USB code."

 

FFS! :angry:

Share this post


Link to post
Share on other sites

That’s a VERY bad regression! I hate that with software. How it should be:

  1. download
  2. maybe install
  3. run

How it actually is:

  1. download
  2. no installer, just source code
  3. get toolchain (compiler, cmake)
  4. version conflict; try with a different version
  5. google the correct versions
  6. compile
  7. try to run
  8. but command-line arguments are missing, create the proper batch file for that
  9. try again to run
  10. set up PATH variables

… I usually stop after three steps. Sorry to hear ReactOS is in the latter category as well …

Share this post


Link to post
Share on other sites

Yep, it's not getting any better either.

 

It's suggested to run ReactOS in a VM, but what's the point of that? I might as well just run Windows 2000 in the VM.

 

 

Share this post


Link to post
Share on other sites

Looking again at alternatives to Windows (and ReactOS) and choices seem rather thin on the ground.

 

What we (OK, it's probably just me :) ) want is a modern equivalent of DOS and some low level drivers for the hardware.

This would allow TFXplorer (in this case) exclusive use of all resources without worrying what else the OS is up to. Win-Win!

 

I'm probably overlooking something though...

Share this post


Link to post
Share on other sites

Speaking for me, I’ll rather make clever use of the resources instead of tearing down the operating system :) File mapping/paging/preemptive multitasking are just too handy, I don’t want to go back to DOS/embedded. Plus, it’s not secure enough for me.

 

However, it would be fine if my OS didn’t send telemetry all the time and came without ten language runtimes, each a dozen gigabytes, just for “apps” that I won’t ever install … Unix is fine in that regard.

 

Some “invisible” improvements to past TFXplorer versions have been to code portability. There is some chance that it will run on all major OS’s in the next years. Prerequisites:

  1. a new graphics renderer, based on Vulkan (because it supports Android/Mac/Linux/Windows)
  2. a new sound renderer (I have no idea on that one, actually – is OpenAL still a good choice?)
  3. me having lots of spare time :)

Share this post


Link to post
Share on other sites

Yes, I believe OpenAL is still the best choice for cross platform audio.

 

In my NeoDOS world, you wouldn't connect to the internet at all, so can forget about security...although maybe allow dial-up for multiplayer. :)

I'm not suggesting we go back to floppy disks, so we'd boot the game with autoexec.bat and config.sys on a USB stick.

 

As I suspect you won't have 'lots of spare time', I need to find the optimum configuration in Wine or just accept the next version of Windows like I always do.

I almost wish MS would impose the subscription model now to get it over with.

Share this post


Link to post
Share on other sites

No need to accept Windows 8/10/whatever; I’m developing on Windows 7 and I won’t upgrade in the foreseeable future.

 

(… and TFXplorer still supports Windows XP, doesn’t it? ;) )

  • Like 1

Share this post


Link to post
Share on other sites

Not much time for TFX recently, but have been playing around with a 'synthetic' .3 file today to see what I can get away with using TFXplorer.

This is the simple tent_3.3 which has been modified to define all the vertices with 0062 opcodes, and the 009F opcodes replaced with 0047.

So, apart from the syntax, the information held in the .3 file and a .wrl file I made earlier is the same.

viewers.png.b8082cbca9c3b42a24e56b8001eb91c0.png

This was running on Windows 7, but as of today Lean Viewer is now working for me on Linux with default Wine (version 3.8-1) settings. :thumbsup:

Before, while the bitmaps were OK, only the grey background could be seen when loading a model despite 'file loaded successfully'.

Share this post


Link to post
Share on other sites
7 hours ago, mikew said:

This is the simple tent_3.3 which has been modified to define all the vertices with 0062 opcodes, and the 009F opcodes replaced with 0047.

So, apart from the syntax, the information held in the .3 file and a .wrl file I made earlier is the same.

So it’s a first conversion? Very good! No duplicate triangles?

 

7 hours ago, mikew said:

Before, while the bitmaps were OK, only the grey background could be seen when loading a model despite 'file loaded successfully'.

Interesting. I can’t imagine what the problem was …

Share this post


Link to post
Share on other sites

Not really a conversion, it's more an exercise in building a .3 file from the ground up with the minimum effort. That model consists only of 10 vertices, 6 textured quads and 2 textured triangles with the necessary information taken from the original tent_3.3. I'd earlier used the same basic information to create the VRML version.

I'd imagine any converter would be best implemented with a modification of the 3view code, since you already have an internal model of the object.

 

About two thirds of tent_3.3 deals with the shadow positions over time and the change of shadow opacity with distance. It would be nice not to have to deal with this, but that would involve a slight tweak of the graphics engine to introduce some directional lighting effects. :)

 

I had two problems with Lean Viewer on Linux (fedora). The first, that I mentioned some months ago, was that the on-chip GPU was not being recognised, and the software renderer reported that it didn't support DX11, so Lean Viewer reported that.

This was fixed by reinstalling Fedora with the default Gnome 3 desktop environment where the GPU was detected correctly, but then I encountered the problem mentioned above.

The cause was surely Wine's fault, and they've addressed the underlying issue. They are just as likely to break it again though.

 

Share this post


Link to post
Share on other sites
7 hours ago, mikew said:

I had two problems with Lean Viewer on Linux (fedora). The first, that I mentioned some months ago, was that the on-chip GPU was not being recognised, and the software renderer reported that it didn't support DX11, so Lean Viewer reported that.

This was fixed by reinstalling Fedora with the default Gnome 3 desktop environment where the GPU was detected correctly

 

Well I might add software rendering as a fallback path, just in case. But the software renderer needs to be provided by Wine and is a complex, rarely used component, so I suspect even more problems to arise …

 

7 hours ago, mikew said:

but then I encountered the problem mentioned above.

The cause was surely Wine's fault, and they've addressed the underlying issue. They are just as likely to break it again though.

 

Okay. I got a suspicion, because I do clever things here and there (always 100 % compliant with the D3D API, though! ;) ) but good to know it’s been fixed anyway.

Share this post


Link to post
Share on other sites

Any comments about Lean Viewer or TFXplorer on Linux are for your information only. Since I know you only use the Microsoft APIs, and if it works on Windows, any problem is obviously Wine's fault.

It would be cool to find out exactly what they are doing wrong, but I don't have the time/knowledge/enthusiasm to get the appropriate logs.

 

Share this post


Link to post
Share on other sites

Linux is actually a common request for my software, from something like 5 % of users. So I seek to enhance compatibility wherever I can, and I welcome and value your information :)

 

FYI: You can set render states in D3D 11 to NULL to trigger default behavior. E.g. set depth-stencil to NULL and you get default Z buffering with "pass if closer" Z test. This saves me a dozen function calls where others pass explicit parameters. It’s easy to overlook in the documentation and I’ve never seen anyone else do it, so I suspect early Wine missed out on it and this resulted in a mis-configured render pipeline.

 

Anyway, I hope to improve the lighting situation soon. There will be no hard-coded shadows in TFXplorer’s custom terrain. It will be computed from directional light, just the way it’s meant to be. Don’t waste your time on shadows.

 

Still very slow progress and short on time, though.

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

×