flag

[Arcturus]

I've been making animated flag and I've been disappointed that "twosided" keyword doesn't work on md5mesh. Is there no way to make a 2D plane visible from both sides?

[Domarius]

Most games don't do this. What you usually do is just duplicate the polys. If this sounds "bad" it's not, because if the game had the ability to draw two sided polys, it would be actually drawing the extra polys anyway

 

In max it's as simple as pressing W for the move tool, selecting the polys you want to duplicate, holding shift, clicking them once, this causes a clone, then with the cloned polys still selected, click "Flip" in the modifier panel to invert the polys. You need to also right click the object, properties, then check "Backface cull" to see what the game will see.

[Arcturus]

There will need to be a gap between polys to avoid the z-fighting.

[rebb]

Are you sure that it doesn't work because its an md5mesh ? Maybe something isn't right with the material definition somewhere.

 

It just seems strange that the material system should make a difference between the polygons of an md5mesh and the ones loaded from a different format

[Springheel]

There are lots of things that md5meshes don't like that are ok with regular meshes, like verts that exist in more than one place on a uvmap, or merged polys that have a angle of less than 90 degrees.

 

I've run into the problem with double-sided polys as well in md5meshes. In my case it was the hair on the werebeast, so I was able to just copy and flip it since they didn't have to line up exactly. In your case I think you'll have to just make the flag 3d.

[Crispy]

There will need to be a gap between polys to avoid the z-fighting.

Are you sure? I mean, I can see why it might happen, but I would hope that the backfacing poly would get culled completely before z-fighting ever became an issue. Might be worth testing to make sure.

 

Then again, it might be hardware/driver-dependent.

[Springheel]

Even if it worked (and I have no evidence to the contrary) you'd still get those black areas along the edge the way we used to get them on the citywatch tunic. That was essentially the same situation as this one.

[Crispy]

I could be wrong, but wasn't that due to screwed-up normals? i.e. The vertices at the bottom of the tunic were shared between both polygons (the one facing forward and the one facing back). Like taking a piece of paper and folding it in half to make a "V" shape. The vertices along the fold (the bottom of the V) are shared between both sides of the folded paper. So the normals of those vertices were some kind of freaky average which ended up pointing downwards. Thus, as the model's normals were interpolated over the surface of those polygons, they'd shade from their correct colour down to black or near-black (since there was no light coming up from the floor, vertices with normals "facing the floor" would not get lit very much).

 

If the polygons facing each way didn't share vertices (like cutting the piece of paper in half and thus separating its halves instead of leaving them joined by a crease), presumably the normals wouldn't be screwed up and everything would be OK. Which is, I thought, essentially what you did to fix the citywatch; cut the "join" between those polygons, or add a line of polygons so that the tunic doesn't taper to a point, and the black areas go away.

 

Thus, the flag would look fine as long as the two 2D planes weren't joined together in any way. I think.

 

I may be totally off-base here, this is mostly guesswork.

[Springheel]

If the polygons facing each way didn't share vertices (like cutting the piece of paper in half and thus separating its halves instead of leaving them joined by a crease), presumably the normals wouldn't be screwed up and everything would be OK.

 

I didn't think that message through very well. You're right, the problem was that exporting to a md5mesh automatically welds the verts unless they are separate meshes. If the two planes are on separate layers then that shadow problem should be avoided. Don't know about the z-fighting, but I'd be interested in seeing whether that happens or not.

[Crispy]

Ah, OK, didn't know that about the md5mesh exporter. That's definitely something to watch out for then.

 

Don't know about the z-fighting, but I'd be interested in seeing whether that happens or not.

Yeah, me too.

[Arcturus]

Yes, there's no z-fight if I put the planes on separate submeshes. By the way, does anyone know what happened to models/darkmod/props/textures/flag_pirate1.tga?

[Domarius]

Of course there's no z-fighting, there doesn't need to be a gap - the whole reason you're duplicating them is because they can't be seen from the other side it's pretty common - I've seen it done many times at work and I've even had to do it myself a few times.

[Arcturus]

There is z-fighting if polys are on the same sub-mesh (or whatever it's called). Each side needs to be separate with it's own material definition in md5mesh.

I put flag_pirate1.tga and flag_pirate1_local files some time ago. Now there's only _local and editor images. I don't see what happened in the log.

[Flanders]

All non-local tga's have been converted to dds, look here darkmod\dds\models\darkmod\props\textures.

[Arcturus]

I wasn't aware of that, thanks.

[Springheel]

There is z-fighting if polys are on the same sub-mesh (or whatever it's called). Each side needs to be separate with it's own material definition in md5mesh.

 

So you've checked from a distance away? I'm a little surprised that there isn't a problem, as I've done the same thing (cloned and flipped meshes) on regular static meshes, and there WAS z-fighting at a distance.

 

Though, now that I think of it, I probably didn't put them on different layers. Maybe that would work for static meshes as well.

[Arcturus]

Yes, it's rendered properly. But each side has to be on diffderent layer in file e.g.:

 

mesh {
 // meshes: flag
shader "flag_pirate"

 numverts 21
 vert 0 ( 0.250000 0.000003 ) 0 2
 vert 1 ( 0.000003 0.000000 ) 2 1
}

mesh {
 // meshes: flag_back
shader "flag_pirate"

 numverts 21
 vert 0 ( 0.250000 0.000003 ) 0 2
 vert 1 ( 0.000001 0.499996 ) 2 2
}

[Domarius]

I'm surprised there is z fighting in this situation. Must be something unique to the Doom 3 engine. When I model like this for games at work, the whole reason z fighting will never happen between 2 polys back to back, is because only one poly can be visible at a time, due to the very nature of the arrangement.

[Arcturus]

I put the flag on the mast in test/galleon.map. Iron rings are made using textures with alpha channel. They look good, only inaccurate shadow looks bad:

 

I wanted to use as small amount of polys as possible. I think it's ok for this type of model. What do you think?

[Springheel]

I think it looks fine. Maybe just set it to noshadows if the shadow bothers you.

[Arcturus]

I'll just leave it as is. Ambient light is usually non shadowcasting anyway.

[Arcturus]

Last month I replaced the animation of the md5.mesh flag, as the original was horrible. It's still not very realistic, for a better looking flag I suggest using this one:

I would like to add another animation and blend the two randomly for a variation.

I thought it would be easy, but I don't know how to do it.

//waving flag

model flag_pirate_01 {
    mesh        models/md5/props/flag/flag01.md5mesh
    anim idle    models/md5/props/flag/idle01.md5anim
    anim idle_01    models/md5/props/flag/idle_no_wind.md5anim
    
    {
    random_cycle_start
    }
}

entityDef atdm:flag_waving_pirate
{
    "editor_displayFolder"    "Animated Props"
    "spawnclass"            "idAnimated"
    "model"                    "flag_pirate_01"
    "start_anim"            "idle"
}

random_cycle_start does absolutely nothing.