In the short window Fable was available I decided to finish off one of my background projects and was pretty blown away with the combination of Ghidra and Fable working together.
Xenon II - Megablast by the Bitmap Brothers was one of my favorite games growing up. The style and music (Bomb The Bass!!) was groundbreaking for the time IMHO.
The gold standard version of Xenon II was for the Amiga but I wasn't cool enough to have one, so I had to make do the with (also amazing) PC port from the Assembly Line.
I've always want to make the PC port the best version and show those Amiga guys the true way of DOS.
I've been working on reverse engineering the PC version into Typescript and making some updates. I'd got a bunch of the core work done using Opus etc but wanted to see if the Fable reverse engineer hype was true.
Using Ghidra for a decompilation pre-pass / spot decompilation and Fable was amazing. I got more done in two days than I'd got done in 6 or 7 weekends before that.
I ended up with
* A Jos Stam style GPU accelerated fluid simulation for the play field
* A modular FM synth with impulse response audio system
* Rock solid 60 fps
* Fully updated collision, projectile and shield rendering
The gameplay is authentic to the original, but the FX, audio and rendering is fully updated.
Fully credit of course goes to the Bitmap Brothers / Assembly line.
If you’ve worked in high end production I would love to work at your facility.
You clearly understand many of the issues involved but downplay the complexity in running high end assets in less than perfect production.
Unless the industry has changed dramatically in 5 years shot changes, per shot fixes, variants (clean, dirty, destroyed), shader tweaks, happen on every single show I’ve ever been part of.
Render time and storage is one factor as is individual artist iteration, but the real productivity killer is an inter discipline iteration.
Going from a “blurry texture” note in comp to a TD fix to a texture “upres” is potentially a 5 person, 4 day turn around. I would trade a whole bunch of cpu and storage to avoid that.
Computers are cheap, people are expensive, people coordinating even more so.
This was created with the requirement that the director be able to use it at will. Closeups. Set replacements, destruction, the works.
You don’t have a shot breakdown or camera list.
You’ve got 6 months of pre production to support 1000 shots. Once in production you will be the only texture artist supporting 30 TDS.
How do you spend your 6 months to make sure production runs smoothly?
I’m kinda interested in your experience of this stuff as the numbers you’re quoting for 2k work are, in my experience, waaaaaay off and are closer to how a high end games asset would currently be textured.
I don’t disagree with you that the numbers involved are crazy when taken in isolation but it is (or at least was 5 years ago) a very common workflow at ILM, Weta, Dneg, DD, R&H Framestore etc etc. The quoted high numbers are the very upper end but many thousands of assets on hundreds of productions have been textured at what I believe you would consider “insane” detail levels.
Mari was designed in production at Weta, based off the lessons learned from, well, everything that Weta does.
Take for example, a large hero asset like King Kong.
Kong look development started many months before a script was locked down. Kong is 60ft tall, our leading lady is 5’2”.
We think we need shots where she’ll be standing in Kong’s hands, feet, be lifted up to his face, nose etc.
So we need fingers prints that will stand up at 4K renders, tear ducts, pores on the inside on the nose, etc etc but we don’t know. All of which will have to match shot plates in detail.
We could address each of these as the shots turn up and tell the director (who owns the company) he needs to wait a few days for his new shot, or you can break Kong into 500 patches and create a texture for each of the diffuse, 3 spec, 3 subsurface, 4 bump, dirt, blood, dust, scratch, fur, flow etc etc inputs to our shaders.
Let’s says we have 500 UDIM patches for Kong so we can sit our leading lady on the finger tips, and 20 channels to drive our shaders and effects systems.
When working the artist uses 6 paint layers for each channel ( 6 is a massive underestimate for most interesting texture work).
So we have 500 patches * 20 channels * 6 layers which gives us 60k images. Not all of these will need be at 4K however.
For Kong replace any hero asset where shots will be more placed “in and on” the asset rather than “at”. Heli carriers, oil rigs, elven great halls, space ships, giant robots.... The line between asset and environment is blurred at that point and maybe think “set” rather than “asset”
Texture caching in modern renders tends to be on demand and paged so it is very unlikely the full texture set is ever pulled from the filers.
Over texturing like this can be a good decision depending on the production. Asset creation often starts a long time before shots or cameras are locked down.
If you don’t know how an asset is to be used it makes sense to texture all of it upfront as if it will be full screen, 4K.
Taking an asset off final to ‘Upres’ it for a can be a pain in the ass and more costly than just detailing it up in the first place.
In isolation it’s a insane amount of detail and given perfect production planning it is normally not needed, but until directors lock down the scripts and shots it can be the simplest option.
The largest texture sets are heading towards 1TB in size, or at least they were when I was last involved in production support. I saw Mari projects north of 650gb and that was 5 years ago. Disclaimer : I wrote Mari, the vfx industry standard painting system.
Note though these are not single 1TB textures, they’re multiple sets of textures, plus all of the layers that constitute them. Some large robots In particular had 65k 4K textures if you count the layers.
Xenon II - Megablast by the Bitmap Brothers was one of my favorite games growing up. The style and music (Bomb The Bass!!) was groundbreaking for the time IMHO.
The gold standard version of Xenon II was for the Amiga but I wasn't cool enough to have one, so I had to make do the with (also amazing) PC port from the Assembly Line.
I've always want to make the PC port the best version and show those Amiga guys the true way of DOS.
I've been working on reverse engineering the PC version into Typescript and making some updates. I'd got a bunch of the core work done using Opus etc but wanted to see if the Fable reverse engineer hype was true.
Using Ghidra for a decompilation pre-pass / spot decompilation and Fable was amazing. I got more done in two days than I'd got done in 6 or 7 weekends before that.
I ended up with
* A Jos Stam style GPU accelerated fluid simulation for the play field * A modular FM synth with impulse response audio system * Rock solid 60 fps * Fully updated collision, projectile and shield rendering
The gameplay is authentic to the original, but the FX, audio and rendering is fully updated.
Fully credit of course goes to the Bitmap Brothers / Assembly line.