[OPTing] texture limits

Need help editing the game? Check for help here!

Moderators: Darksaber, General_Trageton, Forceflow

Re: [OPTing] texture limits

User avatar
keiranhalcyon7
Cadet 2nd Class
Posts: 95
Joined: Tue Jan 02, 2018 6:41 am

Post by keiranhalcyon7 » Tue May 22, 2018 6:11 am

ual002 wrote:
Tue May 22, 2018 2:14 am
Question... are there examples of different models attached to seperate flight group colors or does it only affect textures?
Examples? Maybe not in circulation, but see viewtopic.php?p=154280#p154280.

JeremyaFr
Lieutenant JG
XWAU Member
Posts: 746
Joined: Mon Jan 18, 2010 5:52 pm
Contact:

Post by JeremyaFr » Tue May 22, 2018 12:03 pm

With a geometry selector (flight group color), the ship stats (in the exe), descriptor, hardpoints and engine glows (in the opt) are shared between the different elements in the switch node. Only the rendered geometry is affected.

User avatar
ual002
Cadet 1st Class
Galactic Empire
Posts: 148
Joined: Wed Sep 24, 2008 2:23 am

Post by ual002 » Tue May 22, 2018 6:35 pm

So there would be no class consolidations... just minor model detail changes for existing ships.. more in line with my YT series freighter suggestion.

User avatar
Driftwood
Lieutenant Commander
XWAU Member
Posts: 1183
Joined: Wed Oct 22, 2003 11:01 pm
Contact:

Post by Driftwood » Wed May 23, 2018 2:53 am

ual002 wrote:
Tue May 22, 2018 2:14 am
Question... are there examples of different models attached to seperate flight group colors or does it only affect textures?

I ask because if multiple models and textures can occupy a single slot, then we have the ability to condense specific groupings of like ships into a single slot. ISD I and ISD II occupying the same slot for instance with multiple livery variations of each. VSDs, calamari classes, etc.

Now I am realizing a few limitations... first, an editor that can select beyond the standard 4 FG colors, and second, variations in ship stats, specifically shields and engine speeds... and finally the tech library.

This is mainly a thought exercise but the potential to have the same ship with minor model details and colors is very exciting. For example... a YT1300 model with and without nose cone, with variations of color scheme. Artistic and unique interpretations of smuggler and trader models of YT2000s, 2400s and even murian transports.
The ISD and VSD would likely be easy enough to change visually, but the stats and weapon loadouts would be identical. I personally have no issue with this.
The Calamari cruisers would only work with the two that share the same base hull. I personally have no issue with this.
The Interdictor/Enforcer would be easy enough also. I personally have no issue with this.

Beyond those I fail to see the point as offhand besides the few TIE packages and the custom X-Wing skins I can't think of anything that would be viable to convert. Just those 6 ships, would net us an additional 4 shipslots.

If "we" were feeling ambitious the First Order TF, and TI could be rolled into the base model and the 181st skin, and the TD, TB, RGInt, could also likely as well. Plus the Mining Guild TIE.

And I guess the TFA Falcon also.

Fundamentally I believe it'd be a massive quality of life upgrade, BUT does anybody really want to take the time to do it. The big question is, IF "we" (I could try myself if DS had no issue with it, when / if, I have the time.)

Actually, this explains how the Escort Transport uses a different model for the control ships now that I think about it, but I don't know how it was implemented in the missions offhand.

I think long term though, having an easy way through a mission editor to change the FGs beyond 0-4 would likely be a necessity to make this functionality relatively easily accessible for the end user. Lets face it, with some of the mission hooks, while easy enough to use, is going to put off a super casual, non-modder, period.
Image
R.I.P RSF_Zjon1, RSF_Mac, RSF_Vasquez

User avatar
ual002
Cadet 1st Class
Galactic Empire
Posts: 148
Joined: Wed Sep 24, 2008 2:23 am

Post by ual002 » Wed May 23, 2018 3:15 am

Yea... it is just mainly a thought experement. But your additional mention of potential consolidations does provide us space for things like those incorporated into the RebCP that are aproprate to inclusion in DSUCP if that is both acceptable and desired.

Yogme will be our best bet going forward unless someone has a line on Troy. More advanced users could use the newly available hook but I definately understand consolidation pretty much requires both an easily usable editor and massive changes to vanilla campaigns.

So yes. Consolidation seems like well more work than it is worth to open a few ship slots. It can definately help consolidate similar add on ships lesser used.

User avatar
Driftwood
Lieutenant Commander
XWAU Member
Posts: 1183
Joined: Wed Oct 22, 2003 11:01 pm
Contact:

Post by Driftwood » Wed May 23, 2018 3:36 am

I can't imagine changing a handful of fg and then the colors would take very long, but it would be tedious to go through every mission.

The hard part is adapting the models.

That's what's daunting to me...
Image
R.I.P RSF_Zjon1, RSF_Mac, RSF_Vasquez

User avatar
keiranhalcyon7
Cadet 2nd Class
Posts: 95
Joined: Tue Jan 02, 2018 6:41 am

Post by keiranhalcyon7 » Thu May 24, 2018 3:45 pm

No on the ISD/VSD. The VSD is much smaller and has a much lighter armament. Additionally, consolidating the Interdictor and Enforcer would probably give the interdiction property to the Enforcer (though this might be fixable with a hook).

The Cal cruisers are a neat idea. On top of consolidating the two that differ only in the wings, additional variations could be introduced to reflect that each ship is theoretically supposed to be unique. That's still canon, right?

IIRC, there are several Falcon variants, differing mostly in the pilots, that could be merged. Also Lady Luck/Luxury Yacht. I'd love to have a visibly pilotless version for that mission where K'Armyn Viraxo's ship turns out to be on autopilot. Most ships with multiple install options are candidates, really.

As for updating the existing missions - It's possible to build custom programs on top of Yogeme's back-end to automate just about anything. Like, iterate over all flight groups in all missions looking for specific ships and altering them. It's not as straightforward as just using the editor, since you have to learn the coding api, but would be less tedious than doing it by hand. (That said, I haven't gotten such a custom program working yet, so the idea is a little theoretical.)

User avatar
Driftwood
Lieutenant Commander
XWAU Member
Posts: 1183
Joined: Wed Oct 22, 2003 11:01 pm
Contact:

Post by Driftwood » Thu May 24, 2018 4:20 pm

There are two ISD and vsd models, occupying4 slots. Why on earth would one assume we'd switch the isd with the vsd, rather than consolidate within the same class to net 2x more slots.

The luxury yacht displays a base, not exterior models when controlled by AI outside your flight group. No changes are needed.
Image
R.I.P RSF_Zjon1, RSF_Mac, RSF_Vasquez

User avatar
keiranhalcyon7
Cadet 2nd Class
Posts: 95
Joined: Tue Jan 02, 2018 6:41 am

Post by keiranhalcyon7 » Thu May 24, 2018 4:32 pm

Oh you meant the ISD/ISDII and VSD/VSDII. Duh. Still a no, though, since their armaments & other stats are quite different.

Ok, I give. Where can I find an explanation of the difference between the base and exterior opts?
ual002 wrote:
Thu May 17, 2018 8:36 pm
Yogme isnt set up for it but if the hook exists you can throw a ticket into the Yogme github to request support.
Done: https://github.com/MikeG621/YOGEME/issues/21

Rich C
Lieutenant JG
Posts: 746
Joined: Thu Jan 18, 2001 12:01 am

Post by Rich C » Thu May 24, 2018 6:54 pm

keiranhalcyon7 wrote:
Thu May 24, 2018 4:32 pm
Where can I find an explanation of the difference between the base and exterior opts?
Base OPT is used for AI craft; Exterior is used when you view your own ship, in flight and in the hangar. Exterior models usually have a bit more detail, and a cockpit interior.
"If you're going through hell, keep going."

User avatar
keiranhalcyon7
Cadet 2nd Class
Posts: 95
Joined: Tue Jan 02, 2018 6:41 am

Post by keiranhalcyon7 » Fri May 25, 2018 12:07 am

Question (for Jeremy, I guess): is there any way to embed in the opt a descriptor string for each fg color?

JeremyaFr
Lieutenant JG
XWAU Member
Posts: 746
Joined: Mon Jan 18, 2010 5:52 pm
Contact:

Post by JeremyaFr » Fri May 25, 2018 8:04 am

Hello,
You can set a name (or any text) for each node (not only textures) in the opt file. But for now, the only way to do that is by code. Then you can view the string associated with the nodes with OptStructure (part of XwaOptEditor).

User avatar
keiranhalcyon7
Cadet 2nd Class
Posts: 95
Joined: Tue Jan 02, 2018 6:41 am

Post by keiranhalcyon7 » Sat May 26, 2018 3:52 am

Hmm. Ok. My idea was to have some standardized labeling scheme for the fg colors that a hypothetical opt-aware mission editor could display in the fg color field instead of making assumptions like "red" and "gold".

JeremyaFr
Lieutenant JG
XWAU Member
Posts: 746
Joined: Mon Jan 18, 2010 5:52 pm
Contact:

Post by JeremyaFr » Wed May 30, 2018 4:08 pm

UPDATE

Hello,
I've fixed a crash with OPTs that have a FaceGroup with more than around 1024 3d vertices. I've increased the size of the execute buffer to fix the buffer overflow. The limit is now around 32768 3d vertices.

Please redownload xwa_hook_opt_limit.zip

Bman
Ensign
Posts: 480
Joined: Mon Apr 05, 2004 11:01 pm

Post by Bman » Mon Jul 02, 2018 3:42 am

Hello, proof of concept. Using only Jeremy's editor, I've been able to successfully role all 6 flight group textures from Xwing Red Squadron including all 6 separate droid heads into one model (the base, exterior, cockpit, and alternate cockpit). I did not include the Gold, Blue, or Green group colored markings since they would add to the file size, but they would work well under their own color groups. For example: Flightmodels/Xwing.opt = Flightmodels/XwingBlue.opt, Flightmodels/XwingExterior.opt = Flightmodels/XwingBlueExterior.opt, Flightmodels/XwingCockpit.opt = Flightmodels/XwingBlueCockpit.opt and with gold and green group and so forth. I've tested these and they work perfectly and I've been able to get all 6 separate Xwings present in the same mission. :-) Question then is what if someone wanted Xwing Red and Blue and Gold groups in the same mission? Then contents of Blue, Gold, and/or Green group model(s) can be assigned temporarily to another slot with similar stats like the Partisan and T70 Xwing and so forth.


Anyway, using Jeremy's editor I'm selecting the View tab, then clicking Version: [spin-up button] (FlightGroup Colors) 0,1,2,3,4,5 to see all six Xwing markings from Red Group Squadron in this video I recorded:

https://www.dailymotion.com/video/x6ncwit


I think this same technique can be used with other models, even for such things such as atmospheric projects like DTM did... perhaps clouds, asteroids with different textures, buildings/city scapes, trees/vegetation, mountains, landscapes and planet surfaces from a birds-eye view etc.
W-I-P: ISD-II, XQ-1 Platform1, New Escort Carrier Hangar, & Misc.

User avatar
keiranhalcyon7
Cadet 2nd Class
Posts: 95
Joined: Tue Jan 02, 2018 6:41 am

Post by keiranhalcyon7 » Mon Jul 02, 2018 4:14 am

How does the merged opt size compare to the individual opts? Is there any performance impact?

Bman
Ensign
Posts: 480
Joined: Mon Apr 05, 2004 11:01 pm

Post by Bman » Mon Jul 02, 2018 4:59 am

I didn't notice any performance issues except maybe in the hangar, but I think it's related to other things I have present. I sent DS his files back so he can review and see if this is feasible. A BIG assumption I made is all meshes (or rather all three of the related .opt files) are exactly the same from Red1 through Red6. I ended up with 40 meshes per each .opt file since placeholder meshes were needed as indicated in *pilot.txt and *SFoils.txt files. Reording all of the rotating meshes in the list of Jeremy's editor to the top or moving them all to the bottom of the list might be more efficient and reduce file size. But they affect the two text files. Some of the FG textures are different for sure, but that's the easy part. In summary, all I did was start with Red1 and import the other 5 droid meshes (Xwings), keep any different textures as a sequential FG colors where needed, and delete all of the rest of the redundant imported meshes. Didn't need Optech editor at all.
W-I-P: ISD-II, XQ-1 Platform1, New Escort Carrier Hangar, & Misc.

User avatar
Driftwood
Lieutenant Commander
XWAU Member
Posts: 1183
Joined: Wed Oct 22, 2003 11:01 pm
Contact:

Post by Driftwood » Tue Jul 03, 2018 11:20 pm

Should be pretty straight forward to add other FG colors then at this point since you did the hard part by adding the new meshes and structuring everything I would imagine. I applaud your industrious efforts on this venture. Perhaps we can look forward to DS releasing the updated files at some point in the future.

Personally I'd simply advocate adding more FG colors to the newly modified opt, rather than using the opt replacer hook, I'd figure for just additional textures it's not really necessary.

We can get up to what 120 per last thread on this regarding texture limits?
Image
R.I.P RSF_Zjon1, RSF_Mac, RSF_Vasquez

Bman
Ensign
Posts: 480
Joined: Mon Apr 05, 2004 11:01 pm

Post by Bman » Wed Jul 04, 2018 12:44 am

What I did is cloak the droids.... they're all there but I used a transparent 8x8 texture to hide the mesh faces when other 5 FG "colors" as not in use.
We can get up to 128 FG textures on any FaceGroup/Mesh (indexed as 0 thru 127) but file size would be huge if you maxed out even on one mesh and depending on resolutions used. It would be more applicable for static models ... idea I had was a spaceport/city like NaShadda et al or background images.
W-I-P: ISD-II, XQ-1 Platform1, New Escort Carrier Hangar, & Misc.

User avatar
Driftwood
Lieutenant Commander
XWAU Member
Posts: 1183
Joined: Wed Oct 22, 2003 11:01 pm
Contact:

Post by Driftwood » Wed Jul 04, 2018 1:51 am

I played arma mil sims for several years, plus most of the Bethesda rpgs, so perhaps I'm a bit numb to file sizes at this point since my game folder would average 150+ gb.

So I have to play devil's advocate at this point. With how cheap hard drive space is, and efficient modern internet is comparably to 1999, are we really overly concerned about file sizes, provided the data included is even 'peripherally useful"?

As is even with more opts than I have slots for, my install is still under 2gb last I checked.

Provided it doesn't crash the game, isn't it worth maximizing efficiency for limited slots? Increasing options available, and utilizing our new limits to the fullest?

I'm just spitballing here, I have big ideas, and some albeit limited ability to harness and produce them, but I'm definitely of the opinion of utilizing any quality of life feature we can at this point.

I'm going to start messing with the TIE models I think... I've been debating what you've done with the swing since we discussed this concept in the other thread.

Out of curiosity, what was the final file size, minus Y/B/G flightgroup textures?
Image
R.I.P RSF_Zjon1, RSF_Mac, RSF_Vasquez

User avatar
keiranhalcyon7
Cadet 2nd Class
Posts: 95
Joined: Tue Jan 02, 2018 6:41 am

Post by keiranhalcyon7 » Wed Jul 04, 2018 2:44 am

It's not just the size on disk or the bandwidth, though. Depending on how the engine handles the data, pushing everything into a single huge opt could bring the engine to a crawl, even on modern hardware. That's not to say that I oppose this effort - just that I think it should be tested on some less-than-bleeding-edge hardware before rolling it into the official release. (My PC is from... 2011? Holy shit has it been 7 years since I built it? Gah!)

"Cloaking" the unused droid models is neat, but kind of a hack, since it forces the engine to process a bunch of geometries that it shouldn't have to. I think waiting for Jeremy to add support to XwaOptEditor for the switch node solution he discovered is the better way to go.

User avatar
Driftwood
Lieutenant Commander
XWAU Member
Posts: 1183
Joined: Wed Oct 22, 2003 11:01 pm
Contact:

Post by Driftwood » Wed Jul 04, 2018 3:17 am

I don't necessarily disagree with any points you've made. But obviously, we're hypothesizing (reasonably so) at this point. And testing will be required to see if this is viable, as clearly performance is rather important.

I also would agree with using Jeremy's hidden geometry functionality likely being a "better" way to utilize this functionality. However, since there isn't support to easily access that functionality for that right now by my understanding, I'll gladly settle for this "hack" method for my own purposes. And I'll be thrilled to be able to have the ability to have Darksaber's TIE Fighter, Mining Guild Fighter, and First Order TIE all in one slot. (Cake and eat it too :P) Provided there aren't any significant unforseen complications.

My hypothesis is that this will work with no issues regarding performance. I do however predict that one will likely still be able to collide with transparent meshes as I presume that merely altering the appearance of a model via texture render does not adapt the mesh geometry too. (I see this being an issue with the TIE bomber model that has reversed wings regarding a potential game-play issue due to unintended collisions)

My second hypothesis is that the game rendering a model with a transparent texture over multiple meshes in and of itself isn't going to be a problem. However, I do recall DTM saying that a given opt has a limit of how many transparent textures it can use before running into problems, but as I do not know what that limit is, this is the likely "big issue" I expect to possibly run into.

As for not being concerned with the amount of meshes rendered in the engine, transparent* or otherwise, my logic is based on the fact that many (fine, pretty much all) of my opts exceed the old game limitations in regards to poly count significantly and in orders of magnitude comparatively and perform just fine. With those opts there's an awful lot of model being rendered that if it wasn't for Jeremy's hooks surpassing the original limits would simply crash the game previously. I don't see combined meshes creating any problems, provided the meshes all fit within the same collision boxes.

I believe that taking existing XWA opts that fit well within the limitations of the old game specs and merging them while staying within the new game limits, should not have much of a performance drop, if any, comparatively if you are running on a relatively modern system. No more so than the Rebel Platform, or Resurgent Star Destroyer causes performance dips.

Granted, I'm assuming one isn't running Win98 on a toaster, or running 96 modified TIE fighters in the same region at once.

I finished consolidating the Mining Guild TIE, and the basic TIE Fighter base opts and they're still well under the old game limits for a single opt, as for the file size, it's around 3mb. The opt currently has has 57 textures, and 16 meshes, all with less than 512 vertices/mesh. I can add 34 more meshes to the model and combine meshes if necessary up to 4096 vertices/mesh if I approach the 50 mesh hardcap, unsure about max textures per model offhand. And incidentally, since the Mining Guild wings fit the basic TIE geometry, no need to worry about collision issues. I should be able to merge the FO TIE model with little to no issue.

The big downside I see regarding this venture at the moment, is that it will simply take time to merge and set up the FG colors/textures on a given opt in the event they only have 1fg color per face group.
The TIE Fighter took approximately 1 hour to convert properly, and required renaming the MG TIE wing textures in blender and deleting unwanted meshes to import (for my sanity) into OptEditor. Given how simple the exterior model is, it shouldn't take much longer than that, possibly less.

As for a list of viable mergable ships offhand:

TIE Fighter
Mining Guild TIE modified mesh - done
FO TIE modified mesh - easily viable
**Special Forces TIE (entirely different weapon loadout, probably deserves own slot)

TIE Interceptor, 181st texture - easily viable
Royal Guard Interceptor, modified mesh - easily viable
FO Interceptor (I believe RG Int retexture) - easily viable

TIE Scimitar, FO texture - easily viable

TIE Bomber, FO texture/mesh - easily viable

TIE Defender, FO texture - easily viable

X-Wing, texures mostly, droid meshes - more difficult/viable per Bman (Rotating meshes are an unknown variable to me)

B-Wing, E2 mesh - easily viable

Anyways, it's still an interesting proof of concept, and I'm tired and going to bed now.
Image
R.I.P RSF_Zjon1, RSF_Mac, RSF_Vasquez

User avatar
Darksaber

Fleet Admiral (Administrator)
Posts: 9300
Joined: Mon Jan 10, 2000 12:01 am
Contact:

Post by Darksaber » Thu Jul 05, 2018 1:43 pm

Sorry but that's not going to happen anytime soon

The tie fighters, MG, standard and first order are all different designs, it's not like I just slapped another set of textures on the same model, when I made the FO Ties I updated the Ball, wing struts and wings, the MG is based off that design not the standard TF.

Bwing and E2 are also different, the cockpit module is a lot longer on the E2

Also importing craft degrades the textures, in both Optech and Opt Editor so if you import too many time the craft is going to look darker, sorry but I'm not giving permission for this.

By all means test your own craft, just please leave mine alone.
Good Things Come To Those Who Wait....
Darksaber's X-Wing Station

User avatar
Driftwood
Lieutenant Commander
XWAU Member
Posts: 1183
Joined: Wed Oct 22, 2003 11:01 pm
Contact:

Post by Driftwood » Thu Jul 05, 2018 8:26 pm

Fair enough.
Image
R.I.P RSF_Zjon1, RSF_Mac, RSF_Vasquez

User avatar
Darksaber

Fleet Admiral (Administrator)
Posts: 9300
Joined: Mon Jan 10, 2000 12:01 am
Contact:

Post by Darksaber » Fri Jul 06, 2018 12:04 pm

Thanks :)
Good Things Come To Those Who Wait....
Darksaber's X-Wing Station

Post Reply