Views: 11,204,329 Home | Forums | Uploader | Wiki | Object databases | IRC
Rules/FAQ | Memberlist | Calendar | Stats | Online users | Last posts | Search
09-24-20 07:10 AM

Main - Posts by Fiachra

Pages: 1 2 3 4 5 ... 50 51 52 53 54
Posted on 12-16-12 08:16 AM, in What's this? SM64DS making a comeback? Link | #1817
Hi, Fiachra here, glad you like the changes.

I've nearly got the level models' geometry exporting:

If I can get that working properly it should be possible to compare the game's kcl collision data with that generated by re-importing the level and see what the problem is. Although that may not be neccesary as I think Mega-Mario, blank and others are making good progress on that. (http://kuribo64.net/?page=thread&id=128&from=20)

Posted by Homer
And abilities to add characters and stars

Currently you can import custom models for non-animated objects, such as brick blocks. Importing custom characters would require modifying the bca animation files, though that should be possible in the future as Gericom has it working in his MKDS editor.

Posted on 12-16-12 03:11 PM, in What's this? SM64DS making a comeback? (rev. 3 of 12-16-12 03:17 PM) Link | #1829
Thanks for the GBATek link - it was very helpful.

I've now got it working more or less perfectly - some models have 1 or 2 faces missing but you can just fill them in with Blender as the vertices are still there. Here's the same model as earlier (it was the castle courtyard) and the main castle grounds as they appear now after exporting:


They look identical when re-imported (minus textures).

I'll also be adding the ability to export objects' models.

Also, I've converted the whole GBATek site into a pdf with working links for navigation if anyone wants it:

Posted on 12-17-12 12:06 PM, in Looking into SM64DS fixing collision Link | #1865
The latest version of SM64DSe in the repo has the ability to export level models almost exactly (http://postimage.org/image/ruuu6hmw7/). You can then reimport them (but make sure to reove the textures first - seems to cause problems) and compare the collision files generated by Nintendo and those made by the editor. For example here's the Main Castle before and after collision files:
The original is about 5kB bigger.

Posted on 12-21-12 03:46 PM, in Looking into SM64DS fixing collision Link | #1962
Posted by ray
... Even if the textures sometimes make the wrong sound, it's a BIG improvement and there aren't any bugs! ...

I've added a kcl terrain type editor to SM64DSe so you can now fix that, though it'll be quite tedious - I need to add multiple selections and an easier way of selecting a face.

Posted on 12-24-12 04:18 PM, in Looking into SM64DS fixing collision (rev. 2 of 12-24-12 04:21 PM) Link | #2110
Has there been any word from blank regarding the modified version of his script?
I've already got his python script from collision tools v0.6 in the editor but I haven't been able to get it to produce SM64DS kcl files properly. If I had his new version I reckon I could get it working quite quickly.

Posted on 12-26-12 05:13 AM, in Looking into SM64DS fixing collision Link | #2135
There's also a lot of information on GBAtemp such as:

Posted on 12-26-12 05:43 AM, in Looking into SM64DS fixing collision Link | #2139
That's great, thanks for this. I'm going to try and port this into the editor in the next few days.

Posted on 12-28-12 03:13 PM, in Looking into SM64DS fixing collision (rev. 3 of 12-28-12 03:36 PM) Link | #2231
Finished porting blank's new script into the editor - perfect collision! :)

I've quickly tested it with Skelux's Bob-Omb Islands model and it seems to be working perfectly apart from the small raised bumps around the rim of the floating fort.

[image] On top of tower to the right of the floating fort.
[image]On top of roof of floating fort.

I've committed the code to the repo (http://code.google.com/p/sm64dse/source/list).

Posted by Mega-Mario
But wait, Fiachra has made a change to address that issue. Perhaps you need to click a button or check a checkbox when importing, idk if he made it automatic...

You need to press the 'Save' button (upper left corner) after importing a custom model.

Posted by Mega-Mario
... BTW, I'm also thinking of moving SM64DSe to Git. But I think it should be rewritten into Java for better portability (the 3D interface just won't work right under Linux). I'm not going to do it without first knowing your opinion, though.

I've never used Git so I don't know much about it. If you think it's better I'm happy to change. Rewriting to Java'd be good so it worked in Linux. I don't think I could help much with the NitroROM, NitroFile classes or the GLView parts but if those were done I could probably help a good bit with the rest.

Posted on 12-29-12 05:13 AM, in Looking into SM64DS fixing collision (rev. 2 of 12-29-12 05:18 AM) Link | #2283
Posted by ray
Thanks :) But I just solved it trough recompiling :P ...

The executable in the repo is an old version, it doesn't be updated when new code is committed. You need to download and compile the source code to get the newest version.

Posted by Mega-Mario
... Actually Fiachra has partially addressed the issue already, when importing a new model, texture animation data is erased (am I right?). What'll be left to do is making an interface for entering new texture animation data and we'll be good :)

Yeah, when you press the 'Save' button, if you've imported a custom model it goes through the level data header for each area:

---===[ LEVEL AREA DATA ]===---
Each entry is 12 bytes. Number determined by header[0x74].

Offset Size Desc
00 4 Address of the objects table (NULL = no table)
04 4 Address of the texture animation data (NULL = no data)
08 1 Minimap tilemap index
09 3 ???
and sets the address of the texture animation data to NULL.

Posted by Skelux
Here are some of the collision types:
Also, these levels can be imported over:

Unfortunately the collision types differ for every level, the only one that's the same is zero - solid and it'd be too hard to make a list as some levels have a lot of collision types, eg. Shifting Sand Land has 167 different types (but looks pretty in the KCL editor)!


It should be possible to replace all the levels now, for example the main castle grounds can be replaced.

Posted on 12-30-12 01:04 PM, in Looking into SM64DS fixing collision (rev. 2 of 12-30-12 01:04 PM) Link | #2470
Posted by ray
Ehh... Just wanna say, I still have collision holes in my level...
Somewhere at the borders of this:

Can you post a link to the model so I can look at?
Did you triangulate the model?

Posted on 12-30-12 02:56 PM, in Looking into SM64DS fixing collision Link | #2485
It may be a problem with the normals facing the wrong way. After I exported it to .OBJ and removed duplicate faces and vertices it looked like this:


Some are facing inside instead of outside so the collision also has some faces on the outside and some on the inside. It seems each face is exported twice, with two sets of normals, I'm not sure why.

A good tool for cleaning, fixing, simplifying triangulating etc. models is MeshLab.

It's a great looking level by the way, hope you get it working.

Posted on 12-30-12 03:41 PM, in Looking into SM64DS fixing collision (rev. 3 of 12-30-12 03:53 PM) Link | #2489
When exporting .OBJ from Sketchup (I used this plugin https://sites.google.com/site/messiaen64/level-importer/ObjExporter.rb?attredirects=0) make sure you don't tick "Guess faces to export", but do tick "Front Faces". I think the plugin may be assuming that with a strip of triangles, the normals alternate.

Looks like it should work now:


and here's the Sketchup OBJ Export dialogue:


Posted on 12-30-12 04:46 PM, in Looking into SM64DS fixing collision Link | #2492
Posted by ray
4. The model is mirrored on the Z axis.
5. Actually, some of the faces can't be seen after importing. It's like you said, they are facing inside, but that only happens after triangulating.
6. I have no idea what to do.

4. Import the .obj model into Blender. Right-click on it. Select Object>Mirror>Z Global
This should flip it on its Z axis (if it asks you to select and axis, press 'Z' on the keyboard). There is an option when importing the model to flip Z axis but I just realised that I didn't implement that for the new collision importing so it will flip the model but not the collision.
5. When I left the textures as they were the game crashed because the "yellow-coin.png" one is too large. Resizing that causes only part of the face to be visible. I noticed that the larger its resolution, the more of it can be seen in the game. All faces actually are visible, the game just crashes loading their textures.
The collision is also perfect now.
6. If you can get the coin model textures resized properly, then your model should look fine in the game.

If you can't get it working I'll try and fix it tomorrow for you.

Posted on 12-31-12 05:28 AM, in Looking into SM64DS fixing collision (rev. 2 of 12-31-12 02:41 PM) Link | #2504
Are you deleting the original star in the level? Maybe it freezes because there's a duplicate? Not really sure. What happens if, instead of adding a new star you just move the original star object's position and the star act that it appears in?
I don't know why it would only happen in your rom, maybe Mega-Mario can help more with this. In a patched rom, the level data (including objects) are stored in overlays 103 - 154. You should be able to copy these to a new patched rom. Use Nitro Explorer or NSMBe so as not to corrupt the ROM header.

You're right, the collision on the coins isn't right, I hadn't noticed because I imported them with a small scale. It's definitely a problem with the normals on the coins, the exporter seems to think some of the outside faces are on the inside. Strangely, flipping the normals of those faces didn't work. Also, the player falling out of the sky is just with your model. I'll see if I can get it exporting properly and will let you know.

Posted on 12-31-12 06:14 AM, in Looking into SM64DS fixing collision Link | #2506
Posted by ray
Posted by Fiachra
Also, the player falling out of the sky is just with your model.

What do you mean?

Whenever I import your model, the camera is pointed up at the sky. After a few seconds you can see the player falling from the sky and then hits the gound and loses about half his health. I tried a different OBJ Export plugin and the same thing happens but the coins are even worse using this plugin (http://www.sendspace.com/file/w945la). One time I messed up the model, can't remember how and the player started in the right place. Weird.

Posted on 12-31-12 07:51 AM, in Looking into SM64DS fixing collision Link | #2509
Posted by ray
Hm, for me the player starts at the right position.

That's good then.

Unfortunately I couldn't get the coin working as the sloped parts just wouldn't export properly. Maybe you can try using one of these models:


and give them the old coin's texture. Ones like this shouldn't case a problem when exporting as they're not sloped on the inside.

Posted on 12-31-12 09:59 AM, in Looking into SM64DS fixing collision (rev. 5 of 12-31-12 03:28 PM) Link | #2531
OK, turns out there was a problem with the collision! Two actually. (Sorry Ray)!

This line:
if (cross(v.sub(u), w.sub(u)).norm_sq() < 0.001) { continue; } //#TODO: find a better solution

was getting rid of very small faces, like the ones on the inside of the coin - the coins now work.

Also this:
int result = (int)(ix*this.magic_x + iy*this.magic_y + iz*this.magic_z) % this.num_buckets;

Sometimes num_buckets could be equal to zero if there were fewer than 256 triangles in the model (problem is also in blank's script, download fix here: http://www.sendspace.com/file/yyj6e8). I've fixed this problem as well in the editor (code added to repo).

Ray: What scale are you using for your model? I'm still having the player fall out of the sky.

I've noticed this problem with other models - especially small models and sometimes when otherwise fine models are scaled.

Edit: The problem with falling from the sky isn't just SM64DSe - it happens when using blank's script as well. When I was trying to get it working this usually happened if the octree wasn't right - maybe it's being made too large?

Edit 2: Importing the same model to replace an object's model doesn't cause any problems. Maybe the game expects a level model' size to be within a certain range? Also, I realised there was a problem with importing an object model in that it replaced the level's model/collision instead - this has now been fixed in the latest commit.

Posted on 01-02-13 01:13 PM, in Editor development (rev. 12 of 01-24-13 06:10 AM) Link | #2672
I'll also be posting updates on the progress here as I don't a new thread'd be necessary.

I don't know if it's only me, but when moving the camera with the right mouse button, the camera goes crazy fast and makes flips etc.
Revision: 23

That's been done deliberately - you'll to ask Mega-Mario
It would be really nice if the dark-texture thing could be fixed. When you import your model, you always have to make them a bit brighter, so they don't look dark after importing
Revision: 23

That turned out to be Google Sketchup not exporting them properly.

Latest: Revision 31 - 24/01/2013

Rev. 24 31/12/2012:
2 bug fixes.
This line:
if (cross(v.sub(u), w.sub(u)).norm_sq() < 0.001) { continue; } //#TODO: find a better solution

was getting rid of very small faces, like the ones on the inside of the coin - the coins now work.

Also this:
int result = (int)(ix*this.magic_x + iy*this.magic_y + iz*this.magic_z) % this.num_buckets;

Sometimes num_buckets could be equal to zero if there were fewer than 256 triangles in the model (problem is also in blank's script, download fix here: http://www.sendspace.com/file/yyj6e8). I've fixed this problem as well in the editor (code added to repo).

Rev. 25 31/12/2012:
1 bug fix.
Fixed bug whereby importing an object model/collision would replace the level's model/collision, forgot to update after fixing the collision generation.

Rev. 26 02/01/2013:
2 new features.

Added LZ77 compression with or without header (files where ForceDecompression() was used eg. minimap files).

Added minimap editing. You can now import your own image, must be 256 or fewer colours indexed bitmap and size has to be the same as the minimap you're replacing.
You can also choose which colour to use as the background image (default is first colour in palette).

(Below: Custom image with default background colour, Custom image with custom background colour, Minimap Editor)
I've tested it both using an emulator and the DS itself, fully working.

Rev. 27 06/01/2013
2 improvements, 1 minor change
Making object-moving better. I mean, you should be able to click on one of the axis-arrows to move it on the selected axis.

You can now move an object along a particular axis by using X,Y and Z keys while moving it.

Added multiple face selection in KCL Editor so you can change several or all collision types at once.

Also added option to use old method for generating collision (ImportCollisionMap() instead of ObjToKcl class) when importing models because some people wanted it.

Rev. 28 07/01/2013
1 bug fix

Removing this line:
if (cross(v.sub(u), w.sub(u)).norm_sq() < 0.001) { continue; } //#TODO: find a better solution

was causing some strange collision behaviour and leaving it as it was meant very small faces were dropped. Setting it to check for < 0.0005 seems to fix both problems. If you're still having problems, play about with the value of it.


Rev. 29 07/01/2013
1 improvement

You can now choose the threshold value for removing very small faces when importing collision or set it to not remove any (enter 0). (This line: if (cross(v.sub(u), w.sub(u)).norm_sq() < 0.001) { continue; } //#TODO: find a better solution)


Rev. 30 19/01/2013
1 new feature, 1 minor improvement

Added texture animation editor - you can edit or remove existing texture animations including their scale, rotation and translation values as well as adding new ones.


Also added option for changing minimap co-ordinate scale.

Rev. 31 24/01/2013
2 improvements

Got model exporting working :) I made a mistake with working out the amount of faces in quadrilateral strips, messed up BODMAS. I had this:
4+(N-1)*2 vertices per N quads
((N/2)-4)+1 Quads. per N Vertices
instead of
4+(N-1)*2 vertices per N quads
((N-4)/2) + 1 Quads. per N Vertices

Some textures are upside down or repeated incorrectly but that's because the BMD format supports texture features that OBJ doesn't, that can't be helped. Also fixed the issue with exporting models that had a material without a texture that caused the textures to become swapped around.



I had made improvements to the minimap editor that appeared to be working perfectly but it seems that resolution and other information about the minimaps is hardcoded into the game somewhere. Eg. just swapping playroom's minimap with Bob-Omb Battlefield's doesn't work. As Mega-Mario would say: Blarg!
The changes though should allow it to be used as a general 2D graphics editor with some changes.

Posted on 01-02-13 01:43 PM, in Editor development (rev. 3 of 01-02-13 01:44 PM) Link | #2676
I just used the method LZ77_Compress found here http://nsmb-editor.googlecode.com/svn/trunk/NSMBe4/ROM.cs

It's not used by default in NitroFile.SaveChanges() yet as it's easier to test uncompressed files though it'd be very easy to add for a release. I've just tested it on importing a custom level model and it doesn't seem to make much of a difference to that.

Do you want it on by default?

Posted by NWPlayer123
IDK if this is relevant, but I remember SM64DS (the person who visits SMG2.5 occasionally) once brought up mipmaps, and I'm wondering if they would be of any use. Just a suggestion.

What do you mean? Has he worked on the format?

(post in restricted forum)
Pages: 1 2 3 4 5 ... 50 51 52 53 54

Main - Posts by Fiachra

Page rendered in 0.032 seconds. (2048KB of memory used)
MySQL - queries: 21, rows: 137/137, time: 0.025 seconds.
[powered by Acmlm] Acmlmboard 2.064 (2018-07-20)
© 2005-2008 Acmlm, Xkeeper, blackhole89 et al.