Color Material and Lighting limitations, VCL tooling, and general interest to revival of this project

[meisei4]

I am trying to start studying this project and have made an experimental branch https://github.com/meisei4/ps2gl/blob/experimentation_only (not planning to request merge, I just have it for studying so far) and I am finding some issues with Color behavior quite a lot.

I know that from this Issue: #11, the fix has been to add to the examples ColorMaterial enabling and Lighting as well, but I am trying to figure out how to get things working without Lighting or Material.

---

Lesson05 Behavior

I was able to get lesson05 working to what I think is expected to show up (but it still requiring lighting and material though):

Current main branch behavior:

Where two things happen:

1. The Colors for the quad based cube are not set at a per face basis like they seem to be intended to (instead they are only attached per vertex, where unlike the Normals and Texcoords, there is no filling of the per vertex colors via any GetCurColor (something i will bring up later, and have tried to reconcile with CurMatColor, and CurGeomColor in some experiments i have added <- this is likely only introducing more complexity though compared to how i think OpenGL would expect this to work).

   • Example of how Texcoords does it:
     https://github.com/ps2dev/ps2gl/blob/master/src/base_renderer.cpp#L167

2. After enough time the rotations result in the per vertex colors completely fading to black because they depend on the lighting.

   • A hack to avoid this is by always updating the lighting direction to be facing the Normals as they rotate (documented in comments where this happens, and how i understand it to work:https://github.com/meisei4/ps2gl/blob/experimentation_only/src/gmanager.cpp#L50)

---

Experiments fork

Here is my fork’s result after updating the two issues to allow for updating the Colors at a per vertex basis (still trying to figure out if this should be on Material or if it’s better as an actual Geometry attribute... it seems to cause issues with other tests like lesson02).

Code changes involve:

• Adding the directional light update to face rotating Normals:
  https://github.com/meisei4/ps2gl/blob/experimentation_only/examples/nehe/lesson05/lesson5.cpp#L50
• In the ImmgManager, trying to correct the way Colors are being added, such that it follows the pattern of Texcoords and Normals more closely (from my understanding this is how OpenGL would be doing it, rather than only storing Colors as a Material attribute...):
  https://github.com/meisei4/ps2gl/blob/experimentation_only/src/immgmanager.cpp#L123

---

intended Examples

I have also added two examples that I am trying to get working:

• PVC lit:
  https://github.com/meisei4/ps2gl/blob/experimentation_only/examples/box/lit_pvc_box.cpp

• Corresponding unlit version:
  https://github.com/meisei4/ps2gl/blob/experimentation_only/examples/box/unlit_pvc_box.cpp

The unlit version relies on a very poor attempt at working backwards from general_pvc_diff_tri_vcl.vsm to make this microcode:
https://github.com/meisei4/ps2gl/blob/experimentation_only/vu1/proper_nolights_pv_color_vcl.vsm

That aims to get the RGBA data to just pass through without any lighting instructions. I spent a little bit too much time on this and kind of gave up because I am hoping I can be pointed towards better VCL tools... (or even any vsm examples that cover the most simple way to diagnose what registers are set up for RGBA when its a pass through and then also just how kInputQPerV works with the ordering of lanes when XferColors, XferNormals and everything is being passed

As you can see in the result, I am able to get Vertex data through, it is just that the Registers for loading in the correct RGBA data seem to be scrambling or reading from the wrong lanes or something and alignment is all wrong.

---

Contribution Interest

I would really like to help contribute to this project in light of the potential it has for raylib interfacing, but I am having trouble with the approach here and whether or not VU1 should be how this GL layer is done.

I will provide some links of the resources I have found just for documenting myself below (some I have tried, e.g. VCL Linux compiler, but having no luck with getting it to work, and it seems like many ps2sdk libraries no longer use VU microcode to draw things anymore).

Resources

very dense ps2 documentation: * http://lukasz.dk/playstation-2-programming/an-introduction-to-ps2dev/

• Potential reference for bypassing VU1 in a renderer abstraction: https://github.com/h4570/tyra
• VU1 instruction manual: http://lukasz.dk/files/vu-instruction-manual.pdf
  (even the core ps2sdk draw examples do not demonstrate any simple PVC non-lighting, non-textured rendering... * https://github.com/ps2dev/ps2sdk/tree/master/ee/draw/samples
  lua abstraction layer for potential inspiration * https://github.com/DanielSant0s/Enceladus

---

I hope to come back to this, but I believe that I need to take a break and am hoping for potential review of the locations in the code I am trying to experiment with, to get any insight as to what the main design is intended to be here and what is the best way to begin reviving this project.

[rickgaiser]

Can you run the same OpenGL code examples on your PC as well? Having a reference output greatly helped me.

but I am having trouble with the approach here and whether or not VU1 should be how this GL layer is done.

That's the whole point of this library. It´s how sony intended it to be. Using th VU´s will make the ps2 a very fast 3D machine (from that time). But I get that programming the VU's is very challenging becouse of a lack of good tools. Doing things on the EE will be more simple, but a lot slower.

I will provide some links of the resources I have found just for documenting myself below (some I have tried, e.g. VCL Linux compiler, but having no luck with getting it to work, and it seems like many ps2sdk libraries no longer use VU microcode to draw things anymore).

You´ll need at gasp and vcl. I got it working some time ago: 055fa98
I can provide you the binaries I think (have to search for them).

I hope to come back to this, but I believe that I need to take a break and am hoping for potential review of the locations in the code I am trying to experiment with, to get any insight as to what the main design is intended to be here and what is the best way to begin reviving this project.

I think the way rendermanager selects the best renderer is really nice. If a specialized renderer is not available, a more generic (slower) one will be used. So for this specific case I think we can do 2 things:

• Make a specialized renderer with per-vertex-colors, but without lighting (very fast)
• Use a generic renderer with per-vertex-colors, and with lighting (slower)

I think fixing the fallback should be fairly easy (no change to VU programs). And is needed anyway. With the default lights and the default material, I think the scene should look exactly the same as without lighting.
As a second step a more optimized renderer can be created, but that will be a lot more difficult as you'll also need a new design for data placement inside the VU1.

Here's my WIP investigation into the current "linear" data structure:

// VU1 total data size = 1024x 128bit = 16KiB

// Size: 1x 128bit
typedef struct {
    tU32 dir;    // x
    tU32 point;  // y
    tU32 spot;   // z
    tU32 dummy;  // w
} tLightPtr;

// Size: 6x 128bit
typedef struct {
    tU128 Ambient;
    tU128 Diffuse;
    tU128 Specular;
    tU128 Pos;
    tU128 Spot;
    tU128 AttenCoeff;
} tLight;

// Size: 76x 128bit
struct SVU1Context {
	// Lights
	tLightPtr LightPtr[8];   // Size =  8x 128bit
	tLight    Light[8];      // Size = 48x 128bit
	tU128     GlobalAmbient;
	// Material
	tU128     MatEmission;
	tU128     MatAmbient;
	tU128     MatDiffuse;
	tU128     MatSpecular;
	// Transform
	tU128     VertexXfrm[4];
	tU128     FixedVertToEye;
	tU128     ObjToWorldXfrmTrans[4];
	tU128     WorldToObjXfrm[4];
	// Other
	tU128     GifTag;
	tU128     ClipInfo;
};

// Size: 1024x 128bit (aka 16KiB)
// All linear renderers use the same structure
// Further detailed below
struct SVU1MemoryLinearRaw {
	// Context
	struct SVU1Context ctx;
	// Double buffered IO
	tU128 vertex_buffer_a_in [(1024-76)/4];
	tU128 vertex_buffer_a_out[(1024-76)/4];
	tU128 vertex_buffer_b_in [(1024-76)/4];
	tU128 vertex_buffer_b_out[(1024-76)/4];
};

// Size: 3x 128bit
struct SVertexOut { // VU1 -> GS
	tU128 texcoord; // STQ
	tU128 color;    // RGBA
	tU128 vertex;   // XYZ
};

// Size: 3x 128bit
struct SVertexIn { // EE -> VU1
	tU128 vertex;
	tU128 normal;
	tU128 texcoord;
};

struct SVU1BufferIOLinear {
	// Inputs, EE -> VU1
	// Total input size = (1024-76)/4 = 237x 128bit
	tU128 num_vertices;
	tU128 strip_adcs[4];
	struct SVertexIn vb_in[77];
	tU128 spare_in[1]
	
	// Outputs, VU1 -> GS
	// Total output size = (1024-76)/4 = 237x 128bit
	tU128 giftag;
	struct SVertexOut vb_out[78];
	tU128 spare_out[2]
}

// Size: 1024x 128bit (aka 16KiB)
struct SVU1MemoryLinear {
	// Context
	struct SVU1Context ctx;
	// Double buffered IO
	struct SVU1BufferIOLinear bufa;
	struct SVU1BufferIOLinear bufb;
};

// Size: 4x 128bit
// PV: Per-Vertex colors
// Fits 59x in input buffer (leaving 1x 128bit unused)
struct SVertexInPV { // EE -> VU1
	tU128 vertex;
	tU128 normal;
	tU128 texcoord;
	tU128 color;
};

[meisei4]

@rickgaiser Thank you so much for the reply! It has relieved me greatly, I also agree with the need for a proper OpenGL reference to compare with. In fact, currently that is what I will be working on with a raylib example that I want have also serve as a simple PS2GL example integration. So currently i am trying to simultaneously study some raylib side things where i have some OPENGL 1.1 tests that i am working on where I am hoping to get an open PR solved before I return back to this.

My goal is to have a raylib example (one that i will be proposing for introduction into the actual core raylib examples suite) that can help me with these fundamental features.

I will take a look at the code you provided, I have only been using the Linear renderer with the VU it seems like,

I think fixing the fallback should be fairly easy (no change to VU programs). And is needed anyway. With the default lights and the default material, I think the scene should look exactly the same as without lighting.

Alright I can take a look at this! and just wanted to say its really relieving that you have expressed that VU is also an important purpose of this library, so i can accept that and focus on trying to learn that incrementally. It would be helpful if you could point me in the way of vcl tooling as you metnioned, I might be able to take another crack at the official online hosted one on the playstation for linux site. But if you have any tips for getting vcl working it would be really appreciated. Otherwise I can begin looking at a fallback EE based slow renderer just to see how that is working for common ps2sdk usages.

thanks again! I hope to return to this once i have gotten some more raylib side things situated

[rickgaiser]

Running vcl is going to become more and more difficult in time, becouse it depends on:

• i386 architecture
• libstdc++5

I've created a docker image that contains these things + the latest vcl itself.

Dockerfile:

FROM i386/debian:11.11
COPY vcl /usr/bin/vcl
RUN apt update
RUN apt install libstdc++5

I've pushed the image to dockerhub so you can start using it. Try this:

docker run --rm ps2max/vcl vcl -h

If you get the vcl info then you know it works.

gasp is another issue. I have the linux amd64 binary if you need it. Perhaps I can also put it in the ps2max/dev or ps2max/toolchain docker image.

[meisei4]

I was able to get gasp and vcl working well on my linux machine today!

although I did not try the docker, and instead decided to study the official docs/User Manual of vcl I found on the official playstation for linux website) and so i have begun a more official attempt at contributing to ps2gl: #27

I will continue this discussion over there i think, including potentially many mistakes, but i am going to be trying to make it clear how i am testing all of this especially now that i have a working https://github.com/raylib4Consoles/raylib4PlayStation2 environment that also will allow me to side by side test a raylib ps2gl backend with a raylib Opengl1.1 backend (to finally get some more concrete behavioral comparisons with OpenGL expected behavior.

I will also try to take a look at the fall backs aswell as i go.

thanks again for the responses! I think i have a lot more confidence in trying to contribute!