bump

I was wrong again.

It's either the TGA, or WED/MED.

That previous statement I made about the sprites of the TGA showing up okay in WED was wrong. Upon closer examination at different angles, they were messed up too:


You can clearly see the back image showing through the front image.

I tried this both with and without the wiki's vegetation script. And that texture is a 32-bit non-RLE tga.

So I don't believe it's my model, after all. And from what I can tell, the tga itself is okay. I even used Grimber's before, with the same problem resulting.

So, the only thing I am left with is that it is WED/MED, namely, the "preview" window as opposed to the actual loaded level. Is it possible that tga sorting does not show up correctly in preview mode, but will in "load level" mode? Could someone else test this to see if it works? I would, but my level script file does not load my level properly yet; truth be told, my level has a lot of models and entities and architecture, and I wasn't planning on tackling scripts yet until this tree tga problem came up, so I am unable to see if the sorting issue exists or not in full level load mode without a working level script.

Thanks in advance to anyone who can confirm or deny my theory with testing.

bump?

I just noticed this issue is fairly common on the board. here are other threads about it:

http://www.coniserver.net/ubbthreads/sho...true#Post621138

http://www.coniserver.net/ubbthreads/sho...true#Post624919

And it looks like from those threads that the tga alpha issue is persistent, and not just in 3DGS.

So I don't feel so bad now that this isn't working 100% for me, but if anyoen can still offer a viable solution that won't eat up a ton of my time, I'd be ecstatic.

Does JCL have any comment on the tga issue? Any possible forthcoming fixes/tweaks?

Or Doug?

Or anyone?

Well heck, here's Conitec's answer, which I only found, ironically, after Googling!

Q. I have problems with the sorting of transparent or TGA images. For instance, I'm trying to make a tree by crossing two sprite like a 'X. When using TGA sprites, the first sprite always draw before the second sprite. This doesn't happen when I use PCX or BMP sprites.
A. Transparent objects can not write into the z buffer, and thus are simply sorted according to the distance of their origins. This does look wrong when they overlap or are close - when you think over it, it's logically. You just have to make your 'X' from 4 separate sprites when using transparent textures.

So it's sorting according to the average distance away of that particular chunk of the model, as opposed to the relative distance away of one piece to another.

So, according to this, if you have an "X", and the corners are 1,2,3 & 4 from top left, clockwise:

1 2
X
4 3

and you are at "1" corner of the X, then the far side of that same line of the "X", "3", will render before "2" or "4", even if they are closer to you than "3".

This seems odd. Is there no way to fix this? The "improved overlay" code in the wiki doesn't appear to do the job. And if there isn't a way to fix this, can anyone suggest a quick and easy way to break up a complex model (like a tree) into chunks, and still retain the skin mapping?

I also just found this:

Transparency

Entities can be made transparent by setting their transparent or flare flag, or by using TGA images with alpha channels for sprites or skins. A logical consequence of a transparent object is that you can see other objects behind it. This sounds trivial, but has some consequences for rendering. Transparent polygons do not write into the 3D card's Z buffer and thus do not hide other polygons or parts of the same object behind them .Therefore if you intersect transparent sprites, you can see sorting errors on the screen - and the same happens with intersecting or overlapping triangles of transparent models. This is normally hardly noticeable, but if you see it, be aware that this is not a bug - it's a consequence of the z buffer algorithm used by all today's 3D cards for depth sorting.

The easy solution is normally to split your transparent entity into several entities that are then individually depth sorted. Depending on the type of the game, setting the d3d_entsort variable at 2 can also solve sorting problems.

Can anyone shed soem light on this d3d_entsort variable and how to set it?

i did not read the whole topic, sorry. it was too long. i guess your problem is the alpha sorting, right? you tried the improved overlay from the wiki, and it did not work. did you try

Code:

---

material alpha_sort{
effect="
texture entSkin1;
pass p0 {
texture[0]=<entSkin1>;
zWriteEnable=true;
alphaBlendEnable=true;
}";
}

action alphaTree{
my.material=alpha_sort;
}

---

assign the action to your tree.
for a test tree, visit loopix´ site (just go to his profile and click his hp link). his trees do definitely work with the script.

ah, and btw: what happens if you delete all unnecessary template scripts from the <include> lines at the very top of your script? i one had a problem with shaders, and after deleting them, everything worked fine.

1. export from treemagik as *.x
2. import into MED
3. Export skin as a TGA or BMP
4. open up with photoshop or Gimp
5. in photoshop open color channel window and add an extra alpha channel
6. copy original picture on the layer and makeit alpha by changing brightness/contrast (white = visible, grey = transparent, black = invisible)
7. save image as 32-bit TGA image
8. Import/replace new TGA image with old one in MED
9. Save file
10. Import model into WED
11. Add action vegetation rought properties dialog (wiki's one)

works for me
but, hey listen, is that treemagik a freeware? can i make good looking models and export them as obj, 3ds or whatever? i really dont want to pay for anoter tree modeler, just looking for alternatives. I am currently using xfrog, but as Grimber said, yes it takes alot of fps. But, everyone learns from mistakes!