Kuribo64
Views: 6,523,098 Home | Forums | Uploader | Wiki | Object databases | IRC
Rules/FAQ | Memberlist | Calendar | Stats | Online users | Last posts | Search
01-16-17 11:55 PM
Guest:

0 users reading Editor development | 1 bot

Main - General SM64DS hacking - Editor development New reply

Pages: 1 2 3 4 5 6 7 ... 24 25 26 27 28
Skelux
Posted on 01-06-13 05:06 AM Link | #3980
Posted by Fiachra
Posted by Skelux
Could you paste me the line of code that writes 0 as the collision? Considering the size of my levels, it would be faster for me to just find an appropriate collision and set it for every plane in the level on import.

It's in ObjToKcl.cs - Line 198:
kcl.Write16(pos + 14, (ushort)0);

Just change that 0 to the collision type you want.


Thanks, It doesn't seem to be the problem though, the invisible slowness barrier is still there. Tomorrow I'll try the earlier revision.

Fiachra
Posted on 01-06-13 09:25 AM (rev. 2 of 01-06-13 03:24 PM) Link | #4053
Posted by Skelux
Thanks, It doesn't seem to be the problem though, the invisible slowness barrier is still there. Tomorrow I'll try the earlier revision.

I've added the option to use the old method when importing a model (rev. 27) and some other changes - see second post.

Posted by Skelux
Adding Y-offset options would allow you to place the level down near the death floor. From memory, about -8000 was how much it needed.

Most (if not all) levels have a collision type for the death floor - you can use the KCL editor to set the lower faces of your level to be the death floor

Skelux
Posted on 01-06-13 09:19 PM Link | #4330
Posted by Fiachra
Posted by Skelux
Thanks, It doesn't seem to be the problem though, the invisible slowness barrier is still there. Tomorrow I'll try the earlier revision.

I've added the option to use the old method when importing a model (rev. 27) and some other changes - see second post.

Posted by Skelux
Adding Y-offset options would allow you to place the level down near the death floor. From memory, about -8000 was how much it needed.

Most (if not all) levels have a collision type for the death floor - you can use the KCL editor to set the lower faces of your level to be the death floor


That's the faulty collision with all the horrible gaps.
As I thought, rev 23 has near perfect collision with no problems on any hills. Something changed between r23 and r27 has caused random hill problems.

Fiachra
Posted on 01-07-13 02:15 AM (rev. 5 of 01-07-13 03:19 PM) Link | #4362
The changes between rev. 23 and 24 were:

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

was removed as it was getting rid of very small faces.

Also sometimes num_buckets could be equal to zero if there were fewer than 256 triangles in the model

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

so this has been fixed to set num_buckets = 1 not 0 if there are fewer than 256 faces.

Edit: I have now added the first line back in but you can now configure the value it uses - 0 to keep all faces, default value is original 0.001. For your Bob-Omb Islands model the value 0.0005 seems to sort out both the hill and the raised bumps around the roof of the floating fort.

Please see second post (revision 29 07/01/2013).

shibboleet
Posted on 01-15-13 02:05 PM Link | #6265
Wow, this is actually going great!

So SM64DS hacking has resurrected from the dead :D

____________________
][[[[[[[[[[[[[pp[p[

Fiachra
Posted on 01-15-13 02:39 PM Link | #6277
Yeap :)

I haven't been working on it as much though this past week as I'm working on porting a level from Super Mario Sunshine to SM64DS. So far I've finished simplifying the model from over 16000 faces to 3750 (the maximum the DS can handle, a lot higher than I previously thought) and I'm nearly done with the re-texturing.

I'm currently adding an interface for the texture collision data which hopefully will allow adding and removing from selected areas and renaming the material to use as well as the scale, rotation and translation values.

ray
Posted on 01-15-13 02:43 PM Link | #6279
Posted by Fiachra
So far I've finished simplifying the model from over 16000 faces to 3750 (the maximum the DS can handle, a lot higher than I previously thought)


As soon as my model hits more than 2048 faces, the game freezes. How the hell can you use a 3750-model? o0

____________________
Check out my Patreon Page if you want to support me :)



StapleButter
Posted on 01-15-13 02:46 PM Link | #6280
I guess it depends on how many objects and stuff you have in your level.

It's like for texture size: there's no absolute limit, but you can tell that past a certain number, things tend to become unstable (like textures getting glitched or freezes).

____________________
RHCafe - Kafuka - Jul

Dinosaurs aren't big fans of trams.

Gericom
Posted on 01-16-13 08:04 AM Link | #6368
Posted by Mega-Mario
I guess it depends on how many objects and stuff you have in your level.

It's like for texture size: there's no absolute limit, but you can tell that past a certain number, things tend to become unstable (like textures getting glitched or freezes).

The limit is the available ram on the nintendo ds.

Dirbaio
Posted on 01-16-13 05:56 PM Link | #6437
The DS's hardware can handle maximum 2048 triangles or 1536 quads. (It has Vertex Ram for 6144 vertices).
Polygons that are completely outside the viewing volume are not stored at all in the Vertex RAM. This is why it's possible to put models with more than 2048 triangles. As long as not all of them are visible at the same time, it will work fine.

When the Vertex or Polygon RAM is full, any new polygons will fail to display. I'm not sure if it actually freezes the 3D hardware. GBATek says nothing, and I've never personally tested it. But I *think* it doesn't freeze, it just ignores new polygons.

____________________
Cool Stuff: Dirbaio.net (my boring site) - The NSMB Hacking Domain - Kuribo64 - ABXD DevBoard

Gericom
Posted on 01-17-13 08:13 AM Link | #6564
Posted by Dirbaio
The DS's hardware can handle maximum 2048 triangles or 1536 quads. (It has Vertex Ram for 6144 vertices).
Polygons that are completely outside the viewing volume are not stored at all in the Vertex RAM. This is why it's possible to put models with more than 2048 triangles. As long as not all of them are visible at the same time, it will work fine.

When the Vertex or Polygon RAM is full, any new polygons will fail to display. I'm not sure if it actually freezes the 3D hardware. GBATek says nothing, and I've never personally tested it. But I *think* it doesn't freeze, it just ignores new polygons.

With my mkdd models in mkds it always happens. It just doesn't display the remaining polygons.

Dirbaio
Posted on 01-17-13 04:09 PM Link | #6655
Great, then the models are crashing for some other reason we don't know...
I have no idea...

____________________
Cool Stuff: Dirbaio.net (my boring site) - The NSMB Hacking Domain - Kuribo64 - ABXD DevBoard

Fiachra
(post deleted) #6735

Fiachra
Posted on 01-19-13 01:20 PM (rev. 3 of 01-19-13 01:29 PM) Link | #7391
Has anyone worked out the texture animation data, specifically the last values at offset 0x18 (below)?
The documentation says the last value is 4 bytes but it's actually 2 ushort values. For most texture animations they're the same as the translation values table start index and amount of values but then in others it's just 1, 0 and then in others it seems to be the total length of the translation values table.
I'm trying to allow you to remove a specific texture animation from an area but I think this is causing problems. If no one knows, I'll just leave it as editing existing values - adding/removing scale, rotation and translation values and setting the name (can resize) or removing all of them.

Animation data: 28 bytes per entry.

Offset Size Desc
00 4 ???
04 4 Address of the name of the material with the texture to animate (null-terminated ascii string)
08 4 ???
0C 2 Number of scale values
0E 2 Start offset in dwords in the scale values table
10 2 Number of rotation values
12 2 Start offset in words in the rotation values table
14 2 Number of translation values
16 2 Start offset in dwords in the translation values table
18 4 ???

[image]

Edit: Changing doesn't seem to do anything at all. I can delete individual texture animations if it not the first one, otherwise it deletes the first one but the ones after it just appear as noise in their main colour even though their values appear to be fine when read by the editor.
Edit: Finally got that working, now I need to try and allow adding new texture animations.

Finally finished the texture animation editor (rev. 30). You can edit or remove existing texture animations including their scale, rotation and translation values as well as adding new ones.


[image]

Also added option to change minimap co-ordinate scale.

Mega-Mario:
Is there anything else you think needs added?

Edit: Just merged above post.

Also, this is the level I was talking about, though the water looks better now than in the video.
http://www.youtube.com/watch?v=Llq53_P8Tow

StapleButter
Posted on 01-19-13 03:07 PM Link | #7473
Well, I can't think of anything to add right now, it should be okay :)

Also let me know when you think that all this stuff is ready for a release :)

____________________
RHCafe - Kafuka - Jul

Dinosaurs aren't big fans of trams.

ray
Posted on 01-19-13 03:27 PM Link | #7490
It would be nice, if you can add copy-pasting objects :) Or a "Select multiple objects" mode or something like this, which lets you move more objects at once, or delete or whatever. Maybe when holding CTRL or something.

____________________
Check out my Patreon Page if you want to support me :)



StapleButter
Posted on 01-19-13 04:13 PM (rev. 2 of 01-19-13 04:14 PM) Link | #7508
Multiple selection would definitely be possible, it'd just require a bit of work. Like, every time something is done to selectedObject, we'd have to instead iterate through a list and do the action to each object in that list.

Related detail: the standard Winforms treeview control doesn't support multiple selection. But since the one SM64DSe uses for its object list uses owner-drawing, we can use that to make lines look like they're selected.

Java's treeview implementation does support multiple selection, so when we port SM64DSe, that hack won't be needed anymore :)


Reminds me, on GUI and Linux: Dirbaio once mentioned that anchors cause GUIs to break under Mono. Perhaps that's the cause of our Linux problems, who knows. Another possible cause is owner-drawing, but then blarg and blarg.

____________________
RHCafe - Kafuka - Jul

Dinosaurs aren't big fans of trams.

Fiachra
Posted on 01-19-13 04:27 PM Link | #7517
The only thing that isn't fully working of the stuff I've added is model exporting - there seem to be problems with quads. I'll try and fix that tomorrow but if that doesn't work, I say just release it as it is, it's got plenty of other new features, most importantly the fixed collision :)

Fiachra
Posted on 01-24-13 05:52 AM (rev. 2 of 01-24-13 06:03 AM) Link | #9261
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.

Before:

After:
[image]

Code committed - rev. 31 24/01/2013

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.

shibboleet
Posted on 01-27-13 01:07 AM (rev. 2 of 01-27-13 01:16 AM) Link | #10246
Wow, this is amazing! :D
It's amazing on how fast this got revived :3
I'm really impressed with it! It might make a level...but I have no real knowledge of SM64DS hacking that much...

____________________
][[[[[[[[[[[[[pp[p[
Pages: 1 2 3 4 5 6 7 ... 24 25 26 27 28

Main - General SM64DS hacking - Editor development New reply

Page rendered in 0.038 seconds. (2048KB of memory used)
MySQL - queries: 27, rows: 230/230, time: 0.019 seconds.
[powered by Acmlm] Acmlmboard 2.064 (2015-10-07)
© 2005-2008 Acmlm, Xkeeper, blackhole89 et al.