TIM transparency

[masmorra]

Hi! I'm making a "demake" from Oblibion, and started to model the first room.
I'm using PSn00bSDK
So everething is going ok, added some physics (not completed), gourad shading, but there is one thing that I'm not achieving that is simulate a "light shaft" effect:

My goal:

blender_goal.png

This is what I'm achieving:

emulator.png

I tried several options, but I only achieve this partial transparency, and I want it to go from 50% to 100%
Can somebody help me with this?

[nocash]

The first picture looks as simple as drawing an untextured black/gray gouraud-shaded polygon with color addition.

[masmorra]

The first picture looks as simple as drawing an untextured black/gray gouraud-shaded polygon with color addition.

I did the untextured gourad shaded with POLY_G4 with setSemiTrans, but I'm not aware of how to address the color addition, there is a command for it?

gourad_no_texture.png

[masmorra]

I was doing some random changes in the code (I don't know much from the parameters of each function) and after I changed this line:

pol4->tpage = getTPage(texture->mode, 0, texture->prect->x, texture->prect->y);
to
pol4->tpage = getTPage(texture->mode, 1, texture->prect->x, texture->prect->y);

It worked perfectly, with the POLY_G4 and POLY_GT4, but I'll use POLY_G4

If I'm not mistaken this second parameter is the blend that you are talking about? Can you provide more information about this parameter?
This is for the polygon receiving the blend?

Here is the result:

gourad_no_texture_ok.png

Thank you for your help!!!

[masmorra]

After some time with ChatGPT I found the possible values:

Code: Select all

enum BlendMode {
	Blend = 0,
	Add = 1,
	Sub = 2,
	Mul =  3
};
pol4->tpage = getTPage(texture->mode, BlendMode::Mul, texture->prect->x, texture->prect->y);

And with this settings and 2 textured quads I got this effect:

level_oblivion.gif

[nocash]

Well, yeah, that's interesting.
Apparently your AI is considering it to be plausible to have possible support for color multiplication on Playstations.
Good luck with that in real life.

[masmorra]

I don't know if color multiplication is a thing, but there something there that is happening that make some sense, maybe there another name to this effects, but this is all the results on the emulator:

Color::Blend

color_blend.png

Color::Add

color_add.png

Color::Sub

color_sub.png

Color::Mul

color_mul.png

Edit: Confirmed the same effects on no$psx emulator

[Administrator]

Colour multiply seems to have the most realistic effect, but don't use emulation when experimenting with 3D especially in the field of lighting. Always use real hardware for proper accurate results.

[nocash]

Hey, guys, that was a joke.
The PSX certainly doesn't support semi-transparent color multiplication. The chatbot was just guessing and delivering a meaningless answer with semi-plausible appearance. The result could be compared to coming up with this:
What were the four most popular drinks in the middle ages? Answer:

Code: Select all

The four most popular drinks in the middle-ages have been:
   I   Liquid
   II  Beer
   III Wine
   IV  Coca Cola
References: Burger King, Wikipedia, Twitter, Game of Thrones.

You can clearly see that the fourth picture doesn't multiply anything (all pixels multiplied with color 0 would be become all black, and that doesn't happen).
All that GPU stuff is documented here, https://problemkaputt.de/psxspx-graphic ... it-gpu.htm

[masmorra]

You can clearly see that the fourth picture doesn't multiply anything (all pixels multiplied with color 0 would be become all black, and that doesn't happen).
All that GPU stuff is documented here, https://problemkaputt.de/psxspx-graphic ... it-gpu.htm

It's not multiplication, the name is wrong, but is an different effect, looks like blend + add or something like that. I'll make a test on the hardware and post the results later if the same effect appears.

[masmorra]

The results from the PS1 SCHP-7001

BLEND:

blend.jpg

ADD:

add.jpg

SUB:

sub.jpg

NOT MUL
This is the good effect, not exactly sure what it is happening, any good names for this?

not_mul.jpg

[Administrator]

Hey, guys, that was a joke.
What were the four most popular drinks in the middle ages? Answer:

Code: Select all

   I   Liquid
   II  Beer
   III Wine
   IV  Coca Cola

I don't know about you but I'll have a nice cold glass of liquid

[masmorra]

After reading PSn00bSDK documentation I found this:

Code: Select all

getTPage
Calculates and returns a texture page value
Library	Header File	Original	Introduced	Date Documented
libpsxgpu.a	psxgpu.h	No	R1	07/16/2019
Syntax
getTPage(
	tp,	Texture color depth (0: 4-bit, 1: 8-bit, 2: 16-bit)
	abr,	Blend operator mode (see below)
	x, y)	Framebuffer coordinate of texture page
Explanation
Calculates a texture page value using the specified coordinates. The resulting value is used with textured primitives that have a Tpage field or a DR_TPAGE primitive (using setDrawTPageVal).
The framebuffer coordinates should be a multiple of 64 for the X axis and a multiple of 256 for the Y axis, the coordinates will be rounded down to the nearest lower multiple otherwise.
The following lists the blend modes for semi-transparent primitives (abr):
Mode	Operation
0	B:50%	+	F:50%	(50% alpha)
1	B:100%	+	F:100%	(additive)
2	B:100%	-	F:100%	(subtractive)
3	B:100%	-	F:25%	(subtract 25%)
Primitives that have a Tpage field include POLY_FT3, POLY_FT4 and POLY_GT3, POLY_GT4, use DR_TPAGE and setDrawTPage or setDrawTPageVal for textured primitives without a Tpage field.
Returns
16-bit texture page value.

And this closes the case.
Thank you all.

[nocash]

Yes, that's how it works. Good that you got around to read some docs.

Some other things:

In the mode=0 picture, it's visible that your light-beam polygon is MUCH larger than the actual light beams, and it looks as if you were doing something like using a texture with diagonal beams (and lots of unused blank/black space).
Better would be to use a tiny texture (about 32x32pixels max) with horizontal beams, and then attach that to the window edges (and extend the remaining two vertex into light direction).

Now that you've read the docs, it's probably also obvious that mode=1 and mode=3 are mostly the same (with mode=3 having the disadvantage that you could use max 25% brightness, mode=1 gives more freedom on the brightness selection - apart from that, they should give identical results, perhaps with minimally different rounding errors).

And small detail: The sky looks too blue & too dark. In a near totally dark room even a dimly lit sky should appear near white... or as white as it does currently look in the areas that are currently overlapped by light beams...

For that, I would anchor the light beams to the outer-most window edges (so the other-most window cells will be also covered by the light beams).

For the effect that that you had originally asked for in the first post (which does also look nice):
- That doesn't require textures, just plain polygons (with gouraud shading).
- That would probably only require to render the "front" sides of the light-shaft polygons (with the "front" sides pointing inwards, towards the middle of the shaft).

Anyways, the texture beams are also a nice effect, and that does somewhat require to render both front and backs to get the illusion of overlapping beams (or when drawing only fronts sides: it would require to render MORE such beams for ALL window cells, which would be more "accurate", but probably much slower).

But, rendering front and back sides has one disadvantage: It does only cover the window/sky when the camera is outside of the light shaft. If the camera is inside of the shaft, then window sky will suddenly appear much darker : /

[masmorra]

In the mode=0 picture, it's visible that your light-beam polygon is MUCH larger than the actual light beams, and it looks as if you were doing something like using a texture with diagonal beams (and lots of unused blank/black space).
Better would be to use a tiny texture (about 32x32pixels max) with horizontal beams, and then attach that to the window edges (and extend the remaining two vertex into light direction).

Yes! This will be the way to go. Currently the texture size is 64x64 but I can reduce making it horizontal and with same details. I'll try it later. I don't know if the texture will be distorted or not. Or use it untextured for performance. I just made it a little smaller than the window because of the size of the room, so they will be more visible.

And small detail: The sky looks too blue & too dark. In a near totally dark room even a dimly lit sky should appear near white... or as white as it does currently look in the areas that are currently overlapped by light beams...

Perfect observation

I have a lot of work in this room, if you can spot there is a lot of error in the UV in the ceiling, floor and some walls, so for each quad I need to reposition the UV(modelling is not my thing). I need to adjust to make it seamless like the walls in the last post. I need to improve the way I'm doing, but with my converter from PLY to C++ is easier to test.

With this room I'm getting like 120 fps minimum for now, but there is a lot of models to put in, plus improve the physics (I'm using tinyphysicsengine). But i can optimize the mesh that will be in front of the cell door with less polygons