BritAldo, the "Empty F" debate continues.

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..

True, that the enemy of good is perfect. All you have to do is look at the damage I have caused to a community with my obsession with perfection. Forgive me, this does ramble a bit. as I discuss my history.

I am currently making a Cromwell Mk4 (C hull) 3D model and creating the factory fresh texture for it. Actually, I learned (from Geezer) to make the base texture in grey scale first. That is what I am working on. Fortunately, the current PE object editor is rewritten so that it can add completed, child objects to the parent. This is similar to your empty F format. The base model was fairly easy to make (PE allows 30 child objects), but as I have been texturing each part, I found myself needing to tweak every part of the model to use the minimal number of pixels, yet allow the sharpest textures. The more I work on this model, the more I think back to my early days of modding and all I learned from an professional artist.

I had the privilege to work with Geezer while we were both learning to mod. It was a rocky relationship as I made 3D models and expected perfection from the final textures. I was learning code and had an understanding how precious the texture space was. He knew art and did his best with the 16x16 pixel limitation of PE, we did not have the luxury of UV skinning. I do not know how long I spent reducing his textures to better fit the needs of the game engine. This was the delay of PE's Brit44 mod after version 1.04. It took me even longer to realize the insult I had done to the artist. Too his credit, he was mad and silent for a while, but he continued to teach the community how to create art. This was also a lesson to me in humility, though that took the longest to sink into my skull. Geezer has inspired me to expand my 3D modeling into the texturing world, including UV texturing.

Crap, that is uber rambling.

Ray,
You encourage texture artists to learn 3D modeling. This is great and encouraged, but have you thought at the inverse and learning a bit of skinning? My post is simply to encourage you to think about adding this skill to your tool box.

EAW is hobby time. Every modder is free to do as they wish.

Brit, I do a lot of skinning, usually based off another contributor's work because I'm simply not that good at making something from scratch. Don't have the "eye" for it.

But here's the thing.

When I got into making new models or upgrading old models I learned 3dz Studio and the arcane art of rendering sequences generation.

Then I learned to use Photoshop to make the skins match what I'd done with the 3dz model.

Then I learned how to make a flight model to go with the new model.

Then how to add weapons to the new plane.

Then how to search the internet for a new hangar screen for the new plane.

Then how to add the new model to the 1.6 inventory and how to get it into the game.

And most importantly for this discussion, I have fixed R/S, mapping and texture errors on just about every plane I've upgraded.

Never said anything about it, just fixed them and moved on.

Do you see where I'm going with this?

You fellows are incomprehensible to me.

Talented, talented, talented.

Well, thanks.

We're an incomprehensible group to be sure.

I mean, what person in their right mind fools around with a 20 year old flight sim?

Although, come to think of it, we're way past fooling around with 20 years olds in general so I guess the virtual world is where we belong. :-)

Yes I do. I am sorry I was not here at the beginning to know your progress. It is impressive, and my internet conclusions of you are grossly underestimated.

Let me add one last thought from my life. I have been a motorcycle mechanic for more then 30 years. I have played at every aspect other then owner (unless you count my work from home and a small stint of funding a race team). In recent years I have learned that it is hard for me to remember that what is easy for me is a foreign language to a newbee. I hope you have an easier time remembering this then "That Prick Al" (as I am known in the motorcycle community).

OG,
If you can balance the ego's of modders, then you are a god.

I will point out that there are three guys on this forum who are standouts as far as coaching newbies in the arcane arts of EAW modding.

Mr. Jelly, Moggy and me.

What we've experienced is that most newbies don't really want to climb the steep hill. That's fine, not everyone is as deep into EAW as we are, but we cannot be described as secretive or high handed in any of our dealings.

Personally, I'd love to take a couple of neophytes under my wing to learn all that's involved with model making, scenario building, flight modeling and anything else that's rolling around in this head of mine.

All they have to do is ask.

Second that Ray.

Quite happy to share what's been gained by endless experimentation, as Charles Gunst, Paulo Morais, DOM, Woolfman and others were happy to share with me way back when.

We all stand on the shoulders of those pioneers.

That is a very generous offer. It could help bring in some new people and add to those who endeavor to keep EAW running and improving.

I know we have a lot of stickies here already, but what would the group opinion be on having Rotton50 make the offer a little more detailed and putting it as another sticky ?

Edit - Moggy posted while I was doing my one finger iPad post. So another generous offer to teach and bring in new people.

I'm glad we have some new optimism and enthusiasm from our moderator. I hope it continues as we really can use it around here. I commend you for your spirit.

I'd be happy to work with anyone who shows real interest in learning. However, it can't be a case of cart before the horse.
Meaning, I'm not going to write up a long instruction manual about 3dz editing, flight modeling or campaign creation on the off chance that a newbie might "take the bait" so to speak.

We're talking some serious time input on my part so I'm going to need a serious apprentice or two.

We had a case a while back on the GEN forum where an experienced modder, indeed, a member of the Code Group, said he wanted to learn target editing, something outside his wheelhouse.

Jel and I spent three intense days pretty much ignoring our own projects to coach this guy because we really could have used another target creator to spread the workload.

After three days he threw up his hands and walked away from it all, while declaring we weren't telling him everything he needed to know and the system only worked with 1.4 (now 1.6). None of which was true.

Ask yourself how willing you'd be to spend time with someone only to have them walk away.

FWIW, I've also spent a fair amount of time coaching a few SimHQ members on 3dz editing only to have them decide it wasn't something they were interested in, thus wasting my time.

So please excuse my reticence but I've been down this road before and at age 67 I have less time to waste.

It does remind me of this -

Commitment and involvement are much like ham and eggs.

The chicken is involved but the pig is totally committed.

The best way to learn modding EAW is to do. Start small: change a loadout, edit a skin. See if you get the yen to do more.

I started here in 2000, wanting to give this rather primitive Wellington model a bit more bang in the bomb load ...

That's correct. Find something that doesn't seem quite right and fix it.

As I said earlier, back in the stone ages of flight sims I corrected a bug in the top speed of the P-38 add-on for SWOTL. It bothered me enough that I learned hex editing and from there............................well, here we are today.

I remember there was a small program for EAW where you could just open it and make changes to aircraft. Change the type and number of guns, engine power, etc.

I remember using it when it was discovered that computer AI flying FW190’s didn’t use their cannons and only fired their machine guns. I used it to change the cannons to machine guns.

Gentlemen, I don't bother much with flight sims anymore, but I regularly return to the forums. This might seem odd, but isn't everyone involved with this hobby? The reason I keep coming back, I am beginning to realise, is because of the people. This thread is a prime example. I mean this in a very positive way-you are all honest, principled and grounded. No f@#king s#@t from any of you. It's so hard to find this anywhere nowadays.

Thank you for the kind words.

Indeed, this past month has been great.

I must say, this is what the old EAW forum was like and it's nice to be here for the revival.

I want to make a long, thought out post, but I am 8 beers in, so I will try to keep this simple. Rebuttals are welcome. Once I realized I could not make a living by modding , I started to look at it as a hobby. I equate modding to something like building scale models.

The motivation for modding is both bitter and sweet. The bitterness is created by ego, frustration, and desire for monetary gain. The sweetness is the comrodary (spelling) and the sure joy of creating something new.

Modding an older game is like building a scale model. EAW is an old game engine now, so the paranoia of intellectual property theft is minimal, but any new modder should not be expected to be given the keys to the city. This is an older game. It was expected that people creating content were professionals working with limited tools and vast experience. The newbee has to realize there is a learning curve. The newbee also has to start with the knowledge that this is an older game. It can not do 3000 polygon models and/or 300 players in a MP game. It can, if you rewrite everything. But that would be a life's work or a MOD to Far.

Modern game engines that can be modded have tools that require little learning. A novice will find early joy with a game that has tools that are simple point and click. An opinion, could you imagine a newbee willing to hex edit a file? Anything created 20 years ago will require you to learn how it was done back in the day. The modern tools prevent the modder from lerning how to create these things. That is fine if all you want to do is add something in your spare time. But, you do not learn how you created it.

Ego can only be controlled by the individual. If the community offends your ego, then you should leave. Do not make some war, and return only when you think the community has something to offer you. Speak your mind and do not be shy. But , do not assume that comments are a personal insult.

The sweetness, well, that is something that is unique to each individual. They have to decide if the interaction with the game and the community are worth the time they give to the hobby.

Cracking number 10. out

Wasnt there some work on getting 3dz files being worked on with Blender?

Sounds like 8-10 is your sweet spot for technical philosophy because you made a lot of sense.

FWIW, "Technical Philosophy" sounds like a great name for a heavy metal band.

Since there is access to the code, writing a wrapper for a modeling program that uses a text based format would not be hard. The hardest part would be understanding the action codes and how each part of the model is linked in the rendering sequence. Whom ever writes the wrapper would have to be proficient with the modeling program chosen. The free modeling program I like is Metasequoia 4. Version 4.5.6 runs on Windows XP. The native file format (MQ0) is a text based format.
Example:


Thanks for the compliment Ray. I finished off 11 and 12. I have not had one since. I can not remember the last time I was sober for 5 days.

Brit, EAW can only use integers in it's 3DZ format, changing to floats renders every created 3D model useless. The transition to floats isn't really a big deal, however the entire engine needs to be rewritten to make it work. Sydbod believed he could do it but we both know that it was a futile effort to begin with. The Redering Sequence format used in the 3DZ is not comparable with any other program's 3D format and that goes for the vertices and normals sections too. The 3DZ format is too propriatry to EAW.

The previous effort which allowed simple models to be converted into 3DZ information which could be used is one thing, rewriting to code to another format is another and is a waste of time in my eyes. The use of the F.3DZ doesn't change how the game uses the available parts or how to calulate the proper R/S for these parts, irrespective wether the F.3DZ is empty or not, it merely removes the possibillity to use the 256 polygons that part can have.

When the F.3DZ only contains hardpoints, they still need a poper R/S, which may be easier to calculate, provided that all other parts are subject to the exact same rules dictated by the R/S. In this respect there's hardly any difference if there's polygon data in the F.3DZ or not, on either occasion it needs a properly calculated R/S. With Z-buffering the calculation could be done by the hardware but the EXE has no privisions for this and requires yet another major rewrite.

There's an advantage with precalculated normals and R/S, you don't have to do it during the game as it's already done when the 3D model is created. EAW's 3DZ format is fine and work just as good as 3D models in ANY other game, provided the models were correctly created and have a working R/S. In other words Blender insn't needed to create flawless 3DZ models Just saying.

VonBeerhofen

Here's the way the empty F works.

I start by making a four node rectangular element and placing it at the junction of where the tail section and the fuselage come together, facing backwards.

Then I make an element facing outwards at about -20 from the center line and another facing outward 20 from the center line.

Then I make an element facing outward at -1 from the center line and another facing outwards 1 from the center line.

Lastly I make an element facing forward at the distance where the prop will be located.

Each of these elements gets assigned the pilot code, set for bailed out.

Next I add a hardpoint with a new node as a piggyback on each element, setting the node at 0,0,0. Each hardpoint gets assigned the correct section code which I've standardized as follows:

A (25) = tail section - (sometimes I have to combine two separate tail sections before proceeding)
B (26) =left side of fuselage
C(27) = right side of fuselage
E(28) = Left wing
G(29) = Right wing.
P(10) = propeller

Next I calculate all the normals and then formulate a proper rendering sequence.

Of course, before all this I've broken up the model into the correct sections.

Next I run the model in the game to see if the R/S is working properly. Since I set the elements to "bailed out" they don't show up when observing the model.

I note any problems and first adjust the elements to get a new normals calculation. That usually takes care of the problem but if not, I move the elements around a bit and generate a new R/S. That almost always works.

Once I'm satisfied I delete the elements which leaves just the hardpoints and of course I DO NOT run another normals calculation.

There are some differences depending on the nature of the model, multi-engine models requiring a little more work but generally, that's it.

I've also saved up a number of "empty F" main sections with the elements still in place as a sort of library.

For instance, I'm now working on the He177. It is broken up a little different than other bombers I've worked on. The fuselage is one complete section, nose to tail and left to right.

Fortunately, the Blenheim is broken up exactly the same way so I can use that empty F rather than make a new one.

Really, it's a pretty simple concept and since it's based on the EAW default PShell.3dz concept that binds twin engine plane together, it doesn't put any more stress on a PC that that does.

Good points VBH. It sounds like it would be easier to improve the existing object editor then to port it to some other editor.

I agree, and would call that an understatement when you are not using the GPU.


I believe the code group has access to the object editor. Do they also have access to the render sequence tool?

I don't know if they have the original code, I certainly don't but the calculator tool is available to anyone, when people want it they can PM me and I'll make it available.

VonBeerhofen

FWIW, there was an aborted attempt to incorporate the R/S calculator into 3dz Studio in the same way that the Normals calculator was Shame it wasn't completed.

The big problem with the existing calculator is that it is a pass / fail program. It either gives you an R/S or it runs until it fills up your hard drive with junk, unless of course you turn it off. It does not analyze the model and tell you which elements fail the R/S.

So what you end up doing is adding two or three elements at a time, stop to check the R/S and if it doesn't pass, you have to go back in and adjust the offending element until it does pass, then continue in this vein until the model is complete. If you add more than two or three elements at a time it makes finding an offending element a PITA.

Not a big deal if you're making simple, box like shapes such as buildings or other TMOD's but anything as complex as an aircraft model becomes a real headache.

For what I do, it's much faster to take a lo-res model with a good R/S, break it up and apply the empty F process to make a hi-res model.