Why do the standard trees in FU3 have chinooks (crosses) above them? On the weekend, someone asked me how I got rid of it in my trees because FU3 trees and Rob's tree still have them. I said I didn't know. I went and looked. Sure enough, every FU3 tree has them, mine don't.Beats me. I did make sure that there was a continuous strip of transparency at the top of each image but some of the FU3 trees 'stop' way below the 'chinook' so I don't think that's it. Just thought I'd ask. I also noted that the bus (and some cars) have 'ground effect' lines along each side but my Ducati 996 doesn't!Maybe they were just in too much of a hurry...Jon Point*************************([email protected])*************************

Hi Jon,Remembering back awhile, I think it was either Markus or Capt Bazzathat answered this one; something to do with a 'transparent polygon intersection', I get the impression that the trees are all the same polygons, but with different texture allocations?Anyway, that's what it was/is, :-wavePete

I don't understand the answer - it seems to just describe what's happpening. Yes, Jon and I are both using transparent polygons which intersect, both of us are using double sided graphics, same texture on each polygon. In addition I have bulked out my tree by adding a tetrahedral arrangement of triangles apexed to the same top point, but I don't think that's relevant because the default trees are just two rectangles and clearly show the Chinook effect. I was careful to clear the space above the tree to the transparency colour (zero), and was most disappointed when the lines appeared. Is it possible to find what Bazza or Marcus said - did they have an answer? Jon uses a different method to me - I repalettise after making, he imports his source image directly into the correct pallet then applies transparency (I believe). So possibly the problem is that when I convert the image to a GIF image, some blurring is ocurring at the top of the image, and the solid black RGB='000' in the original is being blurred a little. The way to solve this would be to repaint in transparency after conversion to a GIF, not before. I will try this tonight and see if the problem goes away. If we understand the problem, possibly the original MIPS could also get repainted correctly.

Hmmmm!I do what I do, based on trying to achieve transparency. You see, when I first started this (and we didn't understand the transparency thing), I created all my image textures as GIFs with transparency, using 0,0,0 RGB as my transparent 'colour'. When I made the models, the transparent bits were still black! Fixmip fixed this by allowing me to see the texture before conversion. It seems Corel had inverted the entire palette, making colour 0 to 255 etc. I re-saved the palette, re-inverted it and voila!As Rob said, I re-palettise directly in Corel before exporting the GIF. I do this because it gives a less blurred image. Long before I learned that MAKEMIP blurred images, I found this to be the best way to palettise aircraft textures. See the difference between my first DC3-232 livery and the latest V1.20. In the 232 I did everything at 24bit and used PSP to convert the palette. The result was blurry and uneven dithering. I think Corel's 'colour engine' is much better (it costs much more!). When I tried doing the rivets and lines with PSP, the aircraft became one giant moire pattern :-(As much as Fixmip is a handy program, I simply get better results when I pre-palettise before converting. That said, I have noticed that the palette is 'lumpy' at the black end. The slightest brightness or contrast shift easily 'pushes' the transparent background up one notch to a blue-grey! Really annoying with my new hot-mix carpark! The grease stains (!) were coming up tranparent and I had grass growing under the cars :-hahJon Point*************************([email protected])*************************

I don't remember seeing the crosses above the trees on my Voodoo3 card. I only noticed them after I switched to a G400. It would be interesting to find out how to stop them from appearing and if it's really affected by the graphics card.Peter http://bfu.avsim.net/sigpics/PeterR.gifBFU Forums Moderator[table border=2 cellpadding=0 cellspacing=1][tr][td][table border=0 cellpadding=8 cellspacing=0][tr][td bgcolor=#540000]http://bfu.avsim.net/sigpics/logo75.gif[/td][td align="center" bgcolor=#FFFFF6]Bush Flying Unlimited"At home in the wild"Looking for adventure? Come join us! * [link:bfu.avsim.net|Web Site] * [link:www.cafepress.com/bfu,bfu2,bfu3,bfu4|BFU Store] * [link:bfu.avsim.net/join.htm]Join!][/td][/tr][/table][/td][/tr][/table

It is possibly a video issue.I use an Nvidia card (my 3rd) and all of them have done it. So did my SIS620. Much the same as FSAA causes some funnies with the Geforce cards (cockpit lines, sky banding etc), I wonder if it is happening here. BTW, the reason for the lines is actually because the FSAA on Nvidias is actually better (of course, the sky banding is a side effect, is not very good and is caused by a DirectX incompatibility)! Sorry, no fights here :-) The cockpit line problem is exactly what it should have done. If you get the line you will notice it is as sharp as a knife, no frigglies. The problem occurs because there was NO overlap between rectangles in the cockpit view. Some cards simply 'wipe' small details out in FSAA, hence why some cards don't show Chinooks. They also miss out on a lot of other detail. I remember Chris' comments on FSAA and anisotropy vs. blurring. I think part of his problem was that the Nvidia card actually showed where the clear and 'blurry' areas meet in FU3 (this is a function of FU3's engine). Before that, it was probably ALL blurry :-hahBear in mind that, when FU3 was developed, it was probably assumed that the engine would be patched later for updated drivers. I'd really love to see what you could do now with decent FSAA, anisotropy, DX8 compatibility etc. We all know, it have would reflections and lots of other cute things :-)Jon Point*************************([email protected])*************************

It would seem like a good idea to replace the default chinook trees with a Jon Point version. How about choosing one of your trees that looks about right, rename it to overwrite the original and get rid of the propeller?best regards,Hans Petter

I actually already have suitable replacements for ntree1 though 5. I use them on my system. 2 of them are included in my 'need for trees' package - jtree3b&c. I will upload these as a set if you would like.I don't know if this will work well though - the originals have embedded textures, mine use a MIP file - does FLED know the difference? I call them 'ftree1' through 'ftree5' on my system because when I deleted the originals, I kept on getting error messages in FLED when opening it. Funny though, I can delete other models and they just don't appear - I get no error messages. I just realised - the errors probably relate to existing FU3 scenery, not add-on packages. Any ideas?Finally, off subject - I just upgraded my FBO from 'small uncontrolled' to 'small controlled' and gave Unicom the airport name sound of 122.70. Well, the radio works and AI came alive but I've lost ALL lighting on the runway. All the model lights work, just the taxiway/runway/reil. GRRRRR :-madJon Point*************************([email protected])*************************

I think I have a technical answer. Its nothing to do with MAKEMIPor FIXMIP or Corel at all - I think its BSP. I'll explain my reasoning.1) when I apply a texture to a rectangle, I give it the co-ordinates of the texture corners. For the whole texture this will be (0,0) - (1,0) - (0,1) - (1,1)(Split into two triangles of course). When I made the tree, I triedto avoid the Chinook effect by dropping the 1's in the Y-direction to 0.98, as follows: (0,0) - (1,0) - (0,0.98) - (1,0.98)and was disappointed with the results - the rotors still appeared.But I ran some more tests last night, and had the thought that the bits at the top were probably the trunk of the tree, i.e. the texture is wrapping back to the top. So I changed the 0's as well: (0,0.01) - (1,0.01) - (0,0.98) - (1,0.98)and voila (as they say in Sydney) the rotors disappeared. So the program BSP mismaps by a little - this is a BUG.Since this happens in the Y-direction, it probably also happens in the X-direction. I will be looking for this. But the solution is not to use 0 as the minimum Y mapping. From what I have seen of outputs of PSP and other commercial programs, they do this adjustment automatically (i have some examples from the net), not using the extreme limits 0 or 1. So my tree is now bug free, and I will upload it with my next major set of objects.It would be possible to fix the default trees, but would take some time - I know Jim and John can both do this already (by extracting the ".e" files, remapping, then replacing in MODELMIP.TAG) but I doubt its worth it. Just for future models, we should avoid it.I hope this makes sense and welcome discussion on this.Kind regards to all,Robert D.

That totally makes sense Robert. Bravo!Peter http://bfu.avsim.net/sigpics/PeterR.gifBFU Forums Moderator

Yes, but...I use 0,0 and 1,0 - and don't get chinooks. There may be more in this. I don't use 'your' bsp.exe file, I use another one that came with the JAS tools. The reason is that I had trouble 'bsp-ing' large 'e' files. Of course, now I've realised that I don't want BIG models due to framerates anyway. I just wonder whether the different bsp.exe files do different things?Oh well, while I'm not getting chinooks, I'll leave things alone :-hahJon Point*************************([email protected])*************************

Glad you guys got that one figured out,this 3d modelling stuff is way too complicated already!!Re the FBO, you will need to assign it either a 'radio name' from the list provided or make sure that the radio freq you used (or the radio freq as a callsign) is not in use anywhere else in your total FU3 world, that will allow the lights to be activated by the 'q' button on keyboard. Its one of the 'bugs' with FU3 world, it gets confused when 2 or more airports with the same radio freq, use the radio freq as callsign.Capt Rolo did a list of what freq's had been used where,Seattle,San-Fran and outer, you should find it in avsim library :-):-wavePete

Pete,Yep! It was the 122.70 frequency. I set the airport name to 'ground' anyway. I deleted the radio settings all together and the lights came back. Gotta chase that frequency info. I have deleted a few small, fictional airports but they weren't controlled so I didn't gain any frequencies. I'll keep on looking.BTW, not happy with the bikes - too many polygons and they don't lean in turns. May have to settle for the 2D version - it looks fine at a distance and moves OK. Too many polygons and the moving models kinda 'hop' from one point to the next :-( As I wanted the bikes to be overtaking everything in sight (50m/s in the suburbs - 180km/h!), this would not do.Happy holidays :-hahJon Point*************************([email protected])*************************