Register - Login
Views: 95808624
Main - Memberlist - Active users - Calendar - Wiki - IRC Chat - Online users
Ranks - Rules/FAQ - Stats - Latest Posts - Color Chart - Smilies
11-19-18 12:32:32 PM

Jul - SM64 Hacking (Archive) - Mario 64 Level Importer New poll - New thread - New reply
Pages: 1 2 3 4 5 6 7 8 9 10 ... 46 47 48 49 50 51 52 53 54 55Next newer thread | Next older thread
Breegullbeak
Member
Level: 26


Posts: 36/135
EXP: 92169
For next: 10106

Since: 06-06-09


Since last post: 7.0 years
Last activity: 6.0 years

Posted on 10-10-09 10:48:33 PM (last edited by Breegullbeak at 10-10-09 11:02 PM) Link | Quote
I'll get them up quick. I can get more models if you want, or I can help you get them all.

http://www.rarewitchproject.com/forums/showthread.php?t=11088

RWP's Cooliscool is working on a program that can view the models of Banjo Kazooie and Tooie(eventually DK64) and export them to obj. files with the textures. you do need a rom for the game to use the program though.

http://www.mediafire.com/?sharekey=d1ad73b54e5c24c8e62ea590dc5e5dbb3974d0b407f8f175947708e37b913e74

This should have all the textures as well as the obj. and mlt.(not sure what it is, but it comes with the obj.)

Still can't help but stare in aw at this. Ever since the model importer was anounced, I was waiting for this day.
VL-Tone
Member
Super Mario 64 forum moderator
Level: 51


Posts: 526/621
EXP: 994842
For next: 19096

Since: 07-27-07

From: Montreal, Canada

Since last post: 1.0 years
Last activity: 36 days

Posted on 10-10-09 11:30:51 PM (last edited by VL-Tone at 10-10-09 11:34 PM) Link | Quote
Originally posted by messiaen
By the way, how do you handle normals?


That's funny, I was just about to ask you the same question Normals don't seem to work properly in my importer and I was just investigating that a few minutes ago. I'll get you back on that once I tested Breegullbeak's model.

Breegullbeak: Could you please zip all the textures in one zip file? Downloading each one individually from mediafire is a pain...
messiaen
Catgirl
Level: 65


Posts: 669/1085
EXP: 2265127
For next: 70501

Since: 11-20-07


Since last post: 4.0 years
Last activity: 3.0 years

Posted on 10-10-09 11:49:12 PM (last edited by messiaen at 10-11-09 12:19 AM) Link | Quote
Originally posted by VL-Tone
That's funny, I was just about to ask you the same question Normals don't seem to work properly in my importer and I was just investigating that a few minutes ago. I'll get you back on that once I tested Breegullbeak's model.



Haven't tested much, but perhaps maybe a logical method would be to normalize to 1 dividing by the max value, like you are doing for texture coordinates and them multiplying by 255 127 (since it's a signed number). Tried this method right now, but results are a bit odd, as if the light source is wrong .
VL-Tone
Member
Super Mario 64 forum moderator
Level: 51


Posts: 527/621
EXP: 994842
For next: 19096

Since: 07-27-07

From: Montreal, Canada

Since last post: 1.0 years
Last activity: 36 days

Posted on 10-11-09 12:39:02 AM (last edited by VL-Tone at 10-11-09 12:52 AM) Link | Quote
Originally posted by messiaen
Originally posted by VL-Tone
That's funny, I was just about to ask you the same question Normals don't seem to work properly in my importer and I was just investigating that a few minutes ago. I'll get you back on that once I tested Breegullbeak's model.



Haven't tested much, but perhaps maybe a logical method would be to normalize to 1 dividing by the max value, like you are doing for texture coordinates and them multiplying by 255.


Well that's what I did, except that as far as I know the normal values are signed, so it's a matter of getting values ranging from -128 to 127 (or is it -127 to 128? Damn off-by-one errors!)

Using the "rainbow effect bug" to visualize the normal data as colors, I thought for a moment that my normal data was seriously wrong, but color data is not signed so that was simply a bad interpretation on my part.

Nevertheless, my real problem is that the vertical walls (with the brown texture) in Gecko's level are way too dark. Also, when seen from the top (when Mario is falling when he starts a level) the whole level is also anomaly dark. And when I add objects in my level, a weird thing happens with lighting over the whole level geometry. It changes in very noticeable steps from dark to light depending on the camera angle. At some angle the vertical walls look nice (light enough) but it doesn't happen smoothly at all.

Edit:

Well I found the bug: I was setting the one of the two gouraud shading color twice by setting 0x0386 two times instead of setting 0x0386, then 0x0388.
Gecko
Member
Level: 24


Posts: 49/113
EXP: 71309
For next: 6816

Since: 03-27-09


Since last post: 5.0 years
Last activity: 4.0 years

Posted on 10-11-09 02:36:50 AM (last edited by Gecko at 10-11-09 02:42 AM) Link | Quote




The files I used: http://www.file-upload.net/download-1938246/mariolevel.rar.html

VL-Tone, while using TT64, I thought it would be useful having following tools and/or changes:
- newly added objects should have all star acts enabled or there should be one button for enabling all acts at once
- copying existing objects by clicking on a button, making the new object appear at the same place
- copying and pasting coordinates of object like it's already possible with parameters, e.g. you'd like to add a coin upon a platform or tree
- after I received a "script not found - continue?" error, I could not save the latest changes, pressing on the button would not change anything
- after pressing the "save" button it would be nice having a response from TT64 like "game saved" or simply "saved".

Maybe some options already exist and I've simply missed them.
VL-Tone
Member
Super Mario 64 forum moderator
Level: 51


Posts: 528/621
EXP: 994842
For next: 19096

Since: 07-27-07

From: Montreal, Canada

Since last post: 1.0 years
Last activity: 36 days

Posted on 10-11-09 03:10:04 AM (last edited by VL-Tone at 10-11-09 03:10 AM) Link | Quote
Originally posted by Gecko

VL-Tone, while using TT64, I thought it would be useful having following tools and/or changes:
1. newly added objects should have all star acts enabled or there should be one button for enabling all acts at once
2. copying existing objects by clicking on a button, making the new object appear at the same place
3. copying and pasting coordinates of object like it's already possible with parameters, e.g. you'd like to add a coin upon a platform or tree
4. after I received a "script not found - continue?" error, I could not save the latest changes, pressing on the button would not change anything
5. after pressing the "save" button it would be nice having a response from TT64 like "game saved" or simply "saved".

Maybe some options already exist and I've simply missed them.


Hey it looks like a fun level Gecko!

I added numbers to your suggestions so I could address them more easily:

1. This is definitely planned, I was thinking about these two options just a few minutes ago.
2. This is already implemented in v0.6b. You can copy/paste/duplicate/clear whole objects.
3. You can already select the x, y and z coordinates at once using the shift key, then use "copy parameters". But TT64 will also features "align" buttons that could help you align a coin with a tree.
4. Unfortunately, if you get a script error, it's the equivalent of a crash, don't expect the program to work normally if you click continue. There is an option to "Auto-Save" in the preferences, it could help you to prevent losing work.
5. The save button text turns from red to white when you save (if the button is not red then there's no change made since the last save).

BTW I just made a nice demo video using your other level, I'm about to upload it to Youtube.
Gecko
Member
Level: 24


Posts: 50/113
EXP: 71309
For next: 6816

Since: 03-27-09


Since last post: 5.0 years
Last activity: 4.0 years

Posted on 10-11-09 03:41:44 AM (last edited by Gecko at 10-11-09 03:48 AM) Link | Quote
That sounds great! How could I miss the save button with its red tone. I'll try point three, though it sounds a little complicated. There's not much left to long for for a fully working level editor, except at the moment I'm missing the usage of materials.

<object width="425" height="344"><embed src="http://www.youtube.com/v/CEwBEhdCay0&hl=de&fs=1&" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="425" height="344"></embed></object>

It's interesting to see that even detailed levels like from Banjo Kazooie work with the Mario64 engine, maybe it's not too limited in terms of polygon count as I had thought in the first place.
VL-Tone
Member
Super Mario 64 forum moderator
Level: 51


Posts: 529/621
EXP: 994842
For next: 19096

Since: 07-27-07

From: Montreal, Canada

Since last post: 1.0 years
Last activity: 36 days

Posted on 10-11-09 11:22:41 AM Link | Quote
I'll see what I can do about a dedicated "Copy coordinates" function.

As for Banjo Kazooie levels, I think we may run into problems with texturizing the model. Rare did write an entirely new engine to make use of higher resolution textures.
Breegullbeak
Member
Level: 26


Posts: 37/135
EXP: 92169
For next: 10106

Since: 06-06-09


Since last post: 7.0 years
Last activity: 6.0 years

Posted on 10-11-09 01:03:18 PM Link | Quote
Originally posted by VL-Tone
Originally posted by messiaen
By the way, how do you handle normals?


That's funny, I was just about to ask you the same question Normals don't seem to work properly in my importer and I was just investigating that a few minutes ago. I'll get you back on that once I tested Breegullbeak's model.

Breegullbeak: Could you please zip all the textures in one zip file? Downloading each one individually from mediafire is a pain...




http://www.mediafire.com/file/mt33m0mrnmz/SPiral A.rar

Here you go. I can get you more levels if you want more test subjects.
battleben

Level: 9


Posts: 9/11
EXP: 2248
For next: 914

Since: 06-27-08


Since last post: 9.0 years
Last activity: 8.0 years

Posted on 10-11-09 02:09:22 PM Link | Quote
I believe someone ported a map from banjo to Zelda 64..
speaking of which, wouldn't Zelda 64 really make a ideal choice for the first ported level with textures?
Stevoisiak
Member
Level: 36


Posts: 279/283
EXP: 301651
For next: 6459

Since: 11-22-07

From: New York, Long Island

Since last post: 8.0 years
Last activity: 2.0 years

Posted on 10-11-09 04:42:39 PM (last edited by Stevoisiak at 10-11-09 04:45 PM) Link | Quote
Originally posted by battleben
I believe someone ported a map from banjo to Zelda 64.

Do you have a link to this? Also, it sounds a little far fetched, since link can't even jump normally, which kinda breaks the level.
Originally posted by battleben
speaking of which, wouldn't Zelda 64 really make a ideal choice for the first ported level with textures?

And why would that be? You could use any level with custom textures, assuming their the right resolution. besides, you need the 3D models for the level data first, which nobody has yet to rip. (Or, at least rip and post the OBJ on this forum)
Originally posted by VL-Tone
As for Banjo Kazooie levels, I think we may run into problems with texturizing the model. Rare did write an entirely new engine to make use of higher resolution textures.

Can't the textures just be scaled down? Sure, they won't look as nice, but they'd work at a smaller resolution, right?
messiaen
Catgirl
Level: 65


Posts: 670/1085
EXP: 2265127
For next: 70501

Since: 11-20-07


Since last post: 4.0 years
Last activity: 3.0 years

Posted on 10-11-09 09:29:40 PM (last edited by messiaen at 10-11-09 09:31 PM) Link | Quote
New version up . This one will use material data by default (now working MUCH better!) and supports much larger .obj files. If you have used the previous version, note that the included .ppf patch is different, so you have to patch another ROM in order to use this version.

Download obj_import 0.04 alpha

From the readme:

Usage: obj_import [obj_file] [rom] [scaling] (-culling) (-disablenormals)

example: obj_import myfile.obj myrom.z64 300
obj_import "my file.obj" "my mario 64 rom.z64" 20 -disablenormals
obj_import my_file.obj "super mario 64.z64" 0.75 -culling -disable normals

The scaling value will differ widely depending on how your .obj is laid out. The Mario 64 engine supports vertex values between -8192 and 8192. If your scaling is too big, the program will warn you and you should try using a smaller value. Floats are supported: for instance, if you want to scale down your object to 70%, use a value of 0.7.

There are two additional flags you can enable (order doesn't matter) :

-culling: This will reserve the face order. Use this if only the back faces of the polygons are shown instead of the front faces.

-disablenormals: This will disable reading normals from the .obj file. Use this if the lightning looks weird.
VL-Tone
Member
Super Mario 64 forum moderator
Level: 51


Posts: 532/621
EXP: 994842
For next: 19096

Since: 07-27-07

From: Montreal, Canada

Since last post: 1.0 years
Last activity: 36 days

Posted on 10-11-09 10:48:34 PM Link | Quote
Originally posted by Stevoisiak
Originally posted by VL-Tone
As for Banjo Kazooie levels, I think we may run into problems with texturizing the model. Rare did write an entirely new engine to make use of higher resolution textures.

Can't the textures just be scaled down? Sure, they won't look as nice, but they'd work at a smaller resolution, right?



Yes they can be scaled down

But like I explained in the other thread, there's a lot of other stuff that the BK engine can do that the SM64 engine can't. For example the BK engine can combine 2 layers of textures, fading from one to the other, and can smoothly colorize textures.

Originally posted by messiaen
The scaling value will differ widely depending on how your .obj is laid out. The Mario 64 engine supports vertex values between -8192 and 8192. If your scaling is too big, the program will warn you and you should try using a smaller value. Floats are supported: for instance, if you want to scale down your object to 70%, use a value of 0.7.


SM64 supports vertex values from -16384 to 16384, but the collision engine will only work within the horizontal -8192 to 8192 boundaries, that is, Mario won't be able to reach anything outside of this, there will be an invisible wall at 8192. It could still be usefull to allow for values between 8192 and 16384, as you might want to include unreachable areas around you level (If you look at the Spiral Mountain level, there's a lot of space on the side that's unreachable and could be out of boundaries).

BTW, how do you handle texture coordinates conversion? I'm stuggling to find the exact right way. I got a 10.5 float conversion function, but I'm not even sure if it works correctly. I did manage to get some good scaling values, but if I change the value by even one decimal some of the textures get screwed up for some reason.
battleben

Level: 9


Posts: 10/11
EXP: 2248
For next: 914

Since: 06-27-08


Since last post: 9.0 years
Last activity: 8.0 years

Posted on 10-12-09 03:25:45 AM Link | Quote
As you requested, here is a link to a video of a banjo map in Zelda 64.
http://www.youtube.com/watch?v=e58Ye1x4sJU&feature=player_profilepage
And,The reason i thought porting from ocarina would be ideal was that ocarina uses a heavily modified Mario 64 engine. but then again, i know basically nothing about hacking
SubDrag
Member
Level: 13


Posts: 12/27
EXP: 8778
For next: 1489

Since: 03-01-08


Since last post: 3.0 years
Last activity: 4.0 years

Posted on 10-12-09 07:10:11 PM (last edited by SubDrag at 10-12-09 07:11 PM) Link | Quote
Impressive work.
messiaen
Catgirl
Level: 65


Posts: 672/1085
EXP: 2265127
For next: 70501

Since: 11-20-07


Since last post: 4.0 years
Last activity: 3.0 years

Posted on 10-12-09 10:35:49 PM Link | Quote
Originally posted by VL-Tone
BTW, how do you handle texture coordinates conversion? I'm stuggling to find the exact right way. I got a 10.5 float conversion function, but I'm not even sure if it works correctly. I did manage to get some good scaling values, but if I change the value by even one decimal some of the textures get screwed up for some reason.


The 10.5 converion is easy, a long time ago I asked about it and Cellar Dweller said the texture coordinates are actually 10.5 fixed point, not floating point. The first 10 bits are the integer value and the remaining the fraction, so all you have to do is shift left 5 bits, that is, multiply by 32.

Now that you asked, I noticed that I handle the texture coordinates based on a misreading from one of your posts : I divide them by the biggest vt value and them multiply by scaling, which is probably not a very good method.
VL-Tone
Member
Super Mario 64 forum moderator
Level: 51


Posts: 536/621
EXP: 994842
For next: 19096

Since: 07-27-07

From: Montreal, Canada

Since last post: 1.0 years
Last activity: 36 days

Posted on 10-13-09 03:10:35 AM Link | Quote
Originally posted by messiaen
The 10.5 converion is easy, a long time ago I asked about it and Cellar Dweller said the texture coordinates are actually 10.5 fixed point, not floating point. The first 10 bits are the integer value and the remaining the fraction, so all you have to do is shift left 5 bits, that is, multiply by 32.

Now that you asked, I noticed that I handle the texture coordinates based on a misreading from one of your posts : I divide them by the biggest vt value and them multiply by scaling, which is probably not a very good method.


Damn I spent hours trying to get a a 10.5 floating point function working... That must explain why I had mixed results with it. It also explains why I could decode the coordinates for display in TT64 without some fancy math.

Anyway, even before reading your post I decided to scrap the 10.5 floating point function while working on the BK level. I observed the texture coordinates for simple objects in SM64 (cubes) and found that they were often 0x0 and 0x3DE. So what I did is multiply the texture coordinates from the .obj file by 990, transform this into a 16-bit signed integer and it seemed to work. I did have to offset the numbers a little to get a better result. So the equation I used is (S*990-30,T*990-40) and it was close enough to me.

I first thought I would have to "normalize" the texture coords like I did for the vertices, but I realized that texture coordinates had to be more standardized than vertices, the latter can vary greatly depending on the 3d program (some will ouput vertice values from 0.0 to 1.0 while other will output integers of varying ranges 0 to 1000+ for example). Texture coordinates on the other hand, have to be standardized so that 1.0 in all .obj files should mean the edge of the texture, and 2.0 would mean that the texture gets repeated 2 times, that's why they shouldn't be normalized.


Stevoisiak
Member
Level: 36


Posts: 280/283
EXP: 301651
For next: 6459

Since: 11-22-07

From: New York, Long Island

Since last post: 8.0 years
Last activity: 2.0 years

Posted on 10-13-09 04:18:50 PM Link | Quote
I've seen a couple imports using your program Messiaen. I'm gonna gather a playlist of 3D Model Imports and post it here. Is that ok?
Rez2
User
Level: 12


Posts: 5/24
EXP: 6918
For next: 1003

Since: 05-27-09

From: England

Since last post: 7.0 years
Last activity: 260 days

Posted on 10-13-09 04:49:31 PM (last edited by Rez2 at 10-23-09 06:07 PM) Link | Quote
Does this work with extended roms?

Edit: My problem was the extender.
Breegullbeak
Member
Level: 26


Posts: 43/135
EXP: 92169
For next: 10106

Since: 06-06-09


Since last post: 7.0 years
Last activity: 6.0 years

Posted on 10-13-09 06:50:21 PM Link | Quote
Originally posted by Rez2
Does this work with extended roms?

It only works with extended roms. But the extender can't be above version 1.3 or it won't work.
Pages: 1 2 3 4 5 6 7 8 9 10 ... 46 47 48 49 50 51 52 53 54 55Next newer thread | Next older thread
Jul - SM64 Hacking (Archive) - Mario 64 Level Importer New poll - New thread - New reply




Rusted Logic

Acmlmboard - commit 220d144 [2018-11-04]
©2000-2018 Acmlm, Xkeeper, Inuyasha, et al.

33 database queries, 12 query cache hits.
Query execution time: 0.265535 seconds
Script execution time: 0.035691 seconds
Total render time: 0.301226 seconds