DIF transparency material

#1 Anyone?
Anyone?

Bueller?
Bueller?

#2 Alright, all jokes aside, this is getting truely rediculous, maybe a multiple choice will help people reply.

A) It's impossible to do it on a dif
B) It's easy to do it, there's probably something simple your missing in your setup, but I don't know what.
C) As far as I can see it should work the way your doing it.
D) there's other stuff you probably need to take into account. such as: "comments"
E) I dont' care for commenting about this stuff, I just wanted to select one of the options
F) It doesn't currently work, but the 1.02 version should fix it.
G) I need more information about how you're doing X "comment", Y "comment", and Z "comment"
H) Other "comment"

*bump*

#3 H: straight out of one of our usage cases (might wana just convert that to a striaght def, if youre not planning on using it more than once)

Function translucentMaterial( %name, %dir )
{
%com = "new Material(racing_"@%name@") {"@
"baseTex[0] = " @ %name @ ";" @
"bumpTex[0] = " @ %name @ "b;" @
"specular = \"0.6 0.6 0.6 0.6\";" @
"specularPower = 16.0;" @
"cubemap = WChrome;" @
"translucent = true;" @
"translucentBlendOp = LerpAlpha;" @
"FXIndex = 5;" @
"mapTo = " @ %name @ ";" @
"};";
eval(%com);
}

translucentMaterial("glass_ramp");

also, for comparrison purposes, you can grab the png from here:

img54.imageshack.us/my.php?image=glassrampqb5.png

#4 Thanks for the reply!

Do you actually have this material working on a dif export?

If you do then there's a problem with my implementation, because using your texture and your parameters for the material doesn't work in my engine.

I have a couple of questions about the material definition that you've listed here:

Why do you have %dir in the function call, it's not used anywhere within the function.
Why do you prefix all the material names with "_racing"
What is "FXIndex" keyword, I can't see it listed anywhere

Any other suggestions as to why it's not working?

#5 Oh. sorry.
1-dir's me being lazy and not taking it out of an example I got someplace. Think it might have been in alienforces racing example?

2-racing_name sets it to ensure youre not trying to set up a material of the exact same name as the texture. used to be that'd mess things up pretty bad. not sure if thats still the case or not.

3-fx index is a per-material effects system I'm still in the process of working out. Shoulda killed that off. apologies.

And yes. We've been using this same texture definition since... backup says 03/09/07. Can't really see any differences in implementation as youve described it thusar...

#6 Thanks for your help Kirk,

As strange as it seems, if I put "Emissive = true;" in the material I can get the transparency to work. Otherwise setting transparency on the material makes it dissapear from the world entirely.

Pretty hoopy eh? Has anyone else come across this?

I'd look into this some more, but I've already spent too long on something seemingly so rediculously simple that I must move onto more important stuff if I'm ever going to make some headway.

There also seems to be a problem with it interpreting the alpha channel as either 1 or 0, not a blend of 0 to 255. As I have "alphaTest = false;", but the texture is showing either opaque or transparent even if I put a grey of 128 in the alpha

So, what I really want to do is blend two materials together by overlapping two brush faces. One brush face with a base road texture on it, and the other with a semi-transparent line texture on it (the transparent material I've been trying to get working!)

The problem is if you do this, obviously you'll get Z fighting issues because both are on the same plane. I've looked through the docs and can't find a material Z sort keyword of any kind, or a decal setting etc. I'll also have to disable the hidden face removal in constructor, otherwise it'll remove one of the overlapping faces because it doesn't understand materials yet.
So material options I need to sort out:

Z depth
Blended alpha
Alpha based shadow casting
Alpha based shadow reception

Anyone know if this is possible to do in this way?

Thanks again Kirk for your information, it's saved me alot of time and frustration.

#7 Yep is quite simple.

Just put the line texture into the second rendering pass ([1] instead of [0]) within the same material.
This will take care its rendered after the base texture.
There are most likely other ways to get multi texturing without the need of doing multi render passes ... Still trying to fully understand the system.

as well if you do it within a single material there is no z fight as only a single object exists.

#8 Trouble is that the texture mapping and offsets are different for the base texture and the line texture, so it's going to be near impossible to get the thing to look right. The point of doing it with a seperate brush with an overlapping decal is you can then overlay the lines regardles of the underlying texture mapping so the result is a more natural looking surface instead of lines only crossing at particular spots in the underlying texture, if you know what I mean?

Also take into account the extra work in setting up and cutting all the brushes so that the lines brushes are inset into the road instead of just overlapping with their own texture mapping. It seems a very time consuming way to do it.

#9 Well it looks like torque isn't up to the task without major modification and bug fixes.

incase anyone is interested, here's what I found:

transparency material doesn't work without the "emmissive = true" line, atleast on DIF
There's no Z setting for the material, so overlap brush you'd normally use for a decal setup is not possible
Shadows are cast over transparent sections
Shadows are cast FROM transparent sections
alpha is interpreted as 0 and 255, no blending, regardless of the "alphaTest = false;" setting
Backface culling? I didn't get a chance to look into, but probably doesn't exist either


This is just too much work for me to update the engine myself, this stuff imo "should just work" because it's one of the fundamental things people will need in an engine.

#10

1. The fact that the "emissive" flag makes it work is a "happy coincidence", but I think you've already figured that out.
2. You can tell a Material (or a certain pass of a material) to write to the Z buffer so other textures can be rendered on top. This is done by setting the translucentZWrite flag
3. Yes, shadows are cast over, and from transparent sections. This is a problem.
4. Have you tried setting different values in transluscentBlendOp to get better blending?

If you haven't already, you really should take a look at this TDN article

#11 Thanks for your reply Mark,

1. " Emmissive = true" So this is a confirmed bug?
2. So I'd have to put "TranslucentZWrite = true" on the base road texture?
3. Major problem, makes alot of transparent material situations just ugly and unacceptable
4. I've tried all of the transluscentBlendOp settings, none seem to make any positive difference to the effect.

I followed that TDN article to setup my material and if the "emissive = true" bug isn't going to be fixed then somebody should update it on the tdn page so others don't waste 2 days with it thinking that they've got something wrong in their textures or setup and finding out that it's just an engine bug all along.

#12 I wouldn't call the emissive flag a "bug." Emissive does what it is intended to do. Here's the brief explanation from TDN:

This flag removes any shading calculations performed on a material. It is useful for glowing objects that appear to emit light.

So, setting emissive = true appears to "solve" your problem because it is skipping shading calculations that it probably should be doing for proper transparency.

#13 No not really.
What if you have a refractive transparent surface? The only thing you got there now is a serious problem ...

#14 There were refractive, transluscent textures in the TGEA demo. Take a look in the code and see how they did it there.

#15 MY guess is that the main difference is they aren't applied to a DIF. I couldn't remember seeing any in the demo but I'll check it out. Do you mean the big sphere with the cubemap on it?

EDIT:

Ok I checked the demo out too, it has the same material setups as i do. I even went to the extent of copying the textures so I have exactly the same everything.

The translucency doesn't work still, which leads me to beleive that it won't work on a DIF in the same way that it works on a DTS.

The fact that nobody can point a finger and say "this is what you're doing wrong" or even "Try this", I'm assuming this is atleast one bug, and probably a combination of a few together.

So, trying to do something as rediculously simple as this, it's becoming clear to me that tgea is not the engine I'll need to use for my game.

It's not like I'm a noob or anthing, I've been working in programming and games specifically in one form or another since day dot and in my humble opinion, this engine is in serious need of some fixing.

#16 Honestly, you're the first person I've seen on the forums trying to apply transparency directly to a DIF. By the way, what are you trying to accomplish by this? If you're trying to make windows, nearly everyone does those by creating a DTS and placing it in the DIF. (At least as far as I know)

#17 It was often used in stairways, railings, and other details. Of course, using DTS details makes more sense, especially if you want them to be destructible. There was a patch for transparent interiors in TGE, though the lighting kit worked some strange magic with it, often causing portaling problems as well (as the DIF is still solid, but the texture is what provides the transparency).

#18 Surely quite a few people knew at some stage that transparency doesn't work on DIF, but nowhere on the forums, in the TDN or in any resources does it say anything about it.

@Mark, I use transparent faces to create a "decal" for things like road line markings, grafiti, cracks, details etc. Anywhere you'd want extra details non-aligned to the underlying material. You can't really do this with the material stages because the material has it's own uv mapping, not each stage.

I'm testing out systems primarily so I know how to construct things and how long it'll take. Now if it takes me a week to find out how transparency works, then there's a problem, because something as simple as this should take a few hours at the very most. At this rate I'll get my game done sometime next millennium.

The engine needs a heap of bug fixing and updates AND documentation needs to be updated substantially so rediculous situations like this don't hapen.

There's no status information available on systems. It seems you are expected to dive in and spend months or years trying to determine that for yourself, which is obviously unacceptable.

EDIT: I updated the Translucency TDN page so others don't waste time like I did.