11-01-13, 16:44 | #71 |
Moderator
Joined: Jul 2003
Posts: 33,359
|
I just noticed something in my level which uses TRNG, unpatched.
I made a glass object in a static slot. The textures are applied as "opaque" and in the editor I gave the object OCB 8 to make it "glass stransparent". Right behind the window is a spidersweb which was textured with "semi-tranparent" setting. No OCB has been applied to the placed object. When I look at the spidersweb through the window, parts of the spidersweb disappear. I checked and this has nothing to do with bent faces because all faces of the spidersweb have been triangulated. I don't know if this is of any relevance to you but I thought I'd mention it. Last edited by Titak; 11-01-13 at 17:19. |
11-01-13, 17:05 | #72 |
Member
Joined: Apr 2008
Posts: 368
|
^Titak, I've noticed the same thing as you describe when using TRNG glass transparency. There are limits.
Using the new patch by Lwmte I found that 2 "invert and multiply" transparent faces work perfectly, I can see opaque background faces beyond the 2nd transparent face. However, if I add a 3rd transparent face, then at some angles, triangles in the 3rd transparent face disappear. These limits are probably necessary so that frame rate doesn't suffer. |
11-01-13, 17:08 | #73 |
Member
Joined: Feb 2006
Posts: 536
|
@Titak, The blend modes work similar to layer blending in Photoshop. Some layers get simply "eaten" by the over or under laying layer.
For example if the object with the opacity 10 (0A) is in front of an object with the usual transparency we all know and adore, then the usual transparency "eats" the parts of the object which is in front of it, however illogical it may seem. @meta2tr The problem with slow animating textures, if not possible to fix the usual way, may be circumvented by two flipeffects. One when you enter a room with new transparency faces, (to enable the new transparency mode) and another one to restore default setting which you trigger when leaving the room and entering the one with animating textures. Of course, then you can not have both in one room. By the way, why don't you release your beta version regardless of this problem with anim textures for testing and when all bugs are reported & fixed, then release the stable version for a broader audience? Last edited by HeinzFritz; 11-01-13 at 17:23. |
11-01-13, 17:22 | #74 |
Moderator
Joined: Jul 2003
Posts: 33,359
|
|
11-01-13, 17:43 | #75 | ||
Member
Joined: Apr 2008
Posts: 368
|
Quote:
Quote:
That is my plan, because this is indeed wonderful stuff to play around with. I now have a second object to create, and when that is done I will release everything. |
||
11-01-13, 22:39 | #76 | |||
Member
Joined: Aug 2010
Posts: 1,810
|
Sorry, I have lot of things to do, can't answer to everyone right now! Just another thing I have found out regarding fog bugs with translucent faces.
It seems that TR4 engine can't properly render translucent faces in combination with fog. It affects not only new blending modes, but also classic "add" blending mode. Core programmers did a bypass for translucent faces, so they are not affected by fog, perhaps it was too difficult for them to do it properly. When it's OK for sprites, on room faces it looks very awkward: I think I will leave this behaviour as it is for a moment. Maybe later I will fix this bug. Quote:
It's a pity that this subtype can't render anything translucent behind itself, I think that it is not applicable for room geometry because of this behaviour, and also it's very complicated and fuzzy in code (seems like Core programmers used global variable for alpha value), so I doubt that it can be changed. In simple words, no subtype 7 for room geometry, sorry! Quote:
Quote:
Also, with this version we don't need two seperate subtypes for shadows/black smoke and black room faces, so I only left type 5 for shadows, 8 was replaced with funny "intensity=inversion" blend type, check it out! It may come in handy when creating something like X-Ray vision effects or so. Moreover, latest version fixes corrupted explosion smoke puffs that Heinz pointed to. It happened because certain particles in TR4 engine still refer to missing blending types (which were available in PSX), and by enabling extra blending modes all this hell broke loose... Last edited by Lwmte; 11-01-13 at 23:02. |
|||
11-01-13, 23:23 | #77 |
Member
Joined: Feb 2006
Posts: 536
|
Ensi, I just read your comment, but still did not try out your corrected .drc. But if I understood right, you removed the transparency type 08 and exchanged it for another blend type. I will, of course, try it out later, but from my point of view, the transparency type 08 was elegant and very usable. On the other hand you have left the type 07 which does nothing (or I have not realized what it does actually). Why, if you wanted to add another transparency sub type, did you not replace sub type 07 instead of 08?
Anyway, this whole transparency action is the most exciting breakthrough in years. Keep up the good work! |
11-01-13, 23:48 | #78 |
Member
Joined: Mar 2009
Posts: 1,502
|
I'm really amazed by your works! If these new features work fine, we will be able to create new effects and some stuff (I have in mind)
I'm looking forward this. Thank you already for your great work |
12-01-13, 00:23 | #79 | |
Member
Joined: Apr 2008
Posts: 368
|
Quote:
Edit: the "Invert and multiply" mode (it was mode 10) seems to have gone? Last edited by meta2tr; 12-01-13 at 00:57. |
|
12-01-13, 00:23 | #80 |
Member
Joined: Aug 2010
Posts: 1,810
|
@Heinz: OK, sorry, I haven't made this clear enough. It goes like this.
Classic, unmodified TR4 engine, for both PlayStation and PC, uses 8 rendering subtypes (0 to 7) for transparent faces. Here is the full description of them: 0 - Opaque: Used for bars. I haven't yet encountered another references to it in executable. Note that this subtype IS NOT the same as standard opaque texture type, despite the same index. 1 - Transparent: "Solid" transparency only, specified by magenta colour. 2 - Translucent: Classic translucent face, additive operation. 3 - [broken]: Has to be translucent face with inversion operation (darkness). Was workable on PSX, but on PC it produces the same result as subtype 1. Still, it is used for shadow and fadein/fadeout effect, maybe for something else too. 4 - Font & skybox: Bypasses Z test, so either it will be rendered above or behind anything else. 5 - [unused]: Rendering code for this subtype is missing. I suppose it also was used somewhere in PSX version, but in PC version it simply gets ignored. 6 - Wireframe: Says for itself. 7 - "Forced" alpha: Most complicated one. It's standard opaque face with alpha (translucency) value that is taken from global variable. It works like this: if you send opaque/transparent face to renderer with global alpha variable set to 255 (opaque), it will be treated as subtype 1. But if you will simultaneously set global alpha variable to something else, face type will be converted to 7 and transparency will be calculated with global alpha variable treated as second argument. So what I did is re-used type 5 for new "inversion aka darkness" blending mode. I had some problems with shadow rendering beforehand, so I set 5 for shadows and 10 for anything else, but this bug is now (at least I hope so) fixed. @meta2tr: I'm a bit confused about naming blending modes, you should know it better! Old shadow effect still exists as subtype 5. Last edited by Lwmte; 12-01-13 at 01:09. |
Thread Tools | |
|
|