Airikita and haddockd Sharp Ocarina fix (see last page for build)

[haddockd]

A quote from xDan:

Now, after those screenshots and checking SO's source code again, I'm quite sure that this can easily be fixed by reordering the display list addresses in the mesh header.

 

---

Comparing how SO generates the mesh header with how mesh header type 00 actually works, SO just writes the addresses of all opaque display lists one after the other, followed by all translucent ones, while it really should be "interleaved", with one opaque display list's address first, then a translucent one, then the next opaque one, the next translucent one, etc., etc., to put it simply. How it actually works - to my knowledge - was not known, or at least not documented until I made that post, so SO obviously does it wrong as it predates that post by two years.

 

If anyone wants to take a stab at fixing SO conversions with that information, be my guest! I'd love to see a map generated by SO running properly on hardware... especially after I've been so critical of my own, old project over the last few years, calling it broken, a pain to work with, and so on, as JSA can probably attest to

 

 

 

For more information, check this out:

ZLE3 info

 

Can someone test this and :

a) ensure it works as intended

works on the real hardware

 

Please let me know if it does or does not.

 

Link:

Download here!

[Arcaith]

No dice. It runs, but the depth buffer is still wigging out. Not sure if it's related to the model being mostly one huge group.

 

[haddockd]

Damn. Anyone have any thoughts on this?

[Arcaith]

I think there were more issues with SO's lists than the fact that they weren't interleaved. Here's the post about the differing mesh types. And here's the Model2F3DEX2 source, the models this generates work on hardware.

[haddockd]

Forgive me but this isnt my forte. I am a good programmer but do not know the finer points of display lists (and quite honestly do not have weeks to read up on and perfect it). If anyone has places to look or specific things they think may needs to be changed, I can take a look.

 

For example,

 

If the fdex converter works perfectly, wouldnt it be better to implement that into SO and abandon the non working code?

 

It is doubtful I have one tenth of xDans skill but I will def take a crack at it with the guidance of the community.

[Zeth Ryder]

No dice. It runs, but the depth buffer is still wigging out. Not sure if it's related to the model being mostly one huge group.

 

 

I imagine that is a big problem to begin with anyways as most games and even in OOT, doesn't make the maps into one huge chunk. Have you tried it with several grouped meshes?

[haddockd]

If anyone has any suggestions as how to accomplish this, I can change the code and update the tool

[HeavyZ]

I wish I was more experienced, and skilled enough to be help, but I would most definitely like to see this happen

[Airikita]

I am curious if lighting effects, or fog, might be an issue for z-depth. It appears my map I created with dark fog, etc, shows map mesh in the wrong z-depths.

The water layer appears hidden below the ground, and the walls appear behind the exit cone behind the wall, etc...

 

Is this a related issue to the interleaving?

[haddockd]

I actually dont know. I just changed a part of the app that xDan said to and published the results.

 

xDan, Thoughts?

[Airikita]

Well, not sure then... but I can see a glaring problem:

 

When I run it on the console, it doesn't know which end of the mesh is which without proper z-depth values... this seems to be related to z-depth. It might be a result of the fog, or just the version I have. I will download your update and test it out.

[haddockd]

If you know the issue, I can take a look at the code and try to fix it but I know virtually nothing about DLists, zDepth or map importing but I am versed in coding

[Airikita]

If you know the issue, I can take a look at the code and try to fix it but I know virtually nothing about DLists, zDepth or map importing but I am versed in coding

For starters, for the mesh header to work, like in Hyrule Field, at 0x58 of my map the first line would have to start with 02060000, because type 02 seems to read it that way.

Although, from my test there was some improvement... but I only caused a mess.

 

I can't make heads or tails of the list myself, at least not unless I look into it further and test a lot.

 

Maybe this will help: http://wiki.spinout182.com/w/Maps_and_Scenes#Mesh_Header ?

[haddockd]

Yeeeahhh...that is going to be over my head. Unfortunately I am not going to be able to tackle this alone because it will essentially mean rewriting/tracking down all these issues but I would have to learn the proper map and header formats which I know zero about.

[xdaniel]

Mesh type 0 and the basic composition of it as generated by SO should be fine. Entries for that mesh type don't need any additional data like clipping bounds or what have you, unlike type 2. That said, SO still doesn't work properly on hardware obviously, although there's one thing that comes to mind.

 

I assume you've done this exactly as I said before, i.e. one opaque display list, one translucent display list, one opaque, one translucent, etc. Can't find the code snippet I remember posting, but I think that's how I implemented that there, like...

[AAAAAAAA BBBBBBBB]
[CCCCCCCC DDDDDDDD]

...each set of brackets being one entry in the header. Instead of that, try doubling the amount of entries and putting a single opaque display list into a single entry with no translucent one attached, and vice-versa. So like...

[AAAAAAAA 00000000]
[CCCCCCCC 00000000]
[00000000 BBBBBBBB]
[00000000 DDDDDDDD]

...with all the translucent entries following after all the opaque ones.

 

If any of that makes sense. It's late, I haven't worked on this in ages, and I don't really care anymore for reasons stated more than enough times already. Would like to see SO create stuff that's at least playable on hardware, but... meh, by this point.

[Airikita]

Actually, strangely enough Hyrule Field orders the 00000000 BBBBBBBB stuff as non-collision mesh. The translucent stuff seems to be... somewhat-transparent models.

Idk, Hyrule Field puts the lon-lon ranch walls as a translucent right next to the bridge to Kakariko as an opaque.

 

The "translucent" stuff after appears to be non-collision background objects... such as the castle towers.

 

I think you're close haddockd.

 

The non-collision mesh is listed after the collision mesh list. The collision mesh is as AAAAAAAA 00000000 and the non-collision mesh is 00000000 BBBBBBBB where all the non-collision mesh is listed afterwards.

[haddockd]

Soooo, we have 2 categories and 2 subtypes if I understand properly:

 

Categories:

1) Non-Collision Mesh

   a: opaque

   b: translucent

 

2) Collision Mesh

 

 

As far as the non-collision meshes, how should they be ordered? I believe SO simply interleaves them. I *think* this is the code in reference:

ZScene.cs

 if (MeshHeaderOffset != -1)
            {
                List<NDisplayList> opaqueLists = Room.DLists.FindAll(delegate(NDisplayList DL) { return (DL.TintAlpha >> 24) == 255; });
                List<NDisplayList> translucentLists = Room.DLists.FindAll(delegate(NDisplayList DL) { return (DL.TintAlpha >> 24) != 255; });
                int numEntries = Math.Max(opaqueLists.Count, translucentLists.Count);

                Helpers.Overwrite32(ref Room.RoomData, MeshHeaderOffset, (uint)(0x00000000 | (numEntries << 16)));
                Helpers.Overwrite32(ref Room.RoomData, MeshHeaderOffset + 4, (uint)(0x03000000 | MeshHeaderOffset + 12));
                Helpers.Overwrite32(ref Room.RoomData, MeshHeaderOffset + 8, (uint)(0x03000000 | (MeshHeaderOffset + 12) + (numEntries * 8)));
                MeshHeaderOffset += 12;

                for (int i = 0; i < numEntries; i++)
                {
                    if (i < opaqueLists.Count)
                        Helpers.Overwrite32(ref Room.RoomData, MeshHeaderOffset, (uint)(0x03000000 | opaqueLists[i].Offset));
                    else
                        Helpers.Overwrite32(ref Room.RoomData, MeshHeaderOffset, 0);

                    MeshHeaderOffset += 4;

                    if (i < translucentLists.Count)
                        Helpers.Overwrite32(ref Room.RoomData, MeshHeaderOffset, (uint)(0x03000000 | translucentLists[i].Offset));
                    else
                        Helpers.Overwrite32(ref Room.RoomData, MeshHeaderOffset, 0);

                    MeshHeaderOffset += 4;
                }
            }

[Airikita]

EDIT:

Seems like order matters.

The stuff in the background should be last, and the opaque/translucent order remains fine...

 

Although, comparing Spot04, which requires lighting, and is receptive to fog, I noticed a missing command:

0x03 F3DEX2_CULLDL (usage unknown)

 

I noticed that a farther polygon will appear to overlap a higher plane, and also the ground covers up Link.

 

I assume that, by comparing the ground portion of Spot04 at 0x4860 of spot04_room_0.zmap, it seems like this 03 command probably corrects the culling for proper z-depth.

 

I can only assume the farther polygon has a conflicting issue with the culling of the top layer somehow... because I haven't seen the 03 command used anywhere else, and it seems to make sense.

 

I have no idea where to start with display lists... but the 03 command seems simple, aside from what appears to be a 01 reference to normals.

The 03 command looks like this: 03 00 00 00 00 00 00 0E.

 

Seems basic, and I can only guess that this is what corrects this z-depth issue, but also the DList coding is a lot bulkier in it.

 

Kokiri Forest's ground DList hex:

E7 00 00 00 00 00 00 00 D9 FC FF FF 00 00 00 00

01 00 80 10 03 00 47 E0 03 00 00 00 00 00 00 0E

E7 00 00 00 00 00 00 00 D9 FF FF FF 00 03 00 00

E7 00 00 00 00 00 00 00 E3 00 10 01 00 00 00 00

D7 00 00 02 FF FF FF FF FD 10 00 00 02 01 06 18

F5 10 00 00 07 01 44 51 E6 00 00 00 00 00 00 00

F3 00 00 00 07 3F F1 00 E7 00 00 00 00 00 00 00

F5 10 10 00 00 01 44 51 F2 00 00 00 00 07 C0 7C

FD 10 00 00 02 00 FE 18 F5 10 01 00 07 01 78 5E

E6 00 00 00 00 00 00 00 F3 00 00 00 07 3F F1 00

E7 00 00 00 00 00 00 00 F5 10 11 00 01 01 78 5E

F2 00 00 00 01 07 C0 7C FC 26 7E 04 1F FC FD F8

E2 00 00 1C C8 11 20 78 D9 F3 FF FF 00 00 00 00

D9 FF FF FF 00 03 04 00 FA 00 00 00 FF FF FF FF

01 02 00 40 03 00 34 40

 

EDIT:

seems like you need to convert the models with the Model2N64 tool.

xDaniel, couldn't you upload the one that worked with the cube?

 

================================================

EDIT2:

CORRECTIONS MADE TO F3DEX2 CONVERTER:

-------------------------------------

1) added lines:

E7 00 00 00 00 00 00 00 D9 FC FF FF 00 00 00 00

01 00 80 10 03 00 47 E0 03 00 00 00 00 00 00 0E

E7 00 00 00 00 00 00 00 D9 FF FF FF 00 03 00 00

 

2) removed (Note: just removing these 2 commands seems to work):

FC 12 7E 03 FF FF FD F8 E2 00 00 1C C8 11 30 7C

 

Result:

Ground is behind Link as it should be. (y)

 

Problem:

This does cause a problem for alpha textures... but I can look into that, unless someone knows how to look into the FC commands for maps.

 

Map parts don't use FC and E2 commands though. Maybe FC for alpha textures.

 

Alpha textures (for maps) seem to use the 2 commands, with slight differences:

FC 12 7E 03 FF FF F3 F8 E2 00 00 1C C8 11 30 78

 

The water mesh uses this (for transparency I imagine):

FC 26 7E 04 1F 0C FD FF E2 00 00 1C C8 10 49 D8

 

Once I applied these changes, this is the end result:

-----------------------------------------------------

(apologies for the lighting, I was fixing the mesh over re-adjusting the lighting.... ah well)

 

Also, Haddockd, I couldn't have done this without the interleaving formatting. With the wrong ordering in the header format, the map still displayed out of order even with the DList fixed.

 

I do commend you for your efforts, it was a wise insight.

 

That being said... once this is fixed, maybe getting the 02 type to work will be useful for larger maps.

 

 

 

 

Soooo, we have 2 categories and 2 subtypes if I understand properly:

 

Categories:

1) Non-Collision Mesh

   a: opaque

   b: translucent

 

2) Collision Mesh

 

 

Also... I got the formats mixed up when I was reading the information. You had it right the first time, in fact the way you did it is perfect!

[xdaniel]

I'm out, sorry. Even if I wanted to dive into this whole subject matter again - which I don't for the known reasons -, my real life is a mess and will stay so for an undetermined amount of time (several weeks at least, after having already been a mess since January 3rd). I have no access to my desktop machine right now, and my laptop doesn't even have half of the data/programs/ROMs/etc. I have on the other system. Pretty much all I have here is the OoT3D/MM3D stuff, an Etrian Odyssey 1 ROM and some docs, and whatever I can get from my Github.

 

Whoever is interested in taking this over: either have or gather some C# knowledge, ignore SO and Model2N64 completely, use the HW-compatible converter as a base (you know, the one I ragequit from and open-sourced a year ago, that no one has done anything with since), and make a whole new custom map importer based on whatever new knowledge has been gained over the last year.

[Airikita]

I'm out, sorry. Even if I wanted to dive into this whole subject matter again - which I don't for the known reasons -, my real life is a mess and will stay so for an undetermined amount of time (several weeks at least, after having already been a mess since January 3rd). I have no access to my desktop machine right now, and my laptop doesn't even have half of the data/programs/ROMs/etc. I have on the other system. Pretty much all I have here is the OoT3D/MM3D stuff, an Etrian Odyssey 1 ROM and some docs, and whatever I can get from my Github.

 

Whoever is interested in taking this over: either have or gather some C# knowledge, ignore SO and Model2N64 completely, use the HW-compatible converter as a base (you know, the one I ragequit from and open-sourced a year ago, that no one has done anything with since), and make a whole new custom map importer based on whatever new knowledge has been gained over the last year.

Hey, if you can give some information about the 2 commands (maybe your notes?) we can work on this.

I can understand if you can't work on it xdan. I just have no understanding of these commands, FC especially.

But surely we can manage something.

 

The component missing is where to place the alpha value in the combiner.

I have old notes from SoulOfDeity, but they're REALLY OLD notes.

 

I'm sure me and haddockd can work on this fix.

 

This literally just looks like all that needs to be done is the removal of a few flags, and poof!

Don't even have to remove the lines like I did, just subtract a few values.

 

Haddockd, maybe you can send me your updated source in PM perhaps?

[haddockd]

Sure Airikita!

 

I will create a new project using xDan's source code (keeping it GLP of course). PM me your email address so i can add you to it

[xdaniel]

Dunno if it's of any help, but I hacked together a combiner calculator of sorts from what I have access to at the moment; can decode and encode combiner modes: https://www.dropbox.com/s/631tucbr07l8bm2/CombinerCalculator.rar?dl=0

 

Run like "CombinerCalculator.exe 0xFC119604FF13FFFF" or "CombinerCalculator.exe TEXEL0 0 PRIMITIVE 0 TEXEL0 0 PRIMITIVE 0 COMBINED 0 SHADE 0 COMBINED 0 SHADE 0". Example output:

 

Combiner Calculator -- February 28th 2015 by xdaniel
-------------------------------------------------------------------------------

Decoding combiner mux...

-- Packed Mux -----------------------------------------------------------------
0xFC119604FF13FFFF

-- Cycle 0 --------------------------------------------------------------------
C [(TEXEL0           - 0               ) * PRIMITIVE       ] + 0
A [(TEXEL0           - 0               ) * PRIMITIVE       ] + 0
-- Cycle 1 --------------------------------------------------------------------
C [(COMBINED         - 0               ) * SHADE           ] + 0
A [(COMBINED         - 0               ) * SHADE           ] + 0
-------------------------------------------------------------------------------

Done!

 

Also, http://n64devkit.square7.ch/n64man/gdp/gDPSetCombineLERP.htm and the sources to my HW-compatible converter and SceneNavi. I don't have any other notes about the combiner, I don't think, and even if I do, they're not here with me.

 

[haddockd]

Thanks xDan! I copied the project to a different code repository so we can make all the changes we want and not mess up your original

[Airikita]

LOL, the fix was so minor.

Changes have been committed. Done.  XD

 

Have cake now:

 

Happy Birthday to everyone (especially those who had birthdays the past month, lol)

[haddockd]

What did you change?

 

Also are you saying that it works on hardware now?