The VG Resource

Hey guys! I always wanted 3d models from star fox the snes version. For a long time I looked into it and found it to be almost impossible...almost. A long long time ago, there was a guy named VL-Tone who created a level editor for the Star Fox SNES. It had a 3d model export feature, which excited me the most!. When I used it though, it didn't work. All seemed lost until, I discovered his shockwave file. VL-Tone created a shockwave file that contains almost all the models used in the game and then some. I read on and discovered shockwave uses directx or opengl. I used 3dxml while the shockwave was open in firefox and booyah! It worked! The colors didn't come out, but I'm not too worried!

Here's a screenshot of the viewer:


Here are the rips:
Here's the shockwave file itself. All you have to do is open it in firefox (after updating your shockwave player) and there you go!
http://www.mediafire.com/?18vvqoa7alxjbx7

Now I can go back to ripping pokemon models.

I was actually curious about this, and apparently it's true.

mother of god... i still have the original game for SNES

O_O
I was so close. VL-Tone's website archives are such a mess, huh? ^^;
Anyway, someone was working on making a better viewer over at Romhacking.net. You might want to watch the development on this.

ya thats where I found the decoder, but that guy's models look better because he's making an hd version of the game, not a viewer.

3D models in an SNES game? I never thought I'd see it! I came in here thinking "they're just pre-rendered sprites" then I look at the pictures. That is just awesome.

What we should really do is figure out where all the objects are stored in the ROM. Using the 'Arwing Deconstructed' information, I was able to rebuild the low-poly Arwing, or the one you actually see most of the time, with minimal trouble. (the only problems I had were either misunderstanding how the mirroring worked, or misreading the vertex positions. After that, it was a breeze)


And Jetaku, this isn't much of a surprise. What the SuperFX did was it actually handled the polygon generation, sending the result to on-cart RAM. This was then sent to the console's GPU as essentially a full on-screen frame.

(12-31-2012, 04:15 AM)Tiberious Wrote: [ -> ]What we should really do is figure out where all the objects are stored in the ROM. Using the 'Arwing Deconstructed' information, I was able to rebuild the low-poly Arwing, or the one you actually see most of the time, with minimal trouble. (the only problems I had were either misunderstanding how the mirroring worked, or misreading the vertex positions. After that, it was a breeze)

If you want to learn more, the link in Friedslick6's post has a link to VL-Tone's level editor and findings. I don't know why you'd want to do that (unless you're planning on making a viewer yourself).

Well, one thing I dislike is how 3D PrintScreen programs utterly fail to get scales accurate. Considering these are horrendously simple meshes (the title screen Arwing, for example, has only 36 unique vertices) with a simple -127 to 127 range on each axis, there shouldn't be any real excuse for not having the points lined up on the grid as they would be if you did it yourself from the vertex data.

And since the 3DRipper discards the colors anyway, nothing is lost by taking the time to make sure the vertices are in the right spots.

(12-31-2012, 02:23 PM)Tiberious Wrote: [ -> ]Well, one thing I dislike is how 3D PrintScreen programs utterly fail to get scales accurate. Considering these are horrendously simple meshes (the title screen Arwing, for example, has only 36 unique vertices) with a simple -127 to 127 range on each axis, there shouldn't be any real excuse for not having the points lined up on the grid as they would be if you did it yourself from the vertex data.

And since the 3DRipper discards the colors anyway, nothing is lost by taking the time to make sure the vertices are in the right spots.

I agree regarding scale, but you're wrong about all 3d printscreen tools getting incorrect scaling. That's why I use 3dvia, which gets the scaling correct all the time. As for coloration, it's not a big deal for this game mainly because the colors arent textures. You can printscreen the game and retrieve the proper colors. Also, this is a game where you can't use printscreen tools. You can use them on the shockwave program.

In actuality, you can't have a model exporter for every program, that's why we have these printscreen programs. Please don't diss them before learning how they work. It may be better to write a better printscreen program (which is labor intensive, but I'm willing to go for it (2 years of C, VB, and 1 of Java)).

Pretty amazing work here. Nice job!

@Friedslick6
So this is where you came from!
I was tired of studying and found this thread. I'll sum it up just in case one of you guys is interested.

1-Neither models nor sprites are encrypted in the SF ROM.
2-SF ROM is incredibly well programmed and optimised yet I believe encryption would have made the game harder to program and the SNES would not have handled it.
3-The ROM is mostly a kind of script that points to stuff that appear at certain moments and use certain color palettes, and also trigger centain events (like End Stage animation).
4-The stage scripts list the objects that appear, each object on that list has a Hex address and the color palette of the model to be used (VL-Tone managed to rip all the models by first listing them).
5-Color palettes are defined by a small lists of certain colors, in order to create more colors they use checkerboard patterns of the small list of colors. There are also palettes for day, night, space.
6-Colors are not defined as such and each polygon in each model has a parameter for its 3D Normal. Someone with knowledge of openGL and HEX (VL-Tone) can combine these correctly with the Hex color palettes. Notice that the model visualizer has no checkerboard pattern and as such is not really perfect SNES emulation but is exactly the effect that the SF programmers wanted (guess).
7-Checkerboard patterns appear on your screen as such, the pattern with it's color is rendered on screen in the portions that they are needed.
8-From what I understand the SNES SFX processes the 3D information and then it is drawn onto the cart itself which is slowly read by the SNES as layers which constitute the frames. Don't get me wrong SF is really in 3D, it just has to be programmed well enough for it to be read on non 3D capable equipment (research "tricks" used for Wolf3D and Doom and why Carmack is quite the programmer).

Essentially 3D models have no resolution, therefore the 3D models in SF cannot be "spritted".
My remake is not a remake since it's ilegal for me to rip the 3D models, music and stages from the ROM in any way and insert them into an application. I want to make a very specific ROM emulator that runs SNES Sar Fox in HD resolutions reading the models and all info directly from the ROM. And since 3D models have no resolution nor are they frame dependant it is very easy to make it 1080p 60 FPS. I want to make this:
https://www.youtube.com/watch?feature=pl...Kng8#t=26s

As the original thread says I have little experience in Hex so I am stuck. If you wich to help that would be great. Thanks!

@AllenSword
I don't know if you found this but since you didn't post it then you probably didn't. The VL-Tone's shockwave application of the Star Fox models has an easter egg, it is a fly-by of the whole first stage as if you were playing the game. There is little to no coloring and you can move the ship around. To activate it you have to double click on the "StarFox Object Decoder" logo, wait a bit and there it is and it will cycle by itself, click to go back.
It works at normal speed on older operating systems, at ludicrous speed on new systems and I don't know why.
I mention it also because you were ripping the models and I'm sure you would like to see the first stage.

That is what I wanted to do, read from rom but render on newer hardware.

@dyson123
Thanks for the information. I really just posted this as a kind of fun thing that people can look at and do themselves. I hear you're interested in making a hd emulator for the game and I can't really do much but say learn more programming languages than hex. You may want to look at ZSNES, an open source emulator that runs the game perfectly to get an idea of the emulation. I have taken many a programming course and let me tell you if you want to make an HD emulator (if that's possible for this game) from scratch, you'd best be devoted to your project because it will take lots of time to learn programming and how the system works. Hex isn't enough to go off on if that's all you know. All I'll say is good luck.

(02-09-2013, 02:10 PM)AllenSword Wrote: [ -> ]@dyson123
Thanks for the information. I really just posted this as a kind of fun thing that people can look at and do themselves. I hear you're interested in making a hd emulator for the game and I can't really do much but say learn more programming languages than hex. You may want to look at ZSNES, an open source emulator that runs the game perfectly to get an idea of the emulation. I have taken many a programming course and let me tell you if you want to make an HD emulator (if that's possible for this game) from scratch, you'd best be devoted to your project because it will take lots of time to learn programming and how the system works. Hex isn't enough to go off on if that's all you know. All I'll say is good luck.

Cool! Thanks for the info.
We have made some progress:
http://www.romhacking.net/forum/index.ph...iskio7pio5

I don't expect to build the emulator all myself.