3D Object Misalignment

[ghost]

In a number of titles, there is a misalignment of 3D objects (sorry if the terminology is incorrect). It usually shows as surfaces not lining up properly, such as walls not connecting or gaps in the ground. Here's a screenshot from the opening area of Paper Mario:

Here's how the game looks on a console: Here's how the game looks using GLideN64:

The gaps in the walls are present when emulated but not on the console itself and show up in varying severity in different situations all throughout the game. Some are mild and can easily be missed, others (like this) are incredibly obvious - especially in game.

Setting GLideN64 to render at a high multiple of native resolution can help mask the problem in some of the minor situations, but not all (and not in the example above). Similarly, some of the minor situations only appear at non-native resolution.

[gonetz]

It is known issue. Sometimes it can be fixed with switch to native resolution. I don't know general solution for this problem.

[ghost]

I thought the solution was to rewrite the triangle drawing code to use proper fixed point code.

[theboy181]

I like the sound of that @mudlord!

[ghost]

Doing so would mean a rewrite in many parts. IIRC texel addressing in shaders was also a concern, to use fixedpoint/integer math for texture coordinates, using the same integer based math as the RDP/angrylion.

I'm seriously wondering if coming out of retirement for me and working on N64/GBA emulation again is a good idea. Seems some things could be helped on.

[Gillou68310]

[ghost]

[Kidboy17]

This is probably the same issue that I was experiencing on Zelda OoT. Many places in the game have these misalignments or seams. Jabu-Jabu's belly is very noticeable because it creates these yellow lines.

[oddMLan]

@Gillou68310 Why did you feel the need to mock/ridicule someone over wanting to come back to the N64 scene? Serious question. I don't think there's anything to gain out of being snarky, and most certainly brings nothing of value to the ongoing discussion.

[ghost]

@Gillou68310 :middle_finger:

Seriously.

You Mupen people are all alike. Don't know when someone wants to help or not, so you shit on them instead for having the gall of wanting to help.

You have a really good day now, you'hear?

[Gillou68310]

Well I guess there's a misunderstanding here, I was actually encouraging @mudlord to come out of retirement, nothing else. I had no intention to mock or ridicule anyone. I apologize if I did so.

[LegendOfDragoon]

It's easy to misinterpret posts like these :smile: . The picture shows a guy laughing, so it does looks kinda mean. I like to give people the benefit of the doubt, so I didn't jump to any conclusion.

Lol at downvoting.

@mudlord I think you should try if that's what you think you will have fun doing. Do you, my man. You have my support :smiley: !

I thought the solution was to rewrite the triangle drawing code to use proper fixed point code.

Indeed this may be able to fix these sort of problems. I think this should be high priority..

[gonetz]

I thought the solution was to rewrite the triangle drawing code to use proper fixed point code.

Indeed this may be able to fix these sort of problems. I think this should be high priority..

I would like to see at least a proof of concept.

[ghost]

Funny, what makes you think I would work with you?

[loganmc10]

Lol real classy...

[oddMLan]

I had no intention to mock or ridicule anyone. I apologize if I did so.

@Gillou68310 Huh... I jumped the gun too quick on you, sorry. But to be fair that reaction pic was a little confusing.

Funny, what makes you think I would work with you?

Then what are you doing here?

[vadosnaprimer]

This just gets more confusing every day.

[ghost]

@gonetz

thought I already shown you some triangle code from cen64, which was done using opengl.

@loganmc10

Wow, you are one to talk..................................................................................

@oddMLan

Was going to help out, but then found out @loganmc10 was here all the time, and decided to say "fuck you all" and not bother help out at all now.

I am tired of @loganmc10 's constant bullshit. Its highly hypocritical to say something is classy, when they do exactly the same gutter sniping.

I wish I worked on my own HLE video plugin years ago.

[vadosnaprimer]

@mudlord Please don't get upset by occasional nonsense, I'm sure you know the amount of people that actually need this fix is hundred times bigger than that of bandwagon jumpers. I'm not frequent here (and I might look like a bandwagon jumper myself), but in the place I come from we use this new plugin super intensely (tasvideos 4K encodes). It's the most encoder-friendly, because it has the least bugs of all the n64 plugins. Yet at various resolutions it has this misalignment problem that has to be fixed for every game in one way or another (this is what OP has been doing for months he's spent on his encodes: because by fixing all the errors he makes encodes look better than in the emulator, and that takes tons of manual effort).

[ghost]

Its not being occasional, its been constant and this is the straw that broke the camel's back.

[vadosnaprimer]

Why should this end so terribly D:

[Jj0YzL5nvJ]

At this rate, we are more likely to see a good and enhanced PS5 emulator than one on the N64 emulation side T.T

[AmbientMalice]

Funny, what makes you think I would work with you?

It would prove you're not an emotionally fragile crybaby who talks a big talk but never finishes projects because he gets super angry about criticism on /emugen/ EVERY... SINGLE... TIME.

[ghost]

@AmbientMalice

:middle_finger:

Is that the best you can fucking do? You can do better insults than that. At least accuse me of murder or something.

[theboy181]

@mudlord Now you have to take that challenge! I think ambient thinks insulting you will get you to release something. Kinda puts you in a hard spot if you pay attention to stuff like that, dosn't it?

[ghost]

@theboy181

Will you kindly shut the fuck up? https://pastebin.com/gEztBW0H

@AmbientMalice is just an insufferable ignoramus like the rest of them.

[LegendOfDragoon]

I would like to see at least a proof of concept.

I may give it a try some day. First, I need to figure out a good way to dump dlists so I can do some extensive debugging. Currently, I mostly rely on save states, cheat engine, and visual studio debugger, but I think dumping and replaying dlists would be nice, especially for profiling.

I wish I worked on my own HLE video plugin years ago.

It's not too late :smile: . Are you interested in working together?

[gonetz]

@mudlord

thought I already shown you some triangle code from cen64, which was done using opengl.

Proof of concept is a hardware render, which can work in HD resolution without "3D Object Misalignment" issues. All videos of cen64 I saw were low-res.

[Gillou68310]

But to be fair that reaction pic was a little confusing.

@oddMLan yes I see it now, next time I'll be more carefull before taking the first picture on google.

[SwooshyCueb]

I have been noticing this issue a little in DK64 as well

[Kidboy17]

I have been noticing this issue a little in DK64 as well

I believe this issue is in most, if not all of the 64 games. Some games are much more noticeable than others.

[fallaha56]

is this an integer math VS floating point thingy?

would the Dolphin code be any help here? i think they had a similar problem https://dolphin-emu.org/blog/2014/03/15/pixel-processing-problems/

asking for a friend...

[gonetz]

is this an integer math VS floating point thingy?

My be. This hypothesis is not proved or disproved yet.

[ghost]

well if it means anything, did some debugging with Whomps fortress.

At no point where those bad edges were visible, the triangle functions (which in turn call ziggy's low level edgewalker -> GL triangle code) were hit.

[gonetz]

At no point where those bad edges were visible, the triangle functions (which in turn call ziggy's low level edgewalker -> GL triangle code) were hit.

Could you explain what does it mean?

[ghost]

Means simply, I checked the area where those bad poly edges are shown. At no point was the triangle functions in use. Rectangle ones on the other hand....

[gonetz]

If you are talking about misaligned polygons in Paper Mario, they are definitely triangles, not rects:

[ghost]

I tried whomps fortress and running through a debugger, no tris there, maybe i missed a function to be breakpointed.?

[gonetz]

May be. I did not check whomps fortress with debugger. As I remember, SM64 has misaligned polygons in 3D objects. Rects are not used to build 3D models. My screen shots of Paper Mario are from Glide64 build-in debugger. You may find all information abut these triangles: colors, vertices coordinates, rendering mode etc. You may enable debug log and find information about display list commands for these triangles in the log. Polygons on the screen shots have no common/adjacent vertices. Any mistake in vertex coordinates may lead to misalignment. Can the problem be solved with fixed point calculations? Only practice can prove for sure. For example, all calculations for vertices have been performed with fixed point math in LLE mode, because RSP plugin does all the work. These LLE vertices converted to OpenGL ones with float coordinates, but it is final stage. GLideN64 has the same misalignment issue at this place with LLE and in native resolution. May be rendering mechanism of RDP designed to fill the gaps between adjacent polygons?

[fallaha56]

is fixed-point math OpenGL3 or 4?

[ghost]

OGL3.

[vadosnaprimer]

Overall, this is likely caused by the secret internet for robots thingy, right? http://0.30000000000000004.com/

As in, non-fixed precision boils down to no precision whatsoever?

[oddMLan]

If anyone needs it, here's a savestate where you can see the misalignment issue showcased in OP's picture. Savestate was made for PJ64 2.4.x. I think it should be compatible with Mupen64plus, too. Paper Mario (U).pj.zip

[oddMLan]

Proof of concept is a hardware render, which can work in HD resolution without "3D Object Misalignment" issues. All videos of cen64 I saw were low-res.

Even at native resolution, the seams are still visible. However, if you use the savestate above with Angrylion, you'll briefly see the color buffer with the seams and they'll inmediately dissapear after. VI filters disabled.

[AmbientMalice]

Back in 2008, MooglyGuy wrote a blog post (unfortunately the images are missing now) which reads:

In renderer news, it would appear that I’ve found the source of the cracks between triangles in MESS. Anyone who has attempted to run Mario Kart 64 in MESS has noticed the seams that are present in almost every scene

The reason for this behavior is that the software rasterizer originally written by Ville Linde (currently MIA) does not handle fractional coordinates. At all.

The end result of this is that triangles have their Y coordinates “snapped” to a full-pixel boundary, while the X coordinates remain the same, resulting in uneven boundaries between triangles that would otherwise be aligned.

This can only happen because of the funky way in which the N64 stores its coordinates. As opposed to virtually any rational system such as the Playstation or any modern 3D hardware, the N64 specifies its vertices in low edge / middle edge / high edge / slope form. This was clearly done to save processing time, as the edge-walking hardware on the RDP can take in the data virtually unmodified, but it can easily cause rasterization glitches if a person isn’t careful.

The RDP’s edge-walking hardware very likely operates in the following sequence:

Load High-X and Middle-X into XLeft and XRight
Load High-Slope and Middle-Slope into StepLeft and StepRight
Load High-Y into Y index
Rasterize 0.25-pixel scanline from XLeft to XRight
Add 0.25*StepLeft to XLeft
Add 0.25*StepRight to XEnd
Increment Y index by 0.25
If Y is less than Middle-Y, go to Step 4
Load Low-X into XRight
Load Low-Slope into StepRight
Rasterize 0.25-pixel scanline from XLeft to XRight
Add 0.25*StepLeft to XLeft
Add 0.25*StepRight to XEnd
Increment Y index by 0.25
If Y is less than Low-Y, go to Step 11
Done

It’s a fairly long list of steps, but it’s also fairly simple. Pretty much any software rasterizer functions that way, it usually translates X/Y triplets into that format.

You’ll notice that alpha-blended triangles are overly “bold”. This is an outgrowth of the fact that each scanline is redrawn up to four times. A proper fix for this will be to emulate coverage, which is a bit of a daunting task. Wish me luck.

https://web.archive.org/web/20080511210741/http://moogle-tech.com:80/blog/?paged=2

I'm not entirely sure whether this is the same issue because the screens are missing, unfortunately.

[ghost]

.....,and ziggy's code was based on Ville Lindes.,

[rsn8887]

I just came across this issue by simply playing Mario64 level 2.

In Mario64, the gaps between the brown floor polygons show up as bright white lines where the sky is shining through. It looks pretty bad. It looks especially bad in native res, because the gaps are relatively large then. The gaps are only 1 pixel wide, but in native res one pixel is quite large. So there are just these white lines everywhere on the floor.

I thought Mario64 should pretty much play perfectly at the moment. It seems any user will encounter this issue immediately upon playing Mario64 for longer than 5 minutes. Am I missing something?

[theboy181]

Your missing the fact that VI filters are unemployed by this pluging

[gonetz]

Am I missing something?

Gaps between polygons is a common problem for graphics plugins with hardware rendering. It can appear in any game, even in Mario 64.

[rsn8887]

Thanks for the clear answer @gonetz . So it doesn't have anything to do with missing VI filters. I guess there's no option or hack I can use currently to get rid of the gaps?

[gonetz]

The only option to get rid of the gaps is to use graphics plugin with software rendering.