Jump to content
  • 0

F3DEX2 Lighting


Strati
 Share

Question

18 answers to this question

Recommended Posts

  • 0

I think it's the combiner... not sure how to fix that, but if you post it, maybe it could lead to something useful. I can try digging something up.

 

You can always post a snippet of the portion where the problem display list is.

 

(Also, those are some fine damn sexy trees btw)

Link to comment
Share on other sites

  • 0

To disable lighting altogether, you can remove the lighting flag from the GeometryMode command(s) in the display list, although I'm not sure how that'll look in-game. You could also try and compare the commands in the original tree's leaves' display list(s) to those in your tree's, and see in what way ex. the commands GeometryMode, SetOtherMode_L, SetOtherMode_H and SetCombine differ - selectively taking certain commands/parameters from the original and overwriting their equivalents in your tree's data might help.

Link to comment
Share on other sites

  • 0

To disable lighting altogether, you can remove the lighting flag from the GeometryMode command(s) in the display list, although I'm not sure how that'll look in-game. You could also try and compare the commands in the original tree's leaves' display list(s) to those in your tree's, and see in what way ex. the commands GeometryMode, SetOtherMode_L, SetOtherMode_H and SetCombine differ - selectively taking certain commands/parameters from the original and overwriting their equivalents in your tree's data might help.

Doesn't look like the lighting mode to me... I think it might be the F5 command that is the combiner which takes on environment effects.

Link to comment
Share on other sites

  • 0

I was forced into learning F3DEX2 commands to make small fixes to the Model2N64 Import, namely the backface culling flag.
Basically, I'm doing what xdan suggested: taking pieces from here and there, throwing different values at different places expecting a reaction.

So far I have a small lead on the GeometryMode flags from reverse engineering parsing codes. If I got these flags right, disabling lighting didn't change anything.
For a matter of assurance: D9 Fx FF FF 00 0y 00 00; x => 0100 = lighting bit; y => 0010 = lighting bit.

Combiner modes are something I haven't delved in yet. It looked rather complicated from the outside, that's why I came here for help.

Here's the DL by Airikita's request. By the way, the F5 command is SET_TILE (I had to mess with texture mirroring).
 

E7 00 00 00 00 00 00 00 E3 00 0F 00 00 00 00 00 
D7 00 00 02 FF FF FF FF D9 F3 FB FF 00 00 00 00 
D9 FF FF FF 00 03 00 00 E3 00 10 01 00 00 80 00 
FD 10 00 00 06 00 95 D0 E8 00 00 00 00 00 00 00 
F5 00 01 00 07 00 00 00 E6 00 00 00 00 00 00 00 
F0 00 00 00 07 03 C0 00 E7 00 00 00 00 00 00 00 
FD 50 00 00 06 00 8D D0 F5 50 00 00 07 01 80 60 
E6 00 00 00 00 00 00 00 F3 00 00 00 07 3F F2 00 
E7 00 00 00 00 00 00 00 F5 40 08 00 00 01 81 60 
F2 00 00 00 00 0F C0 FC E2 00 00 1C C8 10 30 3C 
FC 12 7E 03 FF FF F3 F8 FA 00 00 00 AA FF 44 FF 
01 01 40 28 06 00 95 F0 06 00 02 04 00 06 08 0A 
06 00 04 0C 00 0E 10 12 06 0E 14 10 00 16 18 1A 
06 16 1C 18 00 1E 20 22 06 06 24 08 00 1E 22 26 
DF 00 00 00 00 00 00 00

Try using Hylian Toolbox. By Default, it doesn't have weird "shading".

 
Lol. Sometimes I think you are a Hylian Toolbox Bot in disguise.

I even tried HT before, but when it prompts a save dialog after importing, the supposed new file is never created for me.

Finally, this might be wrong, but HT also uses Model2N64 to import .obj models, thus giving the same display list output, no?

 

Very nice! Geez, that's almost the kind of tree I need for my Oracle of Ages remake I started.

 
If this "almost" ever evolves to "exactly", feel free to ask.

Link to comment
Share on other sites

  • 0

(I'm gonna flip my shit soon, I'm getting so pissed off at bullshit today)

 

Well, F5 is using 07, it's using environment effects from the current scene, hence your lighting problem... I'll grab a combiner from another source for you, and maybe that will help. Brb.

 

EDIT:

Try these:

F5 70 00 00 07 09 C1 50 (first F5)

F5 60 04 00 00 09 C1 50 (second F5)

 

Replace your other F5 with this one to test. It uses 07 just the same, but the effects can be to your liking. You can try to change it, but it might result in a crash because 07 is linked to a special code.

 

(Also, F5 is tile properties, not combiner, my bad... anyways, try it out)

 

(Might be the wrong thing, but I'll double check)

 

Also, experiment with this F3 separately (over your current F3):

F3 00 00 00 07 3F F4 00

Link to comment
Share on other sites

  • 0

F5 and F3 are SetTile and LoadBlock, both of which have nothing to do with shading or lighting as such - texture loading, yes, but that's it.

 

As for GeometryMode, here's documentation (F3DEX v1.x, but close enough) and in the spoiler are the flags as taken from the SDK's gbi.h (F3DEX_GBI_2 is F3DEX2, so ex. G_CULL_FRONT is 0x00000200).

 

Sorry that I'm not much of a help right now, I'm about to go to bed finally (2:00 am)

 

 

 

/*
 * flags for G_SETGEOMETRYMODE
 * (this rendering state is maintained in RSP)
 *
 * DO NOT USE THE LOW 8 BITS OF GEOMETRYMODE:
 * The weird bit-ordering is for the micro-code: the lower byte
 * can be OR'd in with G_TRI_SHADE (11001100) to construct 
 * the triangle command directly. Don't break it...
 *
 * DO NOT USE THE HIGH 8 BITS OF GEOMETRYMODE:
 * The high byte is OR'd with 0x703 to form the clip code mask.
 * If it is set to 0x04, this will cause near clipping to occur.
 * If it is zero, near clipping will not occur.
 *
 * Further explanation:
 * G_SHADE is necessary in order to see the color that you passed
 * down with the vertex. If G_SHADE isn't set, you need to set the DP
 * appropriately and use primcolor to see anything.
 *
 * G_SHADING_SMOOTH enabled means use all 3 colors of the triangle.
 * If it is not set, then do 'flat shading', where only one vertex color 
 * is used (and all 3 vertices are set to that same color by the ucode)
 * See the man page for gSP1Triangle().
 *
 */
#define G_ZBUFFER		0x00000001
#define G_SHADE			0x00000004	/* enable Gouraud interp */
/* rest of low byte reserved for setup ucode */
#ifdef	F3DEX_GBI_2
# define G_TEXTURE_ENABLE	0x00000000	/* Ignored               */
# define G_SHADING_SMOOTH	0x00200000	/* flat or smooth shaded */
# define G_CULL_FRONT		0x00000200
# define G_CULL_BACK		0x00000400
# define G_CULL_BOTH		0x00000600	/* To make code cleaner */
#else
# define G_TEXTURE_ENABLE	0x00000002	/* Microcode use only */
# define G_SHADING_SMOOTH	0x00000200	/* flat or smooth shaded */
# define G_CULL_FRONT		0x00001000
# define G_CULL_BACK		0x00002000
# define G_CULL_BOTH		0x00003000	/* To make code cleaner */
#endif
#define G_FOG			0x00010000
#define G_LIGHTING		0x00020000
#define G_TEXTURE_GEN		0x00040000
#define G_TEXTURE_GEN_LINEAR	0x00080000
#define G_LOD			0x00100000	/* NOT IMPLEMENTED */
#if	(defined(F3DEX_GBI)||defined(F3DLP_GBI))
# define G_CLIPPING		0x00800000
#else
# define G_CLIPPING		0x00000000
#endif

 

Link to comment
Share on other sites

  • 0

Yeah, I wasn't hoping on them... plus it seems like the combiner is fine as-is.

 

I think I was thinking of these ones:

0xE2 F3DEX2_SETOTHERMODE_L Sets other attributes (blending)

0xE3 F3DEX2_SETOTHERMODE_H Sets other attributes (combiner)

 

The ones I brought up with an existing display list are:

E3 00 10 01 00 00 00 00

E2 00 00 1C C8 10 4A 50

 

Sorry for the misleading attempts, I'm frustrated tonight and not thinking clearly.

 

 

I'm currently viewing object_wood02.zobj at 0x90 if you want to take a look yourself.

Link to comment
Share on other sites

  • 0

I was forced into learning F3DEX2 commands to make small fixes to the Model2N64 Import, namely the backface culling flag. 

Lol. Sometimes I think you are a Hylian Toolbox Bot in disguise.

 

I even tried HT before, but when it prompts a save dialog after importing, the supposed new file is never created for me.

 

Finally, this might be wrong, but HT also uses Model2N64 to import .obj models, thus giving the same display list output, no?

I'm sorry you think I'm a Hylian Toolbox bot, but I really support is as a modding tool. And at the moment it does use Model2N64 as the converter but as it goes through the process Hylian Toolbox takes over and changes some things, though soon, it is planned to have an integrated cross-platform converter. And I had never heard that problem you're having, so if you just brush it to the side the program doesn't seem to have a chance to get better. :/

Link to comment
Share on other sites

  • 0

I'm sorry you think I'm a Hylian Toolbox bot, but I really support is as a modding tool. And at the moment it does use Model2N64 as the converter but as it goes through the process Hylian Toolbox takes over and changes some things, though soon, it is planned to have an integrated cross-platform converter. And I had never heard that problem you're having, so if you just brush it to the side the program doesn't seem to have a chance to get better. :/

I won't say it's a bad idea, just that there are existing display lists to clean an existing issue. Re-importing doesn't grow the learning process with hacking, but if it comes to it, I agree with the Hylian Toolbox.

Link to comment
Share on other sites

  • 0

For now. I'll have to settle with what I've got - is not THAT bad. Just gotta figure out how to change colors dinamically - as it appears to happen with the standard tree cones.
Thanks for the help.

@ SanguinettiMods:
That was just a joke, no worries.
It explains itself that by expecting HT to output exactly as Model2N64, I could brush it off at my own loss, since it seemed to be working to everyone else all this time - as you just kind of confirmed, saying you never heard this specific problem before.
 
If there is a chance HT will fix the lighting, I'll have to ask someone else to try importing the tree model's .obj file.
 
 
EDIT:
 
Found the right instruction! Thanks SoulofDeity!
 
http://glitchkill.proboards.com/thread/5930/most-difficult-f3d-instruction-cracked

Link to comment
Share on other sites

  • 0

You know you could just have the crossover of the leaves in the middle share vertices and enable smooth shading, right?

 

Now that you mention it, it makes a lot of sense. I was aiming at less polygons, so I decided to just have long faces with textures mirrored instead of a central axis with intersecting vertices.

I'll confess that "enabling smooth shading" is yet a mystery to me. Might have been one of the bits amidst command D9, but I can't really tell.

 

 

 

Yes, the combiner is a challenge... although yours still looked similar to one I pulled up, I guess that worked then?

 

In a way, yes. Rather by randomly plugging numbers in RAM than by logic.

 

 

Now the aim is to get a better coloring. Using grayscale + primary color makes those leaves look like a lettuce.

Hopefully there should be a way to have the code induced color as just a softer hue over a semi-desatured texture.

 

Headaches incoming...

Link to comment
Share on other sites

 Share

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.