-
Notifications
You must be signed in to change notification settings - Fork 73
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
First round of F3DEX3 changes for basic features #258
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
few comments here and there, OoT exports properly after fixing the OOTModel
call from oot_level_classes.py, the import is broken though
most of these comments are either missing type hints where I saw them (probably more?) and few things f-strings can do better imo, the code itself looks good otherwise
fast64_internal/f3d/f3d_material.py
Outdated
@@ -3820,7 +4084,15 @@ def mat_register(): | |||
items=enumF3D, | |||
default="F3D", | |||
) | |||
bpy.types.Scene.isHWv1 = bpy.props.BoolProperty(name="Is Hardware v1?") | |||
bpy.types.Scene.isHWv1 = bpy.props.BoolProperty( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is this really needed? I thought hardware v1 was really really uncommon, I'm just wondering if we should keep support for it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's only a couple SGI Indy N64 devkits owned by collectors which have V1 chips. (Actually not sure if the chips in them are V1 or not.) No retail consoles are V1 and even good emulators will not support V1 display lists. The fast64 support for V1 appears to be because it was in the GBI when that was ported to Python. I'm happy to remove it from the codebase if you are okay with that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd like to hear more fast64 opinions on this but yeah I think we should make it deprecated
return [vertexBuffer.index(v) for v in tri] | ||
|
||
t = 0 | ||
while t < len(triangles): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not a huge fan of while
s in general because of the infinite loop risk if you're not careful, but that's just my own tastes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The index can be incremented by one or two in a particular pass. Editing the index variable in a for loop in Python is frowned upon.
fast64_internal/utility.py
Outdated
x2, y2 = x ^ 0x7F, y ^ 0x7F # 7F - x, 7F - y | ||
z = z ^ 0x7F # = 7F - x - y |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
are those comments dead code?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, it is explaining what operation we're actually trying to do. Doing 0x7F - value on the RSP would take an extra instruction and use an extra temporary register compared to value ^ 0x7F. Clarified the comments.
Where is the f3dex3 repo? Where are its changes (notably, the gbi changes) documented? |
@Dragorn421 Development on the microcode and on fast64 must occur in parallel for three reasons:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
seems good, haven't tested again yet but I'll do it soon!
fast64_internal/f3d/f3d_gbi.py
Outdated
"LIGHT_8": 8, | ||
} | ||
# 1-8 for F3DEX2 etc., 1-10 for F3DEX3 | ||
lightIndex = {"LIGHT_" + str(n): n for n in range(1, 11)} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this could use f-strings
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed
the import still seems broken (tried to import kokiri forest) Traceback (most recent call last):
File "C:\Users\Yanis\AppData\Roaming\Blender Foundation\Blender\3.6\scripts\addons\fast64-F3DEX3Basics\fast64_internal\oot\scene\operators.py", line 118, in execute
run_ops_without_view_layer_update(parseSceneFunc)
File "C:\Users\Yanis\AppData\Roaming\Blender Foundation\Blender\3.6\scripts\addons\fast64-F3DEX3Basics\fast64_internal\oot\scene\operators.py", line 33, in run_ops_without_view_layer_update
func()
File "C:\Users\Yanis\AppData\Roaming\Blender Foundation\Blender\3.6\scripts\addons\fast64-F3DEX3Basics\fast64_internal\oot\scene\operators.py", line 41, in parseSceneFunc
parseScene(settings, settings.option)
File "C:\Users\Yanis\AppData\Roaming\Blender Foundation\Blender\3.6\scripts\addons\fast64-F3DEX3Basics\fast64_internal\oot\oot_level_parser.py", line 271, in parseScene
sceneObj = parseSceneCommands(sceneName, None, None, sceneCommandsName, sceneData, f3dContext, 0, sharedSceneData)
File "C:\Users\Yanis\AppData\Roaming\Blender Foundation\Blender\3.6\scripts\addons\fast64-F3DEX3Basics\fast64_internal\oot\oot_level_parser.py", line 327, in parseSceneCommands
roomObjs = parseRoomList(sceneObj, sceneData, roomListName, f3dContext, sharedSceneData, headerIndex)
File "C:\Users\Yanis\AppData\Roaming\Blender Foundation\Blender\3.6\scripts\addons\fast64-F3DEX3Basics\fast64_internal\oot\oot_level_parser.py", line 430, in parseRoomList
roomObj = parseRoomCommands(
File "C:\Users\Yanis\AppData\Roaming\Blender Foundation\Blender\3.6\scripts\addons\fast64-F3DEX3Basics\fast64_internal\oot\oot_level_parser.py", line 521, in parseRoomCommands
parseMeshHeader(roomObj, sceneData, meshHeaderName, f3dContext, sharedSceneData)
File "C:\Users\Yanis\AppData\Roaming\Blender Foundation\Blender\3.6\scripts\addons\fast64-F3DEX3Basics\fast64_internal\oot\oot_level_parser.py", line 555, in parseMeshHeader
parseMeshList(roomObj, sceneData, meshListName, roomShapeIndex, f3dContext, sharedSceneData)
File "C:\Users\Yanis\AppData\Roaming\Blender Foundation\Blender\3.6\scripts\addons\fast64-F3DEX3Basics\fast64_internal\oot\oot_level_parser.py", line 649, in parseMeshList
meshObj = importMeshC(
File "C:\Users\Yanis\AppData\Roaming\Blender Foundation\Blender\3.6\scripts\addons\fast64-F3DEX3Basics\fast64_internal\f3d\f3d_parser.py", line 2255, in importMeshC
parseF3D(data, name, transformMatrix, name, name, "oot", drawLayer, f3dContext, True)
File "C:\Users\Yanis\AppData\Roaming\Blender Foundation\Blender\3.6\scripts\addons\fast64-F3DEX3Basics\fast64_internal\f3d\f3d_parser.py", line 1903, in parseF3D
f3dContext.processCommands(dlData, processedDLName, dlCommands)
File "C:\Users\Yanis\AppData\Roaming\Blender Foundation\Blender\3.6\scripts\addons\fast64-F3DEX3Basics\fast64_internal\f3d\f3d_parser.py", line 1536, in processCommands
parseVertexData(dlData, vertexDataName, self)
File "C:\Users\Yanis\AppData\Roaming\Blender Foundation\Blender\3.6\scripts\addons\fast64-F3DEX3Basics\fast64_internal\f3d\f3d_parser.py", line 1959, in parseVertexData
vertexData = [
File "C:\Users\Yanis\AppData\Roaming\Blender Foundation\Blender\3.6\scripts\addons\fast64-F3DEX3Basics\fast64_internal\f3d\f3d_parser.py", line 1973, in <listcomp>
math_eval(match.group(10), f3d),
IndexError: no such group |
Fixed import issues, OoT scene import now works correctly. Also a mesh with materials with vertex colors only, normals only, and both / packed normals exports and re-imports with colors and normals preserved correctly. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just a small thing I noticed, now I'll try on Blender to see if I get any issues
mat.rdp_settings.g_attroffset_st_enable = bitFlags & self.f3d.G_ATTROFFSET_ST_ENABLE != 0 | ||
mat.rdp_settings.g_attroffset_z_enable = bitFlags & self.f3d.G_ATTROFFSET_Z_ENABLE != 0 | ||
mat.rdp_settings.g_packed_normals = bitFlags & self.f3d.G_PACKED_NORMALS != 0 | ||
mat.rdp_settings.g_lighttoalpha = bitFlags & self.f3d.G_LIGHTTOALPHA != 0 | ||
mat.rdp_settings.g_ambocclusion = bitFlags & self.f3d.G_AMBOCCLUSION != 0 | ||
mat.rdp_settings.g_fresnel = bitFlags & self.f3d.G_FRESNEL != 0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if those values are only 0 or 1 would it be worth to use true/false? unless you plan on adding more possible values in the future
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The objects on the left are bool
s (actually BoolProperty
s), on the right it's checking if bits in an integer are set. This is the same way all the existing geometry mode properties are set.
everything seems fine! |
Most of these changes were made months ago, but finally now re-synced with current fast64.
Additions for F3DEX3:
SPAmbOcclusion
,SPFresnel
,SPAttrOffsetST
,SPAttrOffsetZ
Changes affecting non-F3DEX3 fast64:
get_F3D_GBI
. The new code is simpler and should be (slightly) faster.What is NOT included in this PR: