#List of useful tools to Convert Assets (3D and 2D)

1 messages · Page 4 of 1

true apex
#

thankful i have my textures saved so this will be fun

cursive junco
#

The before image has that hard line across the chest that the after image does not.

true apex
#

i see the differnces

#

im quite intrigued

cursive junco
#

Thanks a lot for the expedient fix, @wicked gulch

true apex
#

seriously and the inclusion of DEFF

#

im gonna learn some new things on blender im excited

#

i never touched blender or anything til i came across this programs

true apex
#

So ummm not sure if just me and I’m currently at work but the DEFF is only letting me convert textures and not the animations or particles, or is that all that it is right now?

cursive junco
#

@wicked gulch Sorry to bother you again, but I'm also seeing this with a few select models. Sometimes textures are just too dark. Fruegel's cape should be purple, and Mole's mound should be bright green. Is this something that is happening to the texture during conversion, or is the game correcting for it to lighten them? Should I be using either Blender or an external tool to desaturate or otherwise modify the textures to be more true to their in-game appearance?

junior mantle
#

Molypus

#

Platymole?

wicked gulch
#

something around

cursive junco
#

This was with natural forest lighting.

wicked gulch
#

if you want i'm at voice chat

cursive junco
#

Sure. This sin't a priority, though. I can just use Gimp or something to lighten the texture. Go ahead and work on Dart's cool sunglasses.

forest saddle
vestal halo
#

If you want the light to match LoD, I'm guessing you have to add a light and alter its properties / position until the colors seem identical to retail.

#

@sterile lantern Heyo, requesting an explanation of the "basic" light used in battlefields. Is it per-battlefield, where each one has some sort of illumination/color settings?

sterile lantern
#

Yes

#

Scripts can also change lighting

vestal halo
#

Okay, cool. I was on to something haha.

wicked gulch
#

but have dynamic changes... depending on various factors... getting the 'correct' lighting is somehow complex...

wicked gulch
#

the player_combat_script?

#

If not changes from Battle Stage * to Battle Stage we could get a 'Standard' Lighting configuration that should fit

true apex
#

But your probably right Grey

wicked gulch
#

ahhh don't worry just the same setup as previous tools...

#

even if you were using previous version you could just replaces the files and setting the same folders

#

the overwritting of the existent dump is done silently (so if you Convert with this new version the previous glTF files will be replaced with the new ones)...

true apex
#

I figured that part it’s the DEFF portion just lets you convert only textures and not the actual animation or particles which is where I was worried about the set up

wicked gulch
#

ahh yeah

#

Particles are not converted because somehow i yeet my own code and can't make it work... since my very first try was using EULER Calcs, while in the new workflow i'm using Quaternions

sterile lantern
#

I'm like 98% asleep so I won't be any more use than that right now lol

true apex
wicked gulch
#

nop

true apex
#

Oh lol

wicked gulch
#

actually all the animations are converted

#

the "scene" thing came from "how glTF manages the Scene data" + Blender Interaction during Importing the file*

#

i need to research very in depth

#

once i get every part of the puzzle in their places... pull the single scene code will be not much a problem

#

even i'm making all the Databases-Scripts for supporting that directly

true apex
#

Don’t rush was just curious since it wouldn’t let me convert the animation, that box is completely unclickable

#

One again don’t rush yourself to fix it

wicked gulch
#

anyone beside you had the same issue?

#

are you sure that are you using Beta 0.2?

#

the version could be seen in the top bar (where minimize, maximize and close are)

#

or in the About button

true apex
#

Yes cause I can downloaded when you posted the link last night

wicked gulch
#

no error after open it?

true apex
#

Nope

#

I was gonna delete and make a brand new folder since I just got home cause I thought maybe I corrupted it when I put the stuff in the same folder as the 1st version

wicked gulch
#

well i just downloaded the tool and open it and the DEFF Converter is working 🤔

wicked gulch
#

tbh i expect that you had an error, more than a button was not pushable hehehe 😅

#

so a fresh installation always is good too

true apex
#

Yea you know me I’ll find a bug or two for you lol

wicked gulch
#

i always count on that

#

the issue that D-Wrecks got with the inaccuracy of lighting in the model surfaces, lead me to something that was pretty crazy... all this time, since my very first TLoD Conversion tool, i was doing the winding of faces (creation of faces by the vertices linking) in the opposite order that should be... but the Normals bugged like Lavitz crotch still are retail bugged lol

true apex
#

lol

#

Lavitz crotch

wicked gulch
#

those pants always missing for everyone so far...

#

once i put myself to work in the Blender2TLoD Addon again i will fix it

true apex
#

lol yea find the crotch, replace the crotch, make sure the crotch shows up then smash it with a hammer

#

ok starting fresh install

#

huh the READMe is stopping the move at 96% lol my computer doesnt like me lo

wicked gulch
#

that's not related to my tool hehehe 😅 ...

true apex
#

i know thats the funny part

wicked gulch
#

maybe you should be watching protected files or the antivirus

#

sometimes antivirus runs in the background

#

so you cannot tell if it's watching the files

true apex
#

i have it turned off cause i think that was part of our problem last time

#

ok setting it up right now

#

yea all it allows me to click is the convert model textures not Full Scene

wicked gulch
#

that's fine

true apex
#

ok now i feel dumb cause the files are there

wicked gulch
#

as intended

true apex
#

dont mind me Doom i didnt check the actual folder lol the files are there dont mind me

wicked gulch
#

no problem... while it's working for you and you can do your things... it's all right...

true apex
#

loll

#

i do like that the textures are the same

#

while i have the attention of the court lol, umm been playing with Dart's textures and can't find his headband exactly

wicked gulch
wicked gulch
true apex
#

can't also watching my nieces while doing this stuff so slightly distracted

wicked gulch
#

np

#

well the fastest way

#

is taking a good pic of Dart Dragoon

#

for example this one

#

and try to isolate the texture that look the most similar to the one shown in the game...

true apex
#

i guess the hard part is i can find the exact texture on the textures that looks similar to his Normal banana dragoon forms i rocked at

wicked gulch
#

some of them are the same 100%

true apex
#

hmm

#

will try and over layer i didnt think about that

wicked gulch
#

but for some reason they use another palette for it...

#

the reason... i don't know

true apex
#

i literally duplicated his head and just roomed faces and put a red toned color behind it lol

wicked gulch
#

also could be that some of the textures were slightly very slightly more contrast or lighted

true apex
#

that is a good point too

#

since i just ripped everything im gonna try to overlay and see if that helps me find it

#

the tricks and tips ive since learned from getting these models and creating my own database

wicked gulch
#

that's awesome... also tbh i do not get in depth of texture matters because i prefer focusing in my other projects... but maybe you could find some interesting usage for what are you doing... like generate a list of Models that use that same Texture

true apex
#

fun part is ive been creating my own textures along the way

#

but that could be a fun project

wicked gulch
#

also!!!

#

that's sounds great

#

how you do to re-import them into the game?

true apex
#

i havent gotten that far yet lol

#

mostly been just playing and learning

#

that would be the obvious next step putting them into the game so i can use them

wicked gulch
#

anyway that's good to do!... i hope in a future code a Texture creator for TLoD but will take some time and knowledge...

true apex
#

your hoping for what?

wicked gulch
#

to code a tool by myself

#

to create textures for TLoD

true apex
#

awww gotcha

#

that would be amazing

wicked gulch
#

for sure!

wicked gulch
#

Or I'm doing something terribly bad... or Explosion Effect (DEFF) use only half of all the Packed resources in it...

#

including a face animation

#

well i can confirm that there is no face animation

#

i watch frame by frame the Animation and Dart face had his classic Poker face hahaha

wicked gulch
#

scriptResetCameraMovement someone is sure that is resetting the movement and is not actually resetting the position and the attributes?

sterile lantern
wicked gulch
#

well as i thought... resetting all...

sterile lantern
#

It's not resetting position

#

It's resetting the movement vars

wicked gulch
#

but the projection planes and the flags... are not the attributes of the Camera?...

sterile lantern
#

It's not changing the projection plane

#

And look at the javadoc for flags

wicked gulch
#

interesting... there is no function to clear everything...

sterile lantern
#

Why would you want to clear everything? That'd set the camera back to origin

#

Which would probably be in the ground

wicked gulch
#

🤷🏻‍♂️ ... just thought it will exist... sometimes you want to clear everything from camera and setting a new postion would be simply passing new position parameters from a Script...

#

so this method is kind of stopping Camera motion

sterile lantern
#

Clearing things is inefficient, you can just set a new position

restive carbon
#

true, lod is known for its efficiency + optimizations

wicked gulch
#

hmmmm

#

i was thinking...

#

bah better i shut my ass and had all the data presented to clarify my thoughts xD

wicked gulch
#

Well about that was i my thoughts finally i proved myself to be very wrong... which i can say that i'm happy with hehehe

#

btw just finished the Flameshot - Explosion - Final Burst - Red-Eyed Dragon Script Sortings...

#

and waaaaaaoooooowwww

#

this travel to the guts of the DEFF almost break me down...

#

most of the time scripts are a convoluted soup of calls, counter calls, checks, re-checks, move data from here to there because of some reason that i don't get... fork, re-fork, fork-reenter, rewinds, pull ups, push ups well you got the idea...

#

but finally i understand one of the most important things...

#

most of them seems to be very clear divided in 'What i'm doing' blocks...

#

first they setup the BEnts {or BObjs (if needed)} for 'this Scene'

#

then they start to load the things and animate them

#

after the party finish, start to undo the BEnts {or BObjs (if needed)} setups*

#

most of you maybe will say 'DooM don't be so dumb, obviously they do that way'... well actually i was afraid that wans't the case... also because some of the Scripts had not the clear 'ENTRYPOINT' type of writing... some of them had direct Jumps or Calls

#

making sort this decompiled code a very hellish experience

#

now it's time to one-on-one frame-by-frame comparison to get the correct timings and express that in my database files

#

also i'm pretty positive in say that not always they set Waiting frames in a 'global way'*, sometimes i think they set the waiting frames depending on a Animated Model or Particle Lifespan... in other words they attached the waiting depending on the thing that should be happen...

restive carbon
#

madman

#

you did what I wouldnt even begin

wicked gulch
#

i should improve my post-sorting codes to simplify the Scripts...

#

i had some tools written to automatically get some important data and re-sort it

true apex
#

the fact youeven was able to do this is impressive

wicked gulch
#

tbh I'm very surprised that I've learn enough to kind of pull this off... sometimes I look myself to a mirror and try to find out if I'm not kind of possessed by some old coder spirt or something hahaha

wicked gulch
#

still don't get the 'real' difference between scriptSetScriptScript, fork_reenter, scriptLoadSameScriptAndJump. What i mean... technically we can say are different... but in the functionality in my head it's same...
scriptSetScriptScript: Replaces an existing script state's script
scriptLoadSameScriptAndJump: Loads this script into another script state and jumps to a script address
fork_reenter scriptForkAndReenter(){}:/** Forks the script and jumps to an entry point */

#

all of them are making jump to specific addresses and after executing whatever they do... get deallocated...

#

it's obvious that i simplify the idea of them a lot... but are pretty much the same...

wicked gulch
#

while i had a 'more in depth' knowledge of the TLoD Script Engine... decided to halt the TLoD Script Automatic Sort indefinitely... there are a lot of things going on that i cannot solve right now (let's gonna say some 'logic locks')... so... the only way atm it's doing by hand... which burns me a lot... so sorry... my next update will be in a while... atm already sort all the Dart Dragoon Spells... now it's time to clean them, to later generate the Databases

#

sorry for anyone waiting for something more 'speedy' but things are like that... and tbh i feel a little defeated... but as in Dark Souls... the only thing left is start from the last bonfire again, recover you souls and push the boss again... 🤷🏻‍♂️

#

the thing that hurt me the most was... i prepared a Notepad++ UserDefinedLanguage (UDL) file which use syntax highlight for TLoD Scripts

sterile lantern
#

Won't that still come in handy for you?

wicked gulch
#

actually yes... hehehe... but simplifying the way of do this i got the hope one want to join this abhorrent quest... now i find that i'm walking a very lonely path hahahaha

#

this would work just fine for Linear TLoDScripts

#

so the folding will work only with this 'separators' since the Script disassembly had not so clear 'start-end' points...

#

sometimes I wonder how Monoxide did for pull this from nowhere... thanks so much mate... 💪🏻

#

omg... Dart Flameshot had Variable VSync...

#

this means that going from Divider 3 to 4 to 3 and so on

#

we have a Divider 5

#

this is bad.... very bad...

#

i need to refactor the conversion code again

#

i didn't know how variable the VSync Divider could get.... i thought was set from the start and then reset to 'normal' at the end... at least in the Dragoon Transformations were all like that

#

the animation of the fireball + Camera it's something wild in this Script hahaha

sterile lantern
#

Yeah, it can be changed at any time

wicked gulch
#

unexpected.... but not weird... sometimes i think they manipulate the VSync to do a kind of 'slow motion' effect over some of the Animations...

#

but but butt

#

i can tell that everytime a CMB Animation is played... the Divider MUST BE at 4

#

surely had something to do on how the keyframes for CMB Animations is calculated and rendered....

#

scriptSetBentAnimationLoopState i think this is used to set* and rewind the animation of Dart after throwing his sword to the sky and then the sword when returning at his hands... that btw they hide sword and then re-appears at his hands instead of get visibility of it before...

#

a very nice trick...

#

maybe that's Monoxide find that DEFF Scripts had some methods to loop Animations

#

and some kind of rewind on them

#

that would be the more solid explanation

true apex
#

Don’t rush anything take your time rushing a product doesn’t help anyone

wicked gulch
#

that's right!... i try to do some updates because sometimes i "self muted"* for several days... that's because of 1: RL; 2: this is taking me some time so i only focus on decompile/sort/cleanup/create database

#

meanwhile i think in parallel a proper way to do this same things but a little more "automated"

wicked gulch
# wicked gulch that would be the more solid explanation

I couldn't be SO wrong... actually what this does is set a kind of marker in the Animation current frame... once a condition is met will repeat the same animation from the marker... the sword falling animation is just another animation loaded at the end...

#

this is done for the Flameshot scene when Dart hit the Flameball...

#

in that moment the Animation is played three times more...

#

except Dart, all the Particles are loaded again and do a different animation for each one...

#

so the playback flag still not know use... at least in DEFFs.... maybe later i'll see it... or maybe not... seems that this game must be develop in real time on the PSX as the effects... meaning that they need a way to playback animations to see if are correct... maybe was that...

true apex
#

hmm interesting

vestal halo
#

test

wicked gulch
#

yep

#

working

#

as intended hehehe

restive carbon
#

gooning

wicked gulch
#

as always xD

wicked gulch
#

well i'm re-taking the project.... with a new perspective maybe... well first the basics.... for TLoD Battles and Effects are at least 432 Functions that Scripts can call... his is not an exact number... just an approximation... based on Scripts only Calling some SCUS functions, Bttl functions and SEffe Functions and maybe in some rare cases (like crafty thief -theft ability) calling some SItem function

#

the calls could be global... so actually do not matter anything but the call itself (yeah i know that some piece of code maybe is not load into memory during some executions, just playing with the worst case scenario)

#

some of this function calls (maybe a 10%) are NO-OP meaning that get deprecated/deleted during the Development time...

#

also some of them clearly are used in SubMap but for some reason they keep it as "global"

#

what is global for me?

#

anything that is in here Scus94491BpeSegment

#

well maybe global is a poor name... better i call properly as Generic... so this are the functions that work along all the game no matter the Game State... and could be called in anytime since i suspect that Scus94491BpeSegment is always load...

#

now i had some questions about functions like this FUN_800dbb9c it says 'unused' and in the code Raise an Exception 'Not Implemented' but this means that the code was there but removed after the uptades and find out that had no usage?... just to know... i don't think this kind of functions do anything important since i run SC from very early stages and nothing like that eer came to my console hehehe

lime willow
#

hey @wicked gulch, i got a quick question for when you have a moment. I'm checking your github repository looking all of the deffs for transformations and the pieces they consist of. For example file 4204\0\18 is listed as Darts flame armor. My confusion though is when I look into the 4204\0\ folder I am only seeing 0-16

wicked gulch
#

if you refer to the numbers that companion the name of the object in the database

#

is just the "sequence number" but is a totally "invented number"

#

what i mean... that number is only used for me to know when a files is loaded compared to the other files from the same DEFF

#

but internally the Flame Armor or file 18_FlameArmor.csv, it's calling the file armor StaticTMD called file 10

#

this is because there are some particles or objects that are loaded over and over, but with different animations, properties, etc.

#

in other words... do not follow much of that numbers... instead look inside those files in the column with tells the file number

#

here a little what i documented:

#

First understanding that getting Data from the Script files is not an easy task, even people like Monoxide, TheFlyingZamboni, Zychronix, Icarus, struggles a lot to simply follow up whats going on (and seriously i'm not even closer to their understanding about this files), this because the Script Files are not necessarily 'linear'. So getting the exact frame in which an effect start or end is very complex at best (impossible in other words). What i do in this files is comparing some timing/frame data from the Scripts Versus a 15~20~24 FPS Recording (in which i dump each frame into images) and checking frame by frame when a effect start to appear or end (disappear). Also will using as support value VSyncDivider, which will dictate in how to place the Keyframes in the timeline, but is the Frame Rate dictated to be run by the Engine. For the rest of Data I just follow what file is loading. For sake of easy reading and maintainance I opted to split the "Script" into two concepts. First Concept is "Sequecence File", Sequence file is a csv which contains: -------------------------------------------------- Name - Objects Folder - Texture Folder - Total Frames - VSyncDivider - Extra Texture Folder - AnimatedTMDBool - StaticTMDBool - ParticleBool {Extra Texture Folder is the general folders in which this DEFF Stores it's Extra Textures} {AnimatedTMDBool - StaticTMDBool - ParticleBool: This way i can trace prior if creating folders is needed, also avoid Conversion if in General do not exist this kind of Objects inside THIS DEFF} 0_DEFFObject0 1_DEFFObject1 n_DEFFObjectn -------------------------------------------------- Second concept is "DEFF Object Properties File", DEFF Object Properties File have the same name as referred in Sequence File, So for example we say the last DEFFObject is the n_DEFFObjectn, and the name of the file would be "n_DEFFObjectn.csv" This files contains the properties of the Object itself and have General Properties and Script Animation. Objects could be: AnimatedTMD, StaticTMD, Particles. --------------------------------------------------

#

Process Object CSV:\n Will process the csv file, which is created in this way:\n General Properties: Are the properties which are spread across all the Object Sequence, no matter the timing of it.\n ===============================================================================================================================\n FILE - FILETYPE - TEXTURES - ANIM FILES - PARENT - FRAME START - FRAME END - PARTICLE TYPE - COUNT - SIMULATION TYPE - LIFESPAN ===============================================================================================================================\n NOTE: Textures could be more than 1, will depend on the Extra Textures folder if != to NONE After will be the Scripting Animation: This properties are changing across Object Sequences, sometimes in DEFF Devs changed Position, Rotation, Translation, etc.\n Script Animation Types included: Relative Position, Relative Rotation, Relative Scale, Relative Color. First will come the Script Animation Header telling How Many Script Animations are in this Object Sequence:\n =================\n ScriptAnimation N {Where N is a Unsigned Integer | NONE} =================\n Then start the Scripted Animations Types in this fashion:\n ==========================================================\n ScriptAnimationType{Name} - Parent{Name} - Property{Value}\n ========================================================== Working in this way, if some of the properties is variable, is taken as a Script Animation. Anyway, Script Animation would be apply only If we are re-creating the whole sequence, at the moment that is work in progress.

#

tbh this is the most close i can do into the DEFF without doing a lot of coding...

#

because the very optimal to do is actually translating all the Script Files from DEFF into Python... but changing anything would be complex for users which do not have any knowledge on coding...

#

specially because my code and my coding style sucks... and sucks hard hahahaha 🤣

lime willow
#

Gotcha, appreciate it

wicked gulch
#
public void NeedHelp<T, V, R> {
    final T typeOfHelp = new AnyHelp();
    final V isBattleObject = new BattleObject();
    final R String answer;
    if (isBattleObject == true) {
        answer = new stringHelp();
    } else {
        answer = new stringHelp();
    }
}```
#

well i do need... very very exact examples of: for TLoD Game Engine what is a Battle Object... and what is NOT a Battle Object

#

because from the standpoint of the code... it's very explicit

#

anything that inherits the Battle Object properties are actually a Battle Object or a derived of it

#

BattleEntity27c is the abstract class for
MonsterBattleEntity
PlayerBattleEntity

But the problem comes when i find out that EffectManagerData6c also inherits from Battle Object... but inside there are a lot of things (like Cameras) that are treated like Battle Objects... when are actually not...

wicked gulch
#

well turns out that i have to implement the full Battle Engine to get the DEFF into work...

#

now i understand why Monoxide told me that i have to implement all the code as it is in SC...

#

this is describing how i feel right now lol

wicked gulch
#

public final TmdObjTable1c[] tmds_2f8 = new TmdObjTable1c[38]; this looks quite specific...

#

so, they add 1 second of Animation if frameCount_20 != -1 or > than 0

#

in other words... the animation will play until if(a0.init_1c && a0.script_14 != null) in that case will be set as frameCount_20 = 0

#

meaning that the DEFF will play until the Script Exist in memory and running?...

#

now I'm facing the truth... i need to implement the Script Engine... like it or not... DanCrying

restive carbon
#

doom is about to reinvent SC

wicked gulch
#

if i want 'simplify' surely i will have to... hahaha

#

as far as i see in Particles matter, there is a pattern, developers relied on values that already loaded into somewhere but for some reason they copy the same value in various places... also the Particle Inner Stuff is a bitset that is telling almost all the behavior that a Particle had...

wicked gulch
#

also.... the Instance is the actual animation that Particle must play... the tickType is telling 'for each tick do this', and beforeRender is kind of adjusting something...

#

also some Particles had no animation at all... that's a expected behavior... since some of the particles appear static in the place and have no movement at all...

#

also... there are a lot of 'duplicated' Instance... what i mean?.... well the same Instance had no override in their fields or methods, just inherits from an already animated particle...

#

like telling particlesOfThisIndex had this behavior [indexList]...

#

an example is Instance62.java which inherits all from the Instance0.java but there is no override... just set the particle data to the ParticleEffectInstance94 fields...

#

surely in the original code will be something like:
if particleIndex == [0, 62, etc...]:
doThis

#

public final float _18; seems this value suffers of a reduction before entering into the fields... understandably, because most of the particles are very tiny compared to models... also the distance travelled will be accordingly to this value...

#

maybe it's a distance travelled or something like that...

#

i had that value in my calcs for my own implementation... since, if you want to expand or contract the particle system you need to know how much distance a particle travel during a portion of the animation

vestal halo
#

Frankly, your ability to understand any of this is impressive.

wicked gulch
#

thanks a lot.... anyway sometimes my assumptions tend to be a misguided, because I think this Engine works like other engines or like i should do... but sometimes it made some dodge moves that get me off-place...

wicked gulch
#
if((flags & 0xf_ff00) == 0xf_ff00) {
      final SpriteMetrics08 metrics = deffManager_800c693c.spriteMetrics_39c[flags & 0xff];
      this.u_58 = metrics.u_00;
      this.v_5a = metrics.v_02;
      this.w_5e = metrics.w_04;
      this.h_5f = metrics.h_05;
      this.clut_5c = metrics.clut_06;
    } else {
      //LAB_80101fec
      final DeffPart.SpriteType spriteType = (DeffPart.SpriteType)deffManager_800c693c.getDeffPart(flags | 0x400_0000);
      final DeffPart.SpriteMetrics deffMetrics = spriteType.metrics_08;
      this.u_58 = deffMetrics.u_00;
      this.v_5a = deffMetrics.v_02;
      this.w_5e = deffMetrics.w_04 * 4;
      this.h_5f = deffMetrics.h_06;
      this.clut_5c = GetClut(deffMetrics.clutX_08, deffMetrics.clutY_0a);
    }```

If HUD DEFF --->
Else (Rest of DEFF) ---> 

Any file inside the HUD DEFF which is a DeffPart is 0xNN 0F FF NN
#

inside that DEFF also exist an unused Sword 3D model.... i think that was the 'original' pointer to enemies... later replaced by the arrow

#

since TLoD do not have an explicit way to know enemy HP and instead you have the arrows telling Blue (Good Health), Yellow (Middle Health), Red (Critical Health), surely Devs opted to use the Arrow... also coloring the sword was a terrible work to do with this Engine lol

#

@sterile lantern sorry for bothering... maybe you will find that information useful

wicked gulch
#

this GetClut() function is weird, it takes the CLUT values... packed it... to later (in the render) taking the same values and depacked them...

#

anyway i keep them as retail to avoid some silliness going on hahaha

wicked gulch
#

doing some checks... i can tell that i cannot see the point of it... in the VRAM position both types (the HUD DEFF Quad Particle and a Regular DEFF Quad Particle had the CLUT position well expressed in the file... maybe the last step is needed for the VRAM position {when the quad is build}, but the GetClut is something that i cannot get...)

#

anyway i don't care much about CLUT when doing the conversion...

wicked gulch
#

And here i goooooo again... will do a full refactor of all the TLoD Assets Manager code... oh yeah...

#

since i find a way to do things a little more generic also will improve the code readability, now, why i do not implement this directly to the code?... well end to be an unreadable code... even for me -the creator- so i prefer to go into a full rewrite mode...

#

but this will come after i do all the DEFF re-assembling system...

true apex
#

Good luck soldier

wicked gulch
#

So... Monoxide find a TmdType which actually had no TMD file inside.... interesting 🤔

wicked gulch
#

deffManager_800c693c this is the HUD DEFF... if i'm correct...

#

yeah.... the HUD/GUI had a DEFF file loaded into battle as a general overlay...

#

that's why some effects like poison and confusion (even if are Special Visual Effects, are loaded all the time)

#

also the running Combatant particles on the floor

#

this DEFF is 4114 (DEFF)

#

public void loadBattleHudDeff()

#

for more info

#

and script files from there

#

1.- get moved because we need it...

#

2.- get moved originally to be placed in other place

#

surely the DRGN1.bin

#

the Sword to be loaded in there... just is not referenced in the code which load this HUD DEFF

#

also... i was correct lol

wicked gulch
#

hmmmm

#

hmmmmmmm

#

i think... the methods that calls the Animated TMD are for two cases... one with 'animated textures' and the other with 'static textures' i will check on the code in depth when i had.... but i think that's the case...

#

because some models had a lot of texture data in the header... while others had one single... and it's weird that both functions seems to be doing the same... loading a TMD model with SAF/CMB/LMB Animations

#

so the difference must be on how long that Texture Data is...

wicked gulch
#

@sterile lantern sorry mate but this cannot wait longer:
`Warning Monoxide about the TmdWithId that is a misguide name... actually is looking if the TMD Header had some flags to be working with them

public class CContainer {
public final TmdWithId tmdPtr_00;
public final CContainerSubfile1 ext_04;
public final CContainerSubfile2 ptr_08;
}

CContainerSubfile1 -> store the pointer to the File (at the rear of TMD Files - embedded as Animations do in DEFF Files) that holds Animation Texture Properties for SubMap Models

CContainerSubfile2 -> store the pointer to the File (at the rear of TMD Files - embedded as Animations do in DEFF Files) that holds Animation Texture Properties for Battle Models`

#

I believe that CContainerSubfile2 sometimes is 7 and sometimes 10, because in battle could happen that a texture that has Animation, actually could change into a new texture... so they need to store that somewhere...
In SubMap Models this behavior is not like that...

#

and yeah... this time i read all the code way down there to know what's going on... obviously the new way that you made to write things make this easier than ever... so thanks a lot for that

sterile lantern
#

@wicked gulch TmdWithId is the exact name, it's literally the TMD file struct with the ID included

wicked gulch
#

ahhhh i misread then the intentions hahaha

wicked gulch
#

The next IF/ELIF/ELSE nesting is monstrous but i find to be the best way to handle this, if want to know which exact type of primitive is giving Conversion problems, since it works good in the previous versions i keep it at it is. Applying the Rule N°1 of Programming: "IF IT WORKS, DON'T DARE TO TOUCH IT".

#

with this changes I did to my conversion code also, get rid of some of the global variables floating around... there was some stuff that was annoying to handle...

wicked gulch
#

THIS IS BATSHITCRAZY!!!

#

the CLUT Animation used and stored at CContainerSubFile1

#

is used for the SubMap Details

#

stored from 6674 to 7609

#

JUST CONFIRMED IT!!!

#

Finally

#

yeaaaaaaaaaaaah

#

for more context

#

the SubMap Details are the surfaces that are not SubMap Objects and also are not SubMap Environment...

#

for example... the light rays coming from the top of some caves

#

are get from there

#

the water in SubMaps also are part of those SubMap Details

#

So:
CContainerSubFile1 -> Store CLUT Animation (changing the palette of a texture over time)
CContainerSubFile2 -> Store Texture Animation (the effect on textures seen on Slimes for example... passing the texture over time)

wicked gulch
#

exactly that

#

a Rainbow would be a SubMap Detail

#

The environment is the 3D Model + Texture of a SubMap

#

and the SubMap Object would be the person recording that

#

it's funny that i find out this because i was looking how to emulate the behavior of Particle System in TLoD lol

#

THAT deep is the rabbit hole lol

wicked gulch
#

believe it or not... i'm so happy with this discover

sterile lantern
#

@wicked gulch you can look at the reduced motion code to see where the animated submap overlays are handled. I made the reduce motion option disable the animated overlay animation

wicked gulch
#

SMap.java -> public void modelLoaded(final Model124 model, final CContainer cContainer) here a part

#

In same Java file private void FUN_800de138(final Model124 model, final int index)

#

Scus94491BpeSegment_8002.java -> animateSubmapModelClut()

#

that's the one that handles the flashing from the clouds...

wicked gulch
#

seems that Model124 it's the Structure for models which had Animated Textures, Animated CLUTs and* SAF/CMB/LMBTypes Animations involved 🤔

wicked gulch
#

Monoxide if you are around... i can skip the Interpolation calcs to get the animations converted? i mean... i only need to do the calcs directly the interpolation i think is only done to TLoD because they used only Linear interpolation.. if they need a different one they needed* write a code for it...

sterile lantern
#

You should not put interpolation frames in the files

#

Interpolation is done when something is rendered

wicked gulch
#

excellent... wanted to confirm because in the apply function i will cut half of the code in there...

wicked gulch
#

LMB Type 0:\n This is the most tricky Animation format, somehow it's broken but working in game.\n The way that Data is stored: ObjectN -> Keyframes. For Keyframes we got the ThisObjectKeyframes (PartInfo0c) -> LmbTransforms.\n LMB is tricky because not only need more calculations to get them work, but also they do additional calcs to get animated into the model, that is done in the 'apply' and 'processLmbTypeN' stage.
a comment for the Class lol

wicked gulch
#

this is at least weird:
this Function processLmbType0() had a flag check... that more or less tell the next:
"If the current Object had this flag set in their animation... do this lerp calculation"
but there is no else case so i assume that the animation for that object will be applied directly as it is...

#

and yes... it's checking each one of the Objects...

#

so the this.deffFlags_14[lmb.partAnimations_08[i].partFlagIndex_00] ==> partFlagIndex_00 (inside PartInfo0c{}) is actually a Lerp checking value

#

so we stated that get into conclusion that LMB Animation is the less precise Animation format because depends on unpacking values that get degraded from the original values used in the original tools for making them...
This degradation need more Lerp advancing in the Type... Type0 could had or not Lerp, Type1 is needed but in a little degree, Type2 need aggressive Lerping to be not so clunky (because the real animation data is stored in single byte for each vector).
So yeah... LMB seems to be a 'kind of' packed animation format which need Lerping + previous calculations to work... they don't used it much surely because it's expensive into the PSX hardware to get this running all the time

#

the Lerping of Type2 is so aggressive that they need to almost hardcode the values and the cases inside the self code... lol

#

in a future i will write a tool to convert LMBTypeN and CMB Animations into SAF... to know how much data they saved doing this

#

also i notice that if a flag in the DEFF is active they generate Particles... that's ass

#

it's like saying "shit, i forgot to buy bread.... i will put myself to knead some right now" lol

#

so in this file 5078 ---> 5078\0\0 ---> Normal Lenus All party Attack # Used this one to check my tool which is an LMB Type 0, this Particle Generation is done... i think this is to render the hitting particles used in that 'all party attack'

#

but they do this from the Self DEFF instead of having something wrote inside the engine that make it possible like:
'If N characters are hit, render this poly in those characters'

#

maybe that's why they needed two LMB Structs... one holding the animation and the other is transferred to the BEnts if needed

wicked gulch
#

In LmbType1 the only value that have no Lerping (as in LmbType0) is the rotation...

#

not so surprise about this

#

this.deffFlags_14[lmb.partAnimations_0c[i].partFlagIndex_03 ==> PartInfo04{} -> partFlagIndex_03 that value it's telling which is the last object to be animated, that value guard the code to be running and if not reaching that point will continue doing Lmb Calculations... if it's != 0, will send everything to the manager EffectManagerData6c<EffectManagerParams.AnimType>

#

in other words... or bytes: (each one is a PartInfo04)
{previous 00 E0 15 00 are here...}
00 E0 15 00
00 E0 15 00
00 E0 15 00
00 E0 15 00
00 E0 15 00
00 E0 15 00
00 E0 15 00
00 E0 15 00
80 FF 15 01 -> this last one is the last object to get processed by the ProcessLmbType1()

#

the byte 0x01 is the 'termination' byte

#

the 0x80FF only tells that this last animation have everything lerped except for the Scale in the X axis

#

sadly: 5532 ---> 5532\0\0 ---> Divine Dragon Death # The only available to check my tool this means that we don't have any other LmbType1 to check if there was something wrong with it... but as far as i can tell... they miss something... because for exception the termination byte... the last 4 bytes are the only in a 21 Objects PartInfo04 to had that value in the first short

#

maybe was a bug in their building/development tool

#

i think this Lmb file is used to animate the rocks that erupts when Divine Dragon neck impact to the floor

#

i mean the little rocks flying... you know?

#

ohh.. i'm looking to my old code... and i sucked... lol do the same (and wrong) in twice of the code size i do now lol

wicked gulch
#

In the original code what's going on is: it creates an array of Transforms, since data in there is mutable, but read each frame, the data get replaced on the fly, to 'simulate' this behavior the way i found is to fill the first keyframe dictionary with the very first transformation and carry that data from the current keyframe to the next, so in the context of the next frame, would be the current keyframe with data on it and replace the necessary values.

wicked gulch
#

well for some reason the calculations for LmbType2 start to goes well after i ignore voluntarily the first 2 keyframes...

#

so i assume in the very first keyframe the data is set using the InitialTransforms, the next frame get the lowTransforms implemented, from there onwards using the HiTransform component plus the previous values in an accumulative way

wicked gulch
#

FIRST FRAME SEEMS TO BE THE BASE TRANSFORM (Keyframe 0) THEN WILL PROCESS THE HIGH Bytes to be ready for the next processing (Keyframe 1) Finally will start process the High values and the previous calculations for calculate the new transforms FLAGS ARE READ as a single integer, not like LMB Type 1
Past me is telling me the same... but the code is not helping because the first frame seems to start before and nothing is done?
nextKeyframeIndex == 0 && keyframeIndex == 0
then the second frame is telling to apply the things

#

what the hell?... discord supports the exact same string writing as Python? lol

#

ahhhh Discord support Markdown formatting for text...

wicked gulch
#

so far so good

#

seems that i make this possible... finally the LmbType2 is not giving weird errors during conversion

#

now time to fast check this shit out

true apex
#

you got this

wicked gulch
#

well since reading so much code... some things about particles started to make sense... not everything... but most part of it...

#

i had already all the Animation types prepared except for VertexDifferenceAnimation (PSX-VDF)

#

for that i need to read a little bit about how glTF 2.0 apply the targeted Morph so i can replicate that in my code...

#

it's good to know that glTF 2.0 supports natively that type of animation without doing much effort...

wicked gulch
#

if i'm correct... the initType() of each Instance set the common properties of it... but the real player here is the beforeRender() which seems to have the 'how to animate this particle' elements... that function seems to be very busy all the time with the this.velocity += this.innerStuff0aUaU

#

in my code made from scratch I initialized the particles of each kind based on their general behavior not in other thing... but for some reason this kind of Instance looks very odd to me... also i think i found some dividing by zero things... but i bet that those particle instances are never used...

#

or maybe i did the calcs in the wrong way

wicked gulch
#

Monoxide if you had some time... could you explain to me, what does, from the Engine perspective, beforeRender() means?, i'll do the wild assumption that means animateThisParticle.

sterile lantern
#

It runs just before the particle is rendered

#

Does whatever the particle needs to do just before it's rendered

wicked gulch
#

and there is no way to tell where the particles get animated?

sterile lantern
#

That would be wherever the devs decided to stick the code

#

Some do animation stuff there, some do it during render

sterile lantern
#

It's distributed across multiple tick methods on the base class

wicked gulch
#

excellent...

#

so partially right... but actually no...

#

this TLoD engine is bullshit... but the very best

#

so part is in the ParticleEffectInstance94 class... and whatever is not done there if the Particle need will do in the tick() and beforeRender() inherit functions

sterile lantern
#

Yeah

#

I would say that the particle engine is one of the better written parts of the code

#

It's a complex system, you can't always divide things up nicely

wicked gulch
#

hmmm that's true too...

#

if they did in my way the banching of code it's waaaaay larger

#

because in my code i first decide the type of Particle and Behavior, and then based on that i choose the type of functions to apply over them

#

also what i had the advantage is that i don't need to render this on real time

#

i feel bad sometimes because i know that this had to run on a PSX in realtime... and tbh i cannot render a triangle on it lol

wicked gulch
#

Monoxide if you are around... i've seens this in Instance47.java:

final int a1_0 = -((rsin(angle) * s2 >> 12) + s2) / 2;
this.particleVelocity_58.y = (seed_800fa754.nextInt(-a1_0 + 1) + a1_0) * this.particle.effectInner_08._18;

now... if the result of a1_0 when calculated, is negative, why in the nextIntegerRandom is set again to negative?... is not redundant?

#

Negative + Negative = Positive... or I'm missing something?

#

ahh never mind

#

i'm socket... a smelly one...

#

I just omitted that a1_0 is sum just next to the nextIntegerRandom

#

anyway if my maths are right you can use a1_0 as positive in the calc... also in the nextInt and in the (+ a1_0) to (- a1_0)

#

my level of sucker in maths is so big... that i'm almost considered as the Black Hole of maths lol

sterile lantern
#

It's generating a random number in a range around 0

#

-a1_0 to +a1_0

wicked gulch
#
class Instance64(ParticleInstance, ParticlesEffectData):
    def __init__(self) -> None:
        super().__init__()
    
    def init_type(self) -> None:
        # Sets translation vector to position of individual part of model associated with scriptIndex
        a = 0 # Using calculateBentPartPosition((BattleEntity27c)this.particle.parentBobj_04, this.particlePosition_50, this.index);
        # This seems to be applying the Particle in the place when calculating the Position of each Object of a BEnt. 
        # This is the one used by Dart Red-Eyed Dragoon Transform?

How to fake implement

#

now it's time to simplify a little bit... since originally is a linked list... and much of the particles in the list actually are repeated with the same "Instance"

#

also... i was pretty right about the soup of data... what they did was for each particle, they snap 4 structs together and fill their properties, since the total structure is so big (just for Particles of type Particle) they can't load a lot of them... so particles like dust or smoke get loaded directly from the main Battle DEFF structure...

wicked gulch
#

JkNotActuallyALineParticle and WhyIsThereANoParticle i think that were some kind of particles that they remove from the code but for some reason they keep them in the DEFF Scripts...

#

i'm pretty sure about to say... DEFF baking was very very expensive or time consuming...

#

we think in the terms of today... but a desktop PC of today, have at least 100 times the processing power compared to that time...

#

so i imagine the developers saying "let's gonna bake this Kongol Transformation version 8.10.2, so that's all for today"... the next day "guys we remove two particles, because bug all the Particle Engine"... "shoot.."

#

also i'm aware of the empty effectManagers used for some effects like the used on Michael fight... just because they need a way to keep that under a DEFF...

mild masonBOT
#

Q: Should I continue sinking into the madness of the TLoD Particle System?
A: Outlook is grim, ruff.

wicked gulch
#

you are pretty right...

wicked gulch
#
# NOTE From Monoxide: should this still be << 8? - My NOTE: If still working... better don't touch it lol.
#

it's surprising that i can implement almost all the code at a 99% rate as in SC... it's an awesome work that Monoxide did in there... 🤔 ... that's a very important point from a code design perspective...

wicked gulch
#

Now i get it... the behaviorType of the Particle... is actually the index for instanceConstructor

#

yeah

#

also is used for other things... but the most important it's to point which will be the constructor for it

#

it's funny that a Particle Instance is checking if the behaviorType is actually the same Constructor of it lol:
At Instance42.java

if(this.particle.effectInner_08.behaviourType_20 == 0x2a){...}
#

the else block below it will ever should to hit...

#

no matter what it happens

#

even in any part of the code that value change under any chance lol

wicked gulch
#

hmmmm i should rewrite all the Database constructor for DEFFs lol

#

and all the Database files i had to modify... i need that behavior type for this

wicked gulch
sterile lantern
#

behaviourtype 0x2a uses a magnitude scalar, others don't

wicked gulch
#

ahhh yeah... but the behaviorType also defines the Particle Instance that must use... meaning that the Instance42.java class is selected because the behavior type is equal to 42

sterile lantern
#

¯_(ツ)_/¯ oversight

wicked gulch
#

in other words... the else below that part of the code never hits

sterile lantern
#

Probably

#

I don't have time to do a static analysis to make sure that's true

wicked gulch
#

no problem, I'm doing it because i want to know how much i can simply of everything in there... hehehe

#

i would do some analysis and tell you in a full report maybe?

sterile lantern
#

If you feel you are equipped to do that, go for it

wicked gulch
#

tbh i feel like i can handle it...

#

i've already translated all the code from SEffe.java scriptAllocateParticleEffect to everything down below...

wicked gulch
#

well atm i tried to test this code... the mayor problem i get is the circular imports... something that i'm aware of in Python...

wicked gulch
#

it's funny that the idea of Data Soup on the Particle System of TLoD was not so far from the real thing... first i thought was my imagination...

wicked gulch
#

OH SHIT.... this is working

#

lol

#

i don't view a thing... but is working lol

#

and it's fast

true apex
#

Ooooooohhhhhhh

wicked gulch
#

now i think i got an idea of why i don't see any different values... what is actually running in the loop of ticking are the ticking controls, not all the ParticleSystem itself

wicked gulch
#

now, i'm wrong... i need to initialize a Effect Manager Data instance to run stuff inside of it... so i will be able to tick 'virtually' the particle functions

wicked gulch
#

how far I am from what the game do Monoxide? show me your wisdom

#

hahaha

sterile lantern
#

Have you converted the script engine yet? 😆

wicked gulch
#

not to be honest... but i think more or less how it's going... except that data will be constantly injected not only in the moment of performing some changes

sterile lantern
#

I'm sure you'll manage it one way or another

wicked gulch
#

yeah... now i got the idea more or less in my head... since they create the instance, but actually what animates the particles are all the Functions that ticks each frame... meaning that the loop and time that it's used for Script Reading and execution i kind of "simulate" using a frames counter... the result should be more or less the same... and i can inject the transformation data from Script Animations using my own timer or something like that...

sterile lantern
#

Yup

wicked gulch
#

ScriptState is a very interesting thing...

#

the doWhile and the nested while are doing almost all the magic there... 🤔

#

implementing the Script Engine would solve me the thing of "doing work at bare hand"

#

while doing my own way will give me more 'control' but in exchange i will write a lot of shitty code

#

now... i understand the meaning of pushFrame...

#

is not pushing a frame from an animation

#

but a block of data from the script stack

#

is like a cursor in which the data is currently read

sterile lantern
#

Yes, it's pushing a new stack frame

wicked gulch
#

Monoxide, how wrong i'm about this?
final ScriptState<EffectManagerData6c<EffectManagerParams.ParticleType>> state = allocateEffectManager()
Here is Instancing and Allocating a ScriptState which is receiving as parameter a ParticleType?

#

generic types get me a little dizzy in Java... hehehe

#

specially when some conditional > | < it's used

sterile lantern
#

A generic type means that "anywhere in this class that T is used, it's actually a SomeRealClass"

#

So ScriptState<EffectManagerData6c<EffectManagerParams.ParticleType>> is a ScriptState where its generic type is actually EffectManagerData6c which itself has the generic type ParticleType

#

It doesn't necessarily mean you're passing in a parameter of that type

wicked gulch
#

yeah i've been seen some of this Coding with John videos about Java that explain more or less how some stuff works... hehehe

#

in ScriptManager, the fields meta, compiler, lexer and patchDir are only used when need to write Scripts?

sterile lantern
#

Don't think the manager is used for compiling is it?

wicked gulch
#

hmmm

#

well in the class are a lot of public and void functions that seems to be used whenever you want to patch something during the initialization of SC

#

ScriptManager.java i mean

sterile lantern
#

How's it used by scriptstate

wicked gulch
#

are not...

#

but i mean... i ask because i don't know if i'm missing something lol

#

i was yeeting them

#

but i want to be sure that there is no hidden or side effect because of that

#

hahahaha

#

Script Manager: This is a rough implementation of ScriptManager.java from Severed Chains code. Surely won't work as intended, just because some stuff looks like Black Magic to me... fooking voodoo magic... HAHAHAHA...
This is the comment at the start of the module code lol

sterile lantern
#

I just looked and it is

wicked gulch
#

and i need the forking because a lot of effects forks into other sub-scripts

#

this is not only funny because i had to mining in the scripts... but because i have to craft my own pickaxe from planting a tree (to make later the weild) and collect some minerals (to get some iron)... suddenly coding transform into playing Rust (the game lol)

sterile lantern
#

Yeah you'll definitely need a script manager

wicked gulch
#

good thing about this... if i can make it work... i'm pretty sure that my understand about script engine will evolve to 108 %

#

it's funny that the pointer array for ScriptStates on Scus94491BpeSegment_800b.java it's actually 108 + 1 (because 0 is included)

sterile lantern
#

The 108 is the total number including 0, so it's 0-107

#

We expanded it to that because nodart required more script states

#

In retail it's 72

wicked gulch
#

ahhhhh hahaha

#

good reference... almost fell off my chair

vestal halo
#

Perfection

wicked gulch
#

Monoxide, i had a question on the way that Script Files are stored in SC, as far as i see in the ScriptFile Class, the data is stored as individual bytes, and the Operations are stored in this fashion int[] ops = data.length / 4; this means that the 'ops' are always stored as 32 bit data? and the ops are == to the data split every each 32 bits?

sterile lantern
#

Depends on how you wanna look at it

#

There's a 32-bit header which is followed by 0 or more params which are each 1 or more 32-bit words

#

But those are all subdivided into 8-, 16-, 24-, or 32-bit pieces depending on if you're looking at the header or what parameter type it is

wicked gulch
#

i got the idea... now i can proceed... i ask this because i need to be sure that i'm thinking more on less on the correct way

sterile lantern
#

You'll have to look at the code to see how the header and each parameter type is parsed

wicked gulch
#

yep... actually i kind of already implemented the Op

#

and some of the script stack frame running script and script state

#

the Registry Ids it's the only thing i think will ignore... because that seems to be used for mod...

#

specially the ones used in Params.java...

#

in there are 6 functions that are Registry related... and seems to be setting or getting data for the Registry... not for the Script Engine...

sterile lantern
#

You won't be able to run scripts that use registry ids if you don't implement them

wicked gulch
#

hmmm you have a list of them somewhere?

#

as far as i've seen some of the Scripts related to Items seems to be using it

sterile lantern
#

Nope, check the script patches

wicked gulch
#

well time to implement the Registries lol

#

almost all the CutScenes and most iconic Enemies moves requieres Registry for some reason hahaha

sterile lantern
#

They use items

wicked gulch
#

here an example

#

an attack from enemy

#

yeah... some DEFF attacks from enemies are count as Items...

wicked gulch
#

Implementation of the Script Engine at 40%

#

and till this moment i believe this work because Soa it's big... most of the things start at -1 literally...

#

each time a Script is allocated, all the data is written as -1 (i assume that this behavior is because PSX can't handle null or None)

sterile lantern
#

Null is 0

wicked gulch
#

so -1?

#

-Null? xD

sterile lantern
#

-1 is whatever you want it to mean lol

wicked gulch
#

hahahahahaha

#

xD

#

this going crazy

sterile lantern
#

But null is just a macro for 0

wicked gulch
#

oki doki...

#

that's wild

#

supposedly after some settings, should be all signed integers... but for some reason i suspect that some errors came that this -1 became more negative

sterile lantern
#

A pointer is just a number right, that number is the address of memory somewhere

#

By convention in C, a pointer to 0 is called null

wicked gulch
#

make sense... also in the logic... and in the PSX handling would be correct as 0... so maybe they want to say 'uninitialized' marked as -1?

sterile lantern
#

Is it even a pointer? Null doesn't really have meaning outside of pointers

wicked gulch
#

hmmm i mean the data that is set when a Script is Allocated in the storage_44, i clarify if i mess up what i was trying to say hehe

#

whenever a script is allocated, will do a very fast run in the ScriptState setting storage_44 data as -1 (for the 33 members of the Array)

#

for that new allocated Script and it's ScriptState

sterile lantern
#

Just seeing to a known value

wicked gulch
#

Monoxide i came back to give you some strange feelings in your guts haha

#

confirmed to be in the source code

vestal halo
#

What is it? I just see a missing empty line between those two lines that have text.

wicked gulch
#

yup... code...

#

that missing whitespace... code side is not a problem...

#

but much coders start to feel something in the guts if they see it

#

is like Trypophobia

#

anyone will be amazed by the things i've seen recently in there... this implementation open my mind...

wicked gulch
#

well time to really simulate all the fields that compose the Game Engine... also i would be ignoring completely any function/array that is not from the DEFF side...
Game Var Params at itself show the crazyness of this engine... there are gamevarparams flying from any place lol

sterile lantern
#

Have I mentioned it would have been easier for you to just do this in Java? 😆

wicked gulch
#

yeah indeed... but i want to do it in the worst way possible... and ends to be Python the only language which not support a do-while hahaha

#

also tbh... I'm plenty conscious that could do this just doing a 'Java Project' literally copy'n'paste SC code and intercepting the data... but, want to understand what's going on in the Engine/ScriptEngine side so in a future, will be more 'prepared' and consistent for the next 'big step'

#

before i thought the stor[] mentioned in the Script Decomps where a general field for everything... now i perfectly understand that each ScriptState had it's own storage of 33 ints...

#

also that each Engine State had it's own class and inherits some properties to Battle/WMAP/SMAP/etc.

#

it's amazing what you did with the FlowControl... with a simple Enum tells to the Engine in which State must be... sending that kind of global... the states start to work like a kind of 'mega switch statement'

sterile lantern
#

The script engine was one of the first major overhauls I did because it was almost entirely arbitrary raw memory pointers and nearly impossible to work with

wicked gulch
#

and you did a very impressive work in there... you knew that functions should be executed in a certain way and order... but since you didn't know the order you tell the Engine choose it's own order, but keeping as guidance the FlowControl system... so no other Functions will overlap depending on the Engine State... marvelous...

sterile lantern
#

You wanna see the original parameter parser? 😛

#

Well, that wasn't the original, but that was 2022

wicked gulch
# sterile lantern

that's crazy shiet lol... i wonder how many times this engine while devs were developing end into bugs because they fell into a blank space of memory lol

vestal halo
#

Hey @wicked gulch . I had the impression model swapping wasn't in the API yet, but Corey informs me that should be possible now (custom submap and custom objects within it). Oops!

sterile lantern
#

It's not really swapping

#

You're making something new

vestal halo
#

Ah, it can't swap?

sterile lantern
#

Making a new map, yeah

#

I don't remember if the sobj loading events I added a couple months ago let you swap assets out or not, they might

vestal halo
#

Okay. Sorry for the mix-up.

#

Still exciting regardless!

sterile lantern
#

Ask icarus/zy, they were the ones I made the events for

#

I'm currently insulating my endless ceiling

vestal halo
#

This feels like a certain Tootsie Pop commercial.

#

@restive carbon @red marsh thoughts re: new events for submaps/models?

#

Also tagging @hollow mango , a prospective modeler interested in what's currently possible.

red marsh
#

The event I have is more of uh a duplication effort.

restive carbon
#

@vestal halo That event allows complete modification of sobjs, including models and textures

#

Creating a new map is impossible atm

#

That requires new collision engine

vestal halo
#

Gotcha, thank you

wicked gulch
#
class AdditionExtra04:
    def __init__(self) -> None:
        self.index: int = 0
        self.flag_00: int = 0
        """
        FLAG: 0x01 Destroyer Mace ; 0x02 Wargod Calling (half damage) ; 0x06 Ultimate Wargod (full damage)
        """
        self.unknown_01: int = 0
    
    def pack(self) -> int:
        # In here on an elegant way i just ignore everything and set the only possible value. BECAUSE I'M USING ULTIMATE WARGOD
        ultimate_wargod = 0x6
        return (self.unknown_01 & 0xffffff) << 8 | self.flag_00 & 0xff | ultimate_wargod
    
    def unpack(self, val: int) -> None:
        self.flag_00 = val & 0xff
        self.unknown_01 = val >> 8 & 0xffffff```

elegant or nothing...
frigid torrent
#

I came here wondering if anyone else was trying to remaster this game themselves since Sony never did as I was thinking of attempting it but didnt have any of the original disk to grab the data off of and the "ROM" disk don't allow you to open them to inspect the data

vestal halo
#

Heyo @frigid torrent . Firstly, although we're not making any "fan games" for legal reasons, the community has been building the Severed Chains port via reverse-engineering. It's our best and only legal footing. In short, it's a revised game engine. Users must still supply a legal copy of LoD.

Although SC comes with some native improvements like 4K and 60FPS, it is up to modders to replace various game assets with improved models, textures, sounds, et cetera. Or entirely new content, if they like. This way, everyone will be able to choose which mods they wanna use. You can have an OG experience (but better), a remaster-esque experience, a remake-experience, or beyond. With time, more and more mods will be available.

This thread you're posting in is about converting the game's assets to more common file formats, so you can open and edit them if you like. It relies on Severed Chains. Right now it's mainly for the 3D models.

mild masonBOT
vestal halo
#

the download link also has a summary, a FAQ, and more.

frigid torrent
#

thank you thats actually what I was looking for, I know that there has been a huge cry for a "remaster" I've been building 3D models for a long time and once I found SC and this community it became a goal of mine to assist in creating a "remaster" mod for SC I wanted to start with the character models and then move on to the world itself ( i see someone else is also working on the world ) but If I can help contribute to this community and the fan base of the game I've been playing since the month it originally released on PS1 and still play now that I'm in my 40s I want to assist anyway I can

vestal halo
#

Sounds good! I will only say to start small, and entice people with a vertical slice first. That can really help drum up interest and will have a feedback effect on you in turn. <3 good luck!

frigid torrent
#

thank you sir I'll be looking for more help putting the new models into action after I've modernized them

true apex
#

Hey @wicked gulch how is the update to your converter coming along?

wicked gulch
# true apex Hey <@210272460770246658> how is the update to your converter coming along?

Hi Robbie_691!... well as far as you can see I made some interesting discoveries across the TLoD Engine... some of the research seems to point that what I'm doing of adapting the Battle and Effect Engine parts are the correct approach, but I'm making a new move about it... trying to reduce all the code to the very necessary to execute any DEFF Script and Convert them directly into a single Scene... atm had this running partially

wicked gulch
#

well since i will add support for Camera conversion too... it would be a good time to read all this BattleCamera.java and do some analysis... anyway everything is needed in here... but wow... more math that the needed to land on moon...

wicked gulch
#

i assume that the tangent of two angles calculation would be the line that the camera describe to travel from point A to point B

sterile lantern
#

I don't believe that tangent is used anywhere in the code

wicked gulch
#

the same code is used for Refpoint and Viewpoint

#

Viewpoint i assume to be 'looking to the front'
Refpoint 'looking to this objective'

#

ahhh no... i'm very off of the idea

#

sorry

#

reference point it's 'where the camera is placed in the scene'
viewpoint it's 'where the camera is looking at'

sterile lantern
#

Yeah

fleet patio
#

Hi, when i run Dart export of any addition i get this error, has this already happened to anyone?

wicked gulch
#

Hi Marcos... first of all, you speak spanish?... just to avoid some language barrier hehehe

fleet patio
#

Nope sorry, i'm italian though, maybe i understand some

wicked gulch
#

ohhh sooo closee... well no problem i will do my best into it...

#

well first of all, have you use Severed Chains to Unpack TLoD files?

fleet patio
#

yesss

wicked gulch
#

ok... now i assume you setup the SC Files folder... that folder contains all the game assets unpacked

fleet patio
#

yes

wicked gulch
#

ok... which version of TLoD TMD Converter are you running?

fleet patio
#

i tried both with 0.2 from an old link and 0.6

wicked gulch
#

oki doki... let me try a second something and i will tell you what's going on

fleet patio
#

thanks 🙂

wicked gulch
#

well i try the version on my end and do the conversion with no problem... so... will continue with the analysis of the error... now that error is telling that the Animation file is expecting 21326 objects in the Dart model that only had 17

#

meaning that a file is not well read

#

since my tool had almost everything hardcoded to avoid that happening i will ask you

#

you replace the files from version 0.2 to 0.6? or viceversa?

#

because sometimes the databases get not well overwritten or ignored by some reason and that break the tool hehe

fleet patio
#

the dumping folder of the 2 tools are shared
now i try to use 0.6 version on a new folder to dump

wicked gulch
#

ahh no problem with the dump folder

#

i mean the folder in which is the tool

#

you'll see some folders like this

fleet patio
#

oh i see, no they are not mixed

wicked gulch
#

oki doki... hmmm are you sure that for some reason you didn't modify any of the database files?

#

also be sure of not dumping the files into the same SC folder... if not some weird stuff could occur

fleet patio
#

yes i'm sure, i only opened to see that in 0.2 version but i didn't edit
and didn't touch the 0.6 version

maybe i should try to re-export entire SC from the isos

wicked gulch
#

try that... be sure of using SC... and setup the path of SC Files inside: \Severed_Chains\files -> no need to be exactly Severed_Chains

#

I try to keep the SC Version equals to the TLoD TMD Converter Version....

#

so files do not get miss

fleet patio
#

god i wasted your time, i'm so sorry
redoing SC export worked!!!

wicked gulch
#

Anytime mate!... just to help you!... enjoy it!

fleet patio
#

thanks 🙂

wicked gulch
#

Some of you maybe wondering... what's up Doom? what are you doing? are you lost?... well actually I'm in the shadows doing a lot of changes to my code before start implementing some new stuff and ideas... the most important for the moment is.... I'm trying to simplify the code (yeah another TLoD Asset Converter re-writing, the good news is... it's almost done)... also i'm moving some models and workflows... all to do the conversion a little more speedy but also consistent.
Example:
Before, all the Battle Models (Characters, Cutscenes, Battle Stages, Bosses, Enemies and Tutorial) were under the same convert 'interface', that made my tool stupidly hard to handle (since each of this Sub-Classifications were different in what they actually do), now each of this Sub-Classification had it's own 'interface', so weird errors would be less possible...

#

also implementing a more 'SC-Like' way to handle files... so we can write proper and easy debug data if needed (specially in the future, at the moment of create and replace a model/texture/animation, etc)

restive carbon
#

one day doom is going to drop python fork of SC

sterile lantern
#

And then he'll ride off into the sunset, never to be seen again

wicked gulch
#

but was crashing half of the time... hahaha

#

i need to implement almost all the Battle Engine code plus some of the other Game States, since are checking what's going on 'outside' for some reason

#

most of them related to party flags or good flags (checking if you had the Dragoon Spirit for example)

#

also learning a lot of the internal structures... which i find very interesting...

#

as Monoxide told me... SEffe it's the more complex of all the Game Engine parts... but not because of the code itself, but because of the deep nesting that internal structures had...

wicked gulch
vestal halo
#

Yes DooM, the hypothetical question is correct. We're all lost.

wicked gulch
#

the problem comes that TLoD is actually very very complex to work on... since the classic approach to sort objects is not applied... looks more they applied some kind of sorting depending on where original devs were working on hahaha

#

an example of this is how the rendering is managed...

#

instead of creating an overlay to load rendering code...

#

they wrote the same rendering code over and over in different places

true apex
wicked gulch
#

i don't know if i move the MCQ conversion along to the Battle Stages conversion (as part of the texture conversion)

#

the big problem is... there are some of the MCQ Skyboxes that actually had no Battle Stage to be attached

vestal halo
#

Ones we've... never seen before? Perhaps?

wicked gulch
#

hmmm maybe not much times, but the MCQ World Map and Game Over i'm pretty sure that you have seen them

#

the Game Over MCQ it's the Texture that says 'Game Over'

#

and the World Map is the one that you see when set the maximum far zoom to the World Map

#

and the Ending Credits... oml

#

those are bad named lol

#

the reason on why i had the wrong names?.... who knows?... since prior TLoD Assets Converter i've already found out that were wrong lol

#

on my defense... listing more than 7k of files is not easy task xD

#

solved hehehe

vestal halo
#

If it possible the Ending Credits entries are simply the literal credits? Then again, I've seen them in DRGN dumps..

wicked gulch
#

ohhh... nop... the ending credits are TIM Textures... that pass over Quads generated on the fly... during the pass of the ending credits*

#

now i renamed them as they should be

#

'Japanese Text Viewer Bugged' it's the name i put to something guys found to be something that was on the Main Start GUI

#

i don't know what it tells on Japanese so i put the name that i could remember

wicked gulch
#

so... what's the general opinion?...

#

i keep MCQ (Skyboxes in General) in a separate category?, or i join the Skyboxes to the Battle Stages and the lonely MCQ into other category?

wicked gulch
#

well since i get no opinions maybe it's time to the judge made the sentence... and i say...
GUILTY!...
sooo... soorry, i mean i will move the MCQ from Skyboxes to be converted along to the Battle Stage Textures

wicked gulch
#

Lately i was seen my glTF 2.0 code and made me think a little bit...

smoky flare
#

Idk anything about coding but I just wanna say that I really appreciate your work!! You’re the reason I’m able to make a lot of my fanart!

wicked gulch
#

Thanks a lot... hehehe, i'm pretty happy that you use my tools to inspire your work! <3.
Maybe more about coding that table of Pros-Cons it's about future plans to get some models into TLoD...

#

the primary idea behind using glTF 2.0 all this time was because SC was using OpenGL and the glTF 2.0 format it's designed to be an 'easy bridge' between models and direct rendering using OpenGL... but now SC is using SDL and i don't know how compatible is that (because I'm not an engineer hehehe)...

#

I will not lie, was about to write my own format to keep files as original... but will be quite a big quest... since need to design the correct format...

#

and to be honest i wrote my own format for something that i used in TLoD modding... the PrimData files...

wicked gulch
#

indeed... but my tools kind-of-depend on SC so i have to adjust them to the new paths hehehe

restive carbon
#

it took me several days to understand why gltf split vertices when I was working on my own tmd converter

wicked gulch
#

ahhhh

#

you read the notes i just post in the thread? hahaha

#

it can't handle two different colors for a same vertex... in some cases (because of the gradient adjacency) you need to duplicate the vertex and add it to the vertex array + adding a new primitive with that index...

restive carbon
#

a vertex has at most one vertex color

#

however it might have multiple normals

wicked gulch
#

or 0 normals

#

or 1 flat normal

restive carbon
#

if you export flat normals it splits as expected

wicked gulch
#

the best case scenario is to have each vertex with a normal

restive carbon
#

if theres smooth shading then it doesnt split

wicked gulch
#

in which 3D Software are you working?

restive carbon
#

blender

#

2.9

wicked gulch
#

weird... i had the exact inverse issue but in Blender 4.2

#

look at this

restive carbon
#

send a screenshot of your mesh

wicked gulch
#

i had this one

#

this with face orientation

#

this with normals

restive carbon
#

ah I see what you meant

#

I meant different kind of splitting

#

take a look at this

wicked gulch
#

ahhhh hehehe

restive carbon
#

this is flat shading

#

this quad gets splitted into 6 vertices

#

but if there was smooth shading it'd be 4

wicked gulch
#

ahhh yeah you need to split the Quads into Triangles by hand

#

and fill the Normals manually with your tool

restive carbon
#

blender does an alright job of triangulation automatically tbh

wicked gulch
#

yeah... but you will have some issues with Quads in TLoD if are not perfectly aligned

#

will tend to split in wrong directions and deform the mesh

restive carbon
#

I dont convert to quads lol

#

its all tris

#

I do calculate surface normals when the mesh is textured

#

otherwise just grab vertex normals

wicked gulch
#

that's why i was telling you... if you have a Quad and convert into triangle (even if Blender do that) will deform the mesh, the colors would be wrong and the Normals too... maybe the UV get corrupted too

#

the best you can do for Quads it's to manually convert them from your tool

#

and fill the gaps with the same data (if Flat normal)

restive carbon
#

non-planar quads are left to blender's interpretation

wicked gulch
restive carbon
#

here's the thing

#

thats an user error lol

#

you cant just raise 2 vertices of a quad and call it a day

#

triangulate it

#

thats user's job

wicked gulch
#

yeah you can set it and play with the values

#

but it's not efficient in terms of usability... since much people do not know how to properly doing that

restive carbon
#

oh wait

#

is your new tool addon or custom tool

#

I mean the tmd converter

wicked gulch
#

TLoD Assets Converter

#

and will get everything into glTF 2.0 format

restive carbon
#

tlod asset converter converts to tmd?

wicked gulch
#

nop... i have an addon in Blender for that

restive carbon
#

ah then our tools are different

wicked gulch
#

you need to convert a Blender model into TLoD?

wicked gulch
restive carbon
#

always 💀

#

my tool isnt addon

#

thats why it's user's job to triangulate

wicked gulch
restive carbon
#

it just takes a glb asset

restive carbon
#

i didnt want addon because blender keeps breaking addons with every damn update

wicked gulch
#

but you need to convert a Blender Model into TLoD again?

#

or you need to convert a TLoD model into Blender?

restive carbon
#

not rn but probably in rb3

#

i need to get back to black monster fight in rb3 lol

wicked gulch
restive carbon
#

anyway I do have a tool that can convert up to vertex colors

#

then I studied tims for 3 days and still didnt understand the point LOL

wicked gulch
#

the main problem with breaks on the addons in Blender is... devs do not update them for much time... and do not choose a single specific pointed version of Blender... the only exception is Mustard UI Tools

restive carbon
#

I'm gonna say no tbh

#

every addon I've used, a part of it breaks in each update

#

like

#

why 😭

wicked gulch
#

you only need to add the textures and thats the only thing the user must do

#

-for now-

#

i plan to add the auto-texturing soon

restive carbon
#

CLUTs ruin my life

wicked gulch
#

hahahaha

#

the main problem comes that each primitive have it's own CLUT reference

#

so each Primitive in a TMD Model could use 'virtually' a very different and single CLUT inside a TIM... if TIM format supports a U_SHORT to define TPAGE and CLUT data lol

restive carbon
#

iirc gltf supports extras

wicked gulch
#

one of the things that i had in my older tools that i want to implement again into Assets Converter is the PrimData... that file format i designed, compile all the CLUTs and TPages used by each Object in the model and you can retrieve that data into Blender too hahaha

restive carbon
#

I thought about adding those properties that way, like later on vram scrolling since aint no way gltf exports that

wicked gulch
#

because Blender or glTF 2.0 can't know which are your intentions with that data...

#

that's why i asked in here some time ago in which version of Blender i will be working... and tbh i do not plan to move it more than that...

#

if i do the support for that... i will keep using the same Blender version all the time

#

btw this is the result of my algorithm (maybe not clean or speedy, but do the trick)

#

mesh is not deformed even with no 100% planar QUADs

#

because in Blender those non planar QUADs are called N-Gons and N-gons calculations in Blender are weird to say at least hahaha

#

oh... i'm looking into my Blender2TLoD Addon code and it's shit as hell lol

#

also only for working Blender 2.80

#

if you want it i can share it... anyway i do not recommend the usage because you need to do the steps in a very specific way, if not will crash... and btw... in this tool you don't need to triangulate... and will export the file into TMD format

#

the specific way is you need first to create the model and texture it... and then start the conversion... but also you need to select the primitives types to the one you want to work on... so you can add properties like translucency and others hehehe

#

for that you need to select the faces and set them properties

#

that way i create some Custom Models that was shown in some of the SC streams hehehe

restive carbon
#

blender puts custom properties into gltf extras

wicked gulch
# restive carbon nope

ahh yeah... but for some Custom Properties maybe you want to work on a different way... that's why i ended using my own addon to convert models...

restive carbon
#

dw doom, I dont even have time to work on my tool thanks to rb3 lol

wicked gulch
#

maybe i could have something prepared just in time 😉

#

in Blender 4.2 what you think?

restive carbon
#

idk

#

the last blender version I used was 3.3

#

lol

#

I'll need to upgrade my build I think before I set foot into 4s

wicked gulch
#

ahhhhh... yeah for -reasons- i have 3.6 LTS installed too hehehe

#

i was thinking into moving everything to PLY and implement and own animation file format... hahahaha

restive carbon
#

im gonna need 256gb ram to perform subsurface level 15 on dart's model

wicked gulch
#

you want realistic?... well i will show you the atoms of Dart face lol -Icarus 2025.

restive carbon
#

that shall be my upscale /s

wicked gulch
#

tbh i'm half fighting with this... there is not actual-supported format that fulfill the needs we have with this models and animations... this is crazy... well at least not Open Source formats... i know FBX could do this and more... but you must pay to see the code lol...

restive carbon
#

tpage is the most complicated issue

#

like

#

Why would anyone specify "oookay this uses tpage X"

wicked gulch
#

hahahaha

#

that frustration is something i already know very well xD

#

like changing animation formats because of YES hahaha

#

about TPage, because in the game is hardcoded where to put the textures... even in the original PSX Dev tells to everyone to put some types of textures in specified places... so i assume that has to be something to the speed of reading that data or something hahaha

sterile lantern
#

LOD rarely actually uses the tpage except for the translucency bit and stuff

#

But it rarely uses the actual x/y from it

wicked gulch
#

aaaand i was reviewing my code... it's monstrous but is working... lol

#

maybe i won't change nothing from the gltf model... but only making stuff a little more in their 'job'

wicked gulch
#

changes done... now the glTF model 'compiler' looks less monstrous... but now the Model code is... since I had some plans about format conversion for that need to create the glTF 2.0 Specification data just in the moment the tool convert the Primitive Data into human readable form...

wicked gulch
#

Well i think i will remove some if not all the conversion Options from TLoD Assets Converter.
So Everything will be converted (Model+Animations+Texture)

wicked gulch
#

The reason behind this is... the more option I add, the glTF code get more complex directly to that options... the general conversion code is already very slow because of the Texture Conversion (something that I'm very aware of), but in glTF if you want to 'automatic linking' textures to a Model, you need to specify this in a very specific (excuse the redundancy) place of the conversion and also adding that into the list of the glTF Format. I know that sounds like a poor design from my side... but tbh i don't want to get stuck much more on this part...

#

because if not i have to branch the code in several parts, something that i don't think will worth...

vestal halo
#

It might be worth simplifying, at least for now.

wicked gulch
#

yep... the biggest problem comes also from my lack of deep knowledge on the glTF 2.0 format and if Blender supports everything or not from the format... atm I made several test and seems to be supported in a big degree

wicked gulch
#

i've been studying the glTF documentation at certain point... some stuff make a lot of sense... other not so much... but well I'm preparing adding some of the new features... atm i simplify some of the code... enough to merge my code to a direct conversion of glTF... most of the problem comes that the nesting of objects and properties is very different to the TLoD Model format... making some stuff a little difficult to get in the correct path... specially the thing that you can't repeat the same vertex for two different arrays (at least if you don't want to get the model broken in colors or Texture bleeding)...

#

keep in mind that glTF is designed to Direct Rendering... so the less calculations the Engine that uses this format... the best...

wicked gulch
#

well good news (this time fr)... I just finished most of the general conversion code, implementing a more specific Object into the conversion of Primitives from TMD format, this object of type TmdPrimitives will carry the Primitive Data more efficiently... took me some time because was several things that I had to thinking a lot of times, specially about the glTF conversion and sort of the data.

half stag
#

I would like to have rose model with the textures. I used the asset manager and managed to get rose in blender, but her textures seems to be messed up always when I try to apply them. Could someone help to get a complete model of rose with her texture applied right?

wicked gulch
#

Hi Fuzzy... unfortunately we can't share models (original assets) directly or indirectly...

#

anyway your luck maybe be change soon

#

@vestal halo @sterile lantern @junior mantle @smoky flare @round shadow @true apex @restive carbon

#

gonna go to sleep but meanwhile i will figure out what happened to Mayfil... first glance thought to be something related to the the new feature but the error came from a wrong calculation in the animation array that i've already fix, so the missing thing in that model is bugging me a little hahaha

vestal halo
#

Congrats! Another landmark update to the software. <3 thank you.

sterile lantern
#

Nice, looking good doom

true apex
wicked gulch
true apex
#

ooooooohhhhh

wicked gulch
#

so that's why I told Fuzzy that maybe luck changed, I'm glad to announce that finally TLoD Assets Converter is capable of Convert Models with the Textures and Materials already setup for the user, no more adding shaders or any Material stuff by hand... just a few clicks and you got the models already setup with everything you need to work with...

true apex
#

how far are you into the converter, did you manage the deff?

wicked gulch
#

that's a very good question... since i was re-writing the code to made it a little more 'readable' i touch very little from DEFF... so i will start very soon on that... the main problem still remains... doing an Engine simulation, will take DEFFs the exact time to convert, that it take to be seen on screen during game hehehe... maybe with this new add into SC debugger (thanks a LOT again, Monoxide) i will be finally capable of hand writing most of the things to be just a few linear algebra calcs...

true apex
#

wish you the best on that one

wicked gulch
#

thanks a lot!

true apex
#

you got this you've come this far and created a wonderful tool

wicked gulch
#

I have two theories on what's going on with Mayfil... 1 or the Primitive CBA it's retail bugged indicating a displaced CLUT position... or something more weird it's going on...

wicked gulch
#

so far so good... seems to be something wrong with the CBA data written in the Primitives... now i will give you an insight of how i did 'the magic'

#

since the first time i touch glTF 2.0 i was aware that could handle Primitives as PSX do (except that do not support Quads)... now the question that i didn't answer in that time if each of the glTF Primitive could had it's own Material to be assigned (this way we can just assing a Texture to a Material and that Material to an specific Primitive)

#

turns out that was possible (but a little complex), so i decided to re-split the Conversion List, this way even if we take a little more time, will be less than having 500 models converting at once...

#

then i started to re-write some parts of the code to fit this idea... before my code just read the object data and directly write into a single array... making conversion very fast (but the problem was that we cannot assign a primitive it's own material)... to do so i had to split once more the data processing, so now what my code does is... during the Texture Conversion i get the CBA Data from the Texture (TIM) and when i start to convert the TMD Primitive into glTF Primitive i check for the CBA Data written in the CBA Property of the TMD, this way we can match the Textures as in the Original PSX hardware...

#

CBA -> CBA linking...

#

the downside of this:
The conversion is slower, compared with my tool previous versions.
glTF File size considerably increase, because i'm writing one glTF Primitive at a time, having FULL control of the 'Each Primitive, use this Texture'.
So i think this is a price worth to pay in a good cause. Making less effort matching stuff by bare hand

wicked gulch
#

50 seconds in Full Conversion (everything enabled to convert) for Battle Stages, which are: 89 Models + Animations + Textures.
in Average: 0.5 seconds each conversion.

#

Solved Mayfil issue...

#

resulted that i was doing a wrong calculation in the 'next' CLUT X Position Entry

smoky flare
#

That’s so cool! We could basically do custom cutscenes like right now

vestal halo
#

It's probably not that simple, haha.

true apex
#

But the fact that it works so well I don’t mind the slow down

wicked gulch
# smoky flare That’s so cool! We could basically do custom cutscenes like right now

actually this is not a bad idea... the little I've seen from CutScenes (because they actually use the DEFF System to be played) is not so complex and in general are very little particles involved... but the key is that they give the relative positions of Models... and now I can confirm which is the Main object that every object inherit the position. As i thought in most of the case Main is the center of the Battle Stage place (or Gizmo X: 0.0, Y: 0.0, Z: 0.0)

#

now that i get into home i will add the MCQ Conversion directly as Skybox... but in this case the tool won't store the Skybox in the Textures Folder, instead i will leave it just aside to the glTF Model

wicked gulch
#

well already added and working...

#

now... the MCQ Skyboxes will be only generating the Texture... not the Skybox 3D Model... since in TLoD is not made that way... instead they scroll tiles around the Camera Perspective and the texture is applied into quads of the same size of a tile... I think are 16 * 16

#

in other words... the Skybox Texture is applied into a very big plane that 'follow' the Camera, so no matter where are you looking, the texture is always in front, when the scroll finish the last part in width orientation, will continue with the start of the image in width orientation... and i believe that made the same for the Camera when pointing up (there are very few moments this actually happens).

half stag
#

All of this is very exciting. I can't wait for the new version. Your doing a great job.

wicked gulch
#

i'm so amazed... i just find a breaking bug (from this re-write) inside my tool that almost made to the end lol

#

the culprit? a forgotten _

#

yeah an underscore

vestal halo
#

That certainly underscores the problem!

wicked gulch
#

Just figure out (yeah took me a long way...) that WorldMap models have their UV Wrap Data adjusted to be 1/4 to the real texture size...

vestal halo
#

performance savings?

#

Second question: Is it like the battle entities which have multiple texture sizes on the UV?

wicked gulch
# vestal halo performance savings?

hmmm that's a good question... the WorldMap textures blocks (the ground textures themselves*) are pretty big for each part, but the model object for the ground is a single object (is not split in blocks) so i think is related to how they wanted to read the data from VRAM 🤔 ...

#

but the size could be part of that too

#

realized this because I'm trying to find out why the Material creation get broken hehehe...

#

by general rule... each model (if has textures) have an assigned Texture for it, a single one... but for other things like WorldMap multiple textures could be assigned for a single Model... so i have to review my code (because i do not want to branch it too much, in other words i want to keep functions as generic as possible)...

vestal halo
#

I thought you meant world map character models. That's why I asked. There wouldn't be much use for multiple level-of-detail textures in the actual map UV.

wicked gulch
wicked gulch
#

but in that case they used just 1 texture so there is no problem about them

vestal halo
#

I almost wish there was a set of them, because the world map texture is verrryyyyyy low-res. It really needed a higher-res texture IMO.

#

but with everything else being designed, I bet there wasn't much room for wmap refinement.

wicked gulch
#

ahhh yeah... MiniModels for WorldMaps have the lowest resolution in almost all the game... that's a shame... but if you join all the Textures that made the ground for WorldMap Objects, those are pretty big... if i'm correct, all joined could reach easily 512*512 (if not more than that)

#

maybe the 1024*1024... but with all the textures joined i repeat...

sterile lantern
#

Even as it is, wmap could only render at 20fps

#

And they didn't have a whole lot of vram to work with for larger textures either

wicked gulch
#

can you recall? hehehe

#

sorry i'm dumb... just find out

sterile lantern
#

Whatever resolution the game is set to

wicked gulch
#

hmmmm Primitives TPage are displaced by 2 tpage units from the intended Pixel Position of Textures... the CLUTs the same... this is only for the WorldMap Mini Models... i wonder why...

#

and this happens only to the WorldMap Mini Models...

#

i'm aware that in the WorldMap engine there a static array with new X/Y Values for UV Textures... but i'm not so sure if i want to hardcode the same way

wicked gulch
#

well find out what's going on... now i have to rewrite the CLUT split Function...

#

or doing a very special handling to WorldMap Textures

wicked gulch
#

Well MiniModels and in General WorldMap textures are getting correctly assigned... now i face a new problem... each of the Ground WorldMap models are very very variable in size X or Y and need to be set all in a single Texture... i think i find a way to kind of merge all of them but still i think is not the best thing to do... because something tell me that will be giving me some problems...

#

the textures are assigned but the size is 100% incorrect...

wicked gulch
#
# For some reason the Original SC way to handle the Rotations is NOT working in my conversion, even if are pretty similar.```
#

idk why this is happening... but happens... I took an exact 100% approach of how SC manages the rotations and convert PSX Degrees to Radians and for some reason break rotations on the conversion... using my old way it's good enough... i wonder if in some of the calcs they were preparing stuff previously to get into the WorldMatrix conversions

sterile lantern
#

Are you using column-major matrices?

wicked gulch
#

nop... i'm just converting each value and then i directly send it to the Quaternion Converter

#

maybe it's that

#

because i plan using Matrices only for DEFF because i understand less than 10% of the 'why' they do so much matrix calculations

#

most of my knowledge it's based that various DEFF Rendering/Calculations code are interacting directly to the GTE and values stored in real time in there

#

but in my mind was something like 'hmmm if it's working there, why won't work on other parts'... anyway if I add the Matrix Calc would be redundant in this case with more code... while my direct approach it's enough because the rest of calculations are directly done in Blender during animation playback...

#

i will take NOTE on this... because surely i will have to adapt the DEFF Converter code to use a direct approach maybe...

#

tbh when, I read and translate the code, did it directly. Analyzing it's something that I was doing very slowly to try to understand what things are 'really necessary' and what not...

#

obviously I'm very sure that I'm doing things wrong or not 100% correct... but in this case sometimes I sacrifice the "intended way to do things" over the "most efficient and code liner, as possible"

wicked gulch
#

for context: #⛓️‍💥severed-chains message
Now I know what's happening and this shows how a silly assumption almost ruined an entire project... well I'm gonna start explaining:
In the very first attempts of converting TLoD Models I had several issues with UV calculations for 3D Software, since 3D Software of any kind depends on floating points U and V values, while in PSX is using Integer values for that (because the actual UV data is processed as TPage + U | V to define the positions). Since I was working with the Characters models directly in that stage of development and SC was in it's very early steps little did I know about the Engine behavior, so I thought that always was the same calculation (no matter the texture size). After some try'n'error i find that dividing the Characters and Enemies UV data by 256 will fit to the corresponding UV value on 3D Softwares. Now the problem actually is that i have never thought about the different Texture size, making textures doing anything but fit in the position... now that i have the knowledge i will try another approach, ajusting the UV size and divide it, by the power of the Texture to be used!.

vestal halo
#

Congrats on learning more! ^_^

wicked gulch
#

thanks so much Drew!..

vestal halo
#

welcome. Keep pushing! I am right there with you.

sterile lantern
#

Modern UVs are normalized between 0..1

#

You have to divide the UVs by the texture size to normalize them

wicked gulch
#

yep

#

find out that just today

#

hahaha

#

so we are speaking of almost 5 years of a latent hidden bug in my tool

#

who in it's sanity will divide by the power of 256, just because the value is a Byte? xD

sterile lantern
#

It probably worked for most stuff because a 4bpp texture page is 256x256

wicked gulch
#

indeed hehehe

#

because all of them are 4bpp 256*256 of 64 CLUT Entries...

sterile lantern
#

8bpp is 128x256 and 16bpp is 64x256

wicked gulch
#

and forgot about that hahaha

#

so my UV get displaced by the power of 256 that's why i had to adjust them in first place... because i didn't take in account the Texture Size...

#

this new approach made me do that haha

sterile lantern
#

It's easiest to imagine a texture page size in bits, each texture page is 1024x256 bits

#

So the more bits each pixel takes up, the less pixels you have available

wicked gulch
#

also i find out that the 8bpp had a very long CLUT stripe hahaha

#

those almost cross a quarter of a VRAM

#

so it's very easy to get CLUTs from 8bpp overlapped...

sterile lantern
#

Yeah 8 bits means 256 possible values vs 16 for 4bpp

wicked gulch
#

this is so good... even without coding a single line i know that i've solved the issue...

wicked gulch
#

well, tested and work as intended... this bring me some peace to what i'm doing... now i can move on to the next batch... Bosses

wicked gulch
true apex
#

Looking good my moth is watering for this tool lol

wicked gulch
#

there are a lot of improvements made in this new workflow... and tbh I think this will be the very last time i rewrite the tool... since i get the generic and abstraction point that always wanted...

vestal halo
wicked gulch
wicked gulch
#

behold to this two classics!

vestal halo
#

I assumed this was another video that contained no sound. I was wrong. People are looking at me weird.

wicked gulch
#

sorry! hahahaha

#

at least this time i didn't edit the audio to do an echo...

true apex
#

lol

true apex
#

just thought of this playing with models and textures that some of the charecters have different eye colors than the official eye colors lol

vestal halo
#

Welcome to blursed knowledge!

wicked gulch
#

well finally i matched the SubMap MiniModels Textures this is also done automatically

junior mantle
#

Big

vestal halo
#

Dyrt is here.

true apex
#

lol love how it turned out?

junior mantle
#

Sure this isn't Grort? Short for Groin Dart ?

wicked gulch
#

rtDa i call him...

#

hahahaa

#

well now i have a very little issue with the "two models in one" texture matching... but i'm 100% positive that have to do with CLUT matching

sterile lantern
#

Uh no that's obviously

wicked gulch
#

Dart Gizmo

#

since all the object parts are collapsed to the center of Gizmo

#

@sterile lantern how did you solve the Dual Model Texture issue in SC?

#

this is for MiniModels ok?

sterile lantern
#

I haven't gotten around to fixing it yet

wicked gulch
#

well I think i have found the issue but first i will read each Primitive 😉

#

the Texture UV Adjustment is right...

#

and the calculation for them is right too... the problem is from the Primitives in the model... pretty sure that are pointing to anywhere in the VRAM except the one place* that had to...

#

also it's funny that the PXL files -{in their header information}-> Pixel Data Position in VRAM are all pointing to the X = 0 ; Y = 118 or something like that... in other words in the original file are all overlapping to the Buffer RECT, that's why they used some code fixing lol

wicked gulch
#

and to be more honest on this... seems to happen only with the dual models of Dart and Shana (the model used whenever Dart carries Shana)

#

i'm looking on other dual models and seems to be all right

#

as you can see

wicked gulch
#

well the Beta Models also had the same issue lol

vestal halo
#

that is a face.

wicked gulch
#

i can't get it... the Primitives are displaced only by 16 pixels... and that's breaking the whole thing lol

#

now my theory is... originally in the PXL files the some CLUTs for those Dual Textures are stored one after another from right to left to right... the problem was that in the conversion they get all displaced into a single column making the reference get lost?

#

welll i just do a not refined fix and kind of solve it... but is using an incorrect CLUT... at least now i have some texture matching and i'm around the view of what we got in SC

#

so my theory is gaining more and more power... because in retail game this are correct

#

hmmmm

#

As i thought... some CLUTs are not only row, but columns...

#

so the number of SBojs it's limited to the size of PXL files which can be stored in the VRAM

#

we have two entire TPages + half TPage for PXLs files

sterile lantern
#

I'm out atm, I'll be back this evening

wicked gulch
#

FOUND IT!

#

this are the missing CLUTs

#

we have 7 missing CLUTs and the conversion got 7 Missing CLUTs too

#

ahhh we are writing a single CLUT for 32 pixels X textures... when actually we need to duplicate that to the size in X...
in other words:
16 pixels -> 16 pixels CLUT
32 pixels -> 32 pixels CLUT
so on...

#

this is why i knew that 4-BIT TIM files can store at least 64 CLUT Entries for 256*256 Textures...

#

so single slot PXL files have assigned a 16 Pixels CLUT; dual slot PXL files have assigned 32 Pixels CLUT

sterile lantern
#

That seems pretty likely to be the problem

#

Is the image on the left from the SC unpack?

wicked gulch
#

yep

#

and the right is the PXL file that I change the header so TIMEdit could load it as Pixel Raw data

sterile lantern
#

Cool, thanks, I'll look into it when I'm home

#

Can you create a ticket for this if there isn't one already please?

wicked gulch
#

sure no problem!

#

done

wicked gulch
#

@sterile lantern now we have the correct CLUT dump for PXL files which have double size double CLUT

#

now, the problem in SC persist... but i think it's something to do with the UV Adjustment... i can tell because in my tool i still having the texturing issue, but i know that's something related on how i write the Textures 🙂

junior mantle
#

This is an SC only issue, right?

sterile lantern
#

Yes