Real Translucency Anyone?

[Serpentine]

rebb

 

Looks exactly how I would expect it should - since this seems to work, rich wanna give it a shot with the foliage example?

[rich_is_bored]

Fair enough. I'll incorporate this into the material shaders I produce.

[Serpentine]

Fair enough. I'll incorporate this into the material shaders I produce.

 

I just want to know it's working for this use, then I'll happily go and make the necessary changes skins+materials to the current TDM foliage

 

Only reason I cant check is that I'm playing with the 3d features in photoshit at the moment, which completely maxes out system mem and doesnt allow me to save other work that I opened along side like a tard (That said, some of the new textures look really awesome with a displaced mesh(1mil tri)+diffuse+normal)

[rich_is_bored]

Yes it does work. I've tested it here and the results are virtually identical.

[aidakeeley]

Excellent work, Rich, Rebb, all you guys...

[nbohr1more]

This is great!

 

Going from:

 

1) Not possible.

 

to

 

2) Possible! ...but lots of custom Asset creation.

 

to

 

3) Possible and practically automatic.

 

Rich, rebb, OrbWeaver, and Serpentine all deserve kudos for their part in the investigation!

 

And Tels gets credit for this tangent on foliage decals!

 

Great work all!

[Springheel]

So what exactly needs to be added to the material shader for this to work? I'm working on the werebeast textures right now and it might work well for the hair.

[HappyCheeze]

Wow,

 

thats beautiful.

[rich_is_bored]

This is as simplified as I can make it...

 

translucent/example
{

// one set comprised of a normal map and diffuse map utilizing the vertexcolor keyword

{
	blend	bumpmap
	map	normalmap.tga
	vertexcolor
}
{
	blend	diffusemap
	map	diffusemap.tga
	vertexcolor
}

// a second set using the same images with the inversevertexcolor keyword

// the scale function here is "inverting" the normal map so that it catches light from the opposite side.

{
	blend	bumpmap
	map	scale(normalmap.tga, 1, 1, 0, 1)
	inversevertexcolor
}
{
	blend	diffusemap
	map	diffusemap.tga
	inversevertexcolor
}
}

 

You'll have a couple additional stages in practice because of the way you guys are handling ambient light but I hope this conveys the idea.

 

My only concern is I don't know if the MD5mesh format supports vertex colors. It doesn't look like it does...

 

http://www.modwiki.net/wiki/MD5MESH_%28file_format%29

[Baddcog]

hmm, be a bummer if vert clors aren't useable, was planning on using them for a mesh I'm finishing up. Would make more skins available easily.

 

-----

What does this mean on the wiki page you linked then?:

 

 

Flags

Note: Enemy Territory: Quake Wars only: This type of ordered list only exists in ET:QW.The ordered list should be defined even when empty. Each line may specify one of the following known flags:

 

 

noAnimate

vertexColor

----------

 

 

It shows vertcolor and this is under md5.mesh, and it appears that what it means is 'the ordered list' is a quake wars thing, not the vertex color specifically.

[Springheel]

My only concern is I don't know if the MD5mesh format supports vertex colors.

 

Yeah, it just shows up as black. Too bad.

[Fidcal]

I'm trying this with some old sacking curtains but can't get it to work. I get total black texture in-game but there is no error in the console that I can see. The sacking shows in DR so it's not a typo in the map. Can someone check my material to see if I've made a blunder please?

 

textures/manor_royale/fabric/translucent2/cloth_coarse
{
qer_editorimage	models/md5/chars/guards/proguard/old_cloth_ed
surftype15
description "cloth"

       // one set comprised of a normal map and diffuse map utilizing the vertexcolor keyword

       {
               blend   bumpmap
               map     models/md5/chars/guards/proguard/old_cloth_local
               vertexcolor
       }
       {
               blend   diffusemap
               map     models/md5/chars/guards/old_cloth
               vertexcolor
       }

       // a second set using the same images with the inversevertexcolor keyword

       // the scale function here is "inverting" the normal map so that it catches light from the opposite side.

       {
               blend   bumpmap
               map     scale(models/md5/chars/guards/proguard/old_cloth_local, 1, 1, 0, 1)
               inversevertexcolor
       }
       {
               blend   diffusemap
               map     models/md5/chars/guards/old_cloth
               inversevertexcolor
       }
}

[nbohr1more]

I thought that this would only work with models because you have to set the Vertex Color to 50% (cant be done to Brush work)?

 

Vertex colour. Models can provide vertex colours which are multiplied with the model texture to introduce low-frequency colour variation over the model surface. Brushes and patches do not support vertex colours.

 

Yep.

 

http://www.modwiki.n...dels_vs_brushes

 

(this is presuming that your curtain design is similar to your table-cloth in the other thread)

Edited August 31, 2010 by nbohr1more

[Fidcal]

Ah of course. Thanks. I'll maybe try converting them to models - they are simpler than the tablecloth so should be no problem.

[jdude]

How does this react to noshadow sources?

[Fidcal]

The model texture shows OK but no translucency. I wonder if this is because I have two patches back to back, one inverted matrix. It was the only way to get the shadows working correctly. A two sided texture just gave the venetian blind shadow. How does foliage deal with that? noshadow? Mmm... maybe it's different for models and a two-sided texture would work? But that makes no sense. Texture is texture.

 

 

 

Here's an old picture I just found showing the single patch 2-sided texture with the bad shadow.

 

[rich_is_bored]

You're using the same diffuse map in both stages. In the inversevertex color set, you need to paint a new diffusemap that looks like it's being backlit.

 

Think of it this way, you're using an image editing program. You have two layers and your erasing parts of the first layer. If the second layer is identical, you won't see any difference.

[Fidcal]

Yeah I wasn't studying this enough - just looked at that material and tried it on impulse. I need to also vertex paint the model in Blender.

[Nosslak]

Thread necromancy! Heck yeah!

 

Rich, I want to implement translucency for my trees but I'm not sure how a backlit leaf texture would look like so could you upload yours? Also does this work without the twosided keyword in the material (I want to just duplicate and invert normals in my 3D program)?

[Serpentine]

Also does this work without the twosided keyword in the material (I want to just duplicate and invert normals in my 3D program)?

That's actually the best way for this

 

Did Blender's export get it's normal export problems fixed? Might run into issues with that, and since you cant merge the vertices, hmmmm

[rich_is_bored]

@Nosslak:

 

Example TGAs are here...

 

http://min.us/mvfedmr

 

It's not hard to paint the back lit diffuse. You just take the existing diffuse and paint over it so it looks like a light is behind it like this...

 

http://robertgilbert...eaves-140469098

 

@Serpentine:

 

You wouldn't want to merge the vertices when manually producing a twosided surface as you want a clear seam between the back and front faces.

[Nosslak]

Did Blender's export get it's normal export problems fixed? Might run into issues with that, and since you cant merge the vertices, hmmmm

I think the problem actually was in Xnormals generated normalmaps and not in Blender, but I'm not sure if my normalmaps are correct so I should probably go take a look at that. I don't really understand why I'd want to merge the vertices either?

 

@Nosslak:

 

Example TGAs are here...

 

http://min.us/mvfedmr

 

It's not hard to paint the back lit diffuse. You just take the existing diffuse and paint over it so it looks like a light is behind it like this...

 

http://robertgilbert...eaves-140469098

Thanks! I'll try it out after I've successfully imported the tree as a regular object. Also should I offset (move) the faces at all (it looked like they were in your video)?

 

Is this more performance heavy than just the ordinary lighting method? I would assume so, but I'm not sure, because then I probably should turn it off for the LOD-versions. Is it enough to turn it off by just changing to a mesh without vertex colors?

[Serpentine]

I think the problem actually was in Xnormals generated normalmaps and not in Blender, but I'm not sure if my normalmaps are correct so I should probably go take a look at that. I don't really understand why I'd want to merge the vertices either?

 

You don't, but the blender exporter somehow mangles the vertex normals, as such the easiest way to avoid letting it use the broken vertex normals is to merge them all. If the vertices are all merged then doom3 just recalculates them, the down side is that you cant make sharp corners and you might get shading issues on polygons using shared vertices. If the exporter is working correctly then the vertices will have valid normals, and as such there's no reason to really merge them (tho, for the sake of simplicity it's often easier to merge non-edge clusters, since they most likely are not being manually oriented).

 

But umm, I'd just carry on the way you are now, if you're getting good bakes and the surfaces dont show up black in game, then this is not a problem

 

@Serpentine:

You wouldn't want to merge the vertices when manually producing a twosided surface as you want a clear seam between the back and front faces.

Yup, that's what I meant with not being able to merge them

[rich_is_bored]

No foliage is moving in my video. I guess you're talking about this...

 

 

And yes this translucency trick is slightly more taxing than a standard material. When you start on lower LOD versions I would recommend that you use a different material just to be certain it doesn't render two passes.

[Nosslak]

Nah, I meant this:

If you look right there at 0:20 the planes are a bit offset, they are still very close but they are offset a tiny bit, which makes it possible to see a thin black outline in places. Is this needed or can I just duplicate my planes and flip their normals (without moving them)?