[F3D] Add material bleeding to FMesh GfxLists #186

jesusyoshi54 · 2022-11-26T21:40:15Z

This commit will allow users to export mesh gfx lists with material bleeding. What this will do is remove unnecessary DL cmds inside the gfxlist, and make all the DL cmds part of one gfx list. This option is added as a checkbox in the global f3d settings.

This commit also adjusts texture scrolls for sm64 so that they work with mat bleeding, and fixes a bug where not setting a texture still exported a tile scroll for that material (which would cause UB in game).

This commit has been tested to successfully export multiple test sm64 levels and has been verified to work on console. No testing has been done for OOT.

…global F3D panel settings

…inline material, and use a material name of the mesh plus the offset of the material DL inside the inline mesh Gfx. Also fixed a bug where tile scrolls for tiles not set would still export, resulting in UB behavior

…cmds get bled

…m fModel for inheritance of inline property, cleaned up and clarified some comments

YoshiMilkman · 2022-11-28T17:28:00Z

Currently getting compilation errors when trying to export my object geolayout with the material bleed checkbox turned on. The export works perfectly fine with it off.

jesusyoshi54 · 2022-11-28T17:58:17Z

Ok I understand, there is currently an issue with the geo layout writer not knowing which DLs to use when multiple layers are written. I will fix this in an upcoming commit.

…h.draw objects interfering with DL referencing

jesusyoshi54 · 2022-11-28T18:56:51Z

Naming issue has been resolved. Geo layouts should now properly reference the correct bled display list.
Please test with the latest commit.

YoshiMilkman · 2022-11-28T19:03:17Z

It compiles now, thank you.

kurethedead

I tried testing a map export, which fails to compile. There are a couple other errors as well - I think this should have been tested more before being PR'd. However, the main issue I have is organization. I've mentioned this before, but this PR adds a bunch of to_c_inline functions which does display list building when it should only be doing c exporting, adding a lot of unnecessary code in the process. In FMesh.bleed(), instead of saving data to a bleed_gfx class, the final inlined DL can just be built there and saved over FMesh.draw. FMesh can then use FMesh.inline to determine which data to export in FMesh.to_c(). This removes the need for to_c_inline functions, and also the various other inline checks that are done when handling FMesh writing.

The tile scrolling bleed is a bit hacky, although thats more due to the original tile scrolling being inflexible. I have some issue with how that's organized as well, although that's a whole other thing. Instead, bleed() could save an OrderedDict[FMaterial, tileCommandIndices] to FMesh. FMesh.to_c_vertex_scroll can then be refactored so that it executes code that processes this dict along side the fully inlined DL if inline is true. This would remove the need to create new FMaterials.

I've made a couple comments that might not be relevant anymore if to_c_inline is removed. A couple of the errors here are also irrelevant in this case.

fast64_internal/f3d/f3d_gbi.py

jesusyoshi54 · 2022-11-30T13:13:39Z

I will address the naming, large mat and cull issues in a commit. Also if possible I would like to know what caused the compilation issue if it was something other than vtx culling.

kurethedead · 2022-11-30T17:37:39Z

I'm not sure, vtx culling was as far as I got. I also forgot to mention, I have a tile scrolling issue: I'm trying to export a mesh with two materials, one with s/t tile scrolling and another with s tile scrolling, but only one of the material's tile scrolling code is being exported.

fast64_internal/f3d/f3d_gbi.py

… added more consistency with inline checks, made fMesh inline exporting act from FMesh.draw instead of constructing from individual gfx components, vtx culling now works with inline materials

jesusyoshi54 · 2022-12-01T02:13:48Z

I have fixed the issues with culling exporting and tile scrolling and improved the names for a lot of variables.
I have also fixed some inconsistencies with cmds that were ignored when added to fMesh.draw while creating materials for large textures.
With these changes I was also able to clean up some no longer useful code.

Now exporting is done by making use of the fMesh.draw object, and it is appended to using the triGroup.bleed data after bleeding for that triGroup is finished. I also use this time to add in the tile scroll indices (or at least where to start searching for them). The theory of operation is still mostly the same, it is just organized differently to take the work out of the to_c_inline method and put it into the bleed method.

I have also written a new tile scrolling method for inline materials. This method is basically the same as the original, but it uses data from the triGroup to select the correct GfxList, and to find the tile indices.

I was not able to completely get rid of the to_c_inline method as triGroup writing is still out of the order needed for inline material drawing.

As far as the decision to keep triGroup.bleed when it could probably be deprecated by this point, it is mostly me planning for the future with additional modding support. I believe keeping the bled gfx available for further post processing or mutation may end up being very convenient for certain types of exports, and for additional searching for dynamic DLs beyond sm64 tile scrolls.

kurethedead

To me it seems like the to_c_inline can be removed, and instead FMesh.inline can be used inside to_c to get the desired result. I'm still not seeing the point in saving bled data intermediately in FTriGroup, as everything can still be done in bleed(). If you want to add additional functionality that uses that info, then you can add callbacks inside bleed() that are implemented by game specific classes which pass in the desired display lists.

fast64_internal/f3d/f3d_gbi.py

fast64_internal/f3d/f3d_writer.py

fast64_internal/f3d/f3d_gbi.py

jesusyoshi54 · 2022-12-01T12:29:26Z

I can add an onBleedEnd method and store the bleed prop but I use the bleed to hold the tile scroll information, so it needs to be stored somewhere.
It is much easier to hold the information in the triGroup over the FMesh.draw list because I can parse the individual tile for the cmds I need, and I am not required to commit to identifying only tile scroll indices in cases where other types of scrolls are made in the future

kurethedead · 2022-12-01T17:24:03Z

I was thinking of a callback that would be added inside the loop iterating over triGroups, not at the end. I don't see why the bleed data would be needed after bleeding is done, since the final output of bleed is to merge all the bled display lists together. Also, editing that inlined DL would invalidate tile indices. I still disagree with the location of tile scrolling indices (its a property of a specific display list first before being a property of a material), but you can just store that in the triGroup itself. Also, just for future reference I don't think its a good idea to continue using the method of modifying static display lists for dynamic behaviour - we should find a way to use dynamic DLs or pointers in static DLs.

jesusyoshi54 · 2022-12-01T18:50:41Z

Im not sure what the issue is with modifying Static data is as its something that's always been done for tile scrolls. It isn't like the DLs are literally labelled as Static in the output file.
If I were to use DL jumps or pointers in static DLs it would defeat the purpose of making an inline FMesh draw in the first place.

jesusyoshi54 · 2022-12-01T19:12:35Z

Also more on why store the bled list, it is because I don't want to store set tile scroll indices to the inline DL, but a pointer to the material start.

This makes the code more flexible for other dynamic properties added in the future. If desired, there could easily be changes made to add dynamic palettes, or dynamic texture loads using the most of the same code, because the inlined material is easily accessible.

Either way I need to store the indices, and the DL to parse, for the tile scroll code to work unless I supercede all of that and do it in bleed, but why would I do tile scrolling inside of the bleed method, instead of give the access to variables so that I can use the (mostly) existing tile scroll code.

kurethedead · 2022-12-01T20:18:45Z

Like I said, you can add a callback inside the triGroup loop in bleed() to do this. Whats the purpose of halfway calculating the index in bleed() and then saving intermediate display lists to finish calculating it again in tileScrollInlineMaterialToC() when you can just calculate it all at once in bleed()? Spreading index management through multiple locations just makes things confusing.

jesusyoshi54 · 2022-12-01T21:16:56Z

If I remove the triGroup.bleed property I would have to do the full parsing of tile scroll indices inside the FMesh.bleed function.
I really do not like the idea of doing that because it goes against the established process for non bled gfx and does multiple operations all at once when it really should just be building the bled GfxLists.
If there was something like SM64_fMesh that used the callback to calculate tile scroll indices it would make sense, but otherwise I am adding sm64 specific code to the bleed operation to do this tile scroll, so I want to have that code in the GfxFormatter which requires the bled DL, and the location of the bled DL.

kurethedead · 2023-02-14T03:13:01Z

This is just pushing the complexity down to lower levels where it makes things more cluttered. In the future we could change it if we need it, but I'm not seeing in what case you would want to access these DLs after inlining them. The whole idea of inlining implies that it should be done once the higher level abstractions of materials/meshes aren't needed anymore.

…ized logic throughout code so that it works with those changes

jesusyoshi54 · 2023-02-14T23:42:32Z

Ok I made the changes.
Now writing is determined by if the GfxList.commands is None or not, instead of if the inline bool exists.
I also took all the GbiMacro bleed funcs and put them in the BleedGraphics class.

Basically all the inline checks are removed throughout the repo.
fMaterial is not split up into mat_only_DL and texture_DLs, and then when the material is done being wrote to, they get combined into one under the fMaterial.material gfx list.

There are a few misc changes in here besides bleeding, such as annotations or changing some properties in GbiMacros to be more consistent (all tile props are called "tile" instead of some being "tile" and others being "t")
I also applied black to f3d_gbi.py

kurethedead

The latest changes are an improvement. I made a couple more comments about decoupling bleeding from the f3d_gbi classes. I also think that at this point all the bleed code in f3d_gbi.py should be moved into its own file.

fast64_internal/f3d/f3d_gbi.py

kurethedead · 2023-02-15T02:37:46Z

fast64_internal/f3d/f3d_gbi.py

+        if not fModel.inline:
+            return


Changes for removing inline. You can actually throw an error here as well if you want to make it easier for developers to know that this is a necessary condition for bleeding.

Suggested change

if not fModel.inline:

return

if not fModel.matWriteMethod != GfxMatWriteMethod.WriteAll:

return

kurethedead · 2023-02-15T02:40:20Z

fast64_internal/sm64/sm64_f3d_writer.py

-    def __init__(self, f3dType, isHWv1, name, DLFormat):
-        FModel.__init__(self, f3dType, isHWv1, name, DLFormat, GfxMatWriteMethod.WriteDifferingAndRevert)
+    def __init__(self, f3dType, isHWv1, name, DLFormat, inline = False):
+        FModel.__init__(self, f3dType, isHWv1, name, DLFormat, GfxMatWriteMethod.WriteDifferingAndRevert, inline = inline)


Something like this in order to remove inline from FModel:

Suggested change

FModel.__init__(self, f3dType, isHWv1, name, DLFormat, GfxMatWriteMethod.WriteDifferingAndRevert, inline = inline)

FModel.__init__(self, f3dType, isHWv1, name, DLFormat, GfxMatWriteMethod.WriteAll if inline else GfxMatWriteMethod.WriteDifferingAndRevert)

kurethedead · 2023-02-15T02:43:00Z

fast64_internal/f3d/f3d_gbi.py

+        name: str,
+        DLFormat: "DLFormat",
+        matWriteMethod: GfxMatWriteMethod,
+        inline=False,


inline should be removed, with the code creating the model being responsible for setting the correct GfxMatWriteMethod.

kurethedead · 2023-02-15T04:00:43Z

fast64_internal/sm64/sm64_geolayout_classes.py

+        if not fModel.inline:
+            return


This happens multiple times, but with inline removed these checks should be moved outside these classes.

jesusyoshi54 · 2023-02-15T12:13:32Z

You commented it in several places so Ill just make a general reply.
The mat write method is only set to WriteDifferentAndRevert explicitly for sm64. For OOT it is explicitly set to WriteAll, and for generic f3d exports it is based on your drop down selection of a scene prop.
With this in mind I believe using that in lieu of an inline bool is not proper, as we shouldn't force users into using this write method based on they choose to have materials are written.

kurethedead · 2023-02-15T18:09:43Z

Well the overriding is happening either way regardless, the only difference is the location where it happens. Aside from separation of concerns between bleeding and exporting, I wasn't a huge fan of overriding the write method in the init function anyway, its kind of a code gotcha. At least with this change if you pass a write method into init, you know thats what the write method is going to be.

… is overridden from inside FModel to its initialization calls

jesusyoshi54 · 2023-02-15T23:08:25Z

Ok I changed the construction of the FModel classes so that the passed mat write method is what gets used.
I also moved the bleed class to its own file, and made some of the changes recommended to the bleed class itself.
I also did some slight renaming of variables inside the bleed class, but ultimately nothing has functionally changed.

kurethedead

The inline variables/checks should be removed from FModel and any subclasses of it. The inline checks happening at the beginning of the bleed functions can be moved right outside of those functions. SM64Model can have the write method passed to it instead of inline.

…nd subclasses explicit from passed arguments

jesusyoshi54 · 2023-02-17T21:29:17Z

Ok I removed all uses of inline as a property and made it a bool either passed to a function, or used as a ternary for mat write methods.
SM64Model now also has matWriteMethod passed to it as a constructing argument.

kurethedead

The gfx scroll inline arguments can be removed as well.

kurethedead

Whoops, forgot my attached comment.

kurethedead · 2023-02-17T23:25:42Z

fast64_internal/f3d/f3d_gbi.py

        data = CScrollData()
-        if not self.inline:
+        if not inline:
            for _, (fMaterial, _) in self.materials.items():
                fMaterial: FMaterial
                data.append(gfxFormatter.gfxScrollToC(fMaterial.material, self.f3d))


Both fMaterial.material and fMesh.draw can be handled (works for either bleed on/off) as long as fMaterial.material is None checked, letting you remove inline from this.

…le scroll materials

kurethedead · 2023-02-18T00:49:39Z

I made a PR to this branch to fix a minor naming duplicate issue with scrolling variables. However, I'm still getting an issue where textures aren't showing up with bleed enabled. This seems to happen if exporting with microcode version F3D, regardless if the repo itself is F3D or F3DEX2. When exporting F3DEX2 the issue is gone.

Fixed duplicate scroll variable names

jesusyoshi54 · 2023-02-18T01:07:34Z

I can't replicate this issue. Could you post the exported mesh DL during the F3D export?

kurethedead · 2023-02-18T01:11:20Z

Gfx bob_dl_Plane_001_mesh_layer_1[] = {
	gsDPPipeSync(),
	gsDPSetCombineLERP(TEXEL0, 0, SHADE, 0, 0, 0, 0, ENVIRONMENT, TEXEL0, 0, SHADE, 0, 0, 0, 0, ENVIRONMENT),
	gsSPSetOtherMode(G_SETOTHERMODE_H, 4, 20, G_AD_NOISE | G_CD_MAGICSQ | G_CK_NONE | G_TC_FILT | G_TF_BILERP | G_TL_TILE | G_TD_CLAMP | G_TP_PERSP | G_CYC_1CYCLE | G_PM_1PRIMITIVE),
	gsSPSetOtherMode(G_SETOTHERMODE_L, 0, 3, G_AC_NONE | G_ZS_PIXEL),
	gsSPSetLights1(bob_dl_f3dlite_material_005_lights),
	gsDPSetTextureLUT(G_TT_RGBA16),
	gsDPSetTextureImage(G_IM_FMT_RGBA, G_IM_SIZ_16b, 1, bob_dl_eyes_closed_ci8_ci8_pal_rgba16),
	gsDPSetTile(0, 0, 0, 256, 7, 0, G_TX_WRAP | G_TX_NOMIRROR, 0, 0, G_TX_WRAP | G_TX_NOMIRROR, 0, 0),
	gsDPLoadTLUTCmd(7, 91),
	gsDPLoadSync(),
	gsDPSetTextureImage(G_IM_FMT_CI, G_IM_SIZ_8b_LOAD_BLOCK, 1, bob_dl_eyes_closed_ci8_ci8),
	gsDPSetTile(G_IM_FMT_CI, G_IM_SIZ_8b_LOAD_BLOCK, 0, 0, 7, 0, G_TX_WRAP | G_TX_NOMIRROR, 5, 0, G_TX_WRAP | G_TX_NOMIRROR, 6, 0),
	gsDPLoadBlock(7, 0, 0, 1023, 256),
	gsDPSetTile(G_IM_FMT_CI, G_IM_SIZ_8b, 8, 0, 0, 0, G_TX_WRAP | G_TX_NOMIRROR, 5, 0, G_TX_WRAP | G_TX_NOMIRROR, 6, 0),
	gsDPSetTileSize(0, 0, 0, 252, 124),
	gsSPVertex(bob_dl_Plane_001_mesh_layer_1_vtx_0 + 0, 4, 0),
	gsSP1Triangle(0, 1, 2, 0),
	gsSP1Triangle(0, 2, 3, 0),
	gsDPPipeSync(),
	gsDPSetCombineLERP(TEXEL0, 0, TEXEL1, 0, 0, 0, 0, 1, COMBINED, 0, SHADE, 0, 0, 0, 0, 1),
	gsSPSetOtherMode(G_SETOTHERMODE_H, 4, 20, G_AD_NOISE | G_CD_MAGICSQ | G_CK_NONE | G_TC_FILT | G_TF_BILERP | G_TL_TILE | G_TD_CLAMP | G_TP_PERSP | G_CYC_2CYCLE | G_PM_1PRIMITIVE),
	gsSPSetOtherMode(G_SETOTHERMODE_L, 0, 32, G_AC_NONE | G_ZS_PIXEL | G_RM_PASS | G_RM_AA_ZB_OPA_SURF2),
	gsSPSetLights1(bob_dl_f3dlite_material_001_layer1_lights),
	gsDPSetTextureLUT(G_TT_NONE),
	gsDPSetTextureImage(G_IM_FMT_RGBA, G_IM_SIZ_16b_LOAD_BLOCK, 1, bob_dl_b_rgba16),
	gsDPSetTile(G_IM_FMT_RGBA, G_IM_SIZ_16b_LOAD_BLOCK, 0, 0, 7, 0, G_TX_WRAP | G_TX_NOMIRROR, 5, 0, G_TX_WRAP | G_TX_NOMIRROR, 5, 0),
	gsDPLoadBlock(7, 0, 0, 1023, 256),
	gsDPSetTile(G_IM_FMT_RGBA, G_IM_SIZ_16b, 8, 0, 0, 0, G_TX_WRAP | G_TX_NOMIRROR, 5, 0, G_TX_WRAP | G_TX_NOMIRROR, 5, 0),
	gsDPSetTileSize(0, 0, 0, 124, 124),
	gsDPSetTextureLUT(G_TT_NONE),
	gsDPSetTextureImage(G_IM_FMT_RGBA, G_IM_SIZ_16b_LOAD_BLOCK, 1, bob_dl_a_rgba16),
	gsDPSetTile(G_IM_FMT_RGBA, G_IM_SIZ_16b_LOAD_BLOCK, 0, 256, 6, 0, G_TX_WRAP | G_TX_NOMIRROR, 5, 0, G_TX_WRAP | G_TX_NOMIRROR, 5, 0),
	gsDPLoadBlock(6, 0, 0, 1023, 256),
	gsDPSetTile(G_IM_FMT_RGBA, G_IM_SIZ_16b, 8, 256, 1, 0, G_TX_WRAP | G_TX_NOMIRROR, 5, 0, G_TX_WRAP | G_TX_NOMIRROR, 5, 0),
	gsDPSetTileSize(1, 0, 0, 124, 124),
	gsSPVertex(bob_dl_Plane_001_mesh_layer_1_vtx_1 + 0, 4, 0),
	gsSP1Triangle(0, 1, 2, 0),
	gsSP1Triangle(0, 2, 3, 0),
	gsDPSetCycleType(G_CYC_1CYCLE),
	gsDPSetTextureLUT(G_TT_NONE),
	gsDPSetRenderMode(G_RM_AA_ZB_OPA_SURF, G_RM_AA_ZB_OPA_SURF2),
	gsDPPipeSync(),
	gsSPEndDisplayList(),
};

jesusyoshi54 · 2023-02-18T01:20:27Z

Ok I believe I know what is happening.
Basically during a level geo export, optimizations for the last used material are used so that you don't repeat commands. This does not happen if that mesh uses culling though, because then what the last used material would be depends on your view, and not fully on what the last drawn mesh was. This is why there is a difference between stock F3D and F3DEX and beyond.
So the issue here is that the geo layout is not parsing correctly (I clear the last mat during certain cmds, maybe I missed one), or the last used mat is different than what I recorded it as. Could you post the geo layout for this area?

kurethedead · 2023-02-18T01:29:55Z

const GeoLayout bob_area_1_geo[] = {
	GEO_NODE_START(),
	GEO_OPEN_NODE(),
		GEO_SWITCH_CASE(5, geo_switch_area),
		GEO_OPEN_NODE(),
			GEO_BRANCH(1, bob_dl_Room1_geo),
			GEO_BRANCH(1, bob_dl_Room2_geo),
			GEO_BRANCH(1, bob_dl_Room3_geo),
			GEO_BRANCH(1, bob_dl_Room4_geo),
		GEO_CLOSE_NODE(),
		GEO_TRANSLATE_NODE(LAYER_OPAQUE, 10, -306, 425),
	GEO_CLOSE_NODE(),
	GEO_RETURN(),
};
const GeoLayout bob_dl_Room1_geo[] = {
	GEO_NODE_START(),
	GEO_OPEN_NODE(),
		GEO_TRANSLATE_NODE(LAYER_OPAQUE, 0, -300, 0),
		GEO_OPEN_NODE(),
			GEO_TRANSLATE_NODE_WITH_DL(LAYER_OPAQUE, 0, -714, 0, bob_dl_Plane_mesh_layer_1),
			GEO_TRANSLATE_NODE_WITH_DL(LAYER_OPAQUE, 51, -433, 617, bob_dl_Plane_004_mesh_layer_1),
			GEO_TRANSLATE_NODE_WITH_DL(LAYER_OPAQUE, 896, -714, 180, bob_dl_Plane_008_mesh_layer_1),
		GEO_CLOSE_NODE(),
	GEO_CLOSE_NODE(),
	GEO_RETURN(),
};
const GeoLayout bob_dl_Room2_geo[] = {
	GEO_NODE_START(),
	GEO_OPEN_NODE(),
		GEO_TRANSLATE_NODE(LAYER_OPAQUE, 0, -478, -1323),
		GEO_OPEN_NODE(),
			GEO_TRANSLATE_NODE_WITH_DL(LAYER_OPAQUE, 0, -714, 0, bob_dl_Plane_001_mesh_layer_1),
			GEO_TRANSLATE_NODE_WITH_DL(LAYER_OPAQUE, -1055, -714, 118, bob_dl_Plane_006_mesh_layer_1),
		GEO_CLOSE_NODE(),
	GEO_CLOSE_NODE(),
	GEO_RETURN(),
};
const GeoLayout bob_dl_Room3_geo[] = {
	GEO_NODE_START(),
	GEO_OPEN_NODE(),
		GEO_TRANSLATE_NODE(LAYER_OPAQUE, 0, -712, -2760),
		GEO_OPEN_NODE(),
			GEO_TRANSLATE_NODE_WITH_DL(LAYER_OPAQUE, 0, -714, 0, bob_dl_Plane_002_mesh_layer_1),
			GEO_TRANSLATE_NODE_WITH_DL(LAYER_OPAQUE, 1110, -714, 142, bob_dl_Plane_005_mesh_layer_1),
		GEO_CLOSE_NODE(),
	GEO_CLOSE_NODE(),
	GEO_RETURN(),
};
const GeoLayout bob_dl_Room4_geo[] = {
	GEO_NODE_START(),
	GEO_OPEN_NODE(),
		GEO_TRANSLATE_NODE(LAYER_OPAQUE, 0, -1057, -4202),
		GEO_OPEN_NODE(),
			GEO_TRANSLATE_NODE_WITH_DL(LAYER_OPAQUE, 0, -714, 0, bob_dl_Plane_003_mesh_layer_1),
			GEO_TRANSLATE_NODE_WITH_DL(LAYER_OPAQUE, -791, -714, -32, bob_dl_Plane_007_mesh_layer_1),
		GEO_CLOSE_NODE(),
	GEO_CLOSE_NODE(),
	GEO_RETURN(),
};
const GeoLayout bob_area_1[] = {
	GEO_NODE_SCREEN_AREA(10, SCREEN_WIDTH/2, SCREEN_HEIGHT/2, SCREEN_WIDTH/2, SCREEN_HEIGHT/2),
	GEO_OPEN_NODE(),
		GEO_ZBUFFER(0),
		GEO_OPEN_NODE(),
			GEO_NODE_ORTHO(100.0000),
			GEO_OPEN_NODE(),
				GEO_BACKGROUND(BACKGROUND_OCEAN_SKY, geo_skybox_main),
			GEO_CLOSE_NODE(),
		GEO_CLOSE_NODE(),
		GEO_ZBUFFER(1),
		GEO_OPEN_NODE(),
			GEO_CAMERA_FRUSTUM_WITH_FUNC(45.0000, 100, 30000, geo_camera_fov),
			GEO_OPEN_NODE(),
				GEO_CAMERA(CAMERA_MODE_8_DIRECTIONS, 0, -348, 0, 0, -348, 0, geo_camera_main),
				GEO_OPEN_NODE(),
					GEO_BRANCH(1, bob_area_1_geo),
					GEO_RENDER_OBJ(),
					GEO_ASM(ENVFX_MODE_NONE, geo_envfx_main),
				GEO_CLOSE_NODE(),
			GEO_CLOSE_NODE(),
		GEO_CLOSE_NODE(),
		GEO_DISPLAY_LIST(LAYER_OPAQUE, bob_dl_material_revert_render_settings),
	GEO_CLOSE_NODE(),
	GEO_END(),
};

…t used materials are kept track of during jump nodes

jesusyoshi54 · 2023-02-18T02:14:56Z

The issue was related to the usage of rooms. I added a boolean to the geo layout bleed function to change how last used materials are bleed in the case where rooms are used.

…eed if culling is used

kurethedead

Seems good to me, I'll merge this soon unless there are any other issues that come up.

scut added 11 commits November 13, 2022 12:30

added material bleeding to FMesh objects via an export option in the …

d3d5823

…global F3D panel settings

Merge branch 'fast64_main' into mat_bleed

1e81b32

removed comments

21a4ba8

optimized and cleaned up mat bleeding setup code, improved which gbi …

4e1a597

…cmds get bled

Merge branch 'fast64_main' into mat_bleed

80a4e4b

Merge branch 'fast64_main' into mat_bleed

e3ab43e

Merge remote-tracking branch 'KCS/fast64_main' into fast64_main

35fe6f5

Merge branch 'fast64_main' into mat_bleed

631a789

Merge branch 'fast64_main' into mat_bleed

0507e0d

made inline a property of fMaterial, made fMaterials be generated fro…

eb62717

…m fModel for inheritance of inline property, cleaned up and clarified some comments

added a comment_name prop to GfxList to prevent renaming of bled fMes…

394ca0a

…h.draw objects interfering with DL referencing

added hashing to gbi base classes

a44b1c8

kurethedead requested changes Nov 30, 2022

View reviewed changes

kurethedead reviewed Nov 30, 2022

View reviewed changes

fast64_internal/f3d/f3d_gbi.py Outdated Show resolved Hide resolved

made tile scroll exporting better in mat_bleeding, renamed variables,…

4543848

… added more consistency with inline checks, made fMesh inline exporting act from FMesh.draw instead of constructing from individual gfx components, vtx culling now works with inline materials

kurethedead requested changes Dec 1, 2022

View reviewed changes

removed inline bool and logic from everything but fModel, and central…

1c9e6d2

…ized logic throughout code so that it works with those changes

kurethedead requested changes Feb 15, 2023

View reviewed changes

separated mat bleed into its own file, changed where mat write method…

dc11a0a

… is overridden from inside FModel to its initialization calls

made render mode reset cmd work gooder and cleaned up on_bleed_end

e602a5e

kurethedead reviewed Feb 17, 2023

View reviewed changes

removed inline prop from fModel, made constructor of fModel classes a…

0b3c8a0

…nd subclasses explicit from passed arguments

removed inline prop from OOTModel classes

297d083

kurethedead reviewed Feb 17, 2023

View reviewed changes

scut and others added 2 commits February 17, 2023 18:34

removed inline argument from FModel.to_c_scroll

266e943

Fixed duplicate scroll variable names with inlined meshes with multip…

9ab0843

…le scroll materials

Merge pull request #1 from kurethedead/scroll_var_naming

db24bb7

Fixed duplicate scroll variable names

fixed bleeding for geo layouts when rooms are used, optimized how las…

22a1c8f

…t used materials are kept track of during jump nodes

scut added 2 commits February 17, 2023 21:26

clear out last used material in last_materials dict for geo layout bl…

bf5a720

…eed if culling is used

added fix to other mode encoding if using f3d_old exporting

ae24838

kurethedead approved these changes Feb 18, 2023

View reviewed changes

kurethedead merged commit f5ffd2b into Fast-64:main Feb 18, 2023

gheskett mentioned this pull request Mar 6, 2023

Mat stack light script breaks fast64 tile scrolling HackerN64/HackerSM64#582

Closed

	FModel.__init__(self, f3dType, isHWv1, name, DLFormat, GfxMatWriteMethod.WriteDifferingAndRevert, inline = inline)
	FModel.__init__(self, f3dType, isHWv1, name, DLFormat, GfxMatWriteMethod.WriteAll if inline else GfxMatWriteMethod.WriteDifferingAndRevert)

[F3D] Add material bleeding to FMesh GfxLists #186

[F3D] Add material bleeding to FMesh GfxLists #186

Conversation

jesusyoshi54 commented Nov 26, 2022

YoshiMilkman commented Nov 28, 2022

jesusyoshi54 commented Nov 28, 2022

jesusyoshi54 commented Nov 28, 2022

YoshiMilkman commented Nov 28, 2022

kurethedead left a comment

Choose a reason for hiding this comment

jesusyoshi54 commented Nov 30, 2022 • edited Loading

kurethedead commented Nov 30, 2022

jesusyoshi54 commented Dec 1, 2022

kurethedead left a comment

Choose a reason for hiding this comment

jesusyoshi54 commented Dec 1, 2022

kurethedead commented Dec 1, 2022

jesusyoshi54 commented Dec 1, 2022 • edited Loading

jesusyoshi54 commented Dec 1, 2022 • edited Loading

kurethedead commented Dec 1, 2022

jesusyoshi54 commented Dec 1, 2022

kurethedead commented Feb 14, 2023

jesusyoshi54 commented Feb 14, 2023

kurethedead left a comment

Choose a reason for hiding this comment

kurethedead Feb 15, 2023

Choose a reason for hiding this comment

kurethedead Feb 15, 2023

Choose a reason for hiding this comment

kurethedead Feb 15, 2023

Choose a reason for hiding this comment

kurethedead Feb 15, 2023

Choose a reason for hiding this comment

jesusyoshi54 commented Feb 15, 2023

kurethedead commented Feb 15, 2023

jesusyoshi54 commented Feb 15, 2023

kurethedead left a comment

Choose a reason for hiding this comment

jesusyoshi54 commented Feb 17, 2023

kurethedead left a comment

Choose a reason for hiding this comment

kurethedead left a comment

Choose a reason for hiding this comment

kurethedead Feb 17, 2023

Choose a reason for hiding this comment

jesusyoshi54 Feb 17, 2023

Choose a reason for hiding this comment

kurethedead commented Feb 18, 2023

jesusyoshi54 commented Feb 18, 2023

kurethedead commented Feb 18, 2023

jesusyoshi54 commented Feb 18, 2023

kurethedead commented Feb 18, 2023

jesusyoshi54 commented Feb 18, 2023

kurethedead left a comment

Choose a reason for hiding this comment

jesusyoshi54 commented Nov 30, 2022 •

edited

Loading

jesusyoshi54 commented Dec 1, 2022 •

edited

Loading

jesusyoshi54 commented Dec 1, 2022 •

edited

Loading