Chrono Compendium
Kajar Laboratories - Fan Works and Submissions => Chrono Cross Modification => Topic started by: ZeaLitY on August 05, 2009, 07:01:50 am
-
That's the purpose of this forum—to help with the above, in case I encounter any problems. I think the models are the last content from Chrono Cross that should be ripped to the encyclopedia (we've already got background art and the character menu art, as well as relevant dynamic art such as the Chrono Cross element effect on salient pages), but it's been awhile since I've kept track of what all gets dumped, so suggestions are welcome. (Though I'm guessing people won't be interested in walkmeshes, but who knows...)
Only people who can see this are Vehek, utunnels, FaustWolf, Luminaire85, myself, and the other administrators.
Correspondence so far:
Make sure you've got, I think it's version 0.4.0 of Luminaire's importer. I think you should be good to go since version 0.4.0 can handle 128x128 textures (previously we had to stuff some data in to fake all textures at 128x256). However, I'm not sure whether the latest version could correctly handle double-texture enemies.
As a quick check, see if you can view these properly:
Serge Battle Model (example of 128x256)
Serge Field Model (example of 128x128)
Dario Battle Model (example of dual-texture with two 128x256 textures)
Quaddfid Battle Model (this should be really screwed up, actually -- that and the underwater jellyfish monster are the ones you'll have most trouble with since its textures function somewhat differently than most others'. I think they've got three textures and/or three palettes. If Quaddfid works properly, color me surprised).
Blender does have problems with translucency. So for some of the underwater creatures and the Time Devourer we'll have to call in someone like Unaisis or one of the other experienced modelers.
Last December I got about a third of the way through isolating all the field models from their respective rooms, to create a field model pack like I did the battle model pack (do you have that one?). That's been nagging on me since I left it unfinished, so I might make some time to finish that. Various objects, like doors and the Dragon Tear, should be in the field models.
I still don't have summons because I was having trouble isolating their textures in TileMolester, let alone their battle model data, which seems to be stored in whatever kind of unstructured format spells are stored in. The summons will definitely be last.
I had hoped to write a script for converting the Cross model files into images and/or more common 3D file formats, but it turns out Blender's scripting interface is not well suited to this sort of batch processing. Unfortunately that leaves only the brute force approach.
There is no a priori limitation on transparency from the importer; as long as your texture image files have black (0, 0, 0) set to transparent, then the transparency info will make it into Blender. The trouble is getting Blender to show it properly. If I remember right, my experience was that you needed to render (F12) to have the transparency work. If you have access to the old thread, you might skim the last part of it to see if I or anyone else left any tips behind.
Field models, battle models, and monsters covers the majority of the models. There are a few odds and ends, such as the boats, the cats you are transfomed into on the Zelbess, etc. There could be other things I suppose; that's just what I remember from the time.
You'll probably notice as you go along that strange lines that, for example, bisect a character's face. This is a bug with the handling of the texture info that I was unable to resolve at the time.
Let me know if you run into any trouble or have more questions.
P.S. Not sure how familiar you are with Blender, so this may be anywhere from painfully obvious to incomprehensible, but I might suggest a workflow similar to the following:
For each model:
1. Create a new model in Blender (File -> New or Ctrl+X).
2. Delete the cube that appears by right-clicking on it and pressing X.
3. Execute the import script to import the desired model information.
4. Change draw type to "Textured" to see model with texture applied.
5. Save model in Blender format (.blend).
6. Export model in other formats if desired. (No idea which ones would be good.)
7. Attempt to take screenshot(s).
Hmmm, I feel like I've encountered that purpleness before, but I don't remember what was going wrong. I just tried it myself with both Blender v2.49 and v2.49a and it seemed to be fine (no purpleness).
Current issue is that I'm getting nothing but a purple texture. I've tried 2.44 (script didn't work), 2.48, and 2.49a, using Python 2.6.2. I'm running Vista, if that matters. Attaching image and .blend output file for Serge, in case someone else wants to try opening it and seeing if the texture appears.
-
In case anyone was missing it, here's the Chrono Cross battle model archive, sans the summons.
http://www.sendspace.com/file/ehzpvr
The summons are stored in a different model format, I think it's sort of without the header structure (just raw vertices and animation data) but I'm not entirely sure yet. I need to get all the summon textures from VRAM dumps because those are stored in a funky format too (it probably conforms to the altered .TIM format for the most part, but the image width is greater than what TileMolester allows without some creative distilling).
I'm working on the field models, and hope to have a comprehensive model pack ready to go between Friday and Sunday.
-
Update: when I use the models / textures in that pack, the texture shows up fine.
Previously, I was using the dumped OUTs (forgot if I was using yazoo's or Nemesis's tool), and trying
3056 Model Serge
with
3055 Texture Serge.
Current issue is just playing with camera controls to get front, back, side, and default angles in Blender's render mode to take screenshots.
-
Ah, sweet. I guess the textures are .PNGs in that pack, and that's the input Luminaire's model viewer needs?
-
Well, regarding the line issue, is there any class of models that doesn't have any issues at present with 0.4.0? I could go ahead and make screenshots of those, and then hold off on the rest until improvements come.
-
Player character battle models should be perfectly fine I think.
-
How's the field model labeling going?
-
Player character battle models should be perfectly fine I think.
Serge has a slight line on his chest, though his face is okay.
-
I don't know if that is blender's problem, I tried some models a while back and some of the characters have a line/gap in the middle.
Did you experience this currently?
-
Yeah; it's been an issue with importing since the beginning. It's been too long for me to remember if some lines like that are endemic to the characters in-game, though...
-
So then, is it possible to get each individual weapons' models? Or has that already been done...?
-
Vehek, I've got the field models about 2/3 of the way identified. Then comes the arrangement. Tomorrow would be a realistic date for release of a field model pack. Did you say that you had some field models arranged already, Vehek?
ZeaLitY, can you post a screencap of the Serge problem? I want to make sure the textures in the pack aren't misaligned or something. I also seem to remember people getting different results in Blender's "Render" mode from the normal model viewing mode. I wonder if that would take care of it?
-
Maybe this is an old version:
http://www.duose.com/p/2009/0203/70630_375.png
You see a black line in the middle of Kid's face? If the camera gets zoomed in, it'll be more obvious.
-
Disk 2 NPC models dump.
http://www.megaupload.com/?d=MAMTK3L5
Archive Password: p0w3r
This time, the room numbers match the in-game numbers, not the "8-fewer" of Terminus. I've only included the rooms I know are different from disk 1. I also tried to make the program I used automatically organize double-texture, but it still might have missed a few. And lastly, the 12-byte unknown-data headers have been removed already.
The list of rooms in there only includes ones utunnels didn't list in the past.
-
Oh jeez, I totally forgot about Disk 2 for the field models. So that's a lifesaver, thanks!
Are the disk 2 battle models in the battle model pack? If AI FATE isn't in there, then I never got around to that either. Growr.
-
I don't know which enemies are specific to disk 2, but disk 2 battle models don't seem to be in the pack. Is it hard or annoying to dump them?
-
Here's a dumper MDenham made followed by some .dlls that may have to be included for it to work:
http://www.sendspace.com/file/ytxsan
http://www.sendspace.com/file/qpknfq
I'd feel comfortable with calling MDenham into the discussion if we can't figure this out (I seem to recall we had trouble getting the Terminus Traductions tools to work properly with Disc 2, but maybe I'm wrong) but I'll leave that decision up to ZeaLitY. Now that we know how to work with the file pointer table at the beginning of each disc though, I bet we'd be able to find the missing Disc 2 enemy models without too much hassle. Especially if the dummy files on Disc 1 correspond to actual files on Disc 2.
Other than getting the raw data, we'll have to go through the process of getting the textures in TileMolester since we don't have a conversion tool for that variation on the .TIM file structure.
-
Go ahead and let him in.
-
Done. Not sure when he'll pop in next.
Sorry for the holdup on the field models, I got carried away with Chronotorious. I've still got about 40 folders to go through and then arranging them neatly. I'll upload an archive as soon as I've finished.
-
Done. Not sure when he'll pop in next.
Was in yesterday before work (stupid 3:30pm-midnight shift) but didn't really have anything to say at the time.
Mostly just going to hang around until assistance on my part is actually needed, rather than clogging up this thread with unnecessary commentary. :D
-
Ooh! Ooh! I'm not sure what the status is of the file dumper I believe you made like a year ago, M. I think there was one you made that successfully dumped everything from both Disc 1 and Disc 2; I could have sworn we were having problems with that using the original Terminus Traductions tools. We might need that capability again to get at some Disc 2 models we're no doubt missing.
-
Transparency doesn't seem to be working for me. Is it working when you try?
-
Ooh! Ooh! I'm not sure what the status is of the file dumper I believe you made like a year ago, M. I think there was one you made that successfully dumped everything from both Disc 1 and Disc 2; I could have sworn we were having problems with that using the original Terminus Traductions tools. We might need that capability again to get at some Disc 2 models we're no doubt missing.
:picardno
I'll have to rewrite it as I lost the source to it (it wasn't that hard to make the change to the existing Disc 1 dumper, though).
On that note, a Subversion server would be nice so that I can readily keep the source available for other people to look at (for obvious reasons, preferably not directly associated with here).
-
Hold on M, is the dumper linked in the following post yours, and does it contain all necessary components?
http://www.chronocompendium.com/Forums/index.php/topic,7902.msg174783.html#msg174783
-
Hold on M, is the dumper linked in the following post yours, and does it contain all necessary components?
http://www.chronocompendium.com/Forums/index.php/topic,7902.msg174783.html#msg174783
That should be it, yes.
(I'd still like to rewrite it so that rather than just the generic progress-bar type of result it currently gives for Disc 2, it shows what's what on Disc 2 instead.)
-
Yeah; it's been an issue with importing since the beginning. It's been too long for me to remember if some lines like that are endemic to the characters in-game, though...
LOL
uv[0] = uv[0] / float(textureWidth - 1)
uv[1] = uv[1] / float(textureHeight - 1)
It seems changing line 770 and line 771 in the python script to lines below will fix the problem.
uv[0] = uv[0] / float(textureWidth )
uv[1] = uv[1] / float(textureHeight )
-
Has anyone tried recompiling with utunnels' alteration? I'm not sure if Luminaire's popped in here yet.
-
I tried it briefly.
The advantage of utunnels's version is that your texture polygons always have UV coordinates that are exactly between pixels. The disadvantage is that you are not able to use the last row and column of a 256 x 256 texture, even though there is data there. Not sure which is better, although I'm tending to agree with the utunnels version.
I've summarized where I recall things being in the two attached images. They depict the same exact Serge model viewed in the normal Blender editing window and with the render previewer. As you can see, neither image is perfect.
The normal view shows a thin line down Serge's back and some unexpected orange splotching on the backs of the shoulders. This seems to be due to some blurring of adjacent pixels, and ensuring that the UV coordinates fall exactly between pixels does not help here. This goes away in the render preview. (Although I've not shown it here, the render preview also allows for proper handling of transparent portions of models, e.g. Glenn's bangs.)
However, the render preview shows a problem at the bottom front of Serge's shirt. This is due to the existence of two faces occupying nearly the same space. One of these faces points toward the viewer, while the other points in towards Serge. Only one of these faces should be viewable at a time (based on the location of the observer), but for some reason the renderer is trying to draw them both.
It would be better for ZeaLitY if we could fix the render view, as this would allow for much larger images to be taken. This means fixing the double faces issue. Ideas anyone?
-
I'm not familiar with how uv works.
I tried to export the bulb model into 3ds format (using the original script).
The left most vertex have a u value of 1.0000, but it seems that is beyond 100% of the texture width(the snapshot below).
So in those 3d renderer, are u/v values start position of the pixel, but in CC they stand for the pixel itself?
Edit*
Forgot the picture.
Edit*
It seems in CC, uv ranges from -1 to maxsize-1?
-
utunnels has reported that the Hydra textures and Black Dragon textures were accidently saved as 24bpp PNGs as opposed to 8bpp PNGs. If that's preventing importation into Blender, make a list of any more you find and I'll reup the model pack.
-
The only problem is the transparent color.
Although most of them are OK, but it is better to keep the palettes same as original tim files.
Double Texture Enemies:
BlackDragonBattleTex RIGHT.png
GaraiBattleTex LEFT.png
HydraBattleTex LEFT.png
HydraBattleTex RIGHT.png
TyranoBattleTex RIGHT.png
Normal Enemies:
GloopBattleTex.png
JellyBlubbaBattleTex.png
MegaStarkyBattleTex.png
UnknownBattleTex.png
--------------
BTW, Crossbone's texture is 128*176, should be 128*256.
---------
The Geos' texture works strangely, see below.
-
Because utunnels had trouble opening my previous 7z of Chrono cross models, I've uploaded it again. (Even I couldn't get the password right). Password is "dcba5yz" this time.
http://www.megaupload.com/?d=3T9CZFT3
I've also attached some models I've identified. (No converted textures because I'm not sure how well I'm doing at that.)
Some models, such as Una and the sawfish, appear in rooms for no apparent reason.
Some models that look promising from the texture, might turn out to be disappointing.
-
Thank you Vehek.
BTW, anyone notice that Skelly's model is flipped left-right?
I don't know whether other models have the same problem, since most of them are symmetrical.
:?
(http://www.chronocompendium.com/images/wiki/4/4d/Skelly.png)(http://www.chronocompendium.com/images/wiki/c/c5/Skellymodel.png)(http://www.chronocompendium.com/images/wiki/0/02/Heavy_Skull.png)
-
Huge thanks for the second disc models Vehek. I've got all the disc 1 field models Identified but I need to apply the labels to the individual files now, which will take some time. Bah. I can upload specific ones that might be of most interest (Johnny, etc).
utunnels, if those are the only texture issues you've encountered so far I'll correct those and reup tonight.
-
Here's the models with updated textures in the cases utunnels pointed out. I'm not sure what to do about Geos -- I'd be willing to bet that that big black hole in the middle of the texture is the culprit; maybe if we fill that in, but it's technically changing the original texture...
Also, Jellyblubba is interesting. There's actually two textures in there I think, each possibly with its own palette. I have an ALTERNATE battle tex in there for that one, but it's slightly lower quality because there were something like 270 colors between the textures. I'm not sure how those are supposed to be subdivided palette wise, but that could be determined by looking at Jellyblubba in VRAM and matching up the palettes in a VRAM dump using PVV3. I'll check this out sometime, because I'm curious.
http://www.sendspace.com/file/uqgmyc
-
JellyBlubba has a "core", so it uses 2 textures.
And maybe the alternate colors are used to create the glow effect (palette animation)?
It also uses alpha blend like the TimeDevourer shell (http://cc.ffsky.cn/models/TimeDevourerLavosForm.png), but I don't know how to do that in a 3d rendering software.
BTW, can you dump the original 16bit palette for TimeDevourer? I doubt that choose colors with the highest bit set to 1 are used to create the alpha channels, but maybe I'm wrong, the engine can use another picture for the alpha channels.
-
I believe the Time Devourer palette(s) should be identical to the 256 entry palettes for the PNGs I provided, but since they were acquired through TileMolester I'll check that out whenever I get a chance to look at Jellyblubba's palette in VRAM.
For the field model TIM textures Vehek, you can feel absolutely comfortable converting them through TIMView's batch TIM > BMP feature. I think. There's surely no way I'm doing the disc 1 model textures one-by-one in Tilemolester, hahaha.
-
Nah, I mean the 16bit color palette(s) used by tim.
Usually the colors with the highest bit set to 1 are used for alpha blending, like the Pod below (I wrote the 2d blending code).
http://www.chronocompendium.com/images/wiki/8/8a/Terra_tower_top_hall_2.png (http://www.chronocompendium.com/images/wiki/8/8a/Terra_tower_top_hall_2.png)
However, i have no idea how to do that in a 3d rendering software like blender.
In that case, those enemies with alpha blending effect will look ugly: TimeDevourer, JellyBlubba, RoyalJelly...
----
Edit*
Added a fake alpha channel to show the core.
(http://cc.ffsky.cn/TEMP/WaterCore.png)
-
Hah, it seems the black dragon texture still missed the transparent color.
:picardno
I'm lazy to check other models, since it is simple to edit the image by oneself.
The attachments are the edited black dragon texture and the rendering effects (with/without transparent color).
-
I have my own concerns about just converting with TIMviewer.
For example, Gato has some black around his eyes which is not transparent. When I convert the TIM, the non-transparent black merges with the transparent black.
-
We did have an issue similar to that in Magus Unmasked -- I always wondered why Magus would turn black as opposed to black-transparent when warping to the Darkness Beyond Time. There could be some nuance in the field model texture data we haven't picked up on, and which TIMViewer doesn't preserve (I used TIMViewer for the BMP-to-TIM conversions).
utunnels, I just now remembered that I had been setting pure black to transparent in the battle texture PNGs on my end when we were working on creating a model pack before. Third time's a charm...
http://www.sendspace.com/file/2ci1rk
-
Because utunnels had trouble opening my previous 7z of Chrono cross models, I've uploaded it again. (Even I couldn't get the password right). Password is "dcba5yz" this time.
Ah, what happened?
It still won't open.
:(
-
We did have an issue similar to that in Magus Unmasked -- I always wondered why Magus would turn black as opposed to black-transparent when warping to the Darkness Beyond Time. There could be some nuance in the field model texture data we haven't picked up on, and which TIMViewer doesn't preserve (I used TIMViewer for the BMP-to-TIM conversions).
utunnels, I just now remembered that I had been setting pure black to transparent in the battle texture PNGs on my end when we were working on creating a model pack before. Third time's a charm...
http://www.sendspace.com/file/2ci1rk
Yeah, the safest method is checking the actual value of the original 16bit palette.
For example, 8000 is transparent color, but 0000 is pure black. Although they will be both pure black when converted to 24bit mode.
-
Ah, what happened?
It still won't open.
Sigh... I must be bad at making sure I encrypted it with the right password or something these days. (Once again, I'm having trouble myself opening it.)
Let's try a different tactic. I'm going to use attachments, unencypted.
-
Part 2. (Rooms 493-537)
-
Thanks again.
I thought megaupload damaged the file at first. LOL
-
I have my own concerns about just converting with TIMviewer.
For example, Gato has some black around his eyes which is not transparent. When I convert the TIM, the non-transparent black merges with the transparent black.
You can manually edit the color into a slight different one.
Always edit the image under 9bit mode, never try to convert it into a 24bit one.
-
Something for folks to try out -- HyperGeek tried out an update of Luminaire's plugin that should read the first frame of model animation. This might give us correct stationary poses for pics, but I haven't the ability to take its capabilities for a test drive. It's attached.
EDIT: Vehek tested it out on the Beeba:
(http://img8.imageshack.us/img8/5992/beeba.png)
Looks kind of awesome to me. Anyone notice any problems with the model at all?
-
HyperGeek tried out an update of Luminaire's plugin that should read the first frame of model animation.
Holy Cow, that is awesome.
Now we only lack of Weapon models, right?
For example, Acacia SGT, Solt, Peppor are all bare handed without their weapons.
-
Ah, crap, we'll need weapon models for the player characters too. We know where they are, but I'm not sure the data conforms to what the plugin is expecting -- it'll have fewer sections for example. If ZeaLitY wants to get these done ASAP (I smell Bounty Points looming), we might have to forego the standard pose of the humanoid weaponless models and keep them in frozen "T" pose...
Although I could have sworn someone was able to load the weapon models, so hopefully I'm wrong.
-
Hmm, it seems all models are flipped left-right.
Now Dario holds the Masamune with his left hand.
XD
-
Tried that FamilyTree model. :lol:
-
Hmm, it seems all models are flipped left-right.
Now Dario holds the Masamune with his left hand.
XD
That would be a case of Blender's coordinate system is opposite-handed to the PS1's. Shouldn't be too hard to fix in the importer - it's just a simple sign-flip on any one coordinate (best option would probably be X) when loading the vertices.
-
Ah, don't worry about any pressure. At some point, the low-hanging fruit in the bounty forum will be taken up, and it will solely become the realm of absolute hackers (for example, the developer's ending room script) or translators. Hopefully, gravity will take over for those.
-
BTW, don't forget those ship models, like S.S. Invincible, the boats (the Wingapede on world map, maybe).
I'm always curious whether the S.S. Invincible has a higher resolution model.
-
Can't believe it has been almost 1 year.
:picardno
A small gif animation made by rendering 23 frames (supposed to be Garai's idle animation, but it looks a bit different, guess I made some mistakes).
----
Edit*
Garai's dodge animation.
----
Edit again*
Garai's defend(?) animation.
-
I'm not sure whether it is OK to post in the model thread.
Recently I did some investigation to the weapon models. I edited Luminaire85's blender import script and converted those weapon models into .blend files. You can get the pack here:
http://cid-a5879bd130717196.office.live.com/self.aspx/.Public/Chrono/ccweaponmodel.zip
I kept them in .blend files for the reason that weapon models have vertex colors which I haven't figured out how to render properly. And it seems vertex colors get lost after saved to 3ds format. Anyway, those who know blender better may figure out a way to render with both textures and vertex colors, I just suppose.
Some models, for example, Viper's Venom, look broken without vertex colors (as the background I guess), the textures just can't cover the whole model.
----------------
http://cid-a5879bd130717196.office.live.com/self.aspx/.Public/Chrono/import%5E_ccmodel%5E_animation.py
This edit allows you to import a battle model with its weapon. You'll be asked for the weapon model and texture. There's a bug that it asks twice for the battle model's texture, just click the button once more to load the same file.
Currently it is designed for Serge. For the reason the weapon is attached to a certain joint which is different among models (and some of them don't have one at all), we need to edit the script to fit other characters.
Just watch for fun.
You can edit these lines to load another animation or frame instead.
curFrame = 0
curAnimation = 0
----------------------------
http://cid-a5879bd130717196.office.live.com/self.aspx/.Public/Chrono/import%5E_ccmodel%5E_animation.py
Edit*
Check the new import script.
Thank HyperGeek for his timely information, that saves a lot of guessing work.
----------------------------
http://cid-a5879bd130717196.office.live.com/self.aspx/.Public/Chrono/ccweaponmodel.zip
Edit*
A dummy weapon has been added into the weapon pack (Gloves and other shapeless weapons can use it).
Also fixed the scythe model.
TODO: Glenn with 2 Einlanzers
-
Can't believe it has been almost 1 year.
:picardno
A small gif animation made by rendering 23 frames (supposed to be Garai's idle animation, but it looks a bit different, guess I made some mistakes).
Garai's dodge animation.
----
Edit again*
Garai's defend(?) animation.
i don't care for Glenn when seeing that!... Serge turning into that is awesome enough. make a ccenemyedit with Garai! please!?
-
Does anyone have the 3D models of Crono, Marle, and Lucca from Crono Cross? I'd love to see their faces.