@ethone Yes I tried. Trees are rotating, so I think setup is ok. Main problem is a huge scale. I have units set to metric [meters] and all objects in scene 1:1 scale. @mianiak Simple planes from my test. 3dsmax 2010 http://dl.dropbox.com/u/2817249/trees_croft_2010.max 2012 http://dl.dropbox.com/u/2817249/trees_croft.max One more thing. I imported trees from Josevile_section_rf2.max from ISI and I was suprised that objects in my scene were extremly small (only few cm high)
Ok, this is what I found, Your system units is set to 1 unit = 1 inch When I opened the file and adjusted the file to suit my system units 1 unit = 1 metre, the tree came out at about 8 metres wide which is normal. I exported it and the scale was all good but it was hovering in the air. Reset xform and re exported and it came out exactly as it should. Try reset xform first, if that doesn't work, the try adjusting your unit scale in max. Make sure to close the project before you change the scale and when you import it let it adjust the file to suit your system. (don't forget to make a back up first) Maybe there is a problem with scaling screen aligned quads when you use inches.
I looked into this a bit more, I knew there was something wrong but I had half forgotten about this rule. I knew you had to use 1 unit = 1m but I also knew you could use inches if you wished. You can use inches in the 'Display Unit Scale' but you must have 1 unit = 1 meter in the 'System Units Setup'. This is from the rf1 track making tutorial.
It's me again ;-) I tested billboards and chroma transparency and I noticed strange issue with trees. They look very strange from afar and I have no idea why. http://feels3.strefa.pl/sim/srpl/croft/pblc/isi/GRAB_284.JPG
This is actually expected behaviour for the chroma code we're using. In the past, chroma would be limited to on/off, even in the lower mip maps, because that's how the renderer processed chroma. That's also the reason why no one really used it in rF1 . what you're seeing is pretty much the same as using ink dots to draw/print an image. The alpha channel defines the pattern density, and it's a very effective way of fixing the one big complaint everyone had about the old on/off edges. And this is how the alpha channel for chroma textures should be used really: to make the edges look a bit more natural/soft. When you're up close, you will always see those patterns near the edges. In my case, AA reduces these, and perhaps that's something you need to check when working on these textures to find out how close you're getting to the cut-off point where it starts to display heavy patterning. I don't get any of those patterns at distance (at least not on the tracks I've tested ). Something else you need to keep in mind, is that the typical mip map generation will convert a 2x2 pixel block into 1 pixel, taking the average of the four original pixels. This means that you cannot use a cloud-style alpha channel (something that would work with alpha blending) and expect it to work with the chroma code. If the resulting average pixel's alpha value is too low, it will result in the patterning you see when the lower mips are used. I always try to keep the 255 alpha areas as large as possible. It's just something that needs to be kept in mind when working on the alpha channel. As you can imagine, trees with a lot of small gaps (pine trees at Belgium, pine tree leaf cards at Monaco) can be a bit tricky to find a good balance, because the mip map generation will always drop the alpha level when it calculates the average output pixel. This would again result in a patterned area that's larger than expected. But that's just how things work when things get compressed/resized/approximated by dots. Compare it with a cheap printer's resolution. Think of the chroma's alpha channel as an "on/off with a little bit of a soft edge" in order to get the most out of it. That's what it is, basically: the old chroma with a bit more code to fix the partykiller. I hope this explanation is helpful enough .
There seems to be a lot of confusion with the new way that ISI has implemented chroma transparency. As far as I can tell, it doesn't actually have anything to do with RGB color (as it used to), and it has everything to do with the alpha channel. So, first point of confusion: chroma transparency isn't actually 'chroma' transparency, it's just a different algorithm for alpha transparency. And the fact that there's the color picker next to the Chroma Transparency checkbox doesn't help at all. Solution: Give it a different name, and remove the color picker since it isn't doing anything. 2nd issue: The transparency seems to be nonlinear. If you take a grayscale gradient and apply that as your alpha using DX5 compression, you will notice that most of your image is transparent. The transparency seems to start (fully transparent) at about 185-ish, and end (fully opaque) at 255. Solution: Make the transparency linear (?) 3rd issue: Using different shaders renders different results. Using this so-called "Chroma Transparency" with the 'T1 Stamp Vertex Alpha Test' leads to sorting issues with DX5 textures. Solution: (Well, more of a follow-up question) How does 'T1 Stamp Vertex Alpha Test' actually differ from 'T1 Stamp Vertex'? Why would we need that second option?
ethone beat me to it, but ... did you set the vertex alpha to a non-default value? Have you set up the Screen-Aligned Quads in the exporter as described in the track technology document? Are you using a "Stamp Vertex" shader? blakboks, I remember an earlier discussion where I tried to make clear that chroma is operating on the alpha channel. When you think about it, it is actually still performing Chroma Keying, on the alpha channel, which just happens to be greyscale . For the sake of completeness, I have always used an alpha channel in rF1. I'm surprised that it worked for you, but as I said, I never even attempted to key an RGB colour. The colour would have to be unique in the texture to prevent other areas from being made transparent, and that unique colour would result in horrible edge effects in the lower mip maps. An rF2 rule of thumb would be to always use an alpha channel when dealing with transparency of any kind for best results. So yeah, technically it is still Chroma. Would the name "Lumi Transparency" fit better? I'm not sure if the colour picker is still being used. Can't say I've ever attempted to use anything other than black. I'd have to ask, but for now I'd say it's best to keep that colour box black . It makes sense for the transparency to be non-linear, because it is essentially still a chroma key, optimized to give smoother edges. If you need to use a linear/gradient alpha channel, then Alpha Blending is still the only way to go, because that's not what Chroma is made for. Like I said earlier, Chroma is still Chroma, but it does a MUCH better job around the edges than rF1 ever did. Luckily, I can't think of many materials in the real world that are not solid. See-through glass for instance. You'd still want to use Alpha Blending on that. What I mean is that Alpha Blending no longer needs to be misused the way it was in the past because Chroma couldn't offer acceptably soft edges (i.e. the big partykiller). Another rF2 rule of thumb would be that if your material doesn't require Alpha Blending, don't use it . I'm not sure if the "Alpha Test" shaders were meant to be included. We used them when we tested an intermediate chroma transparency solution which was dropped in favour of the current implementation. I can't see any use for these shaders. There are different calculations in the shader compared to the "non-Alpha Test" shader, but there's no code in the graphics engine that does exciting things with it, as far as I know. I'll report this internally .
Thank you Luc for explanation. They are very helpfull I have another question for you . I copied one plane from my billboard tree to another single object, I changed texture and "Screen-Aligned Quads" I set to "BB". Everything else is the same as my billboard tree which is working fine. Vertex numbering and triangulation is ok. Look at the video.
Yeah, that is a clipping issue for sure--although I thought we had fixed that up a while ago. Question:you said you copied one polygon and made that a new object--did you re-center the pivot point to the new object? If not the exporter MAY think the pivot is somewhere other than in the center of the tree, which could cause some odd clipping... Just taking a stab here hoping that this issue has cropped back up in the engine again...
Yes I did re-center. But video is from dev mode not from single player. Maybe it wasn't fixed in dev mode?
Right now I wouldn't worry about it. I've seen it happen on the ISI tracks as well, so it looks like the issue is indeed back.
I'm only seeing x-shaped trees in your file. The vertices are also numbered wrong in the poly I looked at. You're probably best off creating new billboard trees (http://isiforums.net/f/showthread.php/4383-Trees?p=52374&viewfull=1#post52374) rather than trying to save those older trees. You can of course still use your old textures.
If that was the case, then ALL alpha-channel transparency is "chroma" keying. If you manage your mip-maps ok, then there really isn't a problem. As with any binary alpha, you have a tradeoff between speed, sorting, and quality. If sorting worked 100% right with alpha transparency, then I imagine we'd all be using it 100% of the time. "Lumi/Luma" transparency is another beast alltogether It ends up being pretty similar to additive blending. Maybe just call it "Fast" Alpha Transparency? If I understand you correctly, you're basically saying, that the non-linearity of it is a non-issue because there's few (if any) times where you'd need that kind of accuracy? Yeah, I'll probably have to agree with this. Even if you were using a texture as a decal to add variation (and thus possibly need that accuracy), you'll probably be able to use alpha blending, since sorting won't be an issue. Indeed, the times when "chroma" or "fast" transparency will MOST often be used will be on foliage and fencing. Anything we'll need to know for those of us who might've used it (maybe I'm the only one), so we don't crash when we try to load up our scenes if ISI decides to remove it? Or will it revert back to 'default' like when we took our rF1 scenes and brought them into rF2? Thanks for the engaging discussion, Luc!
Guys i need a little help too... Nood help this is the best i can get View attachment 1923 when i create a plane in front view vertex number become View attachment 1924 what is the correct way to correcte vertex position? i tried rotate plane to put is in right position and after that triangulate like explained in track tecnology pdf. vertex properties alpha are already @ 90.... Aligned quads in BB and "pivot" @ bottom Shading, smooth and Omni what i'm missing?
