#List of useful tools to Convert Assets (3D and 2D)
1 messages · Page 4 of 1
The before image has that hard line across the chest that the after image does not.
Thanks a lot for the expedient fix, @wicked gulch
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
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?
@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?
try a little power/strength over the main light... i recommend using a sunlight and in power set it in 1.2/1.3
something around
Season 01, episode 05: Kiddie Pool
This was with natural forest lighting.
if you want i'm at voice chat
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.
I think Doom is still working on DEFF conversion.
Which viewing mode are you in? Note that the second-from-right option has no external light, while the right-most option requires you to add one (or more) light objects.
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?
Okay, cool. I was on to something haha.
but have dynamic changes... depending on various factors... getting the 'correct' lighting is somehow complex...
question... a dumb one... in the battle script is written that data?
the player_combat_script?
If not changes from Battle Stage * to Battle Stage we could get a 'Standard' Lighting configuration that should fit
Was curious about it since it is available on the beta 2.0 just wanted to make sure I didn’t mess up the set up lol
But your probably right Grey
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)...
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
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
Pretty sure the stage lighting vectors are in the stage data?
I'm like 98% asleep so I won't be any more use than that right now lol
That make sense lol so then I would assume that why the animations can’t be converted too I’m assuming
nop
Oh lol
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
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
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
Yes cause I can downloaded when you posted the link last night
no error after open it?
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
well i just downloaded the tool and open it and the DEFF Converter is working 🤔
maybe... better do that
tbh i expect that you had an error, more than a button was not pushable hehehe 😅
so a fresh installation always is good too
Yea you know me I’ll find a bug or two for you lol
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
those pants always missing for everyone so far...
once i put myself to work in the Blender2TLoD Addon again i will fix it
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
that's not related to my tool hehehe 😅 ...
i know thats the funny part
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
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
that's fine
ok now i feel dumb cause the files are there
as intended
dont mind me Doom i didnt check the actual folder lol the files are there dont mind me
no problem... while it's working for you and you can do your things... it's all right...
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
hahahaha yeah... i'm using the same approach as the Devs did to the game...
you want to go into voice chat?
can't also watching my nieces while doing this stuff so slightly distracted
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...
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
some of them are the same 100%
i literally duplicated his head and just roomed faces and put a red toned color behind it lol
also could be that some of the textures were slightly very slightly more contrast or lighted
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
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
fun part is ive been creating my own textures along the way
but that could be a fun project
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
anyway that's good to do!... i hope in a future code a Texture creator for TLoD but will take some time and knowledge...
your hoping for what?
for sure!
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
scriptResetCameraMovement someone is sure that is resetting the movement and is not actually resetting the position and the attributes?
well as i thought... resetting all...
but the projection planes and the flags... are not the attributes of the Camera?...
interesting... there is no function to clear everything...
Why would you want to clear everything? That'd set the camera back to origin
Which would probably be in the ground
🤷🏻♂️ ... 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
Clearing things is inefficient, you can just set a new position
true, lod is known for its efficiency + optimizations
hmmmm
i was thinking...
bah better i shut my ass and had all the data presented to clarify my thoughts xD
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...
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
the fact youeven was able to do this is impressive
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
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...
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
Won't that still come in handy for you?
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
If anyone interested... here it is...
if anyone interested... you could see how would look like in this file (at least the folding is working great)
here are the 'folding string' i use to define where to fold
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
Yeah, it can be changed at any time
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
Don’t rush anything take your time rushing a product doesn’t help anyone
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"
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...
hmm interesting
test
gooning
as always xD
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
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
nop... is correct is calling the file number 10 which is the Armor...🤔 ...
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 🤣
Gotcha, appreciate it
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...
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
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... 
doom is about to reinvent SC
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...
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
Frankly, your ability to understand any of this is impressive.
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...
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
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
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...
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...
Good luck soldier
So... Monoxide find a TmdType which actually had no TMD file inside.... interesting 🤔
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
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...
@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
@wicked gulch TmdWithId is the exact name, it's literally the TMD file struct with the ID included
ahhhh i misread then the intentions hahaha
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...
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)
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
believe it or not... i'm so happy with this discover
@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
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...
seems that Model124 it's the Structure for models which had Animated Textures, Animated CLUTs and* SAF/CMB/LMBTypes Animations involved 🤔
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...
You should not put interpolation frames in the files
Interpolation is done when something is rendered
excellent... wanted to confirm because in the apply function i will cut half of the code in there...
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
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
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
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.
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
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...
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
you got this
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...
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
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.
It runs just before the particle is rendered
Does whatever the particle needs to do just before it's rendered
and there is no way to tell where the particles get animated?
That would be wherever the devs decided to stick the code
Some do animation stuff there, some do it during render
It's distributed across multiple tick methods on the base class
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
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
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
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
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...
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...
Q: Should I continue sinking into the madness of the TLoD Particle System?
A: Outlook is grim, ruff.
you are pretty right...
# 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...
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
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
@sterile lantern any thoughts of why this is happening? 🤔
behaviourtype 0x2a uses a magnitude scalar, others don't
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
¯_(ツ)_/¯ oversight
in other words... the else below that part of the code never hits
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?
If you feel you are equipped to do that, go for it
tbh i feel like i can handle it...
i've already translated all the code from SEffe.java scriptAllocateParticleEffect to everything down below...
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...
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...
OH SHIT.... this is working
lol
i don't view a thing... but is working lol
and it's fast

Ooooooohhhhhhh
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
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
Have you converted the script engine yet? 😆
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
I'm sure you'll manage it one way or another
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...
Yup
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
Yes, it's pushing a new stack frame
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
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
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?
Don't think the manager is used for compiling is it?
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
How's it used by scriptstate
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
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)
Yeah you'll definitely need a script manager
good thing about this... if i can make it work... i'm pretty sure that my understand about script engine will evolve to
%
it's funny that the pointer array for ScriptStates on Scus94491BpeSegment_800b.java it's actually
+ 1 (because 0 is included)
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
Perfection
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?
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
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
You'll have to look at the code to see how the header and each parameter type is parsed
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...
You won't be able to run scripts that use registry ids if you don't implement them
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
Nope, check the script patches
well time to implement the Registries lol
almost all the CutScenes and most iconic Enemies moves requieres Registry for some reason hahaha
They use items
here an example
an attack from enemy
yeah... some DEFF attacks from enemies are count as Items...
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)
Null is 0
-1 is whatever you want it to mean lol
But null is just a macro for 0
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
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
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?
Is it even a pointer? Null doesn't really have meaning outside of pointers
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
Just seeing to a known value
Monoxide i came back to give you some strange feelings in your guts haha
confirmed to be in the source code
What is it? I just see a missing empty line between those two lines that have text.
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...
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
Have I mentioned it would have been easier for you to just do this in Java? 😆
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'
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
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...
You wanna see the original parameter parser? 😛
Well, that wasn't the original, but that was 2022
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
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!
Ah, it can't swap?
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
Ask icarus/zy, they were the ones I made the events for
I'm currently insulating my endless ceiling
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.
The event I have is more of uh a duplication effort.
@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
Gotcha, thank you
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...
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
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.
Severed Chains
Play LoD with our community-built PC port, which runs the game much better than emulators and has breakout modding capabilities.
Download | PC Setup | SteamDeck Setup | Github | Known Issues
the download link also has a summary, a FAQ, and more.
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
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!
thank you sir I'll be looking for more help putting the new models into action after I've modernized them
Hey @wicked gulch 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
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...
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
I don't believe that tangent is used anywhere in the code
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'
Yeah
Hi, when i run Dart export of any addition i get this error, has this already happened to anyone?
Hi Marcos... first of all, you speak spanish?... just to avoid some language barrier hehehe
Nope sorry, i'm italian though, maybe i understand some
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?
yesss
ok... now i assume you setup the SC Files folder... that folder contains all the game assets unpacked
yes
ok... which version of TLoD TMD Converter are you running?
i tried both with 0.2 from an old link and 0.6
oki doki... let me try a second something and i will tell you what's going on
thanks 🙂
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
the dumping folder of the 2 tools are shared
now i try to use 0.6 version on a new folder to dump
ahh no problem with the dump folder
i mean the folder in which is the tool
you'll see some folders like this
oh i see, no they are not mixed
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
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
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
also... use the latest version of SC for this... you can find it in here:
https://github.com/Legend-of-Dragoon-Modding/Severed-Chains/releases/tag/devbuild
I try to keep the SC Version equals to the TLoD TMD Converter Version....
so files do not get miss
god i wasted your time, i'm so sorry
redoing SC export worked!!!
Anytime mate!... just to help you!... enjoy it!
thanks 🙂
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)
one day doom is going to drop python fork of SC
And then he'll ride off into the sunset, never to be seen again
believe it or not... i had something functional... but only for read the Scripts and made it run while executing some functions... xD
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...
here a little doc to keep my brain on the same tune that my code lol
sorry this was 'on the fly' record to show a little bit the upcoming changes...
Yes DooM, the hypothetical question is correct. We're all lost.
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
but before that comes he will deliver the program of his dreams
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
Ones we've... never seen before? Perhaps?
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
If it possible the Ending Credits entries are simply the literal credits? Then again, I've seen them in DRGN dumps..
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
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?
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
Lately i was seen my glTF 2.0 code and made me think a little bit...
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!
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...
Oof that’s rough
indeed... but my tools kind-of-depend on SC so i have to adjust them to the new paths hehehe
it took me several days to understand why gltf split vertices when I was working on my own tmd converter
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...
if you export flat normals it splits as expected
the best case scenario is to have each vertex with a normal
if theres smooth shading then it doesnt split
in which 3D Software are you working?
send a screenshot of your mesh
ah I see what you meant
I meant different kind of splitting
take a look at this
ahhhh hehehe
this is flat shading
this quad gets splitted into 6 vertices
but if there was smooth shading it'd be 4
ahhh yeah you need to split the Quads into Triangles by hand
and fill the Normals manually with your tool
blender does an alright job of triangulation automatically tbh
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
I dont convert to quads lol
its all tris
I do calculate surface normals when the mesh is textured
otherwise just grab vertex normals
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)
non-planar quads are left to blender's interpretation
that's risky and shurely will deform the mesh... i know because my first shoot on glTF 2.0 on blender was like that
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
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
tlod asset converter converts to tmd?
nop... i have an addon in Blender for that
ah then our tools are different
you need to convert a Blender model into TLoD?
are the day and the night...
in speed... in processing... in writing... hehehe
it just takes a glb asset
nah yours is addon lol
i didnt want addon because blender keeps breaking addons with every damn update
but you need to convert a Blender Model into TLoD again?
or you need to convert a TLoD model into Blender?
ahhhh oki doki... i will put my hands into work that...
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
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
I'm gonna say no tbh
every addon I've used, a part of it breaks in each update
like
why 😭
take my TLoD Assets Manager... and your life will be very simple
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
CLUTs ruin my life
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
iirc gltf supports extras
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
I thought about adding those properties that way, like later on vram scrolling since aint no way gltf exports that
be aware that you need to create an addon into blender to support those 'extras' 😉
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
nope
blender puts custom properties into gltf extras
my mans mathing
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...
dw doom, I dont even have time to work on my tool thanks to rb3 lol
maybe i could have something prepared just in time 😉
in Blender 4.2 what you think?
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
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
im gonna need 256gb ram to perform subsurface level 15 on dart's model
you want realistic?... well i will show you the atoms of Dart face lol -Icarus 2025.
that shall be my upscale /s
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...
tpage is the most complicated issue
like
Why would anyone specify "oookay this uses tpage X"
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
LOD rarely actually uses the tpage except for the translucency bit and stuff
But it rarely uses the actual x/y from it
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'
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...
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)
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...
It might be worth simplifying, at least for now.
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
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...
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.
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?
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
Congrats! Another landmark update to the software. <3 thank you.
Nice, looking good doom
GIMME
turned out really good cant wait til we get to play with this ourselves, i didnt hear you say it in your video but did you manual have to place all those textures to the models or were they attached already when you used the converter
that's the magic i told... it's attaching the texture in an 'automatic' way...
ooooooohhhhh
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...
how far are you into the converter, did you manage the deff?
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...
wish you the best on that one
thanks a lot!
you got this you've come this far and created a wonderful tool
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...
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
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
That’s so cool! We could basically do custom cutscenes like right now
It's probably not that simple, haha.
But the fact that it works so well I don’t mind the slow down
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
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).
All of this is very exciting. I can't wait for the new version. Your doing a great job.
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
That certainly underscores the problem!
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...
performance savings?
Second question: Is it like the battle entities which have multiple texture sizes on the UV?
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)...
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.
I don't know if in retail Battle Entities Mipmapping is applied... but it's true that in the Textures the MipMapping technique is present... if not applied, surely that happened because the authoring tool they used to create textures already generate one for it...
ahh yeah for those models also is happening the same...
but in that case they used just 1 texture so there is no problem about them
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.
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...
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
asking about this topic... how large it's the original TLoD Framebuffer size?
can you recall? hehehe
sorry i'm dumb... just find out
Whatever resolution the game is set to
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
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
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...
# 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
Are you using column-major matrices?
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"
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!.
Congrats on learning more! ^_^
thanks so much Drew!..
welcome. Keep pushing! I am right there with you.
Modern UVs are normalized between 0..1
You have to divide the UVs by the texture size to normalize them
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
It probably worked for most stuff because a 4bpp texture page is 256x256
8bpp is 128x256 and 16bpp is 64x256
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
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
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...
Yeah 8 bits means 256 possible values vs 16 for 4bpp
this is so good... even without coding a single line i know that i've solved the issue...
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
Looking good my moth is watering for this tool lol
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...
All moths should stay hydrated for health and safety.
Implemented Character Conversion
I assumed this was another video that contained no sound. I was wrong. People are looking at me weird.
lol
just thought of this playing with models and textures that some of the charecters have different eye colors than the official eye colors lol
Welcome to blursed knowledge!
well finally i matched the SubMap MiniModels Textures this is also done automatically
Big
Dyrt is here.
lol love how it turned out?
Sure this isn't Grort? Short for Groin Dart ?
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
Uh no that's obviously
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?
I haven't gotten around to fixing it yet
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
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
well the Beta Models also had the same issue lol
i can't get it... the Primitives are displaced only by 16 pixels... and that's breaking the whole thing lol
@sterile lantern maybe you'll find this useful
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
I'm out atm, I'll be back this evening
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
That seems pretty likely to be the problem
Is the image on the left from the SC unpack?
yep
and the right is the PXL file that I change the header so TIMEdit could load it as Pixel Raw data
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?
@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 🙂
This is an SC only issue, right?
Yes