Ok, after a brief hiatus due to "technical difficulties" I'm back and I'd like to take up the discussion once again.

First of all, Brit, you showed great character by posting your thoughts on the "Empty F" subject after I was a little tough on you during an earlier dust up.

I apologize.

Again, I'm sorry to have hammered you while you dealt with your demons and I do value your input.

Now then -

I'm no software engineer. I wouldn't know a Z-buffer from a Zebra, but I still don't think you have the "Empty F" concept correct. However, all I can give is anecdotal evidence in rebuttal to your comments so here goes:

=============================================================
To quote -
"........DX will continue to load the graphics card buffer with polygons until the Z sorting or texture of the polygon is changed. You have added more pieces to the 3D model."
=============================================================

Actually, we've been making hi-res models since about 2005. Hi-res means that various parts of the model are separate but they're held together by hardpoints on the "F" model. 99% of the time the "F" is the fuselage on a hi-res model and the entire model on a lo-res model.

The lo-res model has only one hardpoint coded for the propeller while a hi-res plane will have numerous hardpoints, usually in some kind of progression such as: A=left side tail, B= right side tail, C=cockpit, E=left wing, G=right wing, P=propeller. This is far from standardized though. In the earlier wild west days of EAW each modder tookl his own path. That is unimportant though, the process works the same no matter how the plane is put together.

The point is, the "Empty F" doesn't add a NEW piece. All it does is use an existing piece in a new way.

In addition, there is a file included with EAW called "Pshell.3dz" this file is used to hold together the two halves of multi-engine planes. So EAW already has something similar built into it's basic programming. It was this file that got me thinking about the possibilities of the "Empty F".

=============================================================
To quote -
"That is your double edged sword that I suspect you do not understand. Your empty F method gives you 256x256 new texture for each part, if you want it. To optimize the model, you need to limit this change."
=============================================================

The whole point of hi-res models from back in the day was to give the skinners more room to draw more detailed plane parts. This did put more demand on some early PC's but it was never much of a problem because PC performance improves at a rapid pace.

Here's the kicker.

An "Empty F" model doesn't use any more textures than some other hi-res models so the texture load isn't any different. In fact, there are other hi-res models that use more pieces that some of my "Empty F" types.

=============================================================
To quote -
"The code renders in alphabetical order. You should consider object part naming convention and texture changing"
=============================================================

This may be but as I commented earlier, the modders all took different paths when building hi-res models. For instance the original hi-res ME262 had a split fuselage made up of "C" and "P" and the canopy was the "F". So there may be a rendering order but no one has ever reported one model being more of a drain on resources than any other model.

My standard is to combine the two halves of the tail by conjuring up a new rendering sequence ( Yes, contrary to claims, I'm quite adept at conjuring a new R/S ).

The resulting new piece of tail (sorry) is named "A" and once that's done it frees up the "B" to be used for the left side of the fuselage along with the "C" for the right side. I include the cockpit with the fuselage just because it's easier. Generally, all other pieces remain the same.





One last thing.

There's been some erroneous info posted that increasing the number of pieces will cause a performance hit.

As evidence that increasing the number of pieces of a hi-res model will not cause performance hits I offer up this:

All of the bi-planes I corrected from the originals had dreadful rendering issues .To fix the issues required some fancy 3DZ footwork using some of the new plane pieces available in the 1.6 series. That is, "D", "I", "J", "K", "O" and "Q".

The upgrade ones are included in the Mediterranean plane package. These planes are flown on a regular basis both on and offline and there's never been even one comment about performance drags. Tony showed some data in that earlier dust up thread to confirm this.

The floatplanes also use a lot additional pieces and in one particular case, the PBY included in the SPAW upgrade package is made up of ALL the available pieces, from "A" to "Q". No performance problem here either.

All in all, since "Empty F" models have been airborne since the release of SPAW back in 2007, without any negative performance feedback, I'd say it's time to put this issue to rest.

In the end, my models work and the players don't care one whit how they are built.

The whole hi-res model thing started when many moons ago we unpicked how the big four engine models fitted together E F and G 3dz and the use of the paste-on files A B and C 3dz. I made the first three part spitfire model from E F and G 3dz to illustrate this.

We started using the "paste on" files to bolt on various bits and pieces to new models, and then the community discovered how to use the available 3dzs to build proper hi-res models. This was all pre-code.

Once we were into the code we added the extra D 3dz at first, then we cracked the limiting problem (this may have been related to instigating the non-slot system) and added all the 3dzs we now use.

Peter,

Thanks for filling in some of the historical info pertaining to hi-res modeling. You earlier pioneers did some amazing things with some, uh, less than stellar editing tools.

I'm curious.

Who was it that figured out the a,b,c and e.3dz's were available for use in the pre-code days?

Was it trial and error or did one of the original developers hint at such a thing?

I wonder because as far as I recall, all the default, original models used F and P for single engine planes and F and G for multi-engine planes.

As far back as Paulo's notes (i.e. 2000) we knew that the four engine planes were made up of the E F and G 3dzs, with additional bits turrets etc stuck on with the A B and C (and N) 3dzs.

I started making a Halifax in 2001 and so started some curiosity as to how all that worked. I think it was when I went on to model the Invader in 2001 that it all become clear how the various hardpoints were used to glue the models together. This from an email to a modder seeking advice in August 2001:

Now to use all the stick-on files you have to have all three E F and G
files present and connected. With a two engine after you've stuck the
F and G together you have two them, so all you have to do is put the
coded hardpoint on the F (I've generally just tacked it onto an
existing element) and stick on the E file. This can be a nominal
invisible file if you don't need to use it for anything. In the case
of the Invader it is actually the dorsal turret.

Once you have all three EFG files present and linked, you can put the
other coded hardpoints on the F and stick on A, B, and C. Unless
you're very lucky you will get further rendering problems in that the
stick on files will probably be visible against one side of the plane,
but not the other. That's where the funs comes in and you have to use
trial and error, double rendering some panels, perhaps moving some
panels from G to F or vice versa.

I then used that knowledge also in 2001 to make the Defiant with all its various stuck on parts (including the turret). We called them "stick on" files at that point.

The next up was Dunkirk, and as part of that we used the knowledge of the various model parts to make a first better fix for the biplanes - the ugraded Swordfish in Dunkirk was done that way. with the upper and lower wing surfaces being different parts of the model.

The first hi-res single engine models were with us by mid 2003.

Interesting.

Question though.

Did the "stick on" files render properly?

I ask because I've done a fair bit of "sticking on" myself and they almost NEVER render properly without a lot of fancy 3dz foot work.

Mostly, but it was industrial scale bodging, mostly involving duplicated elements.

We used to say that under the bonnet the models were stuck together with spit and string. But they looked and worked okay for players.

Still saying that today.

FWIW, I think the most impressive bodging ever was the Brit carrier TMOD. Something like 70 piggybacks on about 10 elements.

My hat is off to you.

This was the first attempt at a three part hi-res model of a single engine fighter, October 2001:





And this was Chompy's very first fully realised hi-res single engine model August 2002:

Ray,
I have not been frequenting the forums for a while. I just noticed this reply.

I did not take offence, so you have nothing to apologize for. There is nothing wrong with spirted debate. The only reason I started the topic was to pull the subject outside of the original thread and point out the reasons for some best practices.

I believe that I understand how your method works. You are using a parent / child linking system similar to 3DSMax. The code calls the parent object (empty F). The parent then tells the code to load all additional objects listed before moving to the next part listed in the code. Nice and organized.

I have not verified this, but EAW should consist of a 2D Z buffer, a 3D Z buffer, a fog Z buffer and a screen buffer. I am unsure if EAW uses the GPU of modern graphics cards. I doubt that it does.

I was not saying that your method caused more work for the calculations then the other methods used by EAW. My comments about polygon counts was a reminder that each polygon takes "something" to be rendered. My background comes from Panzer Elite, where the original models were 200 polygons. If each new model was limited to 600 polygons, there was no noticeable hit to fps, but if you put 6 models, consisting of 1000 polygons each, then a noticeable drop in fps was seen.

All EAW 3D models use the 3D Z buffer. When the Z buffer is sent to the screen buffer, all other video operations are halted. All polygons will be sent to the screen buffer in a single operation IF the maximum number set for the Z buffer is not reached AND the texture applied to the polygons is not changed. Obviously, this is not possible. The goal is to minimize the number of times we send the data to the screen buffer. Consider that you have an order for 1000 ball bearings that need to be sent to the shipping department, and you can only have one bin. If your bin can hold 1000 bearings it is a simple matter of dumping them into the bin and walking over to the shipping department. If the bin is smaller, you will have to make multiple trips to the shipping department. Consider the order consists of 500 red and 500 blue bearings. Your bin has no way to keep them separated. If you presort the red and blue, you will have to make fewer trips then if you make a trip each time you grab a different color.

Good you're back.

The only salient point I'm trying to make is that my method doesn't do anything different than what preceded it. It doesn't involve any more calculations than any other hi-res model.

We have a ton of hi-res models that use a regular "F" or main model, usually the fuselage, made up of 50 or so elements with hardpoints to attach all the other pieces.

The only thing different with my method is I use an "F" with nothing but hardpoints to attach the other pieces. No elements at all.

The advantage of the "Empty F" is that once I have a functioning rendering sequence I can apply the same sequence to any other model with similar design. For example, the "empty F" for the SBD works just as well for any other single engine model I care to upgrade. The "empty F' from the Hampton is used on about 6-7 other twin engine bombers.

I have a library of a half dozen of so "Empty F"'s that I can apply to pretty much any plane.

To be clear though, my method removes all the problems of INTER-sectional R/S issues but it does not solve INTRA-sectional R/S issues.

In other words, the "Empty F" solves the problem of one main wing showing through the fuselage from the opposite side because they are on different sections but it doesn't fix the problem of a horizontal elevator showing through the rudder because they are on the same section.

INTRA-sectional problems must be fixed either by patching with piggyback elements or ideally, by calculating a new rendering sequence.

And, as I said, in the real world "Empty F" models have been up and running since the original SPAW release in 2007 without a single complaint about slowed frame rates.

BTW, it's kinda nice around here lately.

Debates without rancor, my compliments to the new moderators.

It is nice to see all the good vibes. Nothing to do with the moderation. It is because you marvelous creators are making it so.

I appreciate your comment, thank you.

Let's just say that faster responses to outlandish behavior over the years would have made this a more pleasant place.

But that's all water under the bridge, we're all looking forward to post-war peace.

Yep, the past is gone and we all start from now.

If any of your piggy backs use the same texture, they should be added so they are rendered in sequence.

I assume R/S stands for Render Sequence. You could eliminate them if you added transformation code, the vertices would be converted to world and/or screen space before sending them to the Z buffer. Better yet, convert to DX9 and send the raw data to the GPU. Modern video drivers are maximized for speed of vertices transformation. Sorry, but I just do not have the drive to take on that large of a project myself.

The system I was using when I helped with multi-skins was a 2 Mhz processer with AGP 8x video. I have had slow frame rates in DX since multi-skins. Like most people, I had to use Glide. I was simply trying to point out best practices that help to maximize fps.

Edit:
I looked at the D3D module. It is virgin DX6 surface 2.. There is not much you can do to improve the visuals or the pipeline beyond considering data flow when you make your mods. Updating to DX7's surface 3 should help with special effects like fog and particles. DX6 to DX7 was better documented the DX8 to DX9. The MP code is DirectPlay. My understanding is that would be better scrapped and start for scratch if you want Client/Server MP.

so I guess, I have been a storm under glass, yet again.

BTW, I left something out.

Some of my models actually use LESS sections than models built to the old standard.

For instance, the Beaufighter only has three pieces vs other hi-res twins that have five or even six pieces.

I had to be creative is laying out the textures for this model and well as the way I broke up the 3dz model but I've demonstrated that it can be done.

In addition, most of my single engine models have one whole tail section rather than two halves, thus reducing the sections by one.

Personally, I think it's a same I came up with the idea so late in EAW's modding life. If I had produced this back in the heyday and it was adopted by the community we'd have a lot more hi-res planes available.

In fact, with the additional sections that the Code Group added to the game we could have had ultra hi-res planes that were broken up into smaller pieces thus giving the skinners more textures to paint on.

Ah, well.

I know your pain Ray,
After leaving EAW, and inspired by Mr. Jelly, I started learning tool programming. I reprogrammed PE and it's object editor to use smaller then 16x16 pixel chunks of the texture. A few years ago, I realized this change allowed true UV texturing of the 3D model. But, the texture artist had only two options. The first option was to wait for me to lean how to link the mouse input to the tool, or the texture artist hex edit the raw 3D file. The best texture artist I know took a second look at the game engine and it's changes, deciding it was not worth is hobby time. Ohh, what could have been if this had been know in the hay day of PE.

It was through this timeline that I learned that modding is only an individuals desires.

Ah, well. I learned something that I could not learn from social media interaction.

Edit:
That is the double edged sword I was referring. Each time you change textures, unless they are in memory as an atlas or single texture, you place a small traffic jam in the rendering pipeline. If they do it wrong, it can create a bottleneck in the rendering pipeline.

I don't think the bottleneck is a bad as you suggest.

Again, I can only offer anecdotal evidence as I'm not a software engineer.

I've put up a large flight of PBY's in SPAW to be intercepted by N1K Rex floatplanes with no noticeable stuttering.

The PBY uses ALL of the available add-on sections and the Rex uses 7 out of 12.

Maybe it's some extraordinary programming by the original developers or maybe it's the vast improvement io calculating power of PC's over the last 20 years.

I haven't a clue but like the agile little bumble bee who aeronautical engineers say shouldn't be able to fly, EAW goes merrily on it's way, absorbing whatever we throw at it.





I'll tell you something else.

We have over 400 views of this thread in three days. It indicates that members like to read about the under the hood stuff that goes into creating the advances EAW modders make on a regular basis.

As long as the textures line up and the various elements within those texture panels line up I'll be happy. Unfortunately, many "updated" models still have the errors in alignments within the panels and other rendering issues that make skinning difficult. I know that I have driven Ray and 'he who is not mentioned' over the edge when asking for reversing wings and elevators, gaps between panels and misaligned elements be fixed. Over the years I have learned a few of the spells and secret handshakes it takes to repair these flaws. But, I am far from being a master and don't have the necessary knowledge or skills to make my own models. If I wasn't such a skinnin ho with a serious jones for accurate lines and rivets it wouldn't matter.

And that's my 2 cents on the matter

Ray,
My intent was not to say that you are causing a bottleneck. My intent was to explain where the choke points are located in the pipeline. I do not know if EAW use the multiple pipelines of modern cards, but if practices consider the results within a single pipeline it would be a good thing. Just my opinion.

IM,
There is noting wrong with being a rivet counter. I have 4 nights of hobby time into this engine deck and it is still far from done. I understand why texture artists want UV editing, but when your the last warm body then you work where you can see results.

Edit:
Thinking more about IM's problem with skinning:
Would it be possible for the 3DZ maker to use a grid texture like the one here to better align the polygons for the skinner?

Actually I do put a grid over the texture to line up the mapping.

Some thoughts on this: .

One is that there are A LOT of models out there and I'm only one man.

Two is that I adhere religiously to the motto of "The enemy of good is perfect".

Three is that rivet counters are always free, nay encouraged to fix these problems themselves. While conjuring rendering sequences is a dark art, 3DZ studio is not hard to master for correcting texture misalignment issues..