ShootersForever.com Forum Index

GoldenEye 007 Nintendo 64 Community, GoldenEye X, Nintendo 64 Games Discussion
GoldenEye Cheats, GoldenEye X Codes, Tips, Help, Nintendo 64 Gaming Community


Viewport, RSP limitations and Modelling requirements

 
Post new topic   Reply to topic    ShootersForever.com Forum Index -> Q-Lab Hacking Department
View previous topic :: View next topic  
Trevor
007
007


Joined: 15 Jan 2010
Posts: 926
Location: UK, Friockheim OS:Win11-Dev PerfectGold:Latest

 PostPosted: Sat Dec 29, 2018 4:00 am    Post subject: Viewport, RSP limitations and Modelling requirements Reply with quote Back to top

Viewport, RSP limitations and Modelling requirements

Original Misconception

For a long time it was considered that the BG was scaled down for storage and then scaled back up at runtime for reasons unknown.
BG is stored as integer unit vertices so perhaps scale was something to do with that and so we built this picture


Raw Data for Dam


Misconceived Level.Scale purpose


Misconceived Visible radius


Misconceived Visible radius from different positions on map

As you can see, Dam poses many problems, the biggest being that both it and your visible radius exceed the 65,535 RSP Fixed point box that which nothing can escape.

Recap:
    The RSP is a 32bit Fixed point machine that uses the format s15.16, that is – the biggest integer it can represent is 32,767 and the smallest is -32,768.
    What is always forgotten about is the 16bits of fraction able to represent 1/65535 of a unit.
    For example; if a unit is 1meter, the RSP can represent a fraction of 0.000015m or 15 microns


This is where Level.Scale truly plays its magic and also shows that the N64 can actually have very large worlds if you used 1Km as your unit (I’m looking at you Rogue Squadron – could have had bigger maps or at least a non-bent trench-run.)



Revelation about Level.Scale

Eventually some thought was done and the realisation dawned that prevented GE from breaking the rules.

Scale has no “Units” so long as ALL objects use the same scale and ratios remain constant.

In other words, if you expect a door to be just taller than you, and a box to be half your height, you can be ANY size – if the door is still a little taller and the box is still half your height you will believe you are the correct size.

To put some number on this;
Bond is 1.8m tall.
He is represented as 1800 in model and scaled by 0.1 bringing him down to 180 - we assume this unit is a cm.
A doorway is 2.1m, but Dams doorways are 48 units

We used to divide 48 by Level.Scale (this case 0.2) to get 2.1m for a door. Bond and Dam were now using the same cm unit with the Bond to Door ratio of 1:1.16

However, if you instead scale bond by 0.2, the door remains 48 and Bond becomes 36, at first you think this is wrong, how can bond be 36cm, however check the ratio, its 1:1.16 meaning the “unit” is irrelevant so long as everything else uses the same scale and ratios match.

The bullet hole of 2cm now uses the fractional part of the RSP and becomes 0.399994 units which on-screen has the apparent size of 2cm Again, the ratio of Bond to Bullet is 90:1 whether Bond is 180 and bullet is 2 OR Bond is 36 and bullet is 0.399994.


Real Size of Dam in RSP


Actual Scaling


Scaled Visible radius

With that realisation, the visible radius now always fits the RSP box too – however…. Here too lies a misconception…



The World revolves around YOU

Most people think of Moving within a world like below


Misconceived Visible radius from different areas of map

However, YOU are always at (0,0,0) and the world revolves around you.
This seems strange but its how computers generate images. The computer first position objects within the world, then it positions you, then it moves everything so that you are back at the (0,0,0) and you are facing (0,0,0) then it renders the screen. Every time you move or turn, the computer does the opposite and renders the screen with you back at (0,0,0)


Actual Visible radius at different places on map

The Highlighted BG shows the effect of you turning to look at the first guard tower at the start of the level.


One further technical note, while this document describes “Visible Radii” the above image shows that the computer can actually simplify its work by using a flat plane.

So the image above would actually look like this to the RSP – anything outside the triangle is clipped.





Modelling Requirements - When problems occur


Level too large (at least 1 vertex exceeds +/-32,768)

Problems occur when you exceed the 65535 box as shown above, and one of 2 things can happen: The console will crash or vertices will be clipped – causing textures to “wobble” on surfaces or triangles to shoot across the whole level.

To prevent this all vertices must remain within the 65535 box at all times. First I will quote the SDK:
    … If numbers in the final coordinate system (or intermediate coordinate systems) are too big, then the geometry of objects can be distorted, textures can shift erratically, and clipping can fail to work correctly. In order to avoid these problems keep the following notes in mind:
    1. No coordinate component (x, y, z, or w) should ever be greater than 32767.0 or less than -32767.0
    2. The difference between any 2 vertices of a triangle should not have any components greater than 32767.0
    3. The sum of the difference of w's of any 2 vertices plus the sum of the differences of any of the x, y, or z components should be less than 32767.0. In other words for any 2 vertices in a triangle, v1=(x1,y1,z1,w1), and v2=(x2,y2,z2,w2), these should all be true:

    abs (x1 - x2) + abs (w1 - w2) lt 32767.0
    abs (y1 - y2) + abs (w1 - w2) lt 32767.0
    abs (z1 - z2) + abs (w1 - w2) lt 32767.0

    One way to check this is to take the largest vertices that you have and run them through the largest matrices you are likely to have, then check to make sure that these conditions are met.
    A recommended way of avoiding trouble is to never allow any component to get larger than 16383.0 or smaller than -16383.0. If you want to keep all components of coordinate value within the range of value above, ensure that M*S+T lt 16383.0. M, S and T are as follows:

    M the largest component (x, y, or z) of the largest model in your database.

    S The largest scale (i.e., number in the upper 3 rows of the matrix) in the matrix made up of the concatenation of the largest modeling matrix, the largest LookAt matrix, and the largest Perspective matrix you will use.

    T the largest translation (i.e., number in the 4th row of the matrix) in the matrix made up of the concatenation of the largest modeling matrix, the largest LookAt matrix, and the largest Perspective matrix you will use.

    If you experience textures wobbling or shifting over a surface, clipping not working correctly, or geometry behaving erratically, this is a good place to check.


What all this means is clear now, as shown in the previous section, everything moves around you, so the maximum co-ordinate of any vertex in the BG is simply +/-16,383 OR the furthest vertex from the furthest place you can stand must be lt= +/-32768 (meaning you can exceed 16,383 if you cannot walk to such a place that such a vertex would exceed +/-32.787

eg, If dam was mirrored it still fits because you cannot walk out to the edge as shown - meaning all vertices are within 32,767 of you at all times.

Now Rares scaling makes sense, they made a BG to within 16,000 and scale bond to fit standard ratios.

PD changes this slightly. Because no BG exceeds 32,768 they removed Scaling and instead use fixed Units where each integer unit = 1cm
This is why Dam will never fit in PD, it is simply FAR too big without the ability to scale away from cm units.

One other point to mention, z-buffer looses accuracy with long view radii.
The z-buffer uses 18bit precision but if you have a draw distance utilising all 16bits integer, the z-buffer will fight among surfaces that are less than 0.25 units apart.
To take dams scale for example, this would mean fighting between 2 surfaces that appear gt 1.5cm (Equivalent to the thickness of the Alarm meaning the Alarm would fight with the wall)

The shorter the view radius the more fractional numbers can be assigned the z-buffer allowing it to correctly order surfaces at shorter distances apart.

For further information on Visibility, Fog, Object Bounding Volumes and Fade-in the doc is available here http://www.shootersforever.com/forums_message_boards/viewtopic.php?t=6991


Trev

PDF Version
 
View user's profile Send private message
Sogun
General
General


Joined: 15 Dec 2010
Posts: 659
Location: Valencia, Spain

 PostPosted: Sat Dec 29, 2018 11:58 am    Post subject: Reply with quote Back to top

Thanks for the technical explanations Trevor.

Background scaling is the very first thing that is missing in the Perfect Dark engine from GoldenEye. It was very useful in the first game and made the Dam level possible. Why would they remove it?


I'm going to talk about my own experiences without being technical:

When modelling, the basic rules are:
1 unit = 1 cm for backgrounds
1 unit = 1 mm for props
This is "true" because it's understood that backgrounds should be 1.0 scale and props 10.0 scale. And you can't have decimals, so something like 1.8 units will be rounded to 2.0 units by the Editor when importing.

As you mentioned, nothing can exceed +/- 32767 units or vertices will be clipped. That means a background can't be larger than 655x655 meters (that feels small) and a prop can't be bigger than 65 x 65 meters (who would need something that big? lol).

But if you change the scale that's when magic begins and levels like Dam, my Holiday Island map or GF64 Alps can be done.
Of course, you have to sacrifice something. In this case is something I call "detail resolution":
-When you are at 1.0 scale, you can't make something smaller than 1 cm. Therefore your detail resolution is 1 cm.
-When you are at 0.5 scale your model can double size to 1310x1310 meters, but your detail resolution becomes 2 cm and you can't make anything smaller than 2 cm in that model.
-If you use 0.2 scale your model can reach 3276x3276 meters, but your detail resolution is 5 cm.

It really is no biggie for backgrounds, since the smaller things you are going to have are probably 10 to 20 cm wide walls (so even a 0.1 or 0.05 scale would be fine).
For everything else you'll use props and it follows the same concept. At 10.0 scale your detail resolution is 1mm and that should be enough.

Can we use any scale combination without any issues? Honestly I'm not sure. I have experienced some weird behaviours but I think it has more to do with very big triangles than having a background scale <1.0.
The thing I experienced is that when the camera is still you can notice how these big triangles shake slightly.


About "drawing distance" or what Trevor named "Visible radius". As he mentioned and showed in and image it isn't a radius but more like a triangle. So the "drawing distance" value is actually the lenght of the apothem in that triangle (or the perpendicular distance between the player and the plane) and the real drawing distance gets bigger at the borders of the screen.
I first noticed this when I was doing my Kakariko map. I was adjusting drawing distance and fog intensity and noticed that I couldn't see Death Mountain if looking at it directly (at the center of the screen) but if I turned around a little then it would appear at the edge of the screen.


Talking about drawing distance and fog. They also have their own scale called "Visibility".
Some sky values are affected by Visibility such as Blend Mult and Far fog which are the most important. You could rise those values and keep Visibility at 1.0 or lower Visibility and keep tha values.
Going too crazy will create issues. Visbility shouldn't be too low or will crash levels within seconds (happened to me with the Blue Resort map in multiplayer) and Far fog shouldn't exceed something like 30,000 or 32,000 units or you will have severe graphical issues. Emulators don't suffer from these issues, though.
Modifying Visibility really comes in handy when you are working in a map with no sky (so no values to edit) and you aren't OK with the drawing distance (specially in 4P multiplayer).


One thing that I couldn't understand is how portals and props are placed in the level. These do have decimals in their XYZ position values while models can't. I guess these are the 16bits of fraction able to represent 1/65535 of a unit that Trevor mentioned.


Another thing that never crossed my mind is how different scales and far fog values could affect Z-fighting. I think this is less noticeable on emulator but definitely an issue on consoles.
My only way to mitigate Z-fighting was to lower the Blend mult value. Blend mult affects fogs in the way it's distribiuted, so a high value will make the fog to concentrate in the distance and a low value will make fog very evident at close range. But when blend Mult is too high you'll see Z-fighting in props. GF64 Alps was very tricky because of that.
 
View user's profile Send private message Visit poster's website
Trevor
007
007


Joined: 15 Jan 2010
Posts: 926
Location: UK, Friockheim OS:Win11-Dev PerfectGold:Latest

 PostPosted: Sat Dec 29, 2018 4:20 pm    Post subject: Reply with quote Back to top

Sogun wrote:

Background scaling is the very first thing that is missing in the Perfect Dark engine from GoldenEye. It was very useful in the first game and made the Dam level possible. Why would they remove it?


To paraphrase the SDK, Matrix Multiplication is fast but not free.

Sogun wrote:

Of course, you have to sacrifice something. In this case is something I call "detail resolution":


Good point, I forgot to mention that.

Sogun wrote:

Can we use any scale combination without any issues?

Yes Smile
Perhaps my doc should clarify that when I mention "Same scale and ratios" I don't mean the scale of each object individually, but rather relative scales between objects hence ratio is the better description.
Bond should always have a ratio of 1:1.16 to a door
Bond should always have a ratio of 90:1 to a bullet hole etc


Sogun wrote:
what Trevor named "Visible radius".

Yes, radius is also part of the misconception related to moving in a world as opposed to a world moving to you.
With a fixed position and a moving world, it can be seen that the radius can be swapped for a quicker plane (hence the term "Far Clip Plane")
But for the purposes of the doc, using "Far Clip Plane" and showing circles would have not made sense.

Sogun wrote:

Talking about drawing distance and fog. They also have their own scale called "Visibility".

I am in the process of updating that doc located here

The Z buffer also has a bias which I failed to mention here.
It reserves more accuracy for near surfaces and looses accuracy on far surfaces.
So that 18bit value of 0.25 is more like an exponential growth from 0.05 to 2.0 across the length of visibility (Far Clip Plane - Near Clip Plane)




Trev
_________________
 
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    ShootersForever.com Forum Index -> Q-Lab Hacking Department All times are GMT - 8 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Cobalt 2.0 BB theme/template by Jakob Persson.
Copyright 2002-2004 Jakob Persson


Powered by BB 01, 02 BB Group

 


Please Visit My Other Sites: GoldenEyeForever.com | GrandTheftAutoForever.com

Got kids? Check out my Dora The Explorer site with games and coloring pages!

Our forums feature Nintendo 64 games, GoldenEye 007 N64 New Maps and Missions, GoldenEye Cheats, N64 Emulator, Gameshark, GoldenEye Multiplayer and more!

[ Privacy Policy ]