Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[WxTech]

In my older 4.08 game I had fixed some issues with buildings having bad surface normals, bad shadows, flickering appearance at the farthest LOD, etc.

I've begun again for BAT.

With the proliferation of new objects over the years, the task can be a bit daunting. There are a host of SFS files now, and I don't want to do a bulk extraction. Which means even making up a file list for each of those would be tedious.

Here's my proposal/request.

If I supply a list of objects I'm willing to fix, can someone who is able to more easily locate and extract the files be willing to do so and upload the batch? Whereupon I'll fix 'em up and make 'em available.

My present thrust is to address the more egregious things:

- Objects flashing at the longest LOD because textures are set to ground level.

- Bad shadows, where they also appear on the side facing the Sun.

- Bad or inapprooriate collision boxes. Particularly for some open hangars and open-sided storage structures.

- Bad surface normals that result in odd lighting.


I would only issue requests in instances of difficulty or the avoidance of the pain of determining which SFS file to get the resources from.

Or if anyone has already prepared the lists of the contents of all the SFS files, I'd be all set. (I've already done this for the SFS files in the folders BAT03 and BAT03B. That took some time.

Thanks for any assistance!

[Vampire_pilot]

you would not believe it when I say: I myself do not know (or need to know) where what object resides. I do an up to date extract when I need it.

At least I can say that the static objects reside in the BAT00 common folder, not in the other ones.

[WxTech]

Thanks, Vamps! But wouldn't you know it; it's only the BAT00 folder that I haven't yet got the file lists for. I sure hope all those 80 SFS files each contains a handy list of files contained within them...

[WxTech]

Well, I got round to extracting all the file lists in each of the SFS archives that have them (over 70 out of 80) in the BAT00 folder. And I've extracted and modded the first batch of objects I wanted to fix.

For example. There are several objects built on the same model of "Warehouse". It's an open-sided storage shed that's basically a roof sitting on 9 posts. In its various flavors it's a pretty widely used object. Originally, the first one of its kind had a pile of stuff inside, but at some point this stuff was removed and made ito its own object. Now this warehouse and its kin are all empty, ready for the mission builder to put inside whatever they want.

But there's a problem. The original collision object is still used for all! This covers the whole thing down to ground level, encompassing the former built-in pile of stuff. That means that objects one might put under the roof, such as an inviting stack of fuel barrels, is protected by the original collision object.

I've shrunk the collision object to encompass only the roof. Now those fuel barrels (or other 'splody things    ) placed under that roof are ready to be strafed.

But the original problem which caught my eye about these warehouse objects is the way they flash when showing the farthest LOD texture, due to said texture being placed at ground level. I've raised these textures to the 9bject's roof height, which ceases the annoying flicker. And those farthest LOD polys were made too large; they're now at the proper size.

And yet another problem with these that's been fixed. At the 3rd (of 4) LODs, the old pile of stuff under the roof that was present originally and supposedly got removed still got drawn in, as either a dark brown or black blob. That's now gone.

So. You see how some objects exhibit a veritable host of issues. Which is why I shake my head when there's so much effort being expended on such things as modeling hyper-detailed oleos (gear struts), or adding yet more planes that never even got off the drawing board. There's LOTS of basic, core things important for the game as it is that are real eye-sores, and which cry out for a re-working.

Well, I've made a small start.

[baggo]

WxTech you’ve made significant improvements to the sim in cockpits, effects,and now this, can’t wait to see this in action, but mainly thank you very much for your efforts they are very much appreciated. Kev

[rogeroger]

- Objects flashing at the longest LOD because textures are set to ground level.

I find this interesting. I'm doing a building mod for the 352nd map using an unlocked Fmb. I currently don't have Bat and I'm placing  English, french, Raf buildings and hangers from Boomer's pack. I noticed that most of the buildings I used did not have shadows and I created shadows for those buidings only, and also split the edges to prevent shading issues on at least one building.

I wondered what was causing the distant flashing or shimmering on the ground textures of some open hangers.

I've extracted buildings from the up3 sfs files and am about to extract buildings from hsfx6 sfs files in search of some buildings that I'm missing from the Can english channel map.

I was very surprised that such old and well used objects still had these problems.

So. You see how some objects exhibit a veritable host of issues. Which is why I shake my head when there's so much effort being expended on such things as modeling hyper-detailed oleos (gear struts), or adding yet more planes that never even got off the drawing board. There's LOTS of basic, core things important for the game as it is that are real eye-sores, and which cry out for a re-working.

I have recently  found myself wondering the same thing.

[WxTech]

rogeroger,
If you're doing much object work, it would be wise to not reinvent the wheel. 

My interest is mainly the Pacific, although there's a certain amount of 'cross pollination' for certain of the more generic and widely useful objects.

Among my earliest mods (2014-2015) were the raising of farthest LOD polygons for buildings from ground level. This included the raising of some hangar floors for even a more intermediate LOD. The game engine demands a greater separation between polys parallel to the ground the more distant they are viewed from. I don't know the mathematical function (I could derive this empirically via experimentation, were I so motivated    ), but it seems that at farthest LODs about a couple of meters does the job. Which we can exceed in most cases anyway because most building and structure roofs are higher than this.

Another thing I've been doing of late--more so for some trees--is to introduce some transparency for the farthest LOD. And even the next farthest in cases where there are 4 LODs.

For instance, for a 4-LOD construct, I might have the two nearest at full opacity, but make the 3rd, say, 70-80% opaque and the farthest 50% opaque.

I think this would be a great scheme to implement pretty widely, because having an object pop into our out of visibility less abruptly is visually more natural. In spite of the limited view distances involved.

[WxTech]

An example of one kind of inefficient modeling that more than baffles me. It makes me grind my teeth.

Here we have a fairly simple hangar. It uses transparency cutouts for the girders running closely along the underside of the arched roof, which technique reduces polygons. But why does this model comprise 1140 polygons? In good part because the interior vertical posts consume 448 of those polys. Even though they're flat, one-sided rectangles! If they were made to show on both sides, that would be just about 900 polygons!

A flat-sided rectangle can be made from as few as 2 polys, meaning that all 14 of these posts, given polys on both sides, would comprise a mere 56, as opposed to the 900 (or 28 vs 448 to make single-sided posts) in this exemplar of inefficiency.

[WxTech]

The previous hangar object, with hundreds of polygons shaved off. I also made the formerly solid vertical supports (looking like Roman or Greek columns    ) look like proper girders. To its left is its sibling hangar differing only in having a solid wall in the back. I plan top fix its vertical supports as well.

I might add that when dealing with these objects, if shadows are missing or messed up, they get added/fixed. These two hangars, for instance, didn't have shadows. And the collision objects are altered so as to allow one to now go inside the hangar. Or the mission maker can put planes, vehicles, etc., inside, and the player can strafe them through the opening. (Numerous hangars have monolithic collision boxes that enclose the whole hanger, blocking off the entrance.)

[WxTech]

The Blister_Open and Blister_Closed hangars (shown in the previous post) have had some more tweaking. The girders following the arch of the roof have been given a bit more width. Here's the open version with a Wildcat inside. As mentioned, the fixed collision objects now allow you to drive planes into and out of them, and stuff inside is able to be strafed.

[WxTech]

An example of completely excreble junk that shouldn't be allowed into the game. It's called buildings.House$Blisterhangar, and is in 3do/Buildings/pacific/blister/.

It's the most crude adaptation of an existing object I've yet stumbled upon. It's a basic 'blister hangar' type object, of which there are a few variants. The aim here was to greate a low-slung arched roof hangar by sinking this one 7m into the ground (via the addHeightLive parameter in its static.ini entry). All the original shadows and collision boxes are left in place. The unwanted elements are removed merely by making them transparent in the texture.

The result is this eye-sore. Because the full shadow data is retained, and sunk into the ground, they still make shadows, but they now project TOWARD THE SUN! And by a considerable distance because of this 7m extension below ground level. And a LOT of needless polygons are being created that only consume resources to no benefit.

The number of things needing to fix on this one leave me wanting to just forget it, at least for now.

[WxTech]

More bad surface normals. This crap has survived since year dot.

Here we have a couple of stock hangars, or at least variants of stock objects. On the big hangar to the left, the green line points to a back vertical wall adjoining the arched roof for which the surface normals are reversed. That wall should be about as dark as the wall lower section touching the ground. It's anomalously bright because the surface normals are appropriate for the interior surface which faces the Sun, instead of what should be a shadowed surface facing well away from the Sun.

Note also the roof itself, and the roof for the smaller hangar to the right. The alternating diffuse, triangular dark bands are the result of yet more reversed surface normals. Where darkest (at the roof edges), the surface normal for that vertex applies for the shaded interior surface of the roof.

In the majority of such cases as this, the modeler has failed to supply enough vertices. And therefore uses a single vertex to apply to two (and sometimes even three!) very different surfaces having very different lighting. What drives me nuts is that attending these instances of too-few vertices, there are also some cases where a surplus of vertices exists for some other vertex involved with the same polygon. I've seen cases of up to six(!) identical vertices where only one is needed.

I'll then either re-purpose a redundant vertex or make a brand new one, so that the poly having this kind of awful lighting affliction looks correct.