Recent content by kion

So i'm not sure if this works in practice, but in theory i was able to retarget the pso animations onto the psz models. one issue with the psz animations is they feel really floaty, so maybe this will help. Note: after playing around with it, i'm going to try to adapt the walk/run animations...

> zed i'll keep it in mind. i'm trying to find something that fits the theme, or just sounds classic. Quests I have a simple quest editor working and the ability to run through it. my thinking is that quests can be more structured and fields could have more of the random element to...

that should be something i need to implement anyways for debugging. i should be able to manage something for quick weapon switching and being able to add more techs. i finished getting all of the stages ported over. grid system for stages is working, added place holder gates and loading...

Wanted to post something i've been working on in the background for a while: psz for godot (needs a name). The project is poorly split across the following repos: 1. https://github.com/DashGL/psz-asset-viewer uses apicula to extract the assets from the rom 2...

For clarification PSOv2 is the Dreamcast version. I wanted to make that clear since their are less weapons, stages and characters compared to Gamecube or PC. I changed the title from "PSOv2 Model Viewer and Downloads" to "PSO(DC) Model Viewer and Downloads" to avoid confusion.

I guess i should mention my Noesis Plugins are here: https://gitlab.com/dashgl/ikaruga/-/snippets These include formats such as .xj, .nj (which is already supported by Noesis, but includes my source), stage files and gamecube .gj.

I get PM'd about this occasionally. Previouly i had an ftp server with all of the extracted assets from PSOv2 on it. The ftp server is gone, but the tools used for the assets are now open source, so you can view and export the models from the Dreamcast version of the game. Tool...

Some screenshots.

Well... fuck. I was hoping that since the Ep 3 maps are nearly working that the Episode 1&2 maps would "Just Work" (TM), but I guess that's not the case. So I guess that means we need to trace through any pointers we skipped over. We can start with the header, we have the text 'fmt1'...

A few notes on the Gamecube model format. The format seems to be best described as an indexed buffer geometry. What that means is that for a specific geometry, the game will declare a list of attributes that can consist of position, normals, vertex color or uvs. for attr in attrs...

Okay, so episode 3 maps seem to be mostly working now. There are a lot of corners I've cut on the materials. Alpha blending, diffuse color, double sided and all of that other general kind of goodness has been ignored while focusing on the geometry part. Right now the only aspect of the material...

That's not too much of a curveball. When I got into exporting 3d stuff, I thought that parsing old formats without documentation would be the hard part, and there would be some modern format that I could port to. Turns out it was the other way around, reading undocumented formats is a matter of...

Well, fml. This strip format or strip formats are really giving me more trouble than they should. In principle these should be pretty straightforward, in-practice these are quite cumbersome. I'll write what I think I know so far. For the saber, there seem to be two kinds of strips which start...

A closer inspection of this limited use-case seems to break down pretty quickly. The bytes 0x98 follows by 0x00 seem to declare a new strip. The first byte after the strip is the number of indexes. And from the there are three bytes, for pos, norm, uv. And this seems to go until 0x90 which seems...

Using this as notes for .gj as this format gets pretty crazy pretty fast. The part that we're interested in is outlined in red. Up to this point, the format is pretty straight forward. We have the same bone/node definition as xj and nj with position, rotation and scale with pointer to child...